Alembic Issues

Forums: Alembic Issues
A forum where development builds are posted for testing by the community.
Forum rules
NOTE: The software in this forum is not %100 reliable, they are development builds and are meant for testing by experienced octane users. If you are a new octane user, we recommend to use the current stable release from the 'Commercial Product News & Releases' forum.

Re: Alembic Issues

Postby mikinik » Thu Mar 15, 2018 4:37 pm

mikinik Thu Mar 15, 2018 4:37 pm
Jolbertoquini , It was in 2015. :evil:
abstrax wrote:When I try to open the Alembic file in Octane it doesn't contain any triangles. How did you create the Alembic file and how did you load it into 3ds max? I.e. which plugin do you use and how do you set up the import?

EDIT: We had a look at the file content and the file seems to be corrupt. At least the HDF5 reader of Alembic can't read most of the file content.


viewtopic.php?f=33&t=44704&start=140#p229816

Even if it is an export bug, Chaos Group avoid this, they made their own loader as it seems to me, everything works through a vrayproxy. Otoy apparently does not know how..
i7-3930/32Gb/gtx780/gtx680/win7x64/3dsmax2016/3dsmax2017
mikinik
Licensed Customer
Licensed Customer
 
Posts: 218
Joined: Sun Oct 07, 2012 1:05 am

Re: Alembic Issues

Postby Jolbertoquini » Mon Mar 26, 2018 9:14 am

Jolbertoquini Mon Mar 26, 2018 9:14 am
mikinik wrote:Jolbertoquini , It was in 2015. :evil:
abstrax wrote:When I try to open the Alembic file in Octane it doesn't contain any triangles. How did you create the Alembic file and how did you load it into 3ds max? I.e. which plugin do you use and how do you set up the import?

EDIT: We had a look at the file content and the file seems to be corrupt. At least the HDF5 reader of Alembic can't read most of the file content.


viewtopic.php?f=33&t=44704&start=140#p229816

Even if it is an export bug, Chaos Group avoid this, they made their own loader as it seems to me, everything works through a vrayproxy. Otoy apparently does not know how..


Wow okay! this is something need be check for such long time problem then. Hope they will look at some point.

Thanks for the link,

Cheers,
JO
Octane Render for Maya.
https://vimeo.com/jocg/videos
https://www.linkedin.com/in/jocgtd
http://www.hmxmedia.com/
--------------------
Join MAYA OCTANE USERS Skype discussion here :
https://join.skype.com/LXEQaqqfN15w
User avatar
Jolbertoquini
Licensed Customer
Licensed Customer
 
Posts: 961
Joined: Sun Aug 31, 2014 7:08 am
Location: London

Re: Alembic Issues

Postby mikinik » Mon Mar 26, 2018 1:06 pm

mikinik Mon Mar 26, 2018 1:06 pm
Jolbertoquini, I have a hope for max 2019, there have been a lot done with alembic, if it's the case.
i7-3930/32Gb/gtx780/gtx680/win7x64/3dsmax2016/3dsmax2017
mikinik
Licensed Customer
Licensed Customer
 
Posts: 218
Joined: Sun Oct 07, 2012 1:05 am

Re: Alembic Issues

Postby abstrax » Tue Oct 09, 2018 9:57 pm

abstrax Tue Oct 09, 2018 9:57 pm
Miknik made me aware of this issue today, so I had a look. And sorry that we missed this post. Please contact our support if you find an issue that doesn't get resolved here.

Anyway, the TL;DR version: With the next release (4 RC6) we will be ignoring the sampling rate of the extra UV coordinates, which causes all frames of the scene ParticleMesh_VDB01_Stitcher_10F.abc to load and render correctly.

Long explanation:

It seems that in the original single-frame export from RealFlow, the UV coordinates, vertex normals and speeds are stored twice. Once as attributes of the mesh and then again underneath the attribute group arbGeomParams. This attribute group is usually used for additional attributes that are not necessarily supported by all Alembic readers. When the stitcher creates one Alembic file out of it, it gives all attributes under arbGeomParams an incorrect sampling rate of 1fps while the residual mesh attributes have a sampling rate of 30fps.

When Octane loads the Alembic file, it loads the UV coordinates under arbGeomParams as second UV coordinate set - because often extra UVs are provided in that group. Unfortunately it has the incorrect sampling rate and thus doesn't change during the first frames while the other attributes describing the mesh topology do change. When Octane compiles the geometry it makes sure that all mesh data is consistent and detects the mismatch and filters the mesh out. This is why only the first frame is rendered. If you open the log window you will also notice an error message that the A_UVWS_2 indices are invalid.

To solve the issue we will be using not a time-based selector but a sample-based value selector in the Alembic reader (effectively ignoring the sampling rate) which solves this problem:
rf_splash.png
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
User avatar
abstrax
OctaneRender Team
OctaneRender Team
 
Posts: 5102
Joined: Tue May 18, 2010 11:01 am
Location: Auckland, New Zealand

Re: Alembic Issues

Postby Jolbertoquini » Thu Oct 11, 2018 6:24 pm

Jolbertoquini Thu Oct 11, 2018 6:24 pm
abstrax wrote:Miknik made me aware of this issue today, so I had a look. And sorry that we missed this post. Please contact our support if you find an issue that doesn't get resolved here.

Anyway, the TL;DR version: With the next release (4 RC6) we will be ignoring the sampling rate of the extra UV coordinates, which causes all frames of the scene ParticleMesh_VDB01_Stitcher_10F.abc to load and render correctly.

Long explanation:

It seems that in the original single-frame export from RealFlow, the UV coordinates, vertex normals and speeds are stored twice. Once as attributes of the mesh and then again underneath the attribute group arbGeomParams. This attribute group is usually used for additional attributes that are not necessarily supported by all Alembic readers. When the stitcher creates one Alembic file out of it, it gives all attributes under arbGeomParams an incorrect sampling rate of 1fps while the residual mesh attributes have a sampling rate of 30fps.

When Octane loads the Alembic file, it loads the UV coordinates under arbGeomParams as second UV coordinate set - because often extra UVs are provided in that group. Unfortunately it has the incorrect sampling rate and thus doesn't change during the first frames while the other attributes describing the mesh topology do change. When Octane compiles the geometry it makes sure that all mesh data is consistent and detects the mismatch and filters the mesh out. This is why only the first frame is rendered. If you open the log window you will also notice an error message that the A_UVWS_2 indices are invalid.

To solve the issue we will be using not a time-based selector but a sample-based value selector in the Alembic reader (effectively ignoring the sampling rate) which solves this problem:
rf_splash.png


Hi Marcus,

No worries, thanks a lot for the fix, I'm glad you find a way for this , I'm really happy!

Cheers,
JO
Octane Render for Maya.
https://vimeo.com/jocg/videos
https://www.linkedin.com/in/jocgtd
http://www.hmxmedia.com/
--------------------
Join MAYA OCTANE USERS Skype discussion here :
https://join.skype.com/LXEQaqqfN15w
User avatar
Jolbertoquini
Licensed Customer
Licensed Customer
 
Posts: 961
Joined: Sun Aug 31, 2014 7:08 am
Location: London
Previous

Return to Development Build Releases


Who is online

Users browsing this forum: No registered users and 0 guests

Thu Nov 14, 2019 2:01 pm [ UTC ]