Daz 3D
Daz Productions, Inc
224 S 200 W, Salt Lake City, UT 84101
Daz 3D is part of 
JOIN DAZ
Daz 3D
Daz Productions, Inc
224 S 200 W, Salt Lake City, UT 84101
Daz 3D is part of
Daz 3D
Daz Productions, Inc
224 S 200 W, Salt Lake City, UT 84101
Daz 3D is part of
JOIN DAZ
Daz 3D
Daz Productions, Inc
224 S 200 W, Salt Lake City, UT 84101
Daz 3D is part of
Comments
Am I really that bad at communication?
I had thought the 3rd party developers had already and the original developer simply integrated the 3rd party contributions and committed it. I may of read the bug report incorrectly though as well and they just reported bugs instead. Multiple people have submitted bug reports that have wound up triggering fixes; which is just the same as contributing code for all intents & purposes.
au contraire.
--ms
We may just need a linux/mac programmer to compile the c++ hd exporter by Donald aka @TheMysteryIsThePoint. If you may want to try it, there's the daz plugin to compile.
https://bitbucket.org/Diffeomorphic/import_daz/issues/191/possible-speedup-for-the-hd-exporter
I have both macOS and Linux. I'll see what I can do.
Thank you. Keep using v. 1.4.2.
Hi. Tested and these are the results (G8F character):
Standard and HD res:
- Only HD morphs were imported + cheekcreasel and cheekcreaser, all as shapekeys (not listed in the add-on).
- Morphs were loaded only via "import custom morphs" from \My DAZ 3D Library\data\DAZ 3D\Genesis 8\Female\Morphs\DAZ 3D\
- When creating MHX rig I got the following error message:
Traceback (most recent call last):<br /> File "C:\Users\PICHAU INFO\AppData\Roaming\Blender Foundation\Blender\2.90\scripts\addons\import_daz\error.py", line 247, in execute<br /> self.run(context)<br /> File "C:\Users\PICHAU INFO\AppData\Roaming\Blender Foundation\Blender\2.90\scripts\addons\import_daz\mhx.py", line 541, in run<br /> doHardUpdate(context, rig)<br /> File "C:\Users\PICHAU INFO\AppData\Roaming\Blender Foundation\Blender\2.90\scripts\addons\import_daz\mhx.py", line 1254, in doHardUpdate<br /> activateObject(context, ob)<br /> File "C:\Users\PICHAU INFO\AppData\Roaming\Blender Foundation\Blender\2.90\scripts\addons\import_daz\utils.py", line 205, in activateObject<br /> context.view_layer.objects.active = ob<br /> RuntimeError: Error: ViewLayer 'View Layer' does not contain object 'Basic Wear Shorts'location: <unknown location>:-1----
Daz Bridge is Open Source. Maybe you could combine efforts and develop a nice Daz to Blender export.
Regards.
With respect, no, that is not at all the same as contributing code, for any intents nor purposes. In the most important way, it is indistinguishable from the closed sourced model. The crucial difference is the diffusion of knowledge.
In the documentary "Revolution OS", the very Richard M. Stallman himself, the father of the Free Software movement, spells it out the difference. I am paraphrasing, but he says when the code is locked away in a "Cathedral" and few people understand it, it should not be surprising when the pace of adding useful features is slow, and support is both expensive and bad. But when there are dozens of experts around the world, in not a "Cathedral" but a "Bazaar", the pace is fast and support is cheap and good.
Imagine if we didn't have one Richard Haseltine, but a hundred Richard Haseltines.
Imagine if the code didn't have functionality that you wanted, you could get one of dozens of people to add it. Or even do it yourself.
So, to the people who founded the movement, the whole point of opening the source code is to maximize the number of people who can understand and improve the code, not just see the code. To that, I add my own observation that every open source project that has dominated its respective area has a strong community.
I think the most important thing being overlooked by Daz is this: If you are still thinking in closed source terms, you may think that dumping 11K lines of code is sufficient because everyone who will see it is being paid to look at it 8 hours per day. In some cases that may even be true. But in truth the vast majority of would-be contributors have other full-time jobs by which they earn a living and donate what little spare time they have to a project they'repassionate about (sound familiar?) for free. These people technically could, but do not have the time to swim through 11K lines of code that has not a single [email protected]#$ comment in the whole [email protected]#$ repo, and no one to give a hand up in understanding it.
Without a community, you get DTB and one guy making commits. With a community, together you dominate your field.
It's just straight ISO C++11/14 with no dependencies beyond the SDK. The task would be to just figure out how to build a plugin with the SDK for MacOS. That done, sliding the HD exporter code into it will be trivial. Count on me as a resource for whatever you need; I just don't know anything uniquely Mac related.
Please, for the love of God, no!
Oh, that's already been make into a Kate Bush music video called "Running Up That Hill."
What do I need to download?
Thanks for taking this on... I'll be as much help as I can and I'm certain we'll get through it. And then you'll be a plugin developer.
First, you'll need a C++ dev environment that can compile C++11/14. I don't think I used any 17. That should be any compiler released in the last several years. I can be of approximately ZERO help with this part.
Second, they say the Daz C++ SDK is cross platform, so get that. It will have several examples, not all that build/run, but I think there is one working one that builds a dialog box, and that's the one closest to what we want. If you can get that to build and load, we're ready for step two. I think I can actually be a resource for this task, as underneath that pretty GUI, it's a POSIX environment so at least certain things will be familiar to me.
Third, I'll give you the code for the exported, and you can just hack the example to throw up a dialog with a big red "export" button that calls the code. Or maybe I'll do that and just give you the code, and you can figure out how to make it build. Not having done any Windows programming in a looooong time, I recall that building the plugins with Visual Studio was more "pain in the neck" than actually difficult. Well, that and laughing at how ridiculous Visual Studio is about certain things.
Okay, maybe not a hundred, but some factor greater than 1. You get my point :)
I feel like I'm being attacked here, so let me explain a little bit of my open source experience before I get accused of not understanding it further. I came to Daz from a company that made open source software, I've consulted a Fortune 100 company on developing their open source business strategy, I was invited to speak at an open source conference while I was still in high school and I have co-founded a project that was given an award by Linus Torvalds himself. So, hopefully those credentials will let you give me a little benefit in that I understand what open source is.
As far as the project being a big blob of code. Yup, sure is. I fought to get these projects released as open source so that over time we could hopefully make things interesting enough that the community would want to be involved. Are we there yet with having bridges that are super exciting for the community? Nope, but hey "Rome wasn't built in a day, but they were laying bricks every hour." (they always leave off the second half of that quote which misses a lot of the meaning). So instead of releasing the bridges and then open sourcing them "sometime in the future" we released them with the launch of the bridges and I think ya'll will agree on that being the right move.
@DAZ_Rawb
First, let me say unequivocably that I have nothing but gratitude for you and efforts. I understand that everyone does what they can, and it is not always everything that they would have liked. When I write that Daz doesn't understand Open Source, I am not referring to any individual as if it were their fault, rather I am referring to the decision-makers who have not given it priority: Why did you have to fight? I mean, I am glad that you did, but why should it have been hard? The bridges were texbook candidates to be Open Sourced.
Again, thank you sincerely for making this happen in the first place. I hope that Daz prioritizes engaging a community in the future, and not just for the bridges.
No show-stopper bugs have shown up in RC2, so it now becomes the stable version 1.5.0. RC1 has been deleted from my dropbox account, to make sure that nobody downloads that by mistake. The development version now becomes 1.5.1.
DAZ importer v 1.5.0: https://www.dropbox.com/s/scoe4umsrnh8z5x/import_daz-v1.5.0-20200918.zip
Documentation (wip): http://diffeomorphic.blogspot.com/p/daz-importer-version-15.html
Is there any way that I can edit the first post in this thread? It still points to the deleted RC1.
I don't know if this is a bug or an operator error but when I export HD to Blender, in the scene collection window the mesh at the bottom with "HD" added to the end is actually the base mesh and what is supposed to be the base mesh above is actually the HD mesh. I followed the process of saving the scene in Daz as high resolution then switching to base resolution when saving the dbz file as I remember reading something about needin g the dbz file to be at base resolution to get the correct reference points or something like that. Am I supposed to do the same when using the HD export script (save scene at high res, save dbz at base res) or am I supposed to leave resolution as "high" when using the HD export script (save scene at high res, also save dbz at high res) ?
Edit: only just noticed this since I've upgraded to the latest dev build. Unsure if this was there or not in the previous 1.5 build I was using.
Edit2: No matter what I do or what mesh I select, the bake normals button is greyed out but the load normals button is clickable, this seems also opposite to what it should be?
You don't need to switch to base resolution any more. The export scripts do that automatically, see the update to http://diffeomorphic.blogspot.com/2020/03/mesh-fitting-without-spurious-smoothing.html. You should definitely not use base resolution with the HD export script, because then all subd levels are lost. The bake button can only be used if the active object has a multires modifier and the blend file has been saved.
Good to know, all working as it should be now, operator error it is lol. Thank you.
If you put your mouse on the upper right corner of the comment box you want to edit, the edit cog should appear. Unless the forums here has some kind of time limit on when you can edit it.
Thank you.
I'm just happy the bridges excists. Thank Daz
Thank you for your hard work @ThomasLarsson, if you want to be able to distribute your plugin through this store instead of just a personal dropbox account let me know. I think the ability for DIM to give people automatic updates would be pretty nice, but if you aren't interested no worries either.
Oh my gosh, being able to have DIM automatic updates would be A-MAZING! I spent about an hour earlier this week trying to reconfigure everything with the new development version that was released. In the end it turned out the importer didn't like the Sunny Days 1 dress and that was the entire issue, but I kept thinking I was doing something wrong as I am not well versed in the technical stuff and 100% believed it to be a user error, so I kept fiddling and tweaking when all I had to do was change her clothes! I think ultimately it didn't like that I had dForced the dress, but whatever version of diffeomorphic I was using back in April, I was able to import dForced clothes right in so I don't know.
But as always, thank you, Thomas, for working hard at this tool, and thank you, Daz_Rawb for working hard at making everything possible on your end.
This would be good.
Distributing the plugin through DAZ Store sounds great, but I need instructions how to do that. Thank you.
I would still Like a manual Update/download option as I don't use DIM, my production machines live offline ALWAYS.!!!
Cheers,
S.K.
@ThomasLarsson I've animated a character in Blender using rigify, animation plays and renders great in either Eevee or Cycles. I am trying to export to render in Unreal as its a much better render engine for my needs (it sits somewhere between Eevee and Cycles for quality as it incorporates ray tracing and has great post processing effects but its also MUCH faster than Eevee, actual real time instead of semi real time), the problem I'm having is getting animated morphs at higher than base subdivision exported by FBX. I can either get the animation with animated morphs/shapekeys exported but with no subdivision (a jaggy edged model, roughly 36k tris, which defeats the purpose of using a better render engine, baking normals doesn't get rid of these hard edges or smooth the base model to the equivalent of subd1) or I can get the animation exported by FBX at subd1 to subd3 and plays brilliantly in real time in UE4, jcms seem to be mostly working but no animated morphs/shapekeys can be exported by FBX if the subdivision modifiers are enabled.
The only other thing that possibly works is alembic export but that comes with its own set of problems, some animations work, others mangle the mesh, udim tiles are not exported correctly, the entire mesh is one udim instead of having legs, arms, torso, etc slots so I can't reapply materials in UE4 like I can with FBX. Is there any way at all that blender can export the higher subd animated mesh complete with the animated morphs/shapekeys as FBX or any other method? Is there a setting or step in the diffeo plug in I'm missing?
Thanks.
I'm switching to v1.5.0. Still having issues with loading morphs at the Corrections step. For instance:
- BrowUp-Down<br /> - BrowUp-DownL<br /> - BrowUp-DownR<br /> - CheekCrease<br /> * CheekCreaseL<br /> * CheekCreaseR<br /> - CheekEyeFlex<br /> - CheekEyeFlexL<br /> - CheekEyeFlexR<br /> ...I could import them as custom morphs directly from the character's folder and /Daz 3D/etc folders as well. I'm not using the standard Daz folder for the Libraries, but they were updated via Global Settings / Load Root Paths.
The materials are very faithful to the original Iray shaders, and MHX rig is fast.
I'm not familiar to Daz internal policies, but you could offer your plugin as an alternative to Bridge, as a Published Artist or via Daz Central.
Thank you for your hard work. The Daz to Blender importer is a crucial link for my project.
Regards.