Ok - i’m not quiet…
I wasn’t complaining. I just wanted to express my worries.
One of the strengths of the current API in my eyes is the relatively fast and easy access to “low-level” functionality (due to wrapped data access) - like changing the vertex location. This low level functionality must be as fast as possible to enable scripts to add NEW functionality to Blender. I’m talking about scripting new modelling tools that use spacehandlers for example. Now it’s possible to create such new stuff - e.g. i’m currently implementing a sketch based modelling tool and it turns out quite nice. You can interactively sketch the silhouette of a mesh and your sketch modifies the 3d-model…
What isn’t possible now is accessing Blender’s high level functionality - as Ideasman said: try to do an “extrude” in your script. It’s either: “code the function yourself in python again” or “leave it”.
For the high level stuff that is already in Blender, the new API will provide the operator access - hello “extrude” (GOOD).
But please don’t disregard the low level stuff. If this happens, the new API will degrade scripting to simple “macro recording”. The consequence will be: if there isn’t a high level function in Blender already you also cannot code it simply because the low level stuff is way too slow to be usable (does Blender have sketch based modelling functionality already? - i know etch-a-ton)
That was also why i voted against a second or third language. It’ll just get more complicated to properly implement all these things and therefore it would be very likely that the scripting api gets restricted to invoking existing high level functionality instead of enabling both: access to existing functionality and proper support (read: fast low level access) for implementing new stuff.
The question whether the (one and only) scripting language for Blender should be python or something else (possibly a “faster” language than python) isn’t my concern. I’d even learn a new language if i think it’s worth it.
I am not for and also not against it. I started learning python some weeks ago and will stay on it. I would suggest to implement Python only. If there is really a need for it, go ahead, sure, but it’s not a priority in my opinion. Do other 3D apps have multiple script languages? Many of them also use Python (only)…
was just reading some time ago about Lightwave Core which uses SWIG for all it’s script interfaces/bindings, they also chose python as the base scripting language, but thx to generating everything with SWIG one will be able to generate interfaces for all the languages SWIG supports using the Lightwave Core SDK. To name a few: Perl, Ruby, Lua, CLISP…
I think that would be a nice way for doing script bindings, but that would need quite some work i guess, i scanned through the blender 2.48 source code and it looks like all the python bindings/wrappers are written by hand so far.
-1 for this whole idea.
How could it be even thought of?
To be honest, Python in Blender needs to be properly implemented.
Before any secondary languages are even considered.
Great, lets have several improperly integrated languages.
That will help.
Anyone ever thought about finishing what they started,
and of consolidating what we have first?
Bah Humbug.
Maby a easier to integrate scripting language should be used instead, as far as ive looked into it(not verry far), Python appears to be difficult to intergrate into outher programs, LUA looks to be easier.
another -1 for the idea…
the Cons outweigh the Pros… especially the ‘bloat’ point and the exchanging scripts written in different languages by script-writers…
Structure 2.5 to allow additional languages in the future, but only include Python ability with 2.5. There is enough work to be done already without something as trivial as Python vs. Ruby taking up more critical development time. Maybe you can make a language implementation a GSoC project or something in the future.
At first glance I saw it as a good idea to give more flexibility and let anyone with any programming knowledge make new scripts.
The down side I agree with is that sharing code will be more difficult, and people learning how to script will have a more complex scenario when asking for help, with different people scripting in different languages.
I don’t know if the best language is Python, I do agree with having only one. I believe comunity-wise it would be a healthier option.
If someone knows how to code is not that difficult to learn Python. Having more options would save programmers the step of learning a language at the expense of losing in cooperation.
I believe coders can handle a language change.
Regarding code indentation in Python… Can’t Blender accept braces and convert them to Python indentation before executing? or just have a feature to convert from braces to tab indentation…
Uhm,I’m not so happy…
From what I can understand it will be slower,so custom stuff will be not doable at decent speed(for example deformation,rigging and shading).
This is a bit annoying,for me blender lacks in customizations made by users, if the system is good designed
mid advanced users can add little features,without asking to coders…
In the future I fear there will be less freedom for users,if you know how to do a feature you will not able to do it yourself without coding in c,and not all people have the time and experience to patch the sources(and also the wish to maintain a own version of the program)
Look at Maya,where people without coding skill can do all what he/she wants,simply connecting some nodes
That is the way to go,at least if you want that 3d generalist artists use the program.
I agree with Michael_S
Bye
Maya uses both MEL and Python. So, Python is a good choice for migration. I think the toughest part of MEL is learning all the Maya-specific objects that wouldn’t be migratable anyway.
I’d be much happier with only one language if there was fast access to some functions or at least a way of getting fast access without resorting to patching an entire branch of blender. That’s one way python works nicely right now: proofing your concept without waiting a huge chunk of time for the entire program to compile again, not having to fish around in miles of commentless code, etc.
EDIT: Wait, wait. I read something in the dev discussion. Ton mentioned C plugins. What form would these take, theoretically, and how fast would they be hoped to be?
OTHER EDIT: Because if there’s an option that allows speed (would a C plugin be faster than the python api now, even?) then I am all for making a totally generic script API.
I was under the impression that Python is becoming (already is?) the de facto industry standard scripting language for 3D apps (and other types of apps as well)? Blender supports it, XSI supports it, someone above mentioned that Maya supports it, it seems that Max, Houdini, and Cinema 4D support it, Newtek just announced Python support as a big new feature of their upcoming Lightwave CORE, etc. That covers all the major 3D apps.
Seems to me that Python is the only common scripting thread through all these 3D apps and a highly desirable feature in a 3D app. And Blender has been supporting it forever (? always? I don’t know). Maybe the saying “don’t ruin a good thing” applies here.
Think about what that could theoretically mean: as Python becomes more and more commonly used in other 3D apps, you could borrow scripts from other apps and possibly convert them for use in Blender and vice-versa. I don’t really know how feasible this is, but that seems to be the implication of what the guy is saying in that link.
Perhaps in the future if the SWIG thing works out really well for Lightwave and if it’s open source tech it could be considered for Blender, but for now it looks like there’s many reasons why it should stay Python all the way!
@renderdemon, “”“so custom stuff will be not doable at decent speed(for example deformation,rigging and shading).”"" - how does this, especially deformation relate to python at the moment?
RNA access is slower now but if its important it can be made to be as fast as the existing api or faster (By autogenerating C/Python api at build time so struct members have direct access rather then inspecting the rna as python is evaluated).
Id also not recommend using SWIG, python maps well into blender operators and rna,
if we use SWIG to wrap the existing C api we will end up having to make another python api around the SWIG generated py api so as to make it nice to use, and it will be slower then what is in 2.5 now.
If we make a nice C api that can be called directly to run operators and set rna then swig would be an option but currently we dont have this.
General comment, we can make any method fast enough if we want to make the effort. But hand writing the whole API is a BAD IDEA. - as well as being a lot of work and allowing for mistakes, you also have areas of blender that cant be accessed.
Edit, if you want fast access blender 2.4x isnt great either, better we allow numpy to access certain RNA data, I havnt used it but I hear its fast enough to do image manipulation and probably over 10x faster then what we have.
Hi Campbell,for deformations I mean manipulating points(not moving,scaling or rotating),for example twisting or other stuff(for example you can move vertices along the normals,sometimes it can be useful for joint deformations(ok,this can be done with a fake displacement modifier but it’s an example).
Now we have shrink wrap,but 2 years ago we had not it,so at that time I made my own script for snapping points on other meshes,it was a bit slow but doable.
I have seen also some people using the python api to manipulate vertex group on the fly(in realtime),I remember someone was able to do the same as the loft modifier in 3ds max for example.
I remember also you(and other people also) did a sculpting script.
There are also some other good script for modelling,I don’t know what will happen there.
Btw,I trust you,for me the important is that if I have to do for myself some little stuff I can do it without having to modify the source.
Bye
Not sure we should be discussing speed of the API on this thread.
The new API will be slower to start with. But we can optimize as needed.
Will also be a lot easier to optimize since changes can be done in much fewer places.
There will advantages too… its too early to start making conclusions.
I also tend to lean towards having only one scripting language, and since I like Python very much, I’d vote for that. I think the pros of having more languages get outweighed by the cons, like splitting of the scripting community, harder maintainability, bloat.
I’d rather have one well integrated language that also has a good chance of getting maintained well in the future, I fear that might be harder to achieve with more languages.