Just some clothes from Daz, imported in Blender, quickly reweighed and parented to the TK17 armature, then sent to Unreal via fbx file format.

Last year I did some tests with clothes, so I picked some Christmas clothes to cheer up a bit.

What means for you clothes as Unreal content?

Once you import any mesh in Unreal editor it becomes an asset(content).

What means for you clothes as Unreal content? -> Something that you don't import by yourself. With other game engine I know (unity and godot engine mainly) their is tons of stuff that you can download and use for prototyping your game.

Same is for Unreal, but usually all Unreal content comes wired with the UE4 or UE5 skeleton. 

Any custom body even if wired to UE5 skeleton will not work with regular clothes as they will probably clip. If the clothes are physics enabled then it might work, but still might need tuning.

Bodies wired with UE5 skeleton should support all store animations out of the box, sometimes with minor modifications/editing but those have a price, like not usually free.

However, it depends on what animation you have in mind. Unreal store/marketplace has a ton of animations but related to games in general, like walking, running, jumping, using weapons, etc.

But even if you have a different skeleton, it is possible to make a retargeting rig, and it will convert animations from Unreal (or Mixamo for example) to whatever skeleton you want. It is one extra step but is proved to work very nice during the conversion.

I still need to settle to the skeleton I will push forward with and I think the most valuable one would be the Daz skeleton with some modifications because it will allow to use Daz animations - including XXX animations, work almost out of the box with the daz bodies and jcm morphs while still being pretty much similar to UE4/5 armature, allowing retargeting for other animations.

But whatever armature I pick, Blender must be used as a pit stop for every moder out there, because you need to support some important bones like children for the breast bones and the butt bones.

nullIt is possible to access all vertices in the body at runtime but it doesn't look efficient to me. There is a substantial hit in the frames, on my machine it drops the PIE fps rate under 20.

Of course, there is no reasonable purpose to do such a thing on all vertices, but accessing some vertices only it might be desirable.

At first I thought that the issue was because the body was over 70k vertices, but no... found another issue with my exporter LODs, because my body had actually the 19k vertices.

Hi, maybe it's a dump question (I'm some kind of benevolent ignorant in 3D rendering), but what is the use to access to a series of vertices at runtime? To me runtime in a game like TK17 is when you have load a room some models and by example you play a pose, so you have to move skeletons and all geometry/vertices with it and apply some textures, etc. So access directly to vertices is for accurate body or clothes deformations by example?

In unreal there is the editor, the PIE and the pure runtime which is when you run the game in a baked/cooked form just like for users/gamers. Unlike the editor mode, in runtime the API has some nasty limitations.

The purpose to access vertices or maybe faces at runtime is various, you could want to parent something to a specific vertex, let's say maybe a piercing to be locked to a vertex (which might have another solution, just saying) or maybe you want to quickly check which vertices responds to a morph. Also knowing their index and accessing vertices directly by their index could help with moving that vertex in the 3d space like fixing an intersection with clothes for example.

Hi, maybe it's to soon, and you don't have the visibility on that, but one thing that's not practical in TK17 is, by example you have 2 good solo poses and you think to a scene with 3 models and you just need that 2 models use the 1st poses at one place in the room and the 3rd use the second pose, to do that you have to make a 3 persons poses where you just load the 2 solo poses on the right models then place them where you want. And in vX if you want this poses but with models 1, 3 and 4 you have to return in pose editor make a 4 persons pose, load the solo poses, etc again. So I was wondering if with Unreal Engine it should be easy or not to have that kind of flexibilty: just tell to the game plays this solo with the 1st model and place it here and play the same pose with the 3rd model and place it in another area of the room and all that without to need to create a specific pose for this?

I hope I'm clear and you understand what I mean (because in my head it's very clear, but in text, I'm not sure...)

Still no progress in the Pose Editor part, so can't say how hard or easy this would be. 

