Page 3 of 6

Re: OpenVDB support

Posted: Thu Apr 12, 2018 2:44 pm
by B.Y.O.B.
Great!
These are my timings:

Old:

Code: Select all

[Smoke Domain] Beginning smoke export (channel: density)
[Smoke Domain] conversion from bpy_prop_array to Python list took 0.640s
>>> Smoke Export total time: 15.671s
New:

Code: Select all

[Smoke Domain] Beginning smoke export (channel: density)
[Smoke Domain] conversion from bpy_prop_array to Python list took 0.610s
>>> Smoke Export total time: 3.480s
(Tests with a grid with 13,141,440 floats)

But currently I'm still converting the bpy_prop_array to a list like we did before.
If I try to pass the bpy_prop_array to AddAllFloat directly, I get this error:

Code: Select all

Wrong data type for the list of values of method GetArray(): bpy_prop_array

Re: OpenVDB support

Posted: Thu Apr 12, 2018 2:59 pm
by Dade
B.Y.O.B. wrote: Thu Apr 12, 2018 2:44 pm But currently I'm still converting the bpy_prop_array to a list like we did before.
If I try to pass the bpy_prop_array to AddAllFloat directly, I get this error:

Code: Select all

Wrong data type for the list of values of method GetArray(): bpy_prop_array
Bah, they don't offer Python buffer interface, can you post a test scene, so I can run the tests here and check if I can directly read from bpy_prop_array.

Re: OpenVDB support

Posted: Thu Apr 12, 2018 3:24 pm
by B.Y.O.B.
Here.
But if it's too much trouble - 0.6 seconds on 13 Mio. floats is OK I think.

You have to checkout the branch byp_prop_array in BlendLuxCore to get the error.

Re: OpenVDB support

Posted: Fri Apr 13, 2018 2:57 pm
by Dade
B.Y.O.B. wrote: Thu Apr 12, 2018 3:24 pm But if it's too much trouble - 0.6 seconds on 13 Mio. floats is OK I think.
Ok, I see, it is just a "list(grid)". Do you need an AddAllFloat with stride ? To read 3 float (aka RGB) and skip one (aka Alpha).

Re: OpenVDB support

Posted: Fri Apr 13, 2018 3:03 pm
by B.Y.O.B.
Dade wrote: Fri Apr 13, 2018 2:57 pm Ok, I see, it is just a "list(grid)". Do you need an AddAllFloat with stride ? To read 3 float (aka RGB) and skip one (aka Alpha).
Would make color grid export faster, yes.

Re: OpenVDB support

Posted: Fri Apr 13, 2018 3:24 pm
by Dade
B.Y.O.B. wrote: Fri Apr 13, 2018 3:03 pm
Dade wrote: Fri Apr 13, 2018 2:57 pm Ok, I see, it is just a "list(grid)". Do you need an AddAllFloat with stride ? To read 3 float (aka RGB) and skip one (aka Alpha).
Would make color grid export faster, yes.
Ok, I added the support for ".AddAllFloat(list, 3, 1)" (it will read 3 float and skip one). And I guess we can can close this chapter for the moment.

Re: OpenVDB support

Posted: Fri Apr 13, 2018 3:42 pm
by B.Y.O.B.
You used u_int instead of unsigned int, will this cause problems on Windows again?

edit: Guess not, it was there before.

Re: OpenVDB support

Posted: Sat Oct 05, 2019 12:43 pm
by Rivental1
Sory for stupid question... I have read the branch, but my English is very bad, and i not understood eventually... Can we render VDB files (not blender simulation cash) inside blender with luxcore?

Re: OpenVDB support

Posted: Sat Oct 05, 2019 11:10 pm
by B.Y.O.B.
Rivental1 wrote: Sat Oct 05, 2019 12:43 pm Can we render VDB files (not blender simulation cash) inside blender with luxcore?
No, the only option currently implemented in the Blender addon is to read the cache through Blender (can be Blender's own format or OpenVDB, but it has to be loaded by Blender).
There has been some work on an OpenVDB node that would bypass Blender's simulation cache, but it's not yet done: https://github.com/LuxCoreRender/BlendL ... penVDBNode

Re: OpenVDB support

Posted: Sun Oct 06, 2019 5:28 am
by Rivental1
Thank you. Blender smoke simulator is very slow and often gives strange results... So would be great to render VDB cash from other programms, like Houdini or Cinema 4d with FumeFX or TFD. Strange why blender no read other VDB files...