OctaneRender™ 4 RC 5

[boeing727223]

I apologize if this has already been posted and I missed the post. I notice that RC 5 (and RC 4) automatically changes the Opacity channel from a Greyscale image (that I originally assigned) to an Alpha image after I saved and relaunched the scene. If I load a Greyscale image in the Opacity channel, save the scene, close it and then re-launch the scene it should remain as a Greyscale image not default to an Alpha image.

I just tried it in the Standalone and there it doesn't happen. I assume you are using one of the plugins? In that case it's probably best to report to the plugin developer since the materials are usually managed outside of the Octane render core (which is due to the fact that each host application has its own totally different material system).

Hi abstrax, nope, I am using the Standalone. I import the .obj (figure, hair etc). Save the file, and when I relaunch the scene I lose my greyscale images for Opacity. I reload them all and save the file. I then close and relaunch the file. This time around the greyscale images stayed. This has been going on since RC4 at least. I have been using Octane since probably 2012 and never seen that happen. The obj loads with the Opacity greyscale maps on import. Not sure if something happens to the greyscale images after the initial save and close of the file. The actual greyscale image .jpg map remains, it just changes to an Alpha map.

[funk]

Hey guys,

I was doing some tests with motion blur (related to another thread), and I can't seem to get any kind of vertex motion blur working on deformed meshes.

Is it working in Modo? I had a look at the exported scene and the scene isn't exported correctly for vertex motion blur to work (because there are no vertex speeds provided and mesh is not marked to have a constant topology either).

Marcus, I've spent the day testing with the modo plugin and it seems vertex motion blur is breaking randomly.

I tested modo's own internal ABC export and Octane always shows vertex motion blur correctly when I import it into standalone. The only difference is, modo does not triangulate ngons in ABC exports, which causes some odd polygon rendering in Octane. If I manually triangulate my meshes in modo, the modo plugin is always exporting the ORBX correctly (vertex motion blur works).

I asked Paul where the triangulation happens on export, and he said the Octane API takes care of all that. I also asked him to run some tests to determine where the problem is and his reply was:

"I'm not sure how I could test that - sorry. It's a fairly direct pipe from the Modo API to the Octane .ABC file. The Octane API handles everything."

I(f) you feel it is really an Octane problem, OTOY should be able to point to the specific geometry that is triggering the topology change.

Right now this leaves modo users with a (randomly) broken ORBX exporter. The modo plugin doesnt natively support vertex motion blur either, so our only option is to export an ORBX to get working vertex motion blur.

I'm posting the original modo file here, so "OTOY" can investigate, as suggested by Paul...
It includes 2 ORBX exports. One has working vertex motion blur, the other doesn't (check frame 74). Both were exported from the same scene. One just happens to work, while the other doesnt.

[coilbook]

please fix gpu count for 3ds max RC4 it still shows too many GPUs even though I have 20
Also I have 1 card just for denoising. Do you count it as 1 of 20. If you do then it is not fair. We cannot use actual rendering card for denoising because vram is full and it always says that it doesn't have enough memory to denoise. There should be 20 cards for rendering and 1 more for denoising with free vram /.

[Studio21]

Hey guys any plans to add OSL setups to the live DB as promised?


Ty
G

[abstrax]

Marcus, I've spent the day testing with the modo plugin and it seems vertex motion blur is breaking randomly.

I tested modo's own internal ABC export and Octane always shows vertex motion blur correctly when I import it into standalone. The only difference is, modo does not triangulate ngons in ABC exports, which causes some odd polygon rendering in Octane. If I manually triangulate my meshes in modo, the modo plugin is always exporting the ORBX correctly (vertex motion blur works).

I asked Paul where the triangulation happens on export, and he said the Octane API takes care of all that. I also asked him to run some tests to determine where the problem is and his reply was:

"I'm not sure how I could test that - sorry. It's a fairly direct pipe from the Modo API to the Octane .ABC file. The Octane API handles everything."

I(f) you feel it is really an Octane problem, OTOY should be able to point to the specific geometry that is triggering the topology change.

Right now this leaves modo users with a (randomly) broken ORBX exporter. The modo plugin doesnt natively support vertex motion blur either, so our only option is to export an ORBX to get working vertex motion blur.

I'm posting the original modo file here, so "OTOY" can investigate, as suggested by Paul...
It includes 2 ORBX exports. One has working vertex motion blur, the other doesn't (check frame 74). Both were exported from the same scene. One just happens to work, while the other doesnt.

Thanks for the tests. Yesterday Paul sent me some 2 exports: One had vertex motion blur the other one didn't.

I compared both exports and one of them animates the polygon topology and one of them doesn't. When the topology changes the Alembic library detects this and sets a flag in the file which is later used by Octane to determine if animated vertices can be rendered as using motion blur or not. The scene that had the changing topology was exported from Modo 12.1v1 while the one with the static topology was exported from Modo 12.1v2. He assumed that it was an issue in Modo that eventually got fixed in 12.1v2.

Regarding the export and triangulation: We just write polygons as they are provided by the plugin to the Alembic export stream. The triangulation is done during the geometry compilation for rendering when you load and render an exported scene. At that point in time the check for the animated topology has been done already.

