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
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Yeah, I will mess with it for sure. Got sudden work, so less time to play now.
Hello guys,
I have problem with model faces in blender after import alembic file (which I created with great sagan alembic export plugin). I tried flip normals, smooth shading.. nothing works.
Any idea what doing this problem?
What's the status of Sagan at the moment? The geograft question is critical for me because all of my characters include them. Just to explain: the first thing I do when I buy a figure or character is to morph it to my own preference, add the geografts, run it through Scene Optimizer to reduce the texture sizes and save as a scene or Scene Subset.
I haven't been able to play with Blender for a while because I have a non-graphics related project which is taking almost all of my computer time. Actually not a bad time to be somewhat removed from DAZ Studio considering the debacle happening with the store right now.
I'm sorry @ondrej_60d75954 I don't know how I missed this message.
Blender is rather a moving target. You have exported a single frame, correct? Then turning off Smooth Normals in the Vertex Group tab should fix it. If I remember and understand correctly, @Padone has suggested simply never exporting normals, and letting Blender calculate them; I just haven't gotten around to trying it.
This also tends to happen in Cycles with Diffeomorphic textures applied, and is due to uv map differences, and there is a script to fix that in your export's scripts directory.
Let me know if the fix works.
@marble I haven't figured this out yet, it's undocumented, but I was able to get what I wanted with a geograft by simply ignoring the extraneous surfaces and saving that configuration. Does this workaround not work for the time being?
Dunno, it might if I knew what you mean by the extraneous surfaces. You overly-clever guys tend to assume that we mere mortals have the same level of knowledge that you have. Just to be clear - I know what the word "extraneous" means and I guess you mean I need to select and ignore them in the Surfaces tab within Sagan? If so, which surfaces are considered extraneous?
extraneous surface = the one that is duplicated. I.e., the one that appears twice in the list.
Ignoring duplicate surfaces works for anatomical elements. Im not so sure it works very well with other geografts - like the metal arm example i posted a while ago (it was either in this thread or some other related thread).
I'm looking at the surfaces list now but I don't see any duplicated surfaces.
Ah, wait a minute ... I see surfaces under the main figure and also surfaces on the geograft objects. OK, right - so which of those do I ignore? Either?
dont remember. i assume the one by itself - i.e., not the one that's with the figure surfaces.
I'll give it a try when I have a few minutes. But thanks for pointing me in the right direction - I had not noticed those duplicates in the expanded surfaces in the Sagan utility.
@lilweep Thanks for the assist.
@marble I would do this:
Import all the surfaces into Blender. Go into edit mode, and in the materials tab, select each material slot one by one, making a note of each one you don't want. The material slot names will be the names of the surfaces to ignore in Sagan.
As @Padone cautioned me, this may create "non-manifold" geometry (geometry that cannot exist in the real world because it is infinitely thin, intersects, etc) that certain shaders don't like, but give it a try until I figure this out.
I think the Diffeo plugin has a trick to hide the unwanted surfaces - maybe @Padone can explain how that works?
@marble
The issue is that the geograft materials often come with a shell because they need a different uvmap and iray can't handle uvmap overlays the same as blender does. For this reason diffeo doesn't import the shell geometry and it only imports the shell materials as an extra material layer. Then the shell itself is ignored and the geograft is merged with the figure with the extra material layer.
To better illustrate this in a real scenario I can use the headlight geograft by Meipe where I changed the shell offset to 0.5 cm. We see the offset in daz studio but we don't get it in blender. The wireframe should be fine with the daz nudity policy.
edit. Then there's a merge shells option in the global panel and actually Thomas is working around shells so I myself am trying to figure out what he did exactly. But overall this should be the idea.
https://bitbucket.org/Diffeomorphic/import_daz/issues/249/shell-color-lost
@Padone - thank you for the explanation. I'm wondering what implications this has for Sagan. I imagine that it is more difficult because Alembic is a polygon-for-polygon exact copy so that would automatically take the shell polygons too, right? I have the Meipe products and even in DAZ Studio there are some problems with clashing geo-shells because the Headlight shells clash with the Golden Palace shells. Meipe had to work around this with fix scripts.
@marble
OK, I feel your pain; I had my first run-in with geo shells exporting the Cobra Queen. It's quite confusing; it resulted in three objects: one for just the geograft part, one with the original part with the geograft in it, and a third part that looks nearly identical to the second part. And the materials were all mixed up.
I don't know what the difference between the second and third objects were, probably UVs, but they had the same material slots and I was actually able to texture both by exporting the textures, setting the nodes up manually, and renaming them with the script so it'll just work next time. After I figure out the HD/Geometry Editor bug, I'll modify Sagan to better name the objects and materials to make working with geografts easier until I can fully understand it.
But from my experience with this particular model, I am not at all sure that geografts work in a universally consistent manner. It would be difficult to get to work perfectly if there's flexibility in the way the PA can implement it from model to model.
My attraction to Sagan is that I can do most of my posing and scene setup in DAZ Studio (which is admittedly my comfort zone and will probably remain so) and then just send it over to Blender to render. Even better for animation. So having an identical figure complete with any grafts would be welcome. Otherwise I could transfer with Diffeo but there are so many options and things to understand with Diffeo that I have become a tad confused - especially with morphs and HD.
@marble As for diffeo the HD exporter has been simplified and now it doesn't duplicate anymore the non-HD objects. A tad better to deal with.
https://bitbucket.org/Diffeomorphic/import_daz/issues/217/parenting-and-pivot-issues
Version 1.16.0.0 is up.
Read the release notes for some interesting things for this version as well as the future.
The biggest thing on the horizon is for a streamlined workflow to retarget all the major sources of mocap, i.e. ActorCore, Mixamo, Rokoko, Perception Neuron, ipiSoft to G8Fs and G8Ms using Houdini 18.5. And this will be honest-to-goodness retargeting nearly on the level of HIK, not just simply renaming bones and copying rotations. I've hired a very good Houdini hacker to work this stuff out on the Houdini side and he's made great progress.
Holy shipoli, pinch me I must be dreaming lol. Plz tell me he is doing a material convert on the too lol.
Ha ha, no :) Literally Thomas is the only one crazy enough to attempt it, and also the only one good enough to actually succeed (with @Padone's help).
But it still looks promising already; check the fingers...
Houdini/Daz Retargeting
Bummer lol. Seems I didn't understand the plugin lol. Still, pretty cool. I am sorta getting the hang of basic vex script, so in like 50 years I will probably be able to do somethin in houdini :P
Also, I needed to do some debugging in Blender, and so I had to build it from source. I built in on a TR, so stuff was scrolling by pretty darned fast, but I did catch something VERY important:
Blender 2.93 builds with Python 3.9
This may not seem so important, but that version of Python supports... drum roll, please... Shared Memory.
This means that a C++ plugin in Daz Studio could communicate directly with a Python Plugin in Blender to instantly share information. This means that a protocol could de developed so that Blender acts as a master, and Daz Studio as a slave. No more janky Alembic, BVH, FBX support. No more diffeo export scripts (Thomas willing, of course). Just Blender talking directly to Daz Studio to get the data that it needs. The problem with much of the file formats is that they solve general problems of interoperability, most of which we as DS users don't care about, and are not aware of DS specific idiosyncrasies. Even USD is bound to not support something in DS.
I would love to work together with all interested parties to come up with this protocol that would essentially abstract away all the details, and produce a platform agnostic model of Daz Studio's scene data that could be used in any software package that has support for the protocol. It'd be open source, so that is conceivably all of them.
I wonder if he'd be interested, if the price were right. I'll ask him. He could probably do it, based on the way he has thrown solutions to my petty little Daz problems back in my face.
If I understand you correctly (and that's admittedly highly unlikely), you are talking Holy Grail stuff now.
I think you do. And just think of what we'll accomplish with the pledged help from Daz. These are great times... there are exciting developments everywhere one looks.
my two remaining braincells cant make sense of half of what is said in this thread, but what i understand im liking
Seems to me that there is an alternative development model evolving at the moment with this software. I'm seeing DAZ open up to independents who are willing to share their skills and I'm seeing those independents adopt a kind of Blender-like cooperation. This must surely be a win-win for all concerned, right?
Alongside this we are seeing developments elsewhere which make it even more critical for DAZ to up their game and any help from the community should be welcomed and encouraged. Just looking at the quality of the new MetaHuman figures just released from Epic, DAZ must be concerned. While I'm not sure that the Unreal environment would be right for me, I would love to see some steps in that direction for DAZ Studio. If that means an expnded ecosystem involving Blender and Houdini, for example, then why not?
I agree 100%... If Daz is true to their word to help third party developers, and my first test is coming up soon with strand based hair, I think there will be some very cool things happening with Daz from many indeendent sources. When you think about it, we're all still in the most basic stage of "how do I get the asset out of Daz?" When we all consider that a solved problem, attention will shift to higher level, cooler things. But it is certainly a win-win. If I couldn't get my characters into Blender/MD/Houdini, the allure of those applications is stronger than even the coolness of the Genesis framework and its talented PAs, and I wouldn't be using DS at all. But because I can, I buy Daz assets prettyn much every day.
Whether Daz new openness was a result of competition or not, I'm just happy for the change. DS is such an awesome app and it was frustrating to not be able to really feel like I belonged to its community.
I believe that if Daz supports the community the way they are saying the will, third parties are going to come out of the woodwork to improve it and its capabilities will approach what we're seeing from Epic. I, for one, have lots of tools that I wrote to solve particular issues of my particular pipeline, but haven't told anyone because they're hard to use right now, unreliable, and/or are not integrated into DS simply because I didn'tmknow how nd don't have the time to, or am frustrated with, learning how. I assume the same is true for many, not just me.
I think DS is going to start moving forward much faster because of community envolvement.
Another test for Daz coming up is something that @Richard Haseltine brought up. I was assuming that v5 was just enough changes to link Qt5, but he correctly pointed out that there's surely innovation having nothing to do with Qt5. So the tests will be how fast the new SDK is released, and how well it is documented. I swear, if they change everything in DS5 and document the SDK in the way that they did v4.5, that just might be it for me and Daz development... I'm not going to start over from zero, not when I've got the source code for Blender and UE, and Houdini has such a slick dev environment. But I have hope that this time will be different and Daz will help us help them.
@TheKD OK, Alex said he could do Iray to Houdini material conversion, already had some preliminary work done on it, but the price he quoted seemed awfully low (I hope he's not reading this) which makes me wonder if he appreciates the complexity. But then again, he's done nothing but prove time after time that he appreciates the complexity of everything. I'm going to hit the "Hire" button.
Good lord... Daz in Houdini with materials.