[Bf-committers] Final Design of Basics (render api)

[Aaron Moore]

Hi Campbell,

Thanks for the quick reply as I'm trying to get started coding on this asap.

> One thing I think should be re-thought is your basic property system.
> http://wiki.blender.org/index.php/Render_API#Bookmarking_Data

This was one of the last added features, so it's certainly up for critique.

> Blender already has property's for anything with an ID (materials,
> objects, geometry etc...)
>
> One of the reasons these were added was to support settings for external
> renderer's.
>
> A solution for this could be to give each scene, object, mesh, material
> and light  a copy of blenders ID-Property, so it could use this for
> storing user settings. but also add temporary settings there without
> messing up the user data.
>
> Joe did a nice job with the ID-Prop api but you'd probably want to have
> your own interface to modifying the data so the render api could be kept
> stable if blenders ID props ever change.
>
> At least its probably not a lot of work wrapping the ID-Prop API, you
> could look at the python API interface as a guide.

I guess I feel inclined to disagree with using ID-Properties for
temporary data. Here are my thoughts.

The ID-Property system I agree will almost definitely be used for
supporting custom renderer's settings. (But when you add custom render
settings you need to add a custom render GUI and that's out of the
scope of my project.) However, using these in the present case seems
odd to me. I will explain.

ID-Properties were design specifically so that custom data could be
saved to the blend file. This data is temporary to each render job,
thus it has no business being saved to the blend file. However, it
might be nice to use ID properties for both renderer's custom data and
temporary data. It would also be nice to reuse the existing system.
But if ID-Properties were assigned during the render job they would
have to be deleted at the end, so they wouldn't appear in blender,
which could be done, but might be strange from a design perspective.
Alternatively a new and separate ID-Property group could be used for
the temporary data, which should make the task of keeping these
separate and deleting the temporary data simple. But when you add to
this that I would want to supplement the access functions (add
arbitrary data), this begins to look very much like a completely new
system, created by hacking the old system.

Finally, as far as I've seen ID-Properties don't have an interface for
arbitrary data. It looks like they are completely capable of storing
arbitrary data, but there are no functions for setting and getting
this, and no "arbitrary" or "other" type. This makes sense, because 1)
how do you save and load arbitrary data from a file? 2) why would you
ever need to?

Now someone could be argued that arbitrary data is not strictly
necessary, and I think they would be right, but I also think it would
be harmless and useful to include support for it. This would be a
convenience for renderman exporters (to give a single example),
because they need to keep track of instance handlers returned by
RiLightSource, RiObjectBegin, and others. These handlers are renderman
types so support for the type can't be expected in the render API, but
void*s can point anywhere, why not assign pointers to assign
customvalue = &RiObjectHandler, and then you can simply plug the
handler in when you need it rather than fetch the handler from some
index that you keep tabs on and store the index number on the property
instead of the handler itself. It removes a step and I don't see the
harm to it. The exporter only has to keep the types strait within
itself, so no harm in using void*s. Correct me if I'm wrong.

This is the way I'm currently thinking about the temporary custom data
for exporters. It could be implemented using ID properties on the back
end, but ID properties were design for something else, so I think that
that would potentially create a conflict of interest when either
system is subject to change, this is why I suggest leaving the design
as it is. Unless there is a good reason not to support arbitrary data,
but that is another discussion.

Aaron