-> At the moment it looks like as if Modo sometime produces a different polygon topology even though it's just applying a deformation of vertices. It may be just one frame or so and might not be visible, but since the export records all provided frames and needs to have a constant topology over all exported frames, vertex motion blur doesn't work in that case.

[abstrax]

please fix gpu count for 3ds max RC4 it still shows too many GPUs even though I have 20
Also I have 1 card just for denoising. Do you count it as 1 of 20. If you do then it is not fair. We cannot use actual rendering card for denoising because vram is full and it always says that it doesn't have enough memory to denoise. There should be 20 cards for rendering and 1 more for denoising with free vram /.

If you've got a device that is only being used for denoising it is still being counted. So what exactly is your setup, how many GPUs are used on the slaves and the master for rendering and how many GPUs are used on the master for denoising?

[abstrax]

I apologize if this has already been posted and I missed the post. I notice that RC 5 (and RC 4) automatically changes the Opacity channel from a Greyscale image (that I originally assigned) to an Alpha image after I saved and relaunched the scene. If I load a Greyscale image in the Opacity channel, save the scene, close it and then re-launch the scene it should remain as a Greyscale image not default to an Alpha image.

I just tried it in the Standalone and there it doesn't happen. I assume you are using one of the plugins? In that case it's probably best to report to the plugin developer since the materials are usually managed outside of the Octane render core (which is due to the fact that each host application has its own totally different material system).

Hi abstrax, nope, I am using the Standalone. I import the .obj (figure, hair etc). Save the file, and when I relaunch the scene I lose my greyscale images for Opacity. I reload them all and save the file. I then close and relaunch the file. This time around the greyscale images stayed. This has been going on since RC4 at least. I have been using Octane since probably 2012 and never seen that happen. The obj loads with the Opacity greyscale maps on import. Not sure if something happens to the greyscale images after the initial save and close of the file. The actual greyscale image .jpg map remains, it just changes to an Alpha map.

Hmm, sorry, but I wasn't able to reproduce the issue here. The Octane scene below just loads the same way after saving of the project as the OBJ file was loaded initially - the opacity texture is loaded as greyscale texture and not as an alpha texture. If you could give me a scene and instructions to reproduce the problem, I will investigate again.

[funk]

Thanks for the tests. Yesterday Paul sent me some 2 exports: One had vertex motion blur the other one didn't.

I compared both exports and one of them animates the polygon topology and one of them doesn't. When the topology changes the Alembic library detects this and sets a flag in the file which is later used by Octane to determine if animated vertices can be rendered as using motion blur or not. The scene that had the changing topology was exported from Modo 12.1v1 while the one with the static topology was exported from Modo 12.1v2. He assumed that it was an issue in Modo that eventually got fixed in 12.1v2.

I confirmed it happens in 12.1v2 as well (probably after he sent you any files). The ORBX export is only working some of the time.

Regarding the export and triangulation: We just write polygons as they are provided by the plugin to the Alembic export stream. The triangulation is done during the geometry compilation for rendering when you load and render an exported scene. At that point in time the check for the animated topology has been done already.

-> At the moment it looks like as if Modo sometime produces a different polygon topology even though it's just applying a deformation of vertices. It may be just one frame or so and might not be visible, but since the export records all provided frames and needs to have a constant topology over all exported frames, vertex motion blur doesn't work in that case.

Ok so where does this leave us? Paul told me he didnt know how to proceed and asked me to go to OTOY.

[abstrax]

...
Ok so where does this leave us? Paul told me he didnt know how to proceed and asked me to go to OTOY.

Could you send the Modo scene to me? I will try to reproduce the issue. I will add logging of a hash for the relevant attributes to see which attributes change between frames. I hope I can then give a more definitive answer to where the problem is. At the moment it looks like the issue is in the Modo API.

Before you send the scene, could you remove all objects except the vertex motion blur one and try again? If the issue is still there, please send that reduced scene to me. Thanks a lot in advance.

[funk]

...
Ok so where does this leave us? Paul told me he didnt know how to proceed and asked me to go to OTOY.

Could you send the Modo scene to me? I will try to reproduce the issue. I will add logging of a hash for the relevant attributes to see which attributes change between frames. I hope I can then give a more definitive answer to where the problem is.

I actually attached a zip of the scene (plus 2 orbx exports) to the post you replied to earlier viewtopic.php?p=347354#p347354 but I'm attaching a modified scene here too

At the moment it looks like the issue is in the Modo API.

I agree it could be a problem on the modo side, and I assumed Paul would be able to output some kind of debug info pinpointing where the problem was. I actually asked him about this and he said he didn't know how to test it.

Before you send the scene, could you remove all objects except the vertex motion blur one and try again? If the issue is still there, please send that reduced scene to me. Thanks a lot in advance.

A modified scene is attached. This one seems to reproduce the "random" problem a bit easier, since the deformation is running over more frames.

I have included 2 orbx exports from this scene. One has working motion blur, the other doesnt. The motion blur is seen best around frames 19-21.

I also did an ABC export from modo's own exporter just in case it helps. As I said earlier, this alembic always works, but ngons don't get triangulated, so you can end up with bad rendering in octane (although its not obvious in this example).