On Mon, Dec 1, 2008 at 12:48 PM, Timothy Baldridge <span dir="ltr"><<a href="mailto:tbaldridge@gmail.com">tbaldridge@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">> What remains is a lot of calls like "Add constraint" or "Delete<br>
> modifier", which is currently a very undefined piece of Blender code,<br>
> closely tied to the buttons for such options. At this moment it's well<br>
> possible we don't tackle all of that via Operators, still allowing<br>
> direct callbacks to buttons (just for the sake of simpler migration).<br>
<br>
</div>It seems to me that part of these issues come from the fact that we're<br>
trying to squish the rather procedural API of C into the OOP based<br>
programming of Python.</blockquote><div> </div><div>Nah it's not too bad. A lot of things map fairly well. I don't think we've really had much trouble in this area. It's not nearly as hard as it might look.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
I'm assuming the issue with things like modifier stacks is that<br>
currently every list of objects in Blender uses a different method of<br>
data modifiying? So in some cases we have linked lists and other times<br>
we have vectors (arrays). Perhaps what we need is a Standard Template<br>
Library for blender. In this way we can make the internal Blender code<br>
more closely match the Python code.</blockquote><div> </div><div>Not really, the modifier system works using a quasi-OOP design itself, using DerivedMesh to access data. And we do have standard functions for manipulating several kinds of lists.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
It seems to me that the best way way to have Python access the<br>
modifier stacks would be with Python lists:<br>
<br>
obj = getObject("MyBlenderObject")<br>
mod = BuildModifyer()<br>
obj.modifiers.append(mod)</blockquote><div> </div><div>That's how most of the py API works already. It's actually not all that hard to write custom list wrappers when you need them. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
But while we're on the subject of rewriting everything, should we<br>
stick with C instead of C++? Now I know, most C++ code is often (or<br>
perhaps most times) abused, but well written C++ code can aid<br>
readability. It seems to me that allot of Blender code could be<br>
simplified by using the OOP-ness of C++. In general the 3d tool set<br>
is object based. We take a object and set the transform and rotation<br>
attributes of that object. We use modifiers to warp object. It seems<br>
that the code should express this to some extent. In the end it's<br>
really 6 of one half a dozen of the other, but C++ would help new<br>
coders make a easier transition from Python to C++.</blockquote><div><br>That'd require rewriting most of the core blender code, which isn't really worth it for the benefits (especially since C++ is so much more complicated than C).<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
</blockquote></div>The issue isn't really the fact we're using C, or any procedural/OOP clashes (remember python supports both an OOP and a procedural approach to things). What ton was talking about specifically is that the new API should always try and use the appropriate C API in blender to do things, even if the part of the code someone's trying to wrap in python doesn't use that API itself yet (in which case the py coder would have to rework it to use the API, or something like that).<br>
<br>Joe<br>