Both of you have excellent points, but I think it all boils down to performance; python is nice for plugins, not as a glue, the overhead of going back and forth to the VM and the memory management will take it's toll.<br>
<br>I vote for a C API - this is the native to blender, it concerns the required part and so on. <br><br>I also don't see the wider angle you are talking about, if python wrapper is needed, wrap the code, but don't use it in the process itself.
<br><br>Also, am reading the wiki (haven't finished) but wanted to ask if this API will be able to change the information before the render, and if so, will it go back to the scene or be part of the rendering only?<br>
<br>my 0.000001 cent<br><br><div><span class="gmail_quote">On 6/6/07, <b class="gmail_sendername">Aaron Moore</b> <<a href="mailto:two.a.ron@gmail.com">two.a.ron@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A last few things to your reply, Jonathan, as I think about it.<br><br>Whenever the blender internals are reworked, depending if it were<br>relevant to the rendering, both the Pythong API and the Render API<br>would have to be updated. This is bad. Bad for maintenance and bad for
<br>debugging.<br><br>But keeping them separate ensures that they won't break each other.<br><br>If they were to be integrated with each other, it would have to be<br>done VERY well. Planning for this would lengthen my design process,
<br>tie more developers into my project (the Python API people, assuming<br>they're not already involved), and make everything much more<br>complicated.<br><br>When you look at things from the point of view of the current source,
<br>simply reimplementing the current convertblender.c as a render API<br>makes a lot of sense, because you only see the localized improvement<br>in development ease.<br><br>But looking from a wider more theoretical angle, you're point is a
<br>definite concern.<br><br>... it is a problem!<br>... which I don't know how to solve.<br><br>If, with further thought and input from others this makes sense, and<br>if someone comes up with a brilliant idea that would solve the
<br>practicality problem, I would be willing to go for it. But those<br>blocks stand in the way right now.<br><br>Ah, also, here's one significant difference between the APIs. The<br>Render API is intended for both internal use (the internal render will
<br>use it) and external. Just one way in which the goals and requirements<br>of the systems differ.<br><br>Aaron<br>_______________________________________________<br>Bf-committers mailing list<br><a href="mailto:Bf-committers@blender.org">
Bf-committers@blender.org</a><br><a href="http://lists.blender.org/mailman/listinfo/bf-committers">http://lists.blender.org/mailman/listinfo/bf-committers</a><br></blockquote></div><br>