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

hfg2

Modder
  • Posts

    476
  • Joined

  • Last visited

  • Days Won

    1
  • XP

    20,306 [ Donate ]

Everything posted by hfg2

  1. hfg2

    Bone supremacy

    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.
  2. hfg2

    Bone supremacy

    There are a couple of approaches to this, you can invert the knee joint, add an extra knee correction joint, or do something like: But the morphs should be used as well, in fact everyone is using them, including Daz. Later edit. There is something that must be added to the knee bone and that is missing apparently from the default inputs. I had this problem with my custom bodies which allowed only a slight change in translation, but this also affects the stock bodies at a high rotation angle. Code for the fix: :Person" + :person + "Anim:Model01:knee_L_joint.SNode?.PreferredAngle (0.0f, 0.0f, 90.0f); :Person" + :person + "Anim:Model01:knee_R_joint.SNode?.PreferredAngle (0.0f, 0.0f, 90.0f);
  3. hfg2

    New Project

    Merry Christmas everyone! Short day in the fun shop but still an update. Customizer window trying to be built as customizable as possible. Details are loaded from YAML file. If you don't know what is the YAML file then is very simple, it is just just like a Json file only on steroids. If you don't know what is a JSON file then don't worry, is just something awesome that some people would like to abuse. No seriously, YAML is a text file, in a human-readable format, used for configuration purposes, something very simple to understand. Very few rules, most important ones is that in YAML you need to keep the tabs/spacing indenting. Below is the configuration YAML file, linking to some test icon that I took from Dark Theme released by @cr532. This should allow everyone to make their own Customizer window and easily arrange/sort/filter the way they wish. Of course, with great powers come great responsibilities, so there should be checks in place to load a default/safe config file.
  4. hfg2

    New Project

    It is possible to know which vertices are affected by a morph, in fact Unreal uses this to minimize cycles and memory consumption on CPU size, it stores only vertices that has a delta value above a specific threshold. This is also required(not only useful) for GPU morphs I believe. And it is possible to render materials using vertex color, if you set a vertex color based on morph inclusion, i guess it could be done.
  5. hfg2

    New Project

    I'm trying to build a PoC (proof of concept) interface for a pose editor, and I settled for a chibi body, now I wonder if this could be a good idea moving forward or should I set up separate control sliders/widgets for face and for the body. For now it loks like this: null
  6. hfg2

    New Project

    Found some messages with my actual journey, while my first learning resources were downloaded back then, my Unreal hands down experience was actually on: Anyway this is another video I took a couple of weeks ago, at that point wanted to test if bone scaling was working properly. So in its most basic implementation it looks like below. Still not convinced if this will work in the final game and play nicely with other components, but hopefully there will be some kind of EASY solution to this.
  7. hfg2

    New Project

    Not much to say about, but lets just say and pretend I got annoyed with the issues in VX/TK17 so I decided to make my own game. I've been looking into Unreal Engine for some time now. Looking at some older info I got around, I determined I started this journey somewhere around August. I was hoping for a fast learning progress, but it turned out there is a ton to learn. The good part is that this is FUN, is awesome, everything looks like a modder's dream come true, graphics are top notch, like PBR out of the box, various physics multiple implementations/approaches, collisions, soft bodies, hair is like Hairworks but next gen, impressive assets to build your rooms/maps available for free. And... I would like to release a demo (like in a game demo, POC/WIP). Stay tuned. Like, subscribe, whatever it takes. 2023-12-22 11-09-03.mp4
  8. This is the code that marked as flipped some of the bones: (https://github.com/search?q=repo%3AModdingClass%2FTK17-Custom-Bodies-plugin+isFlipped&type=code) lowerBodyList = [ "hip_R_joint", "vagina_L_joint01", "clavicle_L_joint"] breastFixList = ["breast_L_joint", "breast_scale_L_joint", "nipple_L_joint01", "nipple_L_jointEnd", "breast_deform01_R_joint01","breast_deform02_R_joint01", "breast_deform03_R_joint01","breast_deform01_R_jointEnd","breast_deform02_R_jointEnd","breast_deform03_R_jointEnd"] lipsFixList = ["upper_lip_R_joint01","upper_lip_R_joint02","upper_lip_R_joint03","upper_lip_R_jointEnd", "lower_lip_R_joint01","lower_lip_R_joint02","lower_lip_R_joint03","lower_lip_R_jointEnd"] headFixList = ["cheek_R_joint01", "cheek_R_jointEnd","ear_R_joint01", "ear_R_jointEnd", "forehead_joint01","forehead_jointEnd", "nose_joint01", "nose_joint01","nose_joint02","nose_jointEnd"] eyeFixList =["eye_socket_R_joint", "eye_brow_R_joint01","eye_brow_R_joint02", "eye_brow_R_jointEnd", "eye_R_joint"] specialCaseList = ["rib_R_jointEnd", "butt_R_jointEnd"] fixList = lowerBodyList + breastFixList +lipsFixList + eyeFixList + headFixList +specialCaseList empty["isFlipped"] = False if name in fixList or hip_R_joint_child or vagina_L_joint01_child or clavicle_L_joint_child : empty["isFlipped"] = True So in practice for me the left arm joints are flipped. So focusing on the right arm should give you proper joints orientation from start, easier to work on that first, not taking into account flipping that must be applied on the other side.
  9. Sorry, can't remember much, but try to get one bone working first, then the other could be flipped. Flipped means pointing to the inside (towards the body/spine) actually. If you need to visualize the bones in the game (those are actually corrected by me, just saying) you can try this. 000.Custom.Body.P001.B001.StockBody-injector.zip Should get something like in the bottom image hopefully. nullSorry, not much experience with hairworks as I'm already transitioning away from this to other hair systems. Blender uses the concept of bones, where you have a head and a tail, but in other game engines there are only joints instead of bones, and each joint has only the orientation. In Blender you will always have the bone length axis defined as the Y axis of the bone, like its local Y coordinate is along the bone length, while the other main coordinate, which is used in IK orientation is defined by the X local axis. Sorry, but dont know which one is supposed to be the primary one, lol. The idea is that in different systems this could be totally messed up, because of this. Dont know in Max, but in Blender you have Y forward and Z up, while the game is -Z forward and Y up. For me this can be converted using something like (just an example, my from forward is -Y in this example, so don't copy paste blindly): p = axis_conversion( from_forward='-Y', from_up='Z', to_forward='Z', to_up='Y' ).to_4x4()
  10. In hairworks you can make your spheres as big as you want and connect the cylinders the way you want, so I doubt there is a situation where you can't block the hair.
  11. Not sure if it works, but if for some reason you don't want to split/cut the mesh (I do have a ton of personal reasons not to do so) then you can try to Edit -> Edge -> Mark Sharp, then stack an Edge Split modifier (check only Sharp Edges) on the growth mesh and see if it helps.
  12. You always need to split/cut the mesh where you want the hair to take a new direction otherwise it will just interpolate.
  13. Is not enough to invert the channel as it is, the entire map should be normalized before export.
  14. I've posted the details on how to do the collisions already in the past, and there should be easy to write a script to create both obj files and invoke the apx converter for you. I had this in my plans to do, but I stopped working on it. I'm switching to Unreal so don't really know if I should invest time in Hairworks, the main difference between usual workflow from blender/alembic/groom system and Nvidia hairworks is that the hairworks is a bit more constraining, because it forces you to grow your hairs from vertices locations while everyone else would like to grow it distributing across the faces of the mesh, not just from the vertices location. There are some plugins for Blender that allows you to port probably 95% of daz hairs, but so far didn't decided how to "snap" the growth positions to the vertices required by hairworks. However I've implemented some code to re-approximate curves, so you could go from 9 segments to 15 segments or from 99 segments to 15 segments or whatever number to whatever number. Unfortunately, I procrastinate a lot, so like I've said there is no code to do the auto-matching from surface to the vertex location. I was looking to port that library with 500+ hairs, but left those for better days. I'm still sad/upset myself on this.
  15. Daz is an ok tool for animations assuming someone invests enough time to master it. But Blender (Full 3D pipeline software) and Unreal (Game Engine but very versatile) for example has very good retargeting options which makes animations a breeze. Cascadeur is the new kid on the block. It is possible to move TK17 animations to Blender, I had some attempts in the past, I k now for sure it can be done (not sure at which level of fidelity). I'm not going to pursue this project. A custom plugin must be wrote in Python to be able to do that. Next, ported animation can be converted from Blender to Daz.
  16. There are online tools that can help you with that, Photoshop has the clone/smudge/soft brush tools, there are a ton of ways to get rid of them, including some youtube tutorials, The "problem" is in many other games and has solutions to be handled.
  17. Is great if you got it working the way you wanted.
  18. Most probably is Mikk algorithm. http://www.mikktspace.com/ Or something simple, like if you have a quad face and you need to triangulate, there are only two diagonals and you pick the shortest one, if the diagonals are equal or approximately equal you can then compare at the uvs face diagonals. But the beauty of this mess is that you don't need to triangulate at all, you can keep all quads and the game will do the triangulation (and subdivision) for you anyway. My custom bodies comes from daz, all quads baby, and just look awesome. Let the game engine do that for you.
  19. The eyes morphs computations are a bit more complicated. There is also: AcAnimFaceLook.bs which has a block like: AppScript . { .Script " :face_poseBlend_eyes_closed_mul.Weight 1.2; :face_poseBlend_eyes_closed_min.Weight 0.2; "; }; How those morphs are driven are explained in AnimFace (PoseBlend :local_19) However, if you want to investigate more you can debug the values at various slider levels and make some kind of mapping correspondence which is probably actually linear. (you can add the right version also). The following code should go in the FGCalc.bs file (to run it, I usually change something like the hair mesh cap) You need to have your log window activated (not send to the file). var :obj_morph FindObj ( "Person" + :FGCalc_PersonID + "Body:body_blends_body_eye_L_morph" ); print ( :obj_morph .Name ? ); print " = "; print ( :obj_morph .Weight ? ); pl ""; var :obj_morph FindObj ( "Person" + :FGCalc_PersonID + "AnimFace:body_blends_body_eye_L_morph" ); print ( :obj_morph .Name ? ); print " = "; print ( :obj_morph .Weight ? ); pl ""; var :obj_morph FindObj ( "Person" + :FGCalc_PersonID + "Anim:Model01:body_blends_body_eye_L_morph" ); print ( :obj_morph .Name ? ); print " = "; print ( :obj_morph .Weight ? ); pl ""; Don't remember much, but you can try and look into more things like, maybe not a good track to follow:
  20. I used to be a long time user of Blender 2.79b, because it used to be the version that was most compatible, and easier to use for my specific use cases. Because of that all my plugins were written for Blender 2.79b, and there is no compatibility with 2.8 or higher. But Blender 3.6 is vastly superior compared to 2.79b, weight painting is very powerful when looking at those brushes, automatic weight painting is just a few clicks using custom plugins and produce very good results. There are a couple of things were people fall in the trap of choosing sides. Blender 2.79b is simpler, like in simpler interface. Easier to learn, memorize, perfect if you already know it. Blender 2.79b with its old materials system, NOT node based for use of the internal render looks in theory a better match for the game addons and basic modding of the game. Blender 2.79b has plugins for it (for TK17 and Sims4). Funny here that if you need the Weather plugin you actually need blender-2.64a. Or if you are a Sims3 harvester you actually need blender-2.62. Blender 3.6 just owns 2.79b if you need any kind of artistic work, any modern material nodes, weight painting, etc. but its interface is different and old time users face resistance when switching to it. Also the lack of plugins adapted for TK17 makes it worthless if you would have to switch. So, my point here is if you want to be grumpy as Grump (an old user from modsgarden) then stick to 2.79b and avoid 3.6. If you are a open minded then start using 3.6 for doing all your work, and if you need something from the game then fall back to 2.79b. I still regret for having my tools compatible with only 2.79b. It was my personal choice back then, I think I was forced somehow to it, but now it starts to bite me back.
  21. hfg2

    Depth of Eyes

    Girl is Blaire for Genesis 3 Female(s), original geometry but other texture applied. I tried in the past playing with eyes, also tried some high resolution texture inspired by Kraegar's work, tried with normals and spec back and forth, after a couple of days and a ton of crashes I decided that eyes are obviously important but really NOT that important, so unless you are doing some very close up shots that highlights the eyes then there is only an insignificant benefit you can squeeze out of this.
  22. hfg2

    Depth of Eyes

    You can make your own mesh from the standard game eye meshes, you even have access to both eyes (yes, those are separated), you can edit the vertices and even the UVs separately. So you can increase the resolution (vertex count), you can sculpt them, or separate their UVs (one robot eye or heterochromy) if you are into such mods. Both the left and right eye iris and the eyewhite share the same uv texture spaces and are just flipped left on top of the right or the other way around. So if you are into eye customization this should be your low hanging fruits. null
  23. If you go and publish on github I could submit bugs/patches/improvements. At least in theory. Your project with the modding tools is highly appreciated by me, is nice to see people that starts implementing Nodes as objects/classes and working on high versions of Blender as well. Also are good for study. You are very dedicated to the stock bodies which I consider inferior bodies, but if your project can export custom bodies (like exporting materials, textures and the rest of nodes like CollaTkane does, not constrained in the old local_XXX numbers) then I will be interested in including this in my bodies exporter. But I'm kinda done at this point with the game as it is, I personally would like to switch to something else because of the issues I've encountered (limitations in the engine and frequent crashes due to high textures sizes I'm using). I'm not saying that I've abandoned the game for good, but for now I would like to focus on alternatives, because a lot of the tools I've built over time I think can be adapted and reused for other engines with little effort and is a pity not to do so.
  24. hfg2

    Depth of Eyes

    Sorry, but I fail to see the difference.
  25. It could be done in Blender, but there is some work and I dont think is worth the effort to go for this. The pes files can be decompiled in dpes files which are in some kind of a json format, human readable, anyone can take it and interpret the values. I'm looking into Unity/Unreal maybe it might be possible to make a similar game, obviously without the constraints imposed by this old game engine. At some point, I'm sure that "the hero we all need" will make a step forward and build such a game. And you dont have to PM me, is enough to quote my name or call me directly in the page using "@". Like @Hoho
×
×
  • 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.