Jump to content

Hi There

Welcome to Klub Exile. If you happened to make your way to the site either from Lovers Lab or a Search on Google, we are glad you found us.  To unlock the entire site you will need to have a account registered.  Don't worry it is free but in the mean time you can read up on why we made the site and other little tidbits.  Feel free to join or Discord Server also if you have any more questions.  Thanks for stopping by and See You on the other side.

admin admin
Creating a Blog? Don't Forget the Feature Photo!! ×
  • entries
    4
  • comments
    118
  • views
    1,517

Connection between the TK17 UI and H5 features


x17

1,797 views

There could be potential idea here, and it doesnt seem complex, if we assume the connection between certain H5 assets to TK17 default UI - so connecting H5 features to something like sliders, or spinboxes, or checkboxes or similar. So, in a way, the way to manipulate with H5 features not only through H5 menu, but potentially also through TK17 UI.

The idea would be simple as switching the _pass input on the flow. For example, a user in game could potentially switch normal maps dynamically. H5 works like that, that it either uses manual ALT+R refresh, but could also use auto-refresh (which is part of extended H5). This way, the logic says, that we could have auto-refresh active, and dynamically switch between normal and specular maps (or possibly even displacement maps).

The only thing that game would need to do is manually replace name of normal map and PBR maps in stage2 and 3 in _pass file. Lets say that default game UI is capable to read the names of our H5 files... then everytime its selected, lets say in spinbox, the game does the operation of replacing the _pass value with the one we selected. And then, the auto refresh of textures updates our visual look of model.

 

This puts even more potential complexity. Something like JCMs (Joint Corrective Morphs) are heavily underutilized in game (something I do work on new body which is made for long time now). Now, some folks will be familiar with something called "tension" or "stress" maps in Blender. These are like maps that give lifelike impression on model, for example wrinkles on face. As the model is morphed through shapekeys or its armature manipulated, the tension maps activate to certain degrees and strength, making the wrinkles stronger in intensity, or lower in intensity. This is just one example, but other things can be affected, too, like color or similar.

However, our usage in TK17, hypothetically, could go in certain way of connecting the normal map to JCM or even morph. Assuming the auto refresh of H5 files works as intended, the normal map relief / imperfections and specular map glossiness / metallicity and glow could be all very dynamic like. Example could be, we rotate certain parts of body and see clear "tension" on certain areas of it, where specular map would increase glossiness. Or wrinkles that could change in intensity. The questions here would be how to connect H5-TK17 UI - this could potentially work for fixed values in norm and spec maps... we would just choose the already predefined map. But in any dynamic way, both normal maps and specular maps should have a way to gradate their value further, and this would be ideal for slider setting. The real question here is, how to gradate this ... 

Now imagine, if one could gradate with three sliders that represent RGB channels H5 files themselves ... normal map would use above logic and in 0 to 1 ranges represent all channels, and it could hypothetically change the XYZ values of dynamically. Or changing RGB values of specular map, seeing the results in real time. Now this assumes there should be a certain temporary file for either maps that could be "hard-saved" everytime its adjusted. Expanded, this would mean capability to link such dynamic changes to above mentioned JCMs, so when part of the body moves or morphs, it also dynamically changes the values of both normal and specular maps. 

If potentially possible in such way, it could create very high realism. Visible wrinkles on face expressions or extremities moving, tension on skin (glossiness) on certain moves, or similar features even on clothing.

  • Like 1
  • Thumbs Up 5

15 Comments


Recommended Comments

  • Administrator
4 minutes ago, Sexvision said:

Now that would be a big step forward. I would love to see that work.

 

There is one issue I havent mentioned, though ... lets say that even most "simplistic" way is possible, or in this case, there are two additional spinbox selections with every asset that can utilize norm and spec maps, or with some of them. So, every time asset is changed as main addon in its own spinbox, it must take this into correlation and read its H5 files correctly. The only way it could be done, is through pass file.

Link to comment
3 minutes ago, x17 said:

There is one issue I havent mentioned, though ... lets say that even most "simplistic" way is possible, or in this case, there are two additional spinbox selections with every asset that can utilize norm and spec maps, or with some of them. So, every time asset is changed as main addon in its own spinbox, it must take this into correlation and read its H5 files correctly. The only way it could be done, is through pass file.

another way could be trough a lua script with some logic. But the game and hook run on two different versions. that could be a issue.

for the simple way: As long as the filename in the passfile stays the same for normal and spec maps auto refresh should work.

  • Thumbs Up 1
Link to comment
  • Administrator
18 minutes ago, Sexvision said:

