Particle Info node for Cycles

Adds a new "Particle Info" node for cycles, to allow using particle data in shaders. For now only Age and total Lifetime are supported, but can be extended easily as required.

Test render:
http://www.youtube.com/watch?v=QvATUlmguyk

The particles from all object psys are first converted into an array in the Cycles object. Then the data is stored in a separate particles texture on the device.

For mapping dupli objects back onto particles they store an additional particle_id number. This number is then used to look up the particle data from the particle device texture.

[brechtvl, 2012-06-01 14:33:32]

Thanks for the patch, node setups with this kind of data could be pretty
powerful. Comments below.

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_ob...
File intern/cycles/blender/blender_object.cpp (left):

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_ob...
intern/cycles/blender/blender_object.cpp:325: bool render_emitter = false;
This code can't be simplified like this. The intention is make existence of a
particle system hide the emitter, not only to unhide it if use_render_emitter is
on.

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_ob...
File intern/cycles/blender/blender_object.cpp (right):

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_ob...
intern/cycles/blender/blender_object.cpp:274: sync_particles(object, b_ob);
This should be done only on demand, by adding a ParticleInfoNode::attributes(..)
callback, which adds a ATTR_STD_PARTICLE request, which can then be checked here
with object->mesh->need_attribute(scene, ATTR_STD_PARTICLE);

This is usually for mesh element attributes but actually was intended to work
for requesting per object attributes as well.

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_ob...
intern/cycles/blender/blender_object.cpp:329: int particle_index = (b_index >
num_particles ? 0 : b_index + particle_offset);
This is not going to work for particles inside dupligroups, trying to match
these indices is not reliable. I think the proper solution is to put the
particle index in the DupliObject.

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_sy...
File intern/cycles/blender/blender_sync.cpp (right):

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_sy...
intern/cycles/blender/blender_sync.cpp:83: if(b_ob->is_updated() ||
b_ob->is_updated_data()) {
Why is this needed?

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_ut...
File intern/cycles/blender/blender_util.h (right):

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_ut...
intern/cycles/blender/blender_util.h:277: if(parent.ptr.data) {
This change can be reverted.

http://codereview.appspot.com/6242069/diff/1/intern/cycles/render/object.cpp
File intern/cycles/render/object.cpp (right):

http://codereview.appspot.com/6242069/diff/1/intern/cycles/render/object.cpp#...
intern/cycles/render/object.cpp:213: object_map[offset_map] =
make_uint4(ob->pass_id, ob->random_id, ob->particle_id, 0);
Why not stick the particle_id in the make_float4 above? __int_as_float and
__float_as_int can be used to avoid any precision loss.

The loss of precision for pass_id is not a problem because it ends up in a float
buffer or as a float in shader nodes anyway.

I try to not use too many textures because OpenCL/CUDA can only handle a limited
number of arrays.

http://codereview.appspot.com/6242069/diff/1/intern/cycles/render/object.cpp#...
intern/cycles/render/object.cpp:286: /* create a dummy 1-particle texture to
avoid invalid lookups */
This avoids invalid lookups in case you have no objects with particles, but the
particle info node is still used.

But for the case you have some objects with particles, and another object with a
particle info node but no particles, it will still do an invalid lookup. Maybe
the first element in the arrays should always be this dummy element?

[lukas.toenne, 2012-06-08 10:57:51]

Improvements suggested by Brecht

[lukas.toenne, 2012-06-08 10:59:04]

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_ob...
File intern/cycles/blender/blender_object.cpp (right):

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_ob...
intern/cycles/blender/blender_object.cpp:274: sync_particles(object, b_ob);
On 2012/06/01 14:33:32, brechtvl wrote:
> This should be done only on demand, by adding a
ParticleInfoNode::attributes(..)
> callback, which adds a ATTR_STD_PARTICLE request, which can then be checked
here
> with object->mesh->need_attribute(scene, ATTR_STD_PARTICLE);
> 
> This is usually for mesh element attributes but actually was intended to work
> for requesting per object attributes as well.

Done. There is now a function object_use_particles to check object particle
systems for all shader users, depending on render mode. Currently only does
dupli object/group, but has code for future billboards (assuming those will be
stored to the object's own mesh).

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_ob...
intern/cycles/blender/blender_object.cpp:329: int particle_index = (b_index >
num_particles ? 0 : b_index + particle_offset);
On 2012/06/01 14:33:32, brechtvl wrote:
> This is not going to work for particles inside dupligroups, trying to match
> these indices is not reliable. I think the proper solution is to put the
> particle index in the DupliObject.

Done. I've added an explicit particle_index to DupliObject, which is the lowest
level (visible) particle index. Does not work with particles on top of particles
(second index is ignored), but should cover most use cases with groups and the
like.

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_sy...
File intern/cycles/blender/blender_sync.cpp (right):

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_sy...
intern/cycles/blender/blender_sync.cpp:83: if(b_ob->is_updated() ||
b_ob->is_updated_data()) {
On 2012/06/01 14:33:32, brechtvl wrote:
> Why is this needed?

In fact it isn't ... Don't remember why this is still here, i think i was trying
to get updates when only particles change, but that seems to work now without
this. Removed.

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_ut...
File intern/cycles/blender/blender_util.h (right):

http://codereview.appspot.com/6242069/diff/1/intern/cycles/blender/blender_ut...
intern/cycles/blender/blender_util.h:277: if(parent.ptr.data) {
On 2012/06/01 14:33:32, brechtvl wrote:
> This change can be reverted.

Done.

http://codereview.appspot.com/6242069/diff/1/intern/cycles/render/object.cpp
File intern/cycles/render/object.cpp (right):

http://codereview.appspot.com/6242069/diff/1/intern/cycles/render/object.cpp#...
intern/cycles/render/object.cpp:213: object_map[offset_map] =
make_uint4(ob->pass_id, ob->random_id, ob->particle_id, 0);
On 2012/06/01 14:33:32, brechtvl wrote:
> Why not stick the particle_id in the make_float4 above? __int_as_float and
> __float_as_int can be used to avoid any precision loss.
> 
> The loss of precision for pass_id is not a problem because it ends up in a
float
> buffer or as a float in shader nodes anyway.
> 
> I try to not use too many textures because OpenCL/CUDA can only handle a
limited
> number of arrays.

Done.

http://codereview.appspot.com/6242069/diff/1/intern/cycles/render/object.cpp#...
intern/cycles/render/object.cpp:286: /* create a dummy 1-particle texture to
avoid invalid lookups */
On 2012/06/01 14:33:32, brechtvl wrote:
> This avoids invalid lookups in case you have no objects with particles, but
the
> particle info node is still used.
> 
> But for the case you have some objects with particles, and another object with
a
> particle info node but no particles, it will still do an invalid lookup. Maybe
> the first element in the arrays should always be this dummy element?

Done.

[brechtvl, 2012-06-08 15:24:24]

Besides one comment, LGTM.

http://codereview.appspot.com/6242069/diff/11001/intern/cycles/render/object.cpp
File intern/cycles/render/object.cpp (right):

http://codereview.appspot.com/6242069/diff/11001/intern/cycles/render/object....
intern/cycles/render/object.cpp:150: /* XXX why using OBJECT_SIZE for flag
texture as well? */
I guess this can be removed? Otherwise don't understand what this question
means.

[lukas.toenne, 2012-06-08 16:04:36]

http://codereview.appspot.com/6242069/diff/11001/intern/cycles/render/object.cpp
File intern/cycles/render/object.cpp (right):

http://codereview.appspot.com/6242069/diff/11001/intern/cycles/render/object....
intern/cycles/render/object.cpp:150: /* XXX why using OBJECT_SIZE for flag
texture as well? */
On 2012/06/08 15:24:24, brechtvl wrote:
> I guess this can be removed? Otherwise don't understand what this question
> means.

I was a bit confused why you are using the OBJECT_SIZE for generating the offset
for the object_flag texture as well. If they actually use the same amount of
bytes per object that would be coincidence? But yeah, shouldn't add random
comments in code when i don't get it, too easy to forget about them ...

[brechtvl, 2012-06-08 16:09:41]

Ah, you're right, the object_flag array is too big, doesn't need the OBJECT_SIZE
multiplier.