OTOY Forums

Oops

https://fstormrender.ru/fstorm-1-2-5/

Whatever the speed hit is, this is not from geometry processing in the V4 core, which someone on FB confirmed is working as expected when collapsing the objects to single mesh - e.g. V4 gets the speed to 10 million polys loaded in 3 seconds, so 70 million polys would be 20 seconds to load. This is how it should be, so we'll have to investigate what is going on with multiple objects slowing things down - can we confirm this speed hit is identical in both V3 and V4.

As for memory consumption, hardware texture compression of 4:1 to 8:1 will be working in RC1, and for geometry, fast out of core goemtry was put ahead of thinning geometry footprint in this release. In V1,V2 - geometry was 2/3 the size, but that came at the expense of many things that V3 added - think about the state of network rendering or volumetrics pre-V3.

We have a plan to get back to the V1/2 geometric memory footprint even as we add more features beyond V4, but that has to wait until we are done with a new primitive system going in 2018.1, which we will share more on next week.

Goldorak wrote:Whatever the speed hit is, this is not from geometry processing in the V4 core, which someone on FB confirmed is working as expected when collapsing the objects to single mesh - e.g. V4 gets the speed to 10 million polys loaded in 3 seconds, so 70 million polys would be 20 seconds to load. This is how it should be, so we'll have to investigate what is going on with multiple objects slowing things down - can we confirm this speed hit is identical in both V3 and V4.

As for memory consumption, hardware texture compression of 4:1 to 8:1 will be working in RC1, and for geometry, fast out of core goemtry was put ahead of thinning geometry footprint in this release. In V1,V2 - geometry was 2/3 the size, but that came at the expense of many things that V3 added - think about the state of network rendering or volumetrics pre-V3.

We have a plan to get back to the V1/2 geometric memory footprint even as we add more features beyond V4, but that has to wait until we are done with a new primitive system going in 2018.1, which we will share more on next week.

Yes this is not a V4 issue - it seems to be a 3ds max plugin issue.

I just made a 3ds max bug thread here to move it away from the v4 release thread:
viewtopic.php?f=81&t=68452&p=343510#p343510

RobSteady wrote:Oops

https://fstormrender.ru/fstorm-1-2-5/

That escalated quickly

We have a bug in the max plug-in with multiple objects as the poster above confirmed. That issue aside, 70 million polys should load in ~21 seconds in V4 - not 6 minutes (and not two minutes - which is still 6x slower than the speed we'd expect). It would be great to get someone to test this out in XB4 by collapsing a scene of that size to one object in Max, or exporting to SA and posting results of scene loading time, to close out the issue on the core engine side of things.

UPDATE - We've just tested individual unique objects (each with their own verts/prims) loading in standalone V4 and ~7000 objects can load in < 1, so this at least confirms object instances are not causing any intrinsic slowdown at the engine layer - and that this almost certainly is a bug happening at the plug-in layer. We'll test the sample scene provided here in ORBX to confirm this is the case with real world scenes, then work backwards to figure out why the Max plug-in is exhibiting this behavior only in the plug-in.

The slow scene evaluation with many objects mainly comes from the 'Use obj render settings' option in the Kernel settings.
I did a test with a scene with 5500 cubes. The evaluation time was :
105.80 sec when turned on
1.06 sec when turned off !

This option allows to get a correct mesh from all the potential modifiers attached to the object and other settings.., but might not be needed in most cases..
I'm investigating the best way to fix this issue in a generic way, probably by moving this option on a per object basis, in the octane object properties..

Another option, the Refresh time (ms) that was recently set to 0 by default can slow down a little bit the evaluation step, and the rendering with many objects when using the viewport..
You could increase it to 10 ~ 30 ms when working with such scenes, at the cost of a less interactive viewport

neonZorglub wrote:The slow scene evaluation with many objects mainly comes from the 'Use obj render settings' option in the Kernel settings.
I did a test with a scene with 5500 cubes. The evaluation time was :
105.80 sec when turned on
1.06 sec when turned off !

This option allows to get a correct mesh from all the potential modifiers attached to the object and other settings.., but might not be needed in most cases..
I'm investigating the best way to fix this issue in a generic way, probably by moving this option on a per object basis, in the octane object properties..

Another option, the Refresh time (ms) that was recently set to 0 by default can slow down a little bit the evaluation step, and the rendering with many objects when using the viewport..
You could increase it to 10 ~ 30 ms when working with such scenes, at the cost of a less interactive viewport

Wow Thank you, guys. You are the best!
By the way any way to test multiple phoenix fd liquid grids or smoke grids? In octane 3 adding the seconds grid processing time goes up by 200% 3 grids 400% and etc Thanks

Thanks a lot Neon Z !! Hope you can find an elegant and effective solution !

neonZorglub wrote:The slow scene evaluation with many objects mainly comes from the 'Use obj render settings' option in the Kernel settings.
I did a test with a scene with 5500 cubes. The evaluation time was :
105.80 sec when turned on
1.06 sec when turned off !

This option allows to get a correct mesh from all the potential modifiers attached to the object and other settings.., but might not be needed in most cases..
I'm investigating the best way to fix this issue in a generic way, probably by moving this option on a per object basis, in the octane object properties..

Another option, the Refresh time (ms) that was recently set to 0 by default can slow down a little bit the evaluation step, and the rendering with many objects when using the viewport..
You could increase it to 10 ~ 30 ms when working with such scenes, at the cost of a less interactive viewport

Hi neonZorglub,

I've tested my scene which took 5.5 minutes to load with OBJ setting is off - now it is 17 seconds
Thank you for the quick respond on this issue, hope next update with elegant fix will come out quickly

Cheers