OctaneRender™ Standalone 2.22.2

[pegot]

When will 2.23 with the VR features be available for download? The 3 Month OctaneVR Trial page links back here for licensed customers but I see only the 2.22.2 version, which I already have.

[gardeler]

I think I have run into a massive memory leak? It is related to my previous posts of prolonged rendertimes when using motionblur on deforming objects, but my scene now goes off the charts!!

I have a 300mb alembic file. When trying to load that into octane my ram usage passes my 32gb!! (and still climbig when i kill it!) There must be some crazy memory leaking going on, as I the object is only about 3mil triangles. I cant see why my computer should use that amount of ram to read it? And it is only when it is moving, so it seems like it is the motionblur causing it.

I will send you a PM marcus, with two alembic files. One mace with crate, and one with maya's standard exporter.

Thanks

[roeland]

I think I have run into a massive memory leak? It is related to my previous posts of prolonged rendertimes when using motionblur on deforming objects, but my scene now goes off the charts!!

I have a 300mb alembic file. When trying to load that into octane my ram usage passes my 32gb!! (and still climbig when i kill it!) There must be some crazy memory leaking going on, as I the object is only about 3mil triangles. I cant see why my computer should use that amount of ram to read it? And it is only when it is moving, so it seems like it is the motionblur causing it.

I will send you a PM marcus, with two alembic files. One mace with crate, and one with maya's standard exporter.

Thanks

You're right, it's an issue with motion blur. Octane currently can render only a limited amount of motion blur, depending on how small the triangles are in your scene.

If there is a lot of small triangles and a lot of motion then the result is a long compiling time and slow rendering. The octopus consists of a lot of small triangles, the limit for the shutter interval length is around 1/1000 sec (or 3% of the time between frames). Until we improve the handling of this motion blur there is no real workaround.

--
Roeland

[gardeler]

I think I have run into a massive memory leak? It is related to my previous posts of prolonged rendertimes when using motionblur on deforming objects, but my scene now goes off the charts!!

I have a 300mb alembic file. When trying to load that into octane my ram usage passes my 32gb!! (and still climbig when i kill it!) There must be some crazy memory leaking going on, as I the object is only about 3mil triangles. I cant see why my computer should use that amount of ram to read it? And it is only when it is moving, so it seems like it is the motionblur causing it.

I will send you a PM marcus, with two alembic files. One mace with crate, and one with maya's standard exporter.

Thanks

You're right, it's an issue with motion blur. Octane currently can render only a limited amount of motion blur, depending on how small the triangles are in your scene.

If there is a lot of small triangles and a lot of motion then the result is a long compiling time and slow rendering. The octopus consists of a lot of small triangles, the limit for the shutter interval length is around 1/1000 sec (or 3% of the time between frames). Until we improve the handling of this motion blur there is no real workaround.

--
Roeland

Thank you for the reply Roeland. this is really sad news for me. I have also discovered that I have other shots that are breaking because of the same problem. It seems to me that it is not the total amount of polys in a scene that is the problem, but rather the amount of them in an alembic file. Is this true? If I could find a way to split the octopus up into smaller "chunks", octane would perhaps not crash during the compile? Or is that just a waste of time?

It seems that this is something that might be hard to solve, so I can assume there is no fix for this in the near future?

[roeland]

Thank you for the reply Roeland. this is really sad news for me. I have also discovered that I have other shots that are breaking because of the same problem. It seems to me that it is not the total amount of polys in a scene that is the problem, but rather the amount of them in an alembic file. Is this true? If I could find a way to split the octopus up into smaller "chunks", octane would perhaps not crash during the compile? Or is that just a waste of time?

It seems that this is something that might be hard to solve, so I can assume there is no fix for this in the near future?

Yes, the fix for this issue will take some time.

Breaking up the mesh won't make a difference, the issue is the ratio between the size of the triangles in your mesh to the distance they travel during one frame. Sometimes you can get away with a more coarse mesh, but that doesn't appear to be the case in your scene.

--
Roeland

[gardeler]

Yes, the fix for this issue will take some time.

Breaking up the mesh won't make a difference, the issue is the ratio between the size of the triangles in your mesh to the distance they travel during one frame. Sometimes you can get away with a more coarse mesh, but that doesn't appear to be the case in your scene.

--
Roeland

Ok, then I will not try that route. does this apply for the motion vector pass as well? I guess it needs to read the velocities to get the amount and direction?

Actually, the reason for the dense mesh is that I'm using it to go around the broken displacement. (I have not yet been able to use displacement successfully in octane.) It creates strange polygons that does not have a normal. At least they do not react to the "polygon side" texture. This causes all kinds of light leaks and catching highlights through occluding surfaces. So my workaround was to subdivide the mesh in maya, then apply a texture deformer with the displacement map. This worked well, until I ran into this bug.

Hope both issues can be fixed soon, as it kind of kills all possibilities to do creature work with octane, which it is actually great for!

[BorisGoreta]

I can't feed the same Octane Camera Mapping output to different Texture Image nodes, I have to use separate Octane Camera Mapping nodes with the same settings.

[abstrax]

I can't feed the same Octane Camera Mapping output to different Texture Image nodes, I have to use separate Octane Camera Mapping nodes with the same settings.

Can you try in 2.23.2 and if it doesn't work there, post an example? Thanks.