Thank you for that information/link.. just reading it all now.roeland wrote:Both, fails to load .abc when using subdivision preservation, but i now know why thanks to youDoes it crash Octane or does it fail to load the file? If it crashes, are you able to upload a file causing a crash?
And crashes Ds when trying to import a Daz studio character called Michael 4, but the newer Genesis character loads fine BUT, ALL Daz Studio characters exported from Daz Studio as .abc files have either surface or texture errors as shown in my pics! Am starting to guess that the issues are both related to unsupported mesh types and that Daz3D did not included camera export when writting their Alembic exporter (maybe based on older code, i just dont know) I can only guess at all this suff i am afraid![]()
![]()
Also if the Alembic file contains a camera objects then the imported scene node will have a camera output (blue-green) for every of these camera objects. Cameras are part of the Alembic standard, this is mentioned on [url=http://www.alembic.io/updates.html]the Alembic website:
Am stuck on my Ipad until the morning but if you still need them i can provide those scenes for you after intake the kids to school in the morning ?
Thanks for your reply Roeland

UPDATE EDIT:
linvanchene (Daz forum), Thank you so much for making things clearer for me & your time to post here

Thank you for taking the time to explain things to me in a way that I understand, sorry for the confusing posts.Orion, thank you a lot for posting this here. I tried to follow all the different threads in all the different forums as good as I could.
I posted in Otoy & Daz forums as (not being the sharpest tool in the box sometimes) I did not know much about the issue(s)
I was having, what the actual causes were and how much of it was user error or software related.
I though that getting the perspective from Daz & Otoy would help me clear that up not foreseeing this issue of multiple threads.
Also, I guess I am guilty of not reading things fully and therefore when the features I was expecting did not work I got lost in the frantic world of google searches rather than FULLY reading & understanding the information provided, sorry once again.
GUILTYIt seems there are two different issues going on at the moment:
1) The otoy OctaneRender Standalone version is not fully ready yet to support Alembic import of meshes with subdivision.
What is needed is some more patience until the “official” version 1.5 of OctaneRender is released as I allready tried to explain in the posts.
Currently Octane Standalone 1.27 is out as a Release Candiate.
We also need to understand that all Release Candidates are unofficial Beta versions that we can use at our own risk.
The last official standalone version available in the downloads is 1.2
Until we see an offical version 1.5 in the downloads area there is still A LOT of work to be done.
For those who do not read through the whole thread

Roeland @ Otoy had this to say in his last post to me:This only affects the Octane standalone version.
The OctaneRender plugin for DS reads the data directly from DS .duf files. No Alembic export / import needed there.
- - -
2) For some reason some people are under the impression that Camera values are not part of the Alembic standard.
I really do not quite understand all the limits and possibilities of the Alembic format yet myself.
I can understand if some things are mixed up because I myself still end up mixing up a lot of things that may or may not be related.
But from a google search for camera+data+alembic+format it seems that other software support camera export & import with the alembic format.
The camera values and the definitions also seem to be included in the alembic documentation:
http://docs.alembic.io/python/search.ht ... ea=default
From my point of view having camera values defined as part of the Alembic standard makes a lot of sense.
As I already pointed out above matching different footage no matter if the source is video or animation depends on using the exact same camera data with the same values.
After all the Alembic standard seems to be introduced by imageworks and lucasfilm both companies dealing probably a lot with composting footage of different sources and all the issues that arise in the process.
The impression I got so far is:
There is one Alembic format. But it seems not every software is yet supporting all features of it.
Otoy seems to be working to make Alembic support happen for subdivided meshes.
I understand the mesh & texturing side of things better now thanks to everyone, I would just like to see how the camera confusion will be cleared up from this point on thenOctane at the moment only supports triangle meshes, the other forms of geometry (subDiv, strands etc.) are not imported.

I certainly hope so as both DazSpookey & Richard Haseltine both seem to be under the impression that Cameras are not supported!Maybe DAZ could have another look at how camera values are calculated in DS and how to include properly calculated realistic camera values in the Alembic Export / Import.
With respect to them (as is only right & due), Here is what they say..
Richard Haseltine: Alembic does not carry camera or texture information - just the mesh and animation.
Here is hoping that Daz & Otoy continue to improve these products (& add camera export to the Daz exporter) with as much dedication & ingenuity as possible. Together Daz & Otoy software complements each other on a great level that serves us users well, I am grateful for the hard work that goes in to both the programs involved in this thread & their developersDazSpookey:Cameras are not part of the Alembic Spec, neither are lights. It is an Vertex exact object and object animation format. It doesn’t do cameras.
