[Bf-committers] A contribution

[Dan Brown]

Jonathan Merritt wrote:
> Hi Dan,
> 
> Could you please expand on your metadata idea a little?  Do your 
> metadata fields exist only for empties, or will they exist for all objects?
> 
> The reason I ask is that I've been thinking for a long time about how 
> best to set custom shaders for objects, for use in RenderMan export.  
> Although we already have quite decent simulation of the basic Blender 
> lights and materials, the ability to set custom shaders is a must-have 
> to be able to truly harness the power of RenderMan renderers.  Both the 
> shader and a varying number of shader parameters (which can be floats, 
> string, matrices, and arrays of those types) need to be set.
> 
> Currently, I'm heading towards the idea of an *entirely* different type 
> of material, integrated into Blender in a way that is independent of any 
> other system (I'm not sure what Paul Gregory's thoughts on the matter 
> are).  However, it continually occurs to me that shader names and 
> parameters might form part of a much larger dictionary of values (like 
> your metadata), that could apply in different contexts and be accessed 
> in a much more generic way.  I'm very reluctant to use the game engine 
> properties for this, but a similar (expanded) system would be ideal.

Hi,

If I understand you correctly, I had a similar idea. But I was going to
implement it as a Python script on top of the metadata to keep the
interface clean for other peoples use. So you would select an object,
then run a script to set it up with the default fields for the required
object. So for my example screenshot, I would create on a new point Empty
then run SetupEmptyAsDoor.py (accesible from a menu) which would automatically 
add the fields 'Type', 'Target', 'Angle', 'OpenAngle', and the other relevant 
ones and fill in default values to make them valid for importing to a different 
engine straight away. Then it is just a case of the user setting the actual 
required values for that object.

I did think about proposing that it could be a blender config setting
though. So you could just load a Empty config list (a text file) which
would define what Empties are available with which properties. So there
could be several point Empties, but with different names and sets of
fields. This way it is highly customisable for those of us exporting
data to use elsewhere. However I think now that using Python as I mentioned
above would be more acceptable all round though. It may not be as
flexible, but it avoids cluttering Blender with features that the
majority of people would never use.

The game engine properties don't seem to support arrays or matrices
though so that might be a problem. Maybe a string with it's value set to the 
name of a text block that contains the actual data? The exporter could just 
replace the string with the correct data, but it would make it more annoying to use.

The gameengine properties seem ideal for these purposes otherwise and
work on all objects that I tried it with not just empties. Putting a similar 
system elsewhere would be duplicating code and functionality and the effort 
involved would probably be better spent expanding on the current properties to 
make it useful for all our needs.

Dan