What I can say is that in Unreal the pose editor is truly advanced, comparing TK17 to Unreal Editor/Sequencer is like comparing Microsoft Movie Maker to Adobe Premiere.

Not sure if I got right your question, but I dont think that it will be easier in Unreal to make what you want (as an amount of work). What you could do in Unreal would be to have the poses separated as animations and in timeline you would just swap actors or move the tracks as a whole or only a portion of it maybe directly to a different actor.

Unreal makes things easy, logical, you get some nice explanations why and how something works, but you still need to learn that and get the hang of it.

So far I've been talking only about Unreal Editor/Sequencer which is not a game but a game engine editor, it comes with its own licensing (for developers, is free to use) but is not for the masses.

Unreal Engine can do impressive stuff like below, but again, this is Unreal Editor/Sequencer, is not the game I'm working on. This is still something I need to figure out, but I'm not excluding the fact that the game will be one thing but in order to make good poses and animations then people will need to use the Unreal Sequencer/Editor if they want full freedom.

I will first try to bridge the gaps and provide all low hanging fruits features, models, basic animations, etc. If people want more, then they can use everything I will provide as the base and continue from there to make their poses/animations, mods, etc.

On 1/27/2024 at 9:18 AM, hfg2 said:

What you could do in Unreal would be to have the poses separated as animations and in timeline you would just swap actors or move the tracks as a whole or only a portion of it maybe directly to a different actor.

Yes, it's exactly what I wanted to say, but preferably without to have to use the Unreal Editor/Sequencer but if it's the simple and headache-proof way to make, so let's do it with the unreal editor.

On 1/27/2024 at 9:18 AM, hfg2 said:

I will first try to bridge the gaps and provide all low hanging fruits features, models, basic animations, etc. If people want more, then they can use everything I will provide as the base and continue from there to make their poses/animations, mods, etc.

I'm not a specialist of the Unreal Engine, but for the game engine I know (Godot Engine) the simplest way to do that is to provide your project (so it becomes quasi open source) to other users. Is it the case also with Unreal?

The short answer is No.

Long answer is complicated.

While I'm doing efforts not to do so, at some point I might include some custom/proprietary libraries that I want to purchase on marketplace. At that point would not be legal and wise from my side as a developer to release source including those libraries. Expecting people to buy those libraries is a bit of nonsense.

The main models I'm using are based on G3F models from Daz, I could move to G8 or G9 or any other models from different sources. Problem is most models are not open source and their licensing has a price. While I could include them in the released game without a problem (based on my interactive license), is not a real option to do that with the source code. 

I plan to release:

-all Blender pipeline tools  (plugins + full source code) with full explanations on how to take a Daz model and bring it in Unreal Editor then eventually in the released game (Unreal Engine).

-all model settings/parameters/exporting settings so anyone could duplicate some of my custom models or make whatever models they wish and bring them in Unreal Editor or the released game

-mod ready Unreal project (simple project without dependencies in which anyone could import any generic assets in order to create baked unreal assets and export to the game as an addon)

In case of pressure, like some people demanding access to the source code (in a very nice and politely way or a very rude way, yes... that happened) then I will give access to the source code but only to that person requesting it, obviously with no models and no proprietary libs, the requester will have to fill in the missing pieces.

It’s an amazing project you have here! All luck for you , dude! 

Hi, since you use a Daz model for armature, etc. I was wondering if this kind of pack would be usable with customizer part of your project?

It always depends on people tastes, but overall any 3d model can be used for clothing as long as it is ported to the game, and the process is similar with the porting we need to do for TK17.

Clothes need to be extracted, brought in Blender or a different modelling software, added to an armature, weight painted, then exported to the game.

Unfortunately there are some very specific steps to be taken, is not possible to take some cloth items as daz files and drop it in the game folder and expect it to work.

