Geo update + motion blur on liquid ? Tweet

[fantome]

Hi guys,

I'm facing the exact same problem describe here :
viewtopic.php?f=81&t=56138

- in a single frame octane update the loading of the geo to the correct frame.
- in rendering sequence octane load the current frame of the animated geo sequence, but never update the geo on the other frames.

Any idea of a proper tricks to solve this issue ?

Does Octane support correct @v attribute store on an animated geo sequence for motion blur calculation ?

Thanks for your lights
Cheers
E

[fantome]

It looks that we must force with a full scene reload when rendering liquids ?
intuitively i might have think mesh deformation would be good enough.

As preprocessing geo is quite slow i was wondering what would be the most efficient way to store geo on disk to help octane go faster.
in Maxwell -> mxs
in Arnold -> Ass
in Octane -> Orbx ? Abc ?
I'm afraid that the bgeo to native octane scene format is one of the main reason of those long preprocessing time ?

Cheers
E

[juanjgon]

Hi, yes, usually while rendering fluids you are going to need to use the full scene reload because the object topology is not constant between the frames, so a full object reload is needed. Updating the mesh only makes sense for objects with deformations that have a constant topology, because if not, in any case, the object must be fully extracted.

The objects extraction/update is usually fast, but Octane spends some time preprocessing the scene to build the final GPU data and pass it to the GPUs. I'm afraid that this time is going to be needed in any case, but if you want to attach here a sample scene with your workflow I could take a look at it and check the extraction/preprocessing times.

Thanks,
-Juanjo

[fantome]

Thanks for your very detail answer Juanjo It does make sense.

The processing time are understandable and acceptable. But i would like to know what would be the most efficient way to store my geometry on disk.
At the moment all my liquid geocache are in native .bgeo.

I know that when i was using Maxwell / Arnold / Vray or Old Prman , there was a significant gain in term of speed and efficiency, when geo were written directly in the native format of the engine ( mxs,ass,vrmesh,rib).
So does octane have a similar workflow ?

- orbx export with the octane ROP sound like a good candidate ?
- are there better candidate or equal ? abc ?

https://docs.otoy.com/HoudiniH/Resource ... rchive.jpg

Or does native geo format translation is pointless ? / useless ? in the case of Octane ?

Thanks again for your help.
Cheers
E

[juanjgon]

Currently, the Houdini plugin can't render .orbx files, although it is a planned feature. In any case, this only could help a bit with the extraction time, but not with the preprocessing time, that is going to be the same even if you try to render an exported .orbx file in the Standalone.

The .bgeo cache is fine for Octane, probably you are not going to find another format to work faster with the Houdini plugin if you need to work with cached files.

Thanks,
-Juanjo

[fantome]

Thanks again for the detail answer Juanjo !

-> bgeo it is then !