Render slowdown issue

[MrFurious]

Hi Paul I've been having this issue for a while but only now am having a chance to post this. Extremely laggy IPR refresh with some mesh items. Oddly any instances of said item are unaffected.

Please check my scene file:
http://www.mediafire.com/file/td4k88yvm ... s.zip/file

There are a couple really strange things happening here. Once you open the scene first please just move/pan/zoom the camera. Notice the IPR updates are immediate. Transforms on the red mclaren are also immediate. Problem starts when the skyline is transformed. It takes a good 3-4 seconds to update in IPR. Also, now camera transforms are also just as slow. It seems like it's reloading the scene into octane with each transform. But...

If you make an instance of the Skyline and place the original mesh item of the skyline far far off camera somewhere in the background and transform the skyline instance, the IPR updates are back to instantaneous. No problem with the instance, but the mesh item is very slow. Camera is now updating instantaneously as well.

No idea why this specific model is causing this. In another test scene similar to this I made sure the geometry was octane legal, no non planars, points merged, polys unified etc.

I have some large scenes where the slowdown is as long as 10+ seconds per transform.

Thanks,
Dino.

[MrFurious]

I did some more testing and here is a better example.

Octane is definitely having issues with denser meshes. In this scene the plant is just over 2.6 million polys. When trying to transform the plant I'm getting about a 15 second wait between IPR updates, also for camera transforms.

There is an instance of the plant off-camera and when you move the plant mesh off-camera and bring the instance into frame, reload octane IPR, everything works as it should with more or less instantaneous IPR refresh.

Scene file is here:
http://www.mediafire.com/file/2gh8dy5my ... t.zip/file

[face_off]

Hi Dino

This is happening because the mesh is being reloaded when you change it's transform. Turning on the Kernel->Render Cache fixes this to an extend, and the next release improves the Render Cache further, however I notice that Replicators are not currently working for the Render Cache if you turn OFF the visibility of the Prototype, so the Render Cache is not working as well as I thought it was and may not be a viable solution for you at the moment.

If you save out any large meshes to OBJ and then use the OBJ as an Octane Mesh Proxy, the transforms update quickly.

Paul

[MrFurious]

More testing.. I imported this scene as an orbx into standalone, manipulated the geometry by using the geometry placement node and no issues at all with this scene in standalone.

[MrFurious]

Render cache in my experience has never been a viable solution. In this case it brings the wait time down from 15 seconds to about 9 second so it's the difference between an extremely long wait, and a slightly lesser extremely long wait.

I'm surprised you say Octane loads the geometry into the GPU every time a mesh item is moved, rotated or scaled? This cant be right.. for deformations maybe but wouldn't octane keep the geometry data in GPU and just send the transform instruction rather than resend the entire mesh? Also I tried transformations in standalone and it was instantaneous.

OBJ as a Octane Mesh Proxy? Do you mean ORBX rather than OBJ?

[face_off]

In this case it brings the wait time down from 15 seconds to about 9 second so it's the difference between an extremely long wait, and a slightly lesser extremely long wait.

It should be instant in the next release.

I'm surprised you say Octane loads the geometry into the GPU every time a mesh item is moved, rotated or scaled? This cant be right..

It happens that way because in the early versions of the plugin the Modo SDK was firing a Mesh Change event to plugins, so it was not possible to determine that only the transform had changed. I don't think this still happens, but there is a lot of code in the plugin which is based on this premise, so it is not trivial to change.

OBJ as a Octane Mesh Proxy? Do you mean ORBX rather than OBJ?

Yes, sorry, ORBX.

Paul

[MrFurious]

It should be instant in the next release.

No offense but I'm not holding my breath, coupled with all the other issues RC brings it's best left alone I think.

there is a lot of code in the plugin which is based on this premise, so it is not trivial to change.

I'd say that's the way to go rather than render cache.

save out any large meshes to OBJ and then use the OBJ as an Octane Mesh Proxy, the transforms update quickly.

Not an option. IPR updates might be fast but scene limitations and workflow hit is not worth it.

Did you see in my scene how fast the mesh instance updates were?

[MrFurious]

t happens that way because in the early versions of the plugin the Modo SDK was firing a Mesh Change event to plugins, so it was not possible to determine that only the transform had changed. I don't think this still happens, but there is a lot of code in the plugin which is based on this premise, so it is not trivial to change.

I think that might be the problem right there.

For now I'm going to do a test scene of a completed project and replace ALL my objects with proxies.

[funk]

Good timing. Just yesterday, I was having almost the exact same conversation with Paul privately and he suggested the same solutions.

Render cache has actually improved quite a bit over the years but it needs a lot of testing in the Octane plugin. Stability is not there right now. I also pointed out that replicators don't work correctly in the plugin with render cache enabled.

ORBX proxies are difficult to use too. There is no one-click "easy" way to create them. You see nothing in the modo viewport, which prevents you using things like shift-a to frame objects. You can't edit the materials in modo anymore etc

[MrFurious]

Thanks for chiming in Funk.

Actually I went a step further with ORBX import and parented the orbx to (yet) another proxy of ultra low resolution geometry. Seems to work fine for shift-a, pos, rot, scale and opengl feedback. Better than nothing. Still, I'm just not prepared to go down that route as I have many library objects lots of them high res trees. I'd probably use the ORBX proxy workflow as a 'one-off' thing here and there but not part of my daily workflow. Also I do on-the fly-mods to these meshes sometimes, deform, trim, morph etc.. all are lost on proxies. That's just off the top of my head I'm sure I could make a list.

So I have to rudely turn my nose up at proxies in it's current form as a solution to this issue (possibly useful for limited asset sharing)

From what Paul said it seems like there may be some redundant code in there based on legacy SDK which may be sending way too much information to the GPU than necessary. Hence the slowdown. I have no idea about programming and this may be a huge undertaking.. I just don't know. But there's a massive bottleneck somewhere in between modo oprations and getting the data to the GPU. Just look at other host apps or standalone and the difference is night and day.

My workaround for now is to create a modo instance for anything over half a million polygons. Send the source mesh 100 meters away from the scene (probably doesn't have to be 100 meters but better safe than sorry I don't want that laggy mesh anywhere near my camera's field of vision) and use an instanced version of it instead. Can still use all the modifiers I can think of right now including morphs etc. and the IPR feedback is fast.