Few people realize this, but Daz models are not exactly top notch work  when it comes to weight painting, because Daz is doing some special tricks to avoid clipping like collision iterations/calculations and it also uses dual quaternion skinning and during static poses a lot of people are using post processing or daz tools like mesh grabber to workaround visible clipping.

What I aim to do is to simplify the pipeline, the way people need to work to get the clothes in the game, while for static objects (think rooms and toys in tk17) it might be possible to do a drag and drop directly for their files (obj, fbx, etc) as long as they are not a mess and the engine can decode them.

On 2/9/2024 at 7:59 AM, hfg2 said:

What I aim to do is to simplify the pipeline, the way people need to work to get the clothes in the game, while for static objects (think rooms and toys in tk17) it might be possible to do a drag and drop directly for their files (obj, fbx, etc) as long as they are not a mess and the engine can decode them.

It would be great if you achieve this, mainly at the begining so people can get stuff for their scenes rapidly.

Hi hfg2, have you made some progress on the pose editor of your project or with the graphic pipeline?

A bit stuck right now in other projects, slow progress on "gaming" side.

1. Alternatively I'm working on a converter for G8F to G3F (and maybe vice versa). I think I've done the heavy lifting, but finalizing this is a bit exhausting. Still not sure if I should fork this into Daz plugin or keep it as a Blender plugin.

2. While doing some investigation I learned some tricks that should allow to export two levels of details for G3F characters:

-first one would be LOD1 (which should be exactly the base resolution)

-second one would be LOD0 (base resolution subdivided and smoothed)

This trick would allow me to have high quality characters, problem is I didn't implemented it yet, is just an idea, I know/I feel this will work, and it should work awesome, but problem is I haven't done this yet. I still might get stuck in some issues.

What I want to achieve is to enable game runtime loading of morphs at base resolution, for LOD1 this would be simple because of direct vertex matching, nothing complicated, for LOD0 it might be some averaging of neighbors vertices.

Now there might be another thing that appeared... and might make my efforts futile, and maybe I will have to rethink the workflow pipeline, maybe it will help and improve the quality of my work or it might scrap everything.

Those two videos I'm talking about, Nanite support for skeletal meshes with tessellation/displacement.

3. And at last I also think more and more about finishing the h5m project I had in Blender, so that h5m objects could be exported/imported using Blender, then implement h5m objects in Unreal.

I still don't know if this is important or not, it might be useful for sure, but can't decide on the viability of this, lol.

While the Blender could help people make their "rooms" in Blender for TK17 and Unreal projects don't know yet if this worth the effort or not.

6 hours ago, hfg2 said:

A bit stuck right now in other projects, slow progress on "gaming" side.

1. Alternatively I'm working on a converter for G8F to G3F (and maybe vice versa). I think I've done the heavy lifting, but finalizing this is a bit exhausting. Still not sure if I should fork this into Daz plugin or keep it as a Blender plugin.

2. While doing some investigation I learned some tricks that should allow to export two levels of details for G3F characters:

-first one would be LOD1 (which should be exactly the base resolution)

-second one would be LOD0 (base resolution subdivided and smoothed)

This trick would allow me to have high quality characters, problem is I didn't implemented it yet, is just an idea, I know/I feel this will work, and it should work awesome, but problem is I haven't done this yet. I still might get stuck in some issues.

What I want to achieve is to enable game runtime loading of morphs at base resolution, for LOD1 this would be simple because of direct vertex matching, nothing complicated, for LOD0 it might be some averaging of neighbors vertices.

Now there might be another thing that appeared... and might make my efforts futile, and maybe I will have to rethink the workflow pipeline, maybe it will help and improve the quality of my work or it might scrap everything.

Those two videos I'm talking about, Nanite support for skeletal meshes with tessellation/displacement.

  Hide contents

 

 

 

 

 

 

3. And at last I also think more and more about finishing the h5m project I had in Blender, so that h5m objects could be exported/imported using Blender, then implement h5m objects in Unreal.

