@clandescent1 Please check again. It should look for the configuration file in the same directory as the scene file, and load it if it finds it.
Everything works well now and overwrite option is a lifesaver. Thanks!
Another thing I can suggest is an option to add a configurable hotkey for quick export, so you dont have to open sagan menu and click export with a mouse every time you want a quick update, but its not that important. Is there a function i could run from daz script to create a hotkey myself? Assuming this function will run without opening the sagan menu and it will use the active config file.
Are meshes/uv's from 1.16 sagan incompatible with 3.2+ ?
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.
Is there any way to port with diffeo materials in 3.1 ?
Yes. When you import via Diffeo, there is now a global option under Materials called "Sort Materials Alphabetically". With that checked, you can now just select the Alembic object, shift-select the diffeo model, and on the mateials tab, select Copy Material to Selected.
I'll make a script to automate that in the future.
I think it is worth mentioning that copy materials to selected method does not work with figures that have geografts. Diffeomorphic imports geografts separately and imports the main figure as base figure, so if you copy paste those materials onto a sagan figure that has all of the geograft materials on one figure it will just break everything because neither the order nor the number of material slots match. This is not a big deal to fix manually as it is now, however if you automate the process in future using this method then every import with geografts will be broken. You could make another checkbox, however i dont understand what was wrong with original method of just replacing materials by their name with a generated python script? That seemed to work fine in 1.16
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...
@mrpdean_7efbae9610 I'm going to borrow some code from LotP. It abstracts the issues of vertex winding order that affects the normals, the coordinate system that might be causing the rotation (does it mirror as well?), etc.
I don't know why these things should be necessary, they should be taken care of by the receiving program's Alembic importer, but at least I'll have a framework to fix it.
Hi again,
So I did some more testing and, using Houdini, I was able to identify and correct the issue with V3+ alembics getting messed up in Unreal and crashing Maya.
I can only explain the issue in Houdini terms as I don't know anything about the internals of alembic files, but hopefully it will make sense to you.
When importing the alembics into Houdini it creates a path primitive attribute. My rough understanding is that this attribute is used to define/represent the hierarchy of the geometry contained within the alembic cache.
For Sagan V2 alembics, this path attribute is always two "layers" deep:
However, for Sagan V3+ alembics the path attribute is only one layer deep:
If I manually change this path attribute in Houdini on the V3+ alembic, to be two layers deep, the resulting alembic works perfectly in both Unreal and Maya.
Hopefully this all means something to you and helps to resolve the issue. At least I now know how to correct for it in my Houdini workflow.
That is another head scratcher. Sagan has always made all objects in the root context, and should have been 1 layer deep, always. I did recently update the version of the Alembic library Sagan uses, stolen from Blender, but I cannot see that affecting this. Clearly I've done something differently, but I can't immediately think of what it is. In any case, I think one layers deep is the correct behavior.
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.
Since any geometry in Maya is defined by its transform container and the geometry shape itself, it needs two names. The first name is the transform container, and the second name is for the shape.
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.
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
I don't really see how vertex count or subd level could be reliably used as an identifier.
If you could explain what you're ultimately wanting to achieve by identifying objects across applications I might be able to offer some other ideas.
It sounds like you're wanting to match an incoming alembic with an object that already exists in the scene.. is that right?
Every app I've used has had a way of reading the vertex count from objects.
Would this subd/vert count info need to be in the path attribute specifically?
I believe the alembic specs support an arbitrary number of attributes at the geo level so perhaps this extra info could be put into their own custom attributes?
Obviously it's up to TheMysteryIsThePoint but please don't make it the default.
Thanks
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.
@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?
@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".
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:
# The vertex count of the prepared asset
# How you query the vert count will depend on the application being used
prepared_asset_vert_count = 16245
# An array of the vertex counts of the objects in the alembic cache
# How you get this list of vert counts will depend on the application being used
vert_counts_of_candidate_objects_in_alembic_cache = [24563, 64980, 36050]
# Loop through each of the objects in the alembic cache
for index, vert_count in enumerate(vert_counts_of_candidate_objects_in_alembic_cache):
# If the object in the alembic cache is divisible by the prepared asset's vertex count
if vert_count % prepared_asset_vert_count == 0:
# Calculate it's subd level
subd = (vert_count / prepared_asset_vert_count) / 4
print("Alembic object %s is a likely match to the prepared asset at a subd level of %i" % (index, subd))
Would output this, noting that the array is zero based:
Alembic object 1 is a likely match to the prepared asset at a subd level of 1
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...
@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".
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:
# The vertex count of the prepared asset
# How you query the vert count will depend on the application being used
prepared_asset_vert_count = 16245
# An array of the vertex counts of the objects in the alembic cache
# How you get this list of vert counts will depend on the application being used
vert_counts_of_candidate_objects_in_alembic_cache = [24563, 64980, 36050]
# Loop through each of the objects in the alembic cache
for index, vert_count in enumerate(vert_counts_of_candidate_objects_in_alembic_cache):
# If the object in the alembic cache is divisible by the prepared asset's vertex count
if vert_count % prepared_asset_vert_count == 0:
# Calculate it's subd level
subd = (vert_count / prepared_asset_vert_count) / 4
print("Alembic object %s is a likely match to the prepared asset at a subd level of %i" % (index, subd))
Would output this, noting that the array is zero based:
Alembic object 1 is a likely match to the prepared asset at a subd level of 1
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.
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.
@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".
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:
# The vertex count of the prepared asset
# How you query the vert count will depend on the application being used
prepared_asset_vert_count = 16245
# An array of the vertex counts of the objects in the alembic cache
# How you get this list of vert counts will depend on the application being used
vert_counts_of_candidate_objects_in_alembic_cache = [24563, 64980, 36050]
# Loop through each of the objects in the alembic cache
for index, vert_count in enumerate(vert_counts_of_candidate_objects_in_alembic_cache):
# If the object in the alembic cache is divisible by the prepared asset's vertex count
if vert_count % prepared_asset_vert_count == 0:
# Calculate it's subd level
subd = (vert_count / prepared_asset_vert_count) / 4
print("Alembic object %s is a likely match to the prepared asset at a subd level of %i" % (index, subd))
Would output this, noting that the array is zero based:
Alembic object 1 is a likely match to the prepared asset at a subd level of 1
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.
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?
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.
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.