[Bf-committers] User-defined Material Properties
gtmacdonald at gmail.com
Thu Oct 13 18:56:27 CEST 2005
On 10/13/05, Ton Roosendaal <ton at blender.org> wrote:
> Yeah... I'm now heading the conference venue to set everything up. The
> rest of the day I have to prepare talks. Then friday to sunday I'm
> fully occupied. :)
> > I think we could do this in steps:
> > 1) Add the property type that's currently being used for game
> > properties to as many DNA structs as makes sense.
> Yep, but not in the ID struct as Campbell proposes. This is the general
> database identifier for Blender data, related to file read/write,
> library linking and some other pointer magic.
> It could be wrapped in a generic call like;
> ListBase *id_get_property_list(ID *id)
Ok, that would definately make more sense. It might be confusing that
properties is inside an ID. Conceptually I see why it wouldn't work, are
there any technical reasons not to though? The pointer magic you were
Since each ID can easily sort out which data is involved. Also that's
> something to think over.
> Also related to how the lists are constructed. For example, the struct
> Property can get another ListBase struct for creating groups and
> I really like to hear some remarks from people who work on other
> exporters first too. On the conference we'll meet with the Aqsis man
> and a CrystalSpace developer. I'll talk with them about it. :)
> > 2) Add custom panels where appropriate, that would take care of the
> > ui. (Maya does it this way with an 'Extra' tab off of each node.)
> I'll involve Matt in this too.
> > 3) Expose all properties to python scripts.
> Afaik there's already a property API (game engine only?). Nevertheless,
> this should be the last step, when the full design is verified.
I'm currently using the game engine properties, but they only apply to
objects and I need a more general solution. Specifically I need to attach
propertis to materials.
> 4) Add the ability for python to create panels and buttons.
> I don't think so! The property system should have this as intrinsic
> feature, would be much more reliable and flexible. Python should follow
> blender functionality too.
You're right. We'd be duplicating functionality.
> 5) Add the ability for python to add custom menus. For example, an
> > entry could be added to the ADD toolbox menu to execute a script and
> > add a custom object. Maybe this could be setup in a config file.
> Well, if Python should become an important means of creating custom
> menus/panels, we should look at a really good generic method for doing
> this. I know Willian has looked into this before... it's a difficult
> project, and I rather keep that separate.
> > I'm confident I can handle steps 1-3. I think those steps are pretty
> > straight forward.
> Yes, but also tricky... I'll be extremely picky on proper coding of
> that feature, it touches the heart of Blender's data system, and should
> be totally stable and future proof.
> You might give it a try... i can review. You can also wait for me to
> code it, it's not much work, but I will only do when the full range of
> usability of this has been explored and verified. :)
If we discuss at length the implementation specs, you aren't going to be
disappointed in what I code. If you're worried about my skills, I can send
you a resume. I realize you don't know me from a bag of beans. :)
You can definately do it faster, but this is a good opportunity for me to
become more familiar with the code and also with the process of adding
features and working with you guys. Plus, in the end you'll have another
developer at your disposal.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-committers