I still don't know if this is important or not, it might be useful for sure, but can't decide on the viability of this, lol.

While the Blender could help people make their "rooms" in Blender for TK17 and Unreal projects don't know yet if this worth the effort or not.

I would leave point 3 for what it is. h5m is actualy not that good. the problem with it is that you can only use .dds files for normals and specs and that leaves Substance painter out of it. normals out of substance painter dont convert well to .dds files. The only good thing about h5m files now is that you can kitbash.

Berger already made the tool to get h5m to .obj but it flips the UV on its Y axis.

For unreal its easiest to use obj or fbx files as i understand it. And that is where all h5m files start anyway.

Hi, glad to see that you still manage to make progress on your project, for the point 2, nanite skin should be customizable at run-time? For the point 1 and 3 I agree with Sexvision these are nice to have but it can be done in a second time if it's too time consuming, especially for the h5m format because if I understand well, it would useful only for H5 objects which have their OBJ file missing, no?

On 4/16/2024 at 9:50 PM, Exiled_Vizir said:

Hi hfg2, have you made some progress on the pose editor of your project or with the graphic pipeline?

Actually failed to explain properly to this question.

Not much progress on the pose editor itself, things are changing fast in Unreal and still not sure which approach should be the best. While watching some VaM tutorials/showcases on youtube I was convinced there could be something much better than the usual pose editor interface found in TK17, so now I'm also considering a mixed interface/an alternative to the TK17 pose editor.

Regarding the graphic pipeline, just like mentioned above things are moving so fast on the Unreal scene that I feel unable to keep up with everything, so much things and eye candy and I don't know what I should implement first. I know this is not the proper answer but I will explain more hopefully in my next posts.

Regarding the mentions from @Sexvision about h5m format support. First, there is no better format really, going for fbx or obj file format can't be better for a couple of things. Obj format for example is a text file, processing it takes time (slow) and the texture support is like 20-30 years old maybe. That means Obj file format doesnt know anything about PBR. H5m on the other hand was implemented to be 3d pipeline friendly, is already in binary format and vertices/faces materials are pre-sorted to be easily sent to the graphics card.

