[Bf-committers] DupliMats, redux

[Joe Eagar]

Ed Halley wrote:
>
> 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?
>
Well a basic duplivert random-offset node would be nice (maybe call it 
"DupliRand Offset"?).  Certainly the concept of controllable realistic 
differences in dupliverts needs to be addressed at some point.

The big hurdle might be figuring out the *best* UI to use, and on this I 
don't really have any ideas other then what hari' said.

joeedh