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
You can set a hotkey outside of Sagan. Mine's Alt-S.
I'm not sure what you mean by "incompatible", but probably, in the sense that the vert counts probably won't match, and they won't map one-to-one. v1.x did optimizations that v3.x no longer does. It was more important for the geometry to match than to gain an extremely slight performance improvement.
Nothing was "wrong" with it, it just made Sagan more complex for various reasons. Complex code means slower updates. But I agree, it would be nice for it to "just work". I plan to add it back with a separate utility. But I'm not sure it ever worked 100% correctly with geografts...
Well I'm out of ideas but I'm 99% certain that the key to getting it to work in Maya and it seems Unreal, lies in having a non-flatten hierarchy.
It looks like some applications can deal with importing it as is but others such as Maya and Unreal don't seem to handle it well.
This talks a little about it in terms of Maya.
I tested how a simple alembic from other apps/exporters come through in terms of the hierarchy, Specifically Blender, 3D Max and also Daz's "official" alembic exporter and they all come through with two layers in the hierarchy, at least by default.
Blender
Max
Daz Official Exporter
Well, that's pretty damning evidence :)
I'll diff the code, but I can't currently think of anything that I did to provoke the difference; the actual exporting code between v2 and v3 is actuall identical (or so I thought). I'll look in to it.
Thanks for all the insights!
Could you add a checkbox that appends a subd level of exported object to the exported label/name so that the this addition is reflected in the object cache path? There is no way to universally determine subd level in targeted applications and there are cases where knowing the subd level an object was exported from daz would be very useful.
Added to the TODO.
Has anyone had any issues importing Alembic to MD lately? I keep getting crashes in MD during alembic loading, but can't really figure out systematically why that is. (MD was also crashing when i tried to import a basic OBJ yesterday from Blender, so really seems to be on MD end...)
I upgraded Sagan to v3, and that seemed to help a bit. However, a new project was causing crashing again. The alembic files load fine in Blender, so definitely seems to be something weird about how MD reads files. (Converting from Alembic to Alembic in blender also seemed to allow it to load in MD).
For posterity, I noticed that in this particular case im troubleshooting right now, when I had the watch parented directly on the characters Forearm bone, the alembic would crash MD when loading. But when i kept the watch in the scene, but unparented, then the Alembic loaded into MD fine.
I think this has to do with the things @mrpdean_7efbae9610 pointed out. I'll address them when I get a chance.
Re-exporting from Blender probably works because the exporter is creating the extra transform that Sagan lacks. But I've been importing into both Blender and MD a day long with no problems, and Sagan doesn't respect any parenting at all, so it is difficult for me to accept that that had anything to do with it... could you have changed something else as well?
In any case, I think the transforms issue might fix everything, and that is next on the list.
i spent so long trying to create minimal and maximal scene that would let me export, admittedly may have made more than one adjustment at a time so cant say for sure if it was just the unparenting that I changed (although it wouldnt have been much more than that). I tried to recreate the issue and couldnt reproduce, which is funny since spent hours trying to solve it now cant even make it happen again!
If it happens again, I will flag and do more detailed troubleshooting.
Edit: Also should add I use this plugin pretty much every render, really valuable tool, so thank you for the hard work!
I'm happy that it's useful to you.
And those are really nice looking materials in your render.
So... further experiments seem to suggest it was something wrong with MD.
As I was using several alembics in MD earlier today, now trying to load those same ones I used earlier causes MD to crash for each.
@mrpdean_7efbae9610 @UncannyValet
OK, give this a try. I now create an empty transform under the archive root just to hold the object of the same name. It works the same as it did in Blender. I definitely did not have to do this before, so I think the Alembic library must have changed under me... give it a try and please post the same debugging info you did with Houdini, just so I can kind of understand what it changed.
@clandescent1
Tell me exactly what you need, and I'll work on that next. I'm not quite sure I understand, and don't want to have to re-work anything. Of course, assuming that the path problem above is actually resolved.
Thanks @TheMysteryIsThePoint
That appears to have resolved the path related issues I was seeing before.
I'm now seeing the two level of the path attribute in Houdini without me having to correct it:
Also, Maya no longer crashes when importing the alembic file and in Unreal, I'm no longer seeing the inverted polygons I was seeing before.
So as far as that particular issue goes, everything seems to have been resolved with this new version!
Thanks again.
So when in the Mesh Sequence Cache modifier in blender, you can select the object path for example "/genesis_8_female", this is derived either from figure label or name based on sagan selection in daz studio. In this path I need to have information about subd level, for example "/genesis_8_female[subd3]". Im not sure if this is a good idea to have enabled by default, so this is why I suggested a checkbox.
Would prefer that it's not enabled by default please.
Checkbox would be the better option.
Thanks
Another thing that I can think of that could be very useful for extending sagan in blender and other software, would be to append the vertext count of the base mesh to the object path if you can get that information from daz API. But its important to be able to detect the informationion in the path so it has to be labeled. For example "/genesis_8_female[subd3][vertex_count:3222111]". Knowing the exact vertex count of base mesh in other software would be useful for identifying objects regardless of their name/label/subd becuase most objects unless very simple have unique vertex count. So with these two pieces of information you can just read an alembic file and dynamically build a mesh out of prepared assets by comparing the subd level and vertex count with the prepared asset.
EDIT: Or maybe there is some other better way to uniquely identify objects across applications?
So, again to be clear on what I need, I need the subd level in the object path and vertex count of the base mesh regardless of current subd level and setting in the object path.
However if you know a better thing to append other then vertex count with purpose of uniquely identifying objects across applications, then maybe that is better then vertex count. I don't think there is since in the context of alembic I think vertex count is the best indicator if an object will be compatible across applications and mesh compatability is what its all about. Even if daz assigns some unique id to each object, it most likely takes into account variables that can vary and our only concern is the variable that doesnt vary which is vertex count because if it varied then the alembic mesh would not be compatible.
@clandescent1
Your requirements are valid, but I cannot help but think that, as @mrpdean_7efbae9610 is suggesting, there may be a better way of accomplishing what you need. I certainly don't want v3 to morph back into the mess that was v2. But I don't undertand what it is that you are trying to do... you're talking specific tactics when maybe we should be talking strategy and deriving together the specific tactics. We've got a lot of knowledge here to help us come up with the best implementation.
Flowed the container xform fix into Version 3.3.0.0 Please test.
@mrpdean_7efbae9610 Yes every 3d application can count vertecies, but the count of vertecies is not the same for base mesh and subd1 mesh. Idea is to use base mesh count as identifier and then if you know the subd level just look up the appropriate subdivided mesh to match the alembic mesh. I think that is better then to keep track of all the vertex counts for each subd level of each object and treat every one of them as unique objects.
To elaborate further how this can be used to streamline alembic to for example blender workflow. You have genesis 8 figure, hair and an outfit. You export that in alembic then in blender you have the figure, the hair and an outfit prepared as assets. It is better to prepare subdivided assets of the same objects separately instead of trying to dynamically build an object because porting daz assets to blender often requires adjustmenent that are not ideal to do programmatically so I think it is best to just manually prepare your assets. Then you have an intermediary addon that either keeps track of the vertex count and subd level of assets or somehow reads them, then if vertex count of the base mesh and subd level you can dynamically decide which asset to instance into the scene all from just reading the alembic file. Alembic is great for porting meshes, its the best, but even with the best case scenario for "Lord of the Plugins", it will still not be ideal. I think the most ideal solution is to just manually prepare assets and have them dynamically update through an addon, this I think is the closest we can get to a "live link".
@TheMysteryIsThePoint If you can get the subd level at least into either the path or some kind of attribute that can be read through python, that would be great. I don't think this would mess up sagan, however from my memory of v2 even though that BVH fix didnt make any sense in sagan I remember ive found it useful on some occasions. So i think adding extra features, as long as they are useful and dont require regular maintenence, is great but its best to make sure they are out of convenitent sight. Porting things between applications is always going to be hacky and problematic and ive seen on many occasions developers strip useful functionality for some ideal of design purity I dont think that makes sense since design purity makes sense only if you are fully responsible for whatever you are making and in case of porting daz to other software i think its best to focus on the question of is what im doing useful. Yes BVH fix didnt make sense in sagan, but it was a useful hack if i can call it that. I remember on diffeomorphic thread that suggested backporting animations from blender to daz, Padone lobbied so hard like his life dependend on it to see it not happen all for ideas of design purity because daz is for daz to blender not other way around. Luckily Thomas decided to implement the idea and now everyone can easily go into blender make an animation and port it back to daz studio with a few clicks. Before that? Almost impossible, if at all. But now a lot of people can and are benefiting from a feature that was not supposed to be there. It may not be obvious why having subd and vertex count appended to the alembic objects, but if it doesnt hurt and it provides additional information about what that thing is then even if i didnt know what i could do with all that(which i do) i would still be sure that someone would find it useful. In any case sagan is great and its really inspiring how well its done and how useful it is, so i do generally have a plan to share my addon when its ready however im not sure on the timing since i am developing it as im working on my projects so im testing it at the same time and its potential is dependent on sagan features so I guess i will see.
I have just discovered that if you dont touch uv map names in blender, then the alembic meshes are compatible across all subdivs. You can export any subd level figure into blender with sagan and as long as uv map names match with uv map name that is assigned by sagan export for that mesh then its going to work. But material setups in blender often require more then one uv map especially if you consider any geografts and if you want to avoid using shells so im guessing that is never going to work with subdivs. Unless anyone can think of a workaround?
Thanks @clandescent1
I think I understand it now.
Just as a quick thought, you might be able to get to the same point mathmatically.
For example, using Python you could do something like this:
EDIT: Looks like code blocks don't display well on the Daz Forum so I'll put the code here as a quote instead:
Would output this, noting that the array is zero based:
This would only work if the original geometry in Daz was modelled cleanly, entirely using quads. It would fall apart if there were any triangles or n-gon's in the original geometry. However, I think this would also be true even if the vert counts and subd levels were stored as an attribute in the alembic cache.
The idea of "design purity" is not an academic point. It comes from the idea of Separating Policy from Mechanism, as well as One Function, both which are long standing maxims since the early 70s. I don't remember the issue but that is probably at least partly the reason, if Padone objected. Software engineers have long understood that violating these concepts leads to overly complex software that is difficult to understand, reason about, update, and get to work with other software. (Read "The Art of UNIX Programming" by Eric S. Raymond) That means the good things that people ask for are slower in the coming.
I think naming objects is a core function of Alembic export and I'm going to figure out a general way to satisfy your requirements. But materials, on the other hand, is not. In fact, materials are expressly not addressed by Alembic at all, and that is the chief thing that made the complexity in Sagan v1/2 get out of hand. I'll have to address materials in a separate app, and give it a more powerful mechanism to deal with geoshells and whatnot. And of course there is the fact that I haven't figured out geoshells yet, anyway...
We'll get there... I ask for your patience.
I too was going to say that this would only work for perfect topology :)
Alembic "objects" can store all sorts of data, Geometry is only one of the data schemas available; I could shove in any kind of data the user wanted. But the problem would be that I don't know of a standardized way that the importing applications would use to interpret these other types.
On the other hand, the object's name seems to be kind of "universal". I'm thinking of removing the code that we have for naming the objects, and creating a general scheme like:
%l - the node's scrubbed label
%L - the node's untransformed label
%n - the node's scrubbed name
%N - the node's untrandformed name
%v - the vertex count
%s - the subd level
etc...
It'll default to the currenbt behavior, but then you could make a configuration like "%N#%v_%s" for Sagan to calculate, for example, "Genesis_8_Female#16554#b" where b means base res.
I think this will be useful because other things can be named differently as well, like UV map names, and my hardcoded assumptions are not working for everyone.
Comments?
Yeah, I like the idea of moving to a naming scheme like this as it would provide the greatest flexibility and future proofing.
One suggestion would be to stick with integers for the subd level... that way it's easier to handle mathmetically.. so the base res would just be subd 0, rather than "b".
My only other thought would be that casual users might find it difficult to understand at first.. Perhaps there could also be a drop-down menu of common presets, for the first 4 examples above at least. So, when a preset is selected, it populates the name field with the correct placeholders?
Sure, presets sounds like a good idea. But I used 'b' because subd0 is not the same as base res.
Is it not? I didn't know that :)
How do they differ if I may ask?
If I remember correctly, the verts/polys are the same but normals still get smoothed. Or maybe I'm thinking of the pre-opensubdiv days. You've created sufficient doubt that I'll have to check again. :)
Edit: I remember now... even at subd 0 there is some smoothing, with opensubdiv.