another way could be trough a lua script with some logic. But the game and hook run on two different versions. that could be a issue.

for the simple way: As long as the filename in the passfile stays the same for normal and spec maps auto refresh should work.

In simplest way, maybe it would just rename the input at _pass file every time when selection would be made to corresponding normal and specular map file that would all be premade.

There is maybe some additional things ... like when tattoos are projected on default skin... and tattoos are default TK17 asset.

Example

TattooArea :TattooArea_LegLeft . {
        .AreaID I32(4);
        .CutGeometryName :pbody + "body_subdiv_cageShape__body_leg_lower_L_SG";
        .AreaImage "Images/Maps/body_main01.Gender=" + :gstr + ".Map=Tattoo";
        .TextureMapping TattooTexGenMode .Cylindrical;
        .ProjectionAxis ( I32(0) , I32(1) , I32(0) );
        .ProjectionTranslation ( F32(0) , F32(0) , F32(0) );
        .ProjectionRotation ( F32(-160.3314972) , F32(-80.03964233) , F32(160.6056976) );
        .ColorValue I32(134);

You can see certain functions like translation and rotation. Clear geometry pointout in script, possible link to image, as well as color. The body would use its regions to "sectorize", then further use all below data to pinpoint where the tattoo is located on the body region.

Seems like "projection axis" appears only in cases when we have symetrically double assets -and only in case of legs. Also no projection translation values in same category, if we have projection axis.

However, translation and rotation have logic only as within 2d plane here, so its maybe UVmap in one sense.

 

This could be a hint maybe to implement some way of "modular texture load" in game.

Link to comment
  • Administrator
20 minutes ago, x17 said:

In simplest way, maybe it would just rename the input at _pass file every time when selection would be made to corresponding normal and specular map file that would all be premade.

There is maybe some additional things ... like when tattoos are projected on default skin... and tattoos are default TK17 asset.

Example

TattooArea :TattooArea_LegLeft . {
        .AreaID I32(4);
        .CutGeometryName :pbody + "body_subdiv_cageShape__body_leg_lower_L_SG";
        .AreaImage "Images/Maps/body_main01.Gender=" + :gstr + ".Map=Tattoo";
        .TextureMapping TattooTexGenMode .Cylindrical;
        .ProjectionAxis ( I32(0) , I32(1) , I32(0) );
        .ProjectionTranslation ( F32(0) , F32(0) , F32(0) );
        .ProjectionRotation ( F32(-160.3314972) , F32(-80.03964233) , F32(160.6056976) );
        .ColorValue I32(134);

You can see certain functions like translation and rotation. Clear geometry pointout in script, possible link to image, as well as color. The body would use its regions to "sectorize", then further use all below data to pinpoint where the tattoo is located on the body region.

Seems like "projection axis" appears only in cases when we have symetrically double assets -and only in case of legs. Also no projection translation values in same category, if we have projection axis.

However, translation and rotation have logic only as within 2d plane here, so its maybe UVmap in one sense.

 

This could be a hint maybe to implement some way of "modular texture load" in game.

What would this mean further ? Well, imagine linking the above translation or rotation within 2d plane to sliders and achieving capability to directly modify the projection of 2d texture on body skin.

As I see, "modular loading" in such way would be most useful maybe for small individual normal map details ... but also could be superior to default tattoos. Overall, the H5 skins are capable already for many things ... and this would be only for maybe achieving more closer integration of certain H5 functions directly. Maybe the H5 skin system itself would be a proper way to go from ...

Also, side mention, one bad thing was that vanilla UVmap of body wasnt good as both hands and feet were overlapping within one UVmap and this, IMO, was fairly pointless when it was about giving certain paint or tattoo details, as it would simply mirror them always.

Link to comment

Would this also make it possible to connect a hook object like a toy. Because that would be a giant step forward?

Link to comment
  • Administrator
3 minutes ago, Sexvision said:

Would this also make it possible to connect a hook object like a toy. Because that would be a giant step forward?

Doubtful, but in general, I dont see a point. Now if you could make objects have animations, morphs, that would be interesting.

 

H5 objects are loaded within level definition, and its already possible (altough through H5 menu, ofc) to control many level definition variations, potentially turning on / off objects easily through [INCLUDES] sub-section as addition into main level definition file.

 

Overall, there is one upside and one downside to toys, compared to H5 objects. Upside - toys can use morphs, H5 objects cannot. Downside - toys are all loaded into the scene, even if theyre not used, then theyre linked one by one to the model. So, theyre not loaded optimally and there shouldnt be too many toys ever loaded otherwise it could make game unstable, while we can load H5 objects easily and all is defined either in main level definition or in above additional file for [INCLUDES] section. Still ... usage of morphs within toys add a certain layer of interaction that H5 objects dont have.

However, this means we just need to categorize both toys and H5 objects more precisely. We dont need as toys anything that is planned to be purely static. We dont need some strictly static furniture as toys - we can convert same assets as objects and use in level definition. BUT, anything supposed to be animatable, and with intention to be morphed ... should be done as a toy. So, more proper thinking about what should be a toy, and what not, should be done.

  • Agree 1
Link to comment

Is there any way to 'hook' into the in-game GUI? Seems like it should be possible, DirectX8 is it? I'm guessing it should be possible to inject a DLL with the required bits and pieces but this will require a dive into the ASM/disassembly info first. Is there any list of discovered/exposed functionality in terms of Windows/DirecxX API calls?

  • Thumbs Up 1
Link to comment
  • Administrator
4 minutes ago, chefette said:

Is there any way to 'hook' into the in-game GUI? Seems like it should be possible, DirectX8 is it? I'm guessing it should be possible to inject a DLL with the required bits and pieces but this will require a dive into the ASM/disassembly info first. Is there any list of discovered/exposed functionality in terms of Windows/DirecxX API calls?

Seems to me like certain integrations are definitely possible - one of the users, JoeNoxwill, has managed to connect morph slider with DoF setting of H5

So, it should technically be possible much more ... but definitely it doesnt seem something as an easy task, as it requires good background knowledge, but even more important, maybe potentially right tools to do such actions.

Overall, injecting dlls is beyond my capabilities, for now.  

Link to comment
9 minutes ago, x17 said:

Seems to me like certain integrations are definitely possible - one of the users, JoeNoxwill, has managed to connect morph slider with DoF setting of H5

So, it should technically be possible much more ... but definitely it doesnt seem something as an easy task, as it requires good background knowledge, but even more important, maybe potentially right tools to do such actions.

Overall, injecting dlls is beyond my capabilities, for now.  

Interesting, nice job by JoeNoxwill. DLL injection isn't especially hard, depending what you are trying to inject a DLL into of course.
Haven't tried any of this stuff with the game yet tbh. Another thing to add to The List 😄

  • Thumbs Up 1
Link to comment

This is definitely what I plan to try to implement (among other things). The "managed layers" concept. I already wrote the basic dll structure, so now it's just a matter of luck and free time. There is a problem that I haven't solve yet (with interseption of fucntions from other dlls). Maybe even start a blog here lol.

  • Thumbs Up 3
Link to comment
  • Administrator
3 hours ago, JoeNoxwill said:

This is definitely what I plan to try to implement (among other things). The "managed layers" concept. I already wrote the basic dll structure, so now it's just a matter of luck and free time. There is a problem that I haven't solve yet (with interseption of fucntions from other dlls). Maybe even start a blog here lol.

Absolutely, feel free. I do wonder how did you manage H5 files ? Did you manage to decompile and recompile some core files of it, but for this, you would need exact tools for it, correct ? I have noticed you used some files that were never part of core H5, which is interesting.

Overall, very few people (that I know at least) actually "hacked" this game through dll injections. First and foremost, White Rabbit, a guy who managed to crack the main game and open this game modding for everyone, then Pervokpetr with his HOOKs, unsure if Rick9 did it, but I assume yes. Maybe Raistin Kane, too, as some dlls were carrying his ideas, but also maybe it was WR who implemented these dlls at one point.

So, what you do, its very rare to see and nothing short of impressive on this game. Sadly, my experience in programming is severely lacking and I have scratched the surface of it to some extent. Also tried to understand the assembly code (as a link between machine and "higher level" code) through Cheat Engine to one extent. Will definitely need much more time and effort to properly understand the capabilities for this game.

But maybe, eventually, the core game features, like story mode or similar could be possible to make big alterations or completely different "modules" (something you have seen just as concept idea in codework). This could potentially expand the game even more.

The default integration of layers / custom skin is very interesting... while we can pretty much achieve everything  easily through H5 menu, seems to me like there is very high untapped potential, as with some ideas above - making certain immitation of tension maps by usage of normal maps in various strengths depending on rotation and translation of joints in game, or even depending on morphs (value A of morph gets translated to value B - but were capable also to different gradual translation in percentage).

 

Overall, if you would need assistance with anything, Ill definitely help to extent to which I can at the moment, freely tell. Its important for this game to evolve when possible, and for game that its in its core foundations two decades old, its fairly impressive what modding and "deeper modding" (aka hacking) did to it. Still very unique in many ways.

  • Thumbs Up 1
Link to comment
25 minutes ago, x17 said:

I do wonder how did you manage H5 files ? Did you manage to decompile and recompile some core files of it, but for this, you would need exact tools for it, correct ? I have noticed you used some files that were never part of core H5, which is interesting

I just found a pointer in memory to the value that used by H5. In fact it was lucky because value don't overwrote in every frame otherwise I need to find and intercept function where I can overwrite overwriting 😆. In case of skin layers definitely it will be harder.

The hardest thing was find sliders' values. While I was looking for them, I also found a place where values of sliders for each frame are stored. This is an interesting find, because in theory it allows to do something like quickly move/scale animations. In general, reverse engineering is a pretty funny thing. While looking for something you can find completely unexpected things. For example, I am currently working on a modification of old strategy, where I lucky discovered a function that bakes (when loading map) static lighting from light sources placed in the map editor. So I intercepted this function and now I call it every frame if the position of some light has changed. That is, I actually added dynamic lighting without using the graphics library.

  • Thumbs Up 5
Link to comment
  • Administrator
4 minutes ago, JoeNoxwill said:

I just found a pointer in memory to the value that used by H5. In fact it was lucky because value don't overwrote in every frame otherwise I need to find and intercept function where I can overwrite overwriting 😆. In case of skin layers definitely it will be harder.

The hardest thing was find sliders' values. While I was looking for them, I also found a place where values of sliders for each frame are stored. This is an interesting find, because in theory it allows to do something like quickly move/scale animations. In general, reverse engineering is a pretty funny thing. While looking for something you can find completely unexpected things. For example, I am currently working on a modification of old strategy, where I lucky discovered a function that bakes (when loading map) static lighting from light sources placed in the map editor. So I intercepted this function and now I call it every frame if the position of some light has changed. That is, I actually added dynamic lighting without using the graphics library.

Thats interesting ... so it could be put as "interception of interception" in one sense, lol ? Because H5 intercepts the default game routines ... and this would be a layer onto it ?

Its also highly interesting what your discovery implies ... it could maybe imply also the possibility to load some things partially or different within the game. For example, there is a big problem as game loads everything into a scene, for example toys are loaded all in bulk. Maybe there could be a way to make partial loads, but unsure in that. It would overall optimize things to extent.

Also, you can check some interesting things ... for example, breathing animation (which I think it was implemented by Raistin Kane by lots of script links) - this is technically a morph that loops as animation, and one can put it into a timeline in PE using shift and right click > generate breathing. This gives some interesting hint how additional animations (those which have sense) could be linked to a model and put into PE timeline easily and effortlessly. The overall idea of these animations would be general "automatization" of certain processes. But one could easily also use external ways, like BVH and Mixamo or similar sources in conversion, as TK17 is capable of BVH load and will be accurate as long as correlation between joints is correct.

Also, logic says to me that we are maybe even capable to change whole weighting of the asset, if lets say, were capable to inject the code in direct way on exact places within the main Scene.bs file of the asset.

Lots of it depends on loading routines of the game ...  everything default seems to be loaded strictly in loading screens, but the only dynamic thing that I have noticed in default TK17 was culling sphere (bounding sphere) of objects (its basically the only way how game "culls" the scene, AFAIK). H5 works differently, and is capable to load many things automatically or with refresh at minimum. 

 

  • Thumbs Up 1
Link to comment
On 6/5/2022 at 7:33 PM, JoeNoxwill said:

I just found a pointer in memory to the value that used by H5. In fact it was lucky because value don't overwrote in every frame otherwise I need to find and intercept function where I can overwrite overwriting 😆. In case of skin layers definitely it will be harder.

The hardest thing was find sliders' values. While I was looking for them, I also found a place where values of sliders for each frame are stored. This is an interesting find, because in theory it allows to do something like quickly move/scale animations. In general, reverse engineering is a pretty funny thing. While looking for something you can find completely unexpected things. For example, I am currently working on a modification of old strategy, where I lucky discovered a function that bakes (when loading map) static lighting from light sources placed in the map editor. So I intercepted this function and now I call it every frame if the position of some light has changed. That is, I actually added dynamic lighting without using the graphics library.

So far (I've been kinda busy) all I did was analyze the game exe and all the associated dlls for exported functions etc, but I didn't save anything yet (used pestudio on Win10), probably easier to do some of this shit on my linux laptop tbh.

Link to comment
×
×
  • Create New...

Important Information

WARNING! Adult Only Content You must be 18 years of age or older to enter. By accepting you agree to Klub Exile's Terms of Use and Guidelines upon creating an account.