DAZ characters in SideFX Houdini
d2houdini
Posts: 34
Hi all!
I wanted to share something I've been working on, to see if any one else is interested 
I'm trying to bring DAZ content to Houdini - but not as a FBX import. Rather, my goal is to have a full, native parser for a DAZ Studio content library, directly in Houdini, with many of the same features found in DAZ Studio.
The primary reason for tackling this is that DAZ Studio has a huge library of characters and supporting assets, all of which are based on a few core character definitions. Having a way to import these characters into Houdini agent simulations and FX projects seems like it would be super-useful for technical / FX artists. The use of a common base character mesh, with switchable variations, means that procedural adaptation of these characters in Houdini would be very tweakable and portable, and could become a great basis for procedural workflows that can be expanded simply by adding more characters to a library from the DAZ store.
In the current (VERY alpha) version, I have the following features working:
- Parse a DAZ Studio Library folder of DSON files
- Build a library of nodes, materials, geometries, UV sets, and modifiers from these DSON files
- Parse DSX files to discover available characters
- Select a character to load in Houdini as a Houdini Digital Asset (e.g. Victoria 8)
- Parse the DUF scene for that selected character
- Make connections between modifiers, channels, functions, and operators to populate the scene's properties for that selected character
- Create a KineFX skeleton for the selected character, natively in Houdini
- Create a bound, weighted Houdini skin geometry for that KineFX skeleton from the DAZ geometry definitions, natively in Houdini
- Create packed primitive geometries for head and body morphs, pose and joint correction morphs, and any other geometry modifiers
- Apply character shaping morphs and joint offsets to match each character's custom shape and skeleton
- Apply pose and joint correction morphs in response to changes in the character's pose
- Translate Iray materials into Mantra or Redshift materials via Houdini material stylesheets
Of course, there's a lot that isn't supported right now:
- Props
- Clothing
- Hair
- Lights
- Camera
- Multiple geometries in a scene
- Basically, anything that isn't a single skinned character
…and the material support is still a work in progress, with some notable gaps:
- Mantra's subsurface scattering (SSS) implementation leaves a lot to be desired
- DAZ's volume shading for skin is hard to translate into Houdini (or at least, I'm still working on how it might translate)…
…but nonetheless: it's a start!
The current project is a combination of Python (for the library parsing and scene construction), Houdini digital assets (for the library node and character node), and custom Mantra / Redshift shaders.
One thing I've been wondering is whether the "parse a library, build a scene, and resolve formulas and channels" code could be broken out into its own Python module, and possibly open-sourced for the greater good. It strikes me that this could be useful for other projects too, and I know folks on these forums have been working on bringing DAZ content to Blender via Python, as an alternative to the (already very nice) DAZ to Blender Bridge. If there's interest in making this part of the project more widely available, do let me know. Everything in that part of the code is based on a deep read of the DSON documentation, combined with a lot of trial and error, plus spelunking through a variety of real-life DSON files. (I'm immensely grateful to DAZ for making the DSON File Format Specification available - I would never have got this far without those docs as inspiration.)
Anyway: here are a few Redshift / Houdini renders of Victoria 8 to show where things are at. Thoughts, questions, and suggestions much appreciated!
– Dave
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
It is impossible to exagerate how this would be a game changer. I don't have much Houdini experience yet, but I have gleaned a certain body of SDK experience, and I've traversed some of the relationships in DSON files. If I can help you with something, please don't hesitate. Both Houdini and DS have native C++ SDKs.
To me, most important are that JCMs work, and that there be an option to export to Houdini the already subdivided model, instead of just the subd cage and allowing Houdinu to subdivide it. This is because small differences in the way subd is implemented can cause the model's appearance to change in subtle but annoying ways.
Thanks, what you are doing is very exciting... so much is happening right now that it's difficult to keep up.
Thank you!
I agree that JCMs are a #1 priority. I had previously tried various approaches to using DAZ characters in Maya, and while I had some success, it always felt like the export from DAZ Studio had to be perfect for everything to work as expected. And more importantly, if you wanted to change the DAZ character, then you would basically have to start over - i.e. none of the process was procedural. This was one of the things that led to me looking for other tools – and of course, nothing is more procedural than Houdini.
My goal with this Houdini work is for the base joint and pose morphs to be applied automatically as you pose the character in Houdini. To that end, I split the modifiers for a character into two groups:
All of the pre-pose modifiers are applied when the character's geometry is created from the library scene (by setting calculated weights on blend shapes, or by changing the transforms of joints). All of the post-pose modifiers are applied by setting weights for JCM morphs in response to the current joint rotations. That way, only the post-pose modifier weights need to be updated in real-time, which keeps things performant. So far, this seems to be working well.
As an aside to that: I've also been experimenting with using Vellum (Houdini's cloth simulation tool) to fix self-collisions for the posed body geometry. One of the things that bugs me about 3D human renders is that you can always tell when the joint correction morphs have been pushed past their limits, and (for example) the character's calf and thigh have ended up intersecting, causing subsurface scattering glitches. These kinds of intersections are super-annoying to fix manually, and I haven't found a good automated solution, or at least not in Maya. With my new approach in Houdini, I've been able to paint weighted attributes for "fleshy" parts of the body like muscles, and run a Vellum sim to resolve those intersections. The nice thing about this is that the painted weights are topology-specific, and so the Vellum weights for any base character mesh should always be the same.
It's interesting that you mention an export of the DAZ subdivided model. One of my principles for this project has been "no exports from DAZ, ever", with a goal of keeping everything in Houdini, including all of the library parsing and geometry generation. I'm hoping to be able to replicate DAZ's subd in Houdini "precisely enough", but you make a good point - even small differences in the subd algorithm can cause the appearance to change. That said, if I can add support for DAZ HD morphs directly in Houdini, then in theory I can use the known-matching geometry topology to ensure a perfect match between base and HD meshes within the Houdini scene. (This was another thing I could never get to work to my satisfaction in Maya - even with a tool such as the excellent seUVBlendShape, I could never quite get Maya's subdivision of the exported base mesh to match up with a DAZ OBJ export of the same HD mesh, because at some point, floating-point precision became an issue. If it's all generated procedurally, however, then those problems should not occur.)
Thanks again for the kind words about the project - they are much appreciated! I've attached some more Redshift renders of a few different characters, to show how it is working for a variety of models (Daz Dog 8, Aiko 8, Ollie 8, and Michael 8.)
– Dave
@d2houdini
Open source project or do you intend to go through the Daz Store? If you're open source, you could probably learn a lot and save a lot of time by studying the excellent Diffeomorphic plugin. Thomas, the author, is active here and he's done an admirable job of reverse engineering things where there's no point in you duplicating effort.
Apparently 18.5s' retargeting in KineFX was not enough to get people excited about Houdini, but maybe your idea about using vellum to fix self-interactions is just the sort of thing that might.
And yes, assuming that by "no exports from Daz, ever" you mean to favor the DSON, I am with you on that. The C++ SDK documentation is often less than helpful, while at least the DSON has structure that is documented and is self-documenting in many ways. I think Daz has given up on updating the DSK interfaces to support new features and just rely on the DSON spec. I couldn't figure out SBH nor geografts from the SDK but I think I found them relatively quickly when I started browsing the DSON files.
In any case, I'm anxious to see whatever it is you release, and however you plan to release it. Again, these are exciting times.
I guess I assumed that Houdini is primarily used by commercial FX companies, and that they would, almost by necessity, be focused on making their own custom characters, based on the artistic needs and requirements of whatever commercial projects they were involved with, their internal workflow and software, etc. Do commercial FX companies actually use, for example, a stock G8 character? I guess I assumed they'd need to make custom face/expression morphs and have them specially rigged for whatever animations they were doing and so on. Am I off base on that?
Thanks.
Rather than speculating check the change log - there are multiple references to updating the documentation. However, for compatibility what we can currently download is the 4.5 SDK - when the update for Big Sur breaks all compatibility with existing plug-ins we may hope the SDK and documentation will be updated.
Yes, and I should probably clarify something on that: my "no exports from DAZ" principle isn't a sleight against DAZ Studio, or its SDK / plugins / export flow. DAZ Studio is awesome :) The "no exports" principle is more of an attempt to use DSON as a portable asset definition format, and to create geometry and skeleton nodes directly in Houdini without the need to round-trip via another tool.
Is that @ThomasLarsson? If so, I would love to learn from Diffeomorphic - Thomas and co have done a great job there.
The bit I am most interested in open-sourcing is the DSON library and scene parsing code I've written in Python that links together all of the modifiers, morphs, channels, functions, and operators in a DAZ library, and calculates their values for a character based on the scene contents and pose. That's the bit that seems most reusable by other projects, and it would be great to get more people involved in making it reliable for a range of characters and scenes. It's the missing piece for "direct from DSON", and while I'm sure there are many things I've got wrong, it seems to kinda work.
For hero characters, I totally agree - VFX studios are already creating their own custom characters and geometries in those cases. But Houdini is also widely used for crowd simulations, and that seems like a place where a large library of existing characters, body shapes, and clothing variations could be great for filling in backgrounds. This is especially true when all of those characters share a small set of common geometries - Houdini is smart at instancing the geometry in these kinds of cases, to optimize performance even when working with large crowds.
I'm also interested in opening up Houdini as a place for DAZ artists to explore simulations beyond what's already possible in dForce. Being able to start with a common mesh, and then add custom guide-based hair grooms with physics that can adapt to any character shape, seems like a super interesting opportunity, for example.
I'm really excited to see how you tackle in bringing Daz characters to Houdini in a convenient way. Although I really enjoy using Blender with Diffeo, the potential in using Houdini as a one man team is enticing. I'm looking forward to seeing how Houdini will develop its character tools in the next couple of years. Being able to work procedurally with character rigs for example will save so much time going forward.
Yes, that's our guy :)
A framework that does what you describe is the sine qua non of DSON reaching its full potential as an interchange format. If there were such a class that represented a Daz character in an abstract way with a good OOD design, then there could be various concrete output filters, one for each target application and bringing Daz content to a new environment would not require knowing anything about Daz at all.
I'm getting carried away, but think if your tool allowed two-way editing, i.e. it could dump a .duf file from its internal representation? You could manipulate characters to a certain degree without Daz Studio at all. Big Sur and Linux users would kiss you. And what if there were a command line interface so that all sorts of things could be scripted and batched? The first tool I'd write is a script to scan your entire character library looking for diffs, so you immediately know if an update has mangled one of your production characters.
If you can pull this off, and it sounds/looks like you've already got a proof of concept, this will be far bigger than just Houdini... it'll turn the entire app ecosystem on its head and Daz content will be at the center of it all. I know we're basically talking about USD, but "universal" is sometimes overrated :) and I'd like something more Daz-aware that "just works".
You might want to introduce yourself to these people if you haven't already.
Best of luck to you, and please keep us informed of your progress.
Richard, a one sentence blurb about something in the SDK is not sufficient for a C++ programmer to start to actually use that facility in practice. In fact, sometimes reading the change log is an exercise in frustration because you now know that there's some new functionality in the main app that you want, but you have no idea how to access it because the update to the documentation the change log refers to is of the form:
DzApplication::getWidget() - get's the application's widget
I.e. completely devoid of any information one could not have inferred from looking at the function's name. Your comment is divorced from the practical reality known and experienced by anyone who has ever tried to use the SDK to do something non-trivial. And sometimes even trivial. I think we should all stay on message so that Daz might recognize this shortcoming for the major impediment to DS's evolution that it is, instead of indirectly suggesting that all the information is in there, and one just has to look for it.
I think it was at you - assuming this is not just a personal project how are you intending to release it?
HOLY GRANDMOTHER! Cant wait for further progress and more Info on your project!
@d2houdini
I've re-read your intro post about 10 times, salivating.
I'd like to make a direct appeal that you are, of course, free to ignore :)
It'd be terrible useful if your design cleanly separated the representation of the characters, etc, from the methods to import them into Houdini. That is, you developed two things instead of one tightly coupled tool: An abstract representation of Daz content that has no dependencies on Houdini at all, and also a Houdini output filter that depends on your first tool, but has no dependencies on DS at all.
This way you pave the way for others to write output filters for other apps, and they can even use the Houdini one you provided as a reference implementation. I did something similar with Sagan (but violating the "no Daz exports, ever" rule) where if someone now wants to add another export file format, it's easier for them because they only have to know about the abstract representation and nothing about Daz Studio.
Sometimes the success of an open source project, and whether it really takes off an starts to grow exponentially, is dependent not on how cool is the functionality it offers, but how easy it is for others to master your technology and start contributing to it, as well. A clean architecture that shields one from having to know the details about things one is not directly concerned with is paramount. For example, to write the diff tool above, I shouldn't have to know anything about Houdini's internals.
Eagerly awaiting the fruition of your plans, in any case, and of course, thank you for taking up this challenge.
Ah! That was just me confirming we were talking about the same Thomas :)
As far as releasing the Houdini work: I'm still thinking through the options, but more on that below…
TheMysteryIsThePoint said:
Aye, that's essentialy what I've been working on - a bunch of Python code that can read in a DUF scene file, link it to all of its dependent assets from other DSON files, and parse all of the above as a fully populated set of Python objects for the scene that can be adapted for any given use case. (A big part of that is crawling the Daz library folder on disk to discover all of the assets that might be relevant for a given character's scene.)
Fun as it would be to try, the one thing I am definitely not looking to do is to recreate all of Daz Studio inside Houdini :) Firstly, we already have Daz Studio; and secondly, that's a much bigger task than I think I could achieve. I see this more as a way to take all of the great content you've already purchased from the Daz store, and use it directly in additional tools.
Aye, that's exactly what I've been thinking. Currently I have a single Python module named "d2h" (nominally, "Daz to Houdini"), but I've been thinking that it would make sense to split it in two - "d2p" ("Daz to Python"), and "d2h" (for all of the Houdini-specific stuff). The former is for reading the library, parsing a scene, and resolving formulas and operations into general-purpose Python objects; the latter is for creating Houdini geometries and skeletons from that content (together with a bunch of Houdini digital assets to integrate them into a scene).
To bring that back round to Richard Haseltine's question: I'm considering that "d2p" would be a good candidate for an open-source project, which could form the basis for all kinds of community-created tools, and might even be of use for the Diffeomorphic folks too (although I haven't spoken to them to find out!). The Houdini-specific stuff, "d2h", could be a better candidate for a closed-source product sold via the Daz Store, that builds on top of the open-source project.
- Dave
I spent a summer trying to figure out how to convert Iray skins to Mantra and never could find a satisfactory solution. Mantra's SSS at the time (Houdini 15 I think) produced tons of rainbow colored noise and I could never get a clean render that didn't take forever. I'm not sure how Karma's SSS stacks up now.
If you open source the code, I'd love to help contribute to it.
Dave, there is no part of that post that is not music to my ears. I'd buy it on Day Zero.
As far a reinventing DS, of course not. Once upon a time, about two and a half years ago, I had it in my head that I was going to make a movie using Daz content. That's how long the detour into developing DS and Blender tools has been for me... I only meant that the more you can pull in, the more other people can take your stuff and run with it, and the more crazy, I-can't-believe-someone-actually-did-that-with-my-script type things will appear. Never under-estimate the power of what you create in the hands of someone who is even more single-minded and dogged in attacking a problem than you are :)
Sorry, I missed this. The chnage log isn't the documentation, it says that the features have been added to the SDK and to the SDK documentation - but that is obviously not the 4.5 SDK that we currently have access to, hence my comment about when the 4.5 SDK is replaced.
Yeah, Mantra's SSS implementation seems kinda funky, and it doesn't support random walk SSS. I also found that as soon as I enabled SSS on their Principled Shader, I lost all of the more subtle self-shadowing on the face, because it only seems to take primary rays into account. That makes it pretty much a no-go for realistic skin shading.
I haven't yet experimented with Karma, but it sounds like it will have an improved SSS implementation. That said, it's still in beta, and it uses a completely different network type to Mantra and other production renderers, so I'm not sure it's quite ready for adoption. For now, I'm focusing my "match Iray rendering" efforts on Redshift, because they just released macOS GPU rendering support, and I'm a Mac user, so it's the fastest way for me to iterate
Yeah I switched over to Redshift after the failed adventure in Mantra only to discover Redshift couldn't render DAZ polygon hair due to multiple overlapping opacity layers. Did Redshift finally fix that limitation? Mantra and Karma have a skin shader too, but there is absolutly zero documentation on how to actually use them. I'm not sure if they use a different SSS algorithm or method than the principal shader.
Don't get me wrong, Richard, I would love to be wrong, for the 5.x SDK to be developer friendly, and to be sure that Sagan is implemented correctly. I just don't think that I am. It is frustrating because I've got other ideas for things that I think would be useful to Daz users of a certain kind, but I'm just not willing to go through the ordeal of reverse engineering even the slightest things while being actively ignored by the devs, who could probably set me straight with a single sentence, and not even a courtesy response saying that they're too busy. That is how you destroy community, not build one.
OK, I don't want to de-rail Dave's topic. The Python SDK is better supported than the C++, but he should still know what he's getting himself in for.
I haven't used Redshift but I'm wondering if this is similar to Cycles? Daz poly hair looked terrible for the reason you specified until I increased transparency light bounces to something silly high like 40-50+ depending on the hair. Wonder if it's similar in Redshift.
The devs would have to fit any help into their free(ish) time - a pause in coding or literally their free time. If you want them to do that, not tearing into their work on explaining the SDK functions might be a step in the right direction.
Seems to me that, as a member of the said community, I appreciate the efforts of both of you to help us all. Documentation has long been a point of contention and looks like remaining so in which case, it doesn't seem to me to be an invalid or harsh criticism. If it is, then we have all been guilty of being harsh at some point because there have been so many complaints about it. Indeed, the lack of documentation at some levels makes it necessary for you, Richard, to spend an inordinate amount of your time answering questions and you can't really give the usual moderator response of RTFM.
Perhaps, as in the case of people like the OP and Donald being willing to write add-ons for DAZ Studio for free, there might be volunteers willing and able to write the manual if the developers are willing to give them access to the information? Just a thought.
Anything new over the past month? Really interested in this topic.
I found a Houdini tutorial course super cheap and am planning on picking it up in the next month or so. Being able to bring Daz characters into Houdini would be an amazing thing.
I wish I could wake up tomorrow and mysteriously be an expert with Houdini. Unfortunately I've got about 100,000 hours of practice ahead of me before that happens (will my life be long enough? I have a day job). From incomprehensible tutorial to incomprehensible YouTube tutorial, with subtly different versions and user interfaces, I've tried and failed many times!
Anyway being able to load a Daz figure into the scene (non-FBX) would be great. Things like tessellation, dual quat skinning and so forth. It's missing from the set of Daz exporters too.
If you wanna learn houdini, may advice would be to ignore all those cool looking VFX tutorials, at least at first. Take a course or ten just on the programming language used called vex. Unless you understand vex, those tutorials will be frustrating as hell. You will run into issues like nodes being renamed/combined/vanishing and whatnot, if you understand the language it will be a lot easier to troubleshoot those issues. Houdini changes a lot and getting a tutorial using the latest version on what you wish to learn can be hard or impossible sometimes lol.
Attempting to learn vex had an interesting side effect for me. Now I can crack open DS scripts and files, and it doesn't looke entirely alien to me. I can understand some of it, and what it is trying to do.
Would love to know how this is progressing as well and hope DAZ can see the value of supporting a functional Bridge between DAZ and Houdini.
+1 on a Daz to Houdini bridge, although it seems all the official Daz bridges to other software incorporated existing solutions.