hfg2

I'm not convinced that CTK is working properly when  calculating TNBs, but with RaistinKane and Pervokpetr missing I can't ask my noob questions, lol.

Trying to do something about, but the UI part/usability part is killing me, not sure how to implement this in a simple and easy to understand manner.

Should I output a single object as a custom name or should I output the entire scene as separate objects, using generic names or using their blender object name?

Another thing is that each h5m file can't be reloaded, somehow hook5 are caching them, so if you overwrite a new h5m file then is not possible to reload them without restarting, for now I just add a number at the end and I increase the number with each export if one already exists.

Attached you can find a WIP project that I used to make the exporter. You need to fix the paths for the textures for materials and then you need in the code at the end to fix the paths where to export, as now is something like:

prefix = "horse"
counter = 0
extension = ".h5m"
folder_name ="F:/Games/VX/Mod/ActiveMod/_hook5data/objects/test"

The code is Blender 2.79b compatible, probably the final addon project will be Blender 2.79b first as well, but should be easy to port to latest Blender like 3.5,3.6 or 4.0 later with some improvements in logic/speed of taking precomputed/blender self calculated normals/tangets/bi.

horse_test.blend

Multiple people claimed that the h5m file is not supporting png files for stage2 and stage3 files, so I've decided to put this to test, because my memory was playing tricks to me.

What I can say however is that swapping/removing the png for dds and the other way around while reloading the h5m file is a sure way to a game crash.

horse-test.zip

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.

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.

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.

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.

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.

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.

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.

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.

Do you have the actual model in the header?

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.

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).

But can she dress?

That video was from someone (back in modsgarden days) that did it in Unity. He used the stock body/materials (had a Blender project) and I think also armature/weights. On top he added some ik functionality to control bones in Unity.

My project is based on Unreal Engine 5.

 There are games that just duplicates the cloths based on the body counts, if the said game has 10 custom body morphs then it can release a cloth in 10 morphs to match each body.

This can be done, can be automated.

Is not  perfect approach (which approach is?!?) but it works at a decent level.

Unity is a great game engine, it is all about the developer skills, I've seen something similar to what I'm building in Unreal, that was done during modsgarden days by someone in Unity. On top of that, it was possible to load poses directly from pes files. I still have the project around.

In the end it all comes down to what the developer wants to achieve, maybe they want to build VAM, Honey Select, Wild Life, a massaging game or just a better look alike TK17.

Gave it a try and looks nice, I liked the customizer part (actually very much) and the smoothness of animations.

What I didn't like is the aggressive movement of the inertia soft bodies, the fact that you need to rub the mouse up and down to increase the excite level of the girl, the fact that you can apply a couple of morphs to get a different body which will instantly make it non-compatible with clothes, the lack of clothes (probably that is the reason).

Considering how advanced in development this game is, I don't understand why the graphics are so under-used.

Don't remember much about HS, but I remember the lack of the pose editor and all faces that looks like some specific hentai models. I think actually HS models are a special trend, is not possible to see a HS model and not recognize it.

A lot of games suffers from the same issues, those are built as some kind of erotic game, using premade/baked poses and not able to mod the way we please. In fact most games kinda sets the scene and lets you know what you can do and how you can do. This is what I would like to change.

14 hours ago, Exiled_Vizir said:

... but I wasn't ready for the: "Guys I cooked a really big turkey this year for Christmas, it was very long to cook. So while waiting I made a TK17 pose editor in Unreal 5."

In a lack of a better explanation, that is exactly how pretty much went.

14 hours ago, Exiled_Vizir said:

Maybe we are assisting to the early days of TK18...

Why not? I got fed up of the engine issues/limitations and frequent crashes from my TK17 instance. So why not move forward since we can get pretty much everything we want from the wish list? Like better models, physics, collisions, PBR engine, RTX, 64bit, better interfaces, huge animations libraries, etc?

It only surprises me that I'm the one doing this, I was hopping for a more experienced programmer to do this, or maybe a full team. But I'm the one that did the step forward, I do have some aces in my sleeve, so I'll push with those instead. There is actual competition, there are alternatives, but not using TK17 as a direct target.

But how fast your TK17 game install can get you from desktop to Pose Edit mode? 

2 hours ago, HDiddy said:

Interesting.  So technically speaking you can add more bones for posing than TK17...which is cool.  Not sure what additional ones you would need.

It uses the same armature as TK17/VX and the same custom bodies I've used in TK17, with only a minor modification that is added/patched at export time. Unreal Engine likes to have something called a "root" bone (the name can be different, and in our case it should be different as the TK17 armature already has a bone named "root" ), that is the first bone in the armature and is supposed to be located at 0,0,0 coordinates (TK17 root bone can't qualify as it is positioned more like a hip bone).

There are multiple options to pick from:

- use native UE5 armature + extra bones for breasts, butt, etc.

- use Daz armature + extra bones for breasts, butt, etc.

- use TK17 armature

- use a new armature created from scratch

Honestly I don't know which would be the best approach, all have pros and cons, is debatable what I should use/implement. But for now I went with TK17 armature because I already have this rigged/weighted/ready for export. Went the quick path because I want to have something functional asap. Is never a problem adding extra bones, is more of a problem making it work properly, getting something useful out of it and being able to easily access/manipulate those bones.

Technically speaking it is possible to add more bones in TK17 as well. Here I've added a couple of extra bone tails to a custom body/custom armature.

When you make an IK chain, the bones must have some kind of bending, so the IK solver knows how the bones are supposed to bend, in which direction. This is usually obtained from the bones themselves, as long as the bones are not in a straight line, there will be some kind of bending (like in the knee area). However, if you translate the bones, then the original bending will be messed up and as a result the bones will flip.

This is where PreferredAngle is useful, it will tell the bones how they should bend.

RK had some info about IK here: 

But can she pose? 

Went a bit further and managed to do first control manipulation, for the main joint. This is a bit similar with selecting the Hip bone in TK17 while holding the Ctrl key pressed. Not the cleanest code (to be honest it looks like a spaghettis invasion) but should be able to go for the main bones control, hands, legs, head and the hip/root bone.

Under Limbs section there is a Knee L and a Knee R, those in fact manipulates the values under 

Anim:Model01:knee_L_pe_transY

This is obviously found in anim01.bs file.

You can drive those sliders manually, but if you want you can auto-drive those sliders using AppExprLinear. I thought this is what you tried to do in your "fixings".

If you drive those sliders to the max the leg will jump out of the place like crazy, to correct that and allow for more extreme sliders you need to fix the PreferredAngle. This is omitted in the anim01.bs file because it doesnt cause problems for original joints values.