Texturing is more or less something that can be supported later, h5m textures can be Substance painter friendly (I'm not expert in Substance painter), h5m usually support dds files or png files. 

Always remember that Unreal has its own file format for textures and models, out of the box Unreal engine has no support for dds or png at runtime, so a custom loader must be used for those.

Also Unreal engine has its own material editor (using nodes), implementing the usual PBR cloth shader from hook5 is actually resulting in a very basic material in Unreal that mimics PBR. For people looking to get the best graphics out of their models they will have to make their rooms not using obj/fbx/h5m/whatever at runtime, but create the rooms in Unreal Editor and exporting them as custom maps to be used in the actual game.

But not everyone wants to install their own Unreal Editor instance, so for those people custom object loaders to make their own maps from obj/fbx/h5m/whatever objects should be available.

12 hours ago, Exiled_Vizir said:

nanite skin should be customizable at run-time?

I don't know that yet. But for existing projects using static meshes Nanite must be enabled in the editor to be used later in runtime.

1 hour ago, hfg2 said:

Actually failed to explain properly to this question.

Not much progress on the pose editor itself, things are changing fast in Unreal and still not sure which approach should be the best. While watching some VaM tutorials/showcases on youtube I was convinced there could be something much better than the usual pose editor interface found in TK17, so now I'm also considering a mixed interface/an alternative to the TK17 pose editor.

Regarding the graphic pipeline, just like mentioned above things are moving so fast on the Unreal scene that I feel unable to keep up with everything, so much things and eye candy and I don't know what I should implement first. I know this is not the proper answer but I will explain more hopefully in my next posts.

 

Regarding the mentions from @Sexvision about h5m format support. First, there is no better format really, going for fbx or obj file format can't be better for a couple of things. Obj format for example is a text file, processing it takes time (slow) and the texture support is like 20-30 years old maybe. That means Obj file format doesnt know anything about PBR. H5m on the other hand was implemented to be 3d pipeline friendly, is already in binary format and vertices/faces materials are pre-sorted to be easily sent to the graphics card.

Texturing is more or less something that can be supported later, h5m textures can be Substance painter friendly (I'm not expert in Substance painter), h5m usually support dds files or png files. 

Always remember that Unreal has its own file format for textures and models, out of the box Unreal engine has no support for dds or png at runtime, so a custom loader must be used for those.

Also Unreal engine has its own material editor (using nodes), implementing the usual PBR cloth shader from hook5 is actually resulting in a very basic material in Unreal that mimics PBR. For people looking to get the best graphics out of their models they will have to make their rooms not using obj/fbx/h5m/whatever at runtime, but create the rooms in Unreal Editor and exporting them as custom maps to be used in the actual game.

But not everyone wants to install their own Unreal Editor instance, so for those people custom object loaders to make their own maps from obj/fbx/h5m/whatever objects should be available.

I don't know that yet. But for existing projects using static meshes Nanite must be enabled in the editor to be used later in runtime.

That was a intresting read. I did not know that h5m was binary. I did see the node setup for unreal engine and it seems very simular to the blender node setups. I did install Unreal engine a few year back to check it out but never got that far to set something up. May need to dive in it some more

Oh, I think I got you or maybe this is what @Sexvision intended to say. Is not possible to load h5m objects in Substance Painter. That is correct, we need to do a conversion to an obj file in order to import that. That is the problem.

H5M is not limited to Hook5. The H5M binary format is public and it can be used/imported for example in Blender, I did that in my plugins.

Unreal only supports its own uasset file format, but it is possible with plugins to use any other file format at runtime, so it is possible to import obj/fbx/collada at runtime. Same for h5m files.

Hook5 can work with png for stage2 and stage3 files as well, one of my frequent mistakes was to have same png file along the dds file, trying to edit the dds file and wondering why it would not work. If both png and dds files are present then the game will load the png version.

For h5m object you can use either png or dds file, but if the filename is embedded as dds then it will not load the png. I think it also works with bmp files (havent tested recently), but this must be hardcoded.

16 minutes ago, hfg2 said:

Oh, I think I got you or maybe this is what @Sexvision intended to say. Is not possible to load h5m objects in Substance Painter. That is correct, we need to do a conversion to an obj file in order to import that. That is the problem.

H5M is not limited to Hook5. The H5M binary format is public and it can be used/imported for example in Blender, I did that in my plugins.

Unreal only supports its own uasset file format, but it is possible with plugins to use any other file format at runtime, so it is possible to import obj/fbx/collada at runtime. Same for h5m files.

Hook5 can work with png for stage2 and stage3 files as well, one of my frequent mistakes was to have same png file along the dds file, trying to edit the dds file and wondering why it would not work. If both png and dds files are present then the game will load the png version.

For h5m object you can use either png or dds file, but if the filename is embedded as dds then it will not load the png. I think it also works with bmp files (havent tested recently), but this must be hardcoded.

quote:Hook5 can work with png for stage2 and stage3 files as well, one of my frequent mistakes was to have same png file along the dds file, trying to edit the dds file and wondering why it would not work. If both png and dds files are present then the game will load the png version.

This is correct if you use a passfiles. Than it can actualy be anything as its specified in the pass file.

But for hook objects the _norm and _spec notation must be in dds format for hook to read them. This is hardcoded in hook 5 i believe. I have tried other formats but they dont work even if i specify them in the .mtl file before converting the spects and normals need to be dds format. For the diffuse texture it does not matter what format its in.

This looks pretty interesting! The only thing I'm worried about is the use of UE5 as an engine. I'm sure my laptop wouldn't even be able to handle it!