The USD Exporter hidden in DAZ Studio
TheMysteryIsThePoint
Posts: 3,020
In another thread, Richard Haseltine nonchalantly dropped a nuclear bomb: When you choose File | Export and select *.blend, you'll get a dialog with an enormous number of options. One is USDZ with Material-X.
I have not tested it thoroughly, but so far it has probably the best DS to Blender material conversion I have ever seen.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
So, we could combine this with Sagan or Diffeomorphic?
Replacing the material after import. Sounds like a great option. Have to test it...
That's the scenario I'd like to test, too.
I don't see it in 4.23, do you mean the beta or the bridge ?
It's strange. It is under the second dialog that you get when you choose File | Export, and *.blend as the file type.
interesting - next time you're in there, could you check the specific version? (beta 23.1.x or general 23.0.x ?)
i'm away from my workspace.
tnx,
ms
4.23.0.1 general
Ok we need the bridge installed for this feature to work. It exports usdz that we can then import in blender. My first simple test is quite disappointing though, I just exported a basic G8F with the translucency changed to green, it doesn't seem USD can handle that, it rather exports basic textures and not materials.
Test scene included for everyone to try.
steps:
update.
I also tried to export with texture baking, to see if it could bake the translucency, but didn't end well I get missing textures in the usd file, it seems it doesn't work. Apart that texture baking takes forever to export. No errors in the log so I guess it worked as intended.
The exported blender file includes the baked textures so it works fine, but doesn't convert the translucency the skin is not green. Again it just exports the base textures and not materials, even with baking.
I had the same wrong result ~~ and the USDz option didn't export Cameras and Lights either.
tnx!
Sometimes such features slip through in a beta then get 'unreleased' when noticed, and I don't collect/save betas unless something like this pops up. Thanks also for pointing this out.
--ms
These exporter options were pointed out by Daz so I don't think that is an issue here - but they are features of the Blender Bridge
Where was this pointed out? That would be a good source of information that I should be following, but I can't seem to find it by Googling.
Pointed out to the mods so we could point them out to you.
Thanks Richard, good to know it's a legit release feature that can be relied upon.
fwiw, I always wrestle with tracking through the DS release notes from the forums. We (the DAZ coders and I) simply don't think the same way about presenting information. No fault - Toe-May-Toe, Toe-Mah-Toe, etc. but I actually wince when we get a new release message in the forums, knowing I get to go on my own little easter egg hunt, again, to eventually find what is invariably there, somewhere - and with no lack of detail, etc. After about 6 links through forum-entries and DAZ-docs, over the river and through the woods... I find it. again. Couldn't tell you how I got there when I get there though. Kind of like Bill Murray in Ground Hog Day, lol. Just one user's silly data point in case anyone cares.
@TheMysteryIsThePoint: I'm certain that you have the DAZ converter series github links handy, but for you or anyone else (Padone?, Thomas?, ...), there might be some handy USD technique(s) to glean from the DAZ-to-Blender code at:
https://github.com/daz3d/DazToBlender
fwiw, roughly web-browsing the repo, it looks like blender is doing the usd heavy-lifting in
/Resources/Scripts/create_blend.py
at around line 309.
I was thinking DAZ had locally added and integrated some USD libraries and was using them on the DAZ dll Plugin side, but my read is they're cleverly loading (some of?) the DAZ figure elements into a blender cli instance and letting it do the USD export with the Blender python libs (bpy) - which is fine and efficient. Perhaps this technique can be extended to include more than textures?
I'm as likely as not to be way off here, as I haven't looked at the underlying utility's logic *at all*, other than grepping around a bit to see where the usd output is being generated.
Anyone know the DAZ-To-Blender code-flow well enough to confirm or quash my speculation? Is this interesting?
cheers,
--ms
If so we could get the same result by exporting as usd in blender, apart that we have more control on parameters. This could also fix the baked textures in the usd file.
Hi MS,
It sounds like you've dug deeper than I have. But two things I can think of (now speculating on my part) corroborate what you are speculating: DTB needs to know where you Blender install is, presumably to invoke it and execute some kind of startup script. And that it can export without any dependencies on USD, presumably because it is actually Blender that is doind the exporting. Not gonna lie, that's kind of a clever approach.
For Hitchens, I initially took a similar approach, i.e. output a Blender Python script that recreates the geometry to be ran in Blender. I then changed the code to instead write the USD file directly in DAZ Studio, but write it as ASCII so there is still no dependency on USD libraries. If the user later wabts USDC or USDZ, there are other official tools to convert (the UNIX philosophy that a tool should do one thing only, but play well with other tools on the CLI). Because I eventually got DS to run headless, I can just pipe hitxhen's output to any downstream tool.
A major benefit I discovered /of this approach and the one I speculate that DTB takes is that it offloads much of the complexity born in the sometimes slight and sometimes enormous difference between DS and Blender onto the Blender devs, as you say. It is no longer necessary to decipher all the minutiae of DS armatures vs Blender armatures; you just write out a USD armature, which is the best documented, straightforward, and modern approach of the three. And it Quaternion based to boot. The work of converting USD to Blender is a problem, but it is no longer my problem.
I keep telling myself that one day I'm going to take a stab at materials, but I continuously talk myself out of it because I am certain that I would not do nearly as good a job as Thomas and Padone, but now that there is some open source C++, I could, at least theoretically. I think Padone already proved that it is pretty rudimentary, but I think I actually prefer the look of it.
Another benefit of USD is that it should also import (with armatures) into Houdini as well, where I'm trying to move as much of my workflow ass possible. At my day job I discovered a coven of Houdini gurus that make snazzy presentations to help customers see the big picture being sold. The more I use Houdini, the more I realize that it truly is undispuedly the best app out there. It's not open source, but its community is very, very open, and believe it or not, its a native version is UNIX, and the red-headed stepchild is actually the Windows port. So developing for it is an order of magnitude simpler than writing a DS plugin in an enviroment as terrible as Win32.
OK, I'm going off topic, maybe I was never, in fact, on topic, but with whomelse am I ever going to get to talk about stuff like this? :) My family and dog included have reached their individual saturation points.
BTW, not sure I ever asked you, but I always assumed you were a dev, but now you've said a few certain magic key words and I suspect that you are a UNIX dev specifically?
what's a "unix"? :)
fwiw, i especially appreciated the tech saturated dog and family scenario you draw up above. glad to be a willing and eager ear for your comments. i concur on your above notes, and am intrigued at how impressed you are with houdini, its foundations, and its culture. precious, that mix.
i've got some hitchens ideas you might find interesting, but i'm a wee behind on my ability to deliver on any discretionary promises of late, so i'll get ahold of you when i can do more than talk.
to the original topic, if DAZ-devs can/will hand the bulk of their content objects/elements to blender for conversion to USD, all the power to them - and us all...
cheers and keep in touch,
--ms
Hi MS,
I'd be interested in any comments you might have.
In short Unix is a closed source operating system. For a long time it was the most used operating system for servers. Linux is a clone of it. This is a rabbit hole and a half if you wan to know more. Just tunderstand my explenation is crude only becasue it's short.
@hardwire666
I think your explanation is a little too crude, even for simplcitiy's sake:
"UNIX", by which I think you mean AT&T UNIX, was not closed source, although it was proprietary. Research institutions and universities could get, and modify, the source code under strict licensing terms. That's where we got BSD from, and later all the other commercial variants
But there's really no rabbit hole; it's simple: Linux is not a clone of anything. It is an independently developed POSIX compliant OS. To say any different minimizes the incredible feat Linus pulled off... he didn't just port existing code to the 386 he had at the time, bro wrote a task switching, protected mode OS from scratch. It isn't certified by the Open Group, as far as I know, POSIX compliance being necessary but insufficient.
BTW, MS could probably tell us both about UNIX's history; I think you may have somehow missed the sarcasm dripping from that :)
per @TMITP above, I was being coy with that line/question, but seriously, thanks to you both for taking the time to explain it, as many in the 3D community may not have known what a 'unix' is, or its close design relationship to linux - which most folks have at least heard of. Interestingly, Iphones/Ipads/MacOS are unix(bsd)-on-mach OS-s and Android and it's family are a linux derivative, so 98% of today's phone users use a unix variant, even if we didn't know what a unix is... now we do!
cheers,
--ms