[Bf-committers] Render API: Framework and Scene Break-Down
two.a.ron at gmail.com
Wed Jun 6 12:18:12 CEST 2007
A last few things to your reply, Jonathan, as I think about it.
Whenever the blender internals are reworked, depending if it were
relevant to the rendering, both the Pythong API and the Render API
would have to be updated. This is bad. Bad for maintenance and bad for
But keeping them separate ensures that they won't break each other.
If they were to be integrated with each other, it would have to be
done VERY well. Planning for this would lengthen my design process,
tie more developers into my project (the Python API people, assuming
they're not already involved), and make everything much more
When you look at things from the point of view of the current source,
simply reimplementing the current convertblender.c as a render API
makes a lot of sense, because you only see the localized improvement
in development ease.
But looking from a wider more theoretical angle, you're point is a
... it is a problem!
... which I don't know how to solve.
If, with further thought and input from others this makes sense, and
if someone comes up with a brilliant idea that would solve the
practicality problem, I would be willing to go for it. But those
blocks stand in the way right now.
Ah, also, here's one significant difference between the APIs. The
Render API is intended for both internal use (the internal render will
use it) and external. Just one way in which the goals and requirements
of the systems differ.
More information about the Bf-committers