Page 1 of 2

BlendLuxCore Particles support

Posted: Wed Jan 10, 2018 7:40 pm
by Piita
B.Y.O.B. wrote:
Mon Jan 08, 2018 11:23 pm
To my knowledge, these 3 areas are the most expensive to export:
  • Meshes (already accelerated in C++)
  • Particle/Hair systems
  • Smoke/Fire systems
The particle/hair system is quite expensive to export if using many particles/particle systems. If no edits have been made to the particle system, it would be very cool if the previous exported files could be used instead of writing new ones. Such as the edited flag on mesh objects. This would speed up exporting a lot while we wait for 2.8.

Re: BlendLuxCore Development

Posted: Wed Jan 10, 2018 8:44 pm
by B.Y.O.B.
Piita wrote:
Wed Jan 10, 2018 7:40 pm
it would be very cool if the previous exported files could be used instead of writing new ones.
Unforunately we can't get much faster in Python, I fear.
How the particle export works in LuxBlend:
  • Export the mesh that will be instanced
  • Export the object definitions for all the particles (using the mesh from the first step)
So we are already caching the expensive mesh export.
But if you export 10,000 particles or so, creating the object definitions alone takes up a lot of time.

edit: Ah, I think I get what you mean: save the object definition properties (pyluxcore.Properties()) to a cache and re-use them.
We can try that but I'll have to see if we can reliably check if the particle system changed.

Re: BlendLuxCore Development

Posted: Wed Jan 10, 2018 9:08 pm
by Dade
The "hair" format can potentially be used for particles too. The idea is to be able to define all particles with just one single call by passing a mesh (i.e. the particle) and the list of particles transformations.

How does Blender particles work ? Do you have a single definition of the particle mesh ?

Re: BlendLuxCore Development

Posted: Wed Jan 10, 2018 11:21 pm
by B.Y.O.B.
Dade wrote:
Wed Jan 10, 2018 9:08 pm
How does Blender particles work ? Do you have a single definition of the particle mesh ?
You can instance single objects or a group of objects.
But as an exporter you can call blender_object.dupli_list_create() and blender_object.dupli_list_clear(), and inbetween you get a blender_object.dupli_list which contains all particle objects and their matrices.
Cycles code: https://github.com/dfelinto/blender/blo ... t.cpp#L567
LuxBlend code: https://bitbucket.org/luxrender/luxblen ... lis.py-103

Re: BlendLuxCore Development

Posted: Thu Jan 11, 2018 12:29 am
by Dade
B.Y.O.B. wrote:
Wed Jan 10, 2018 11:21 pm
Dade wrote:
Wed Jan 10, 2018 9:08 pm
How does Blender particles work ? Do you have a single definition of the particle mesh ?
You can instance single objects or a group of objects.
But as an exporter you can call blender_object.dupli_list_create() and blender_object.dupli_list_clear(), and inbetween you get a blender_object.dupli_list which contains all particle objects and their matrices.
Cycles code: https://github.com/dfelinto/blender/blo ... t.cpp#L567
LuxBlend code: https://bitbucket.org/luxrender/luxblen ... lis.py-103
So the particles are all the same mesh/material aside from the transformation matrices and can be exported as a single mesh plus a list of transformations. I think we can have a quite fast path for this special case.

I'm thinking to this solution:

1) you create an object representing the first particle as usual.

2) I add a new method to the LuxCore API to duplicate an existing object (i.e. the first particle) as many times as you want by providing a list of transformation matrices.

It should be very fast: the cost of creating a single object + one more call to the "duplicate" function (from there it is my problem to run fast but it is all C++ and multi-threading is an option too).

How does it sounds ?

P.S. As usual if the particle is made of multiple materials, the above steps have to be repeated for each material.

Re: BlendLuxCore Development

Posted: Thu Jan 11, 2018 12:54 am
by B.Y.O.B.
That could work.
Note that it would be good to have motion blur support for particles.
So for step 2) I would like to be able to also pass a list of motion properties (step, time, transformation).

We would still have to do the visibility checks and list building in Python, but that can't be avoided.

by the way, I added first motion blur support for objects.
For now, I just matched Cycles behaviour.

Re: BlendLuxCore Particles support

Posted: Thu Jan 11, 2018 1:41 pm
by Dade
Moved the posts into a dedicated thread.

Re: BlendLuxCore Particles support

Posted: Sat Jan 13, 2018 12:26 pm
by Dade
I have added the support for Scene::DuplicateObject(). There are 4 versions of the function:
  • make an instanced copy of the object
  • make multiple instanced copy of the object
  • make an motion blur instanced copy of the object
  • make multiple motion blur instanced copy of the object
The "multiple copy" versions are the one to use for particles. You can find an example of how they works in Python here: https://github.com/LuxCoreRender/LuxCor ... eObject.py

The current version is able to create 1,000,000 of instances in 5.6secs (in Python): about 176K particles/sec

It may be possible to further speedup the process but let's see first how it works.

Re: BlendLuxCore Particles support

Posted: Sat Jan 13, 2018 3:32 pm
by B.Y.O.B.
Very cool.
I implemented support for it in the dupli_export branch: https://github.com/LuxCoreRender/BlendL ... 89341729f6
Results (particle export only, 10000 particles):
Previous export: 4.13 seconds
New export: 0.37 seconds

By the way: always funny when Blender OpenGL viewport lags and LuxCore viewport render is fluid :mrgreen:

Re: BlendLuxCore Particles support

Posted: Sat Jan 13, 2018 3:50 pm
by Dade
B.Y.O.B. wrote:
Sat Jan 13, 2018 3:32 pm
Very cool.
I implemented support for it in the dupli_export branch: https://github.com/LuxCoreRender/BlendL ... 89341729f6
Results (particle export only, 10000 particles):
Previous export: 4.13 seconds
New export: 0.37 seconds

By the way: always funny when Blender OpenGL viewport lags and LuxCore viewport render is fluid :mrgreen:
Ahah :mrgreen:

(Jokes aside, an old argument in the "Rasterization" Vs "Ray tracing" battle has always been that ray tracing is O(log n) with the objects to render while rasterization is (mostly) O(n). So, first or later, ray tracing is always going to be better)