[Bf-committers] DupliMats, redux

[Ed Halley]

The primary goal of duplimats has already been written on the wiki, in 
case this is not familiar already.

   http://mediawiki.blender.org/index.php/BlenderDev/DupliMats

Now that the Orange branch has merged in, with a new dupli iteration 
model, my old DupliMats patch won't merge.  I was expecting this, and 
it's okay with me.  But I've been trying to understand a bit more about 
the Node system to see how the concept would fit in that scheme.

This is my thinking:

   * The old duplimat system provided a private random-number-generating
     thread.  This RNG was re-seeded for every object, including virtual
     objects like duplivert objects.  The seed was derived from the
     object's name, the obdata's name, and a serial number that came from
     the dupli traversal.  This gave each separate rendered object a
     unique and reproduceable seed, which could then tweak the materials.

   * The new node-based materials system could maybe have a node of type
     Random which worked in similar fashion.  It would have a number of
     strategies and input parameters for deciding upon a seed, and for
     deciding the output range, and from that point, it would simply
     produce random [MIN,MAX] range random values as an output.

   * These outputs could be used in anything, but the crucial ones I have
     found through my duplimat testing are for color-deviation in RGB
     space, offsetXYZ in texture space, scaleXYZ in texture space, and
     diffuse-amount variations.  One which I think would be of great use
     would be color-deviations in HSV space, but I didn't code that in
     the first duplimats either.

   * The only situation which I found that the old hashing scheme did
     not work is when animating particles, since new objects were being
     created all the time, which upset the serial number used in the
     old hash scheme.  Other than that, it was quite capable of dealing
     with thousands of dupli-generated materials for the duration of a
     given render.

Does anyone else have feedback on how to implement the concept in 
today's scheme?

-- 
[ e d @ h a l l e y . c c ]