Hi all,
Just a thought why not to make a new programming as LUA for Blender ? Because it is simple, very strong, less typing, easy, it run quite fast over Python? And it is very adapted for games with prototyping.
It would be good to have two more possibility for programming.
So, for or against ?
I’m all for it. It’s not going to happen though. Unless they want to maintain two different scripting interface, they should trash the current way it is implemented and rewrite a different one from scratch - this time binding to a proper virtual machine. Even if they manage to keep a namespace compatibility with the current scripting api - which might even be possible - there is a substantial risk to break behavioral compatibility (same name, subtle difference in the way it does what it says, broken scripts). At that point you’ll have users of “old” scripts asking for changes that will break what creators of “new” scripts took for correct. That will be a big mess :).
More possibility or more freedom of choice, would mean a huge upfront investment and more maintainability work for the core developers.
Of course, people have different preferences regarding programming languages. I wholeheartedly hate Python, but that’s just my own opinion. There are many whole like or even love it. Discussions about programming languages are in most cases discussions about what people prefer. It will lead no where and that’s why it makes sense in my opinion to have a look at the consequences. One of the consequences would be more headaches for the core developers. Even for someone like me who doesn’t like Python at all, that doesn’t sound like an acceptable consequence.
Possible that would be mess, but in my opinion Lua is very stable, not much to change and can be more improve it or adding new feature. The most strong point is creation of games than Python is more general purpose… So no need to code from scratch because Lua bright library of C thus it greatly facilitates and accelerates time.
Quote from the site i read :
Lua is written in C (almost completely compatible with C89 standard; the incompatible features can be easily disabled, if needed, using compile-time switches) and has been designed to be easily integrated with C code. In the the context of Lua, “integrated” means two different, but related, things:
You can easily write C code that can be used as a library by Lua code. The integration is achieved either by static or dynamic linking your C code to Lua engine’s code. The linked library can then be referred to in your Lua code using the Lua require function.
Lua engine can be easily embedded in a C application, i.e. linked (again either statically or dynamically) to the C application code. Then the C application can interact with the Lua code using Lua’s C application programming interface (Lua C-API).
Note: this can be done, with a little more effort, also with a C++ application.
Advantages of embedding a Lua engine If your C application embeds Lua many, if not most, operations can be delegated to the Lua engine, i.e. either to code written using the C-API functions or, better yet, Lua code. Lua code could be embedded as C strings inside your C code or be stored as external Lua scripts.
Having part of your code logic implemented using Lua code has several advantages:
Lua is simpler (less tricky) to learn and use than C, and it is much more high-level. It supports powerful abstractions, such as function closures and object orientation (in a peculiar way, using Lua tables and metamethods).
Lua is a dynamic language: it requires no “off-line” compilation. You can modify the text of your Lua script and that’s all you need to modify your application behavior (no additional compilation+linking steps needed). This simplifies application development and debugging.
Lua is a safer language than C: it is really difficult to write Lua code that exhibit undefined behavior, as intended in the context of C/C++. If a Lua script fails, it fails “loudly”. Moreover Lua supports an exception mechanism (although with a different syntax than C++) which can be employed to implement error management in a much easier way compared to C.
Lua, as most dynamic languages, is garbage collected. This means that the programmer is spared the pain of manually managing dynamic memory, which is a major cause of bugs, leaks, instability and security loopholes in languages that lack garbage collection.
Lua can “eat its own dog food”, i.e. you can build a string at runtime (even in Lua itself) and if it is valid Lua code, your program can execute it on the fly. This is something not frequently seen even in other dynamic languages (still it is not LISP, but it gets closer, and with much more readable syntax). This enables Lua scripts to:
[LIST]
employ powerful text-based metaprogramming techniques, where Lua code can generate other Lua code and execute it on the fly;
implement domain specific languages (DSLs) in an easy way; Lua code can load at runtime other Lua code that is crafted so as to reflect the specific problem domain in which it is used (Lua syntax is simple, yet flexible enough to allow such things);
be used as a configuration language with ease: your application (written in a mix of C and Lua) can use some lua files as configuration files without the need to craft an ad-hoc parser for a specific configuration file format. Therefore you don’t need to parse *.properties, *.csv, *.ini, or whichever other format you would choose if you hadn’t the option of using Lua files for that purpose.
Lua engine has a very small memory footprint (some hundreds kBs), packing powerful capabilities. With very few C code lines and a bunch of Lua files you could create a complete application that would require thousands of C code lines otherwise. The standard Lua standalone interpreter can be seen as just an example of embedding Lua in a C application!
Lua has a very liberal open-source license, which enables its use even in commercial applications without much hassle. This also allows the modification of its source code to adapt it to special needs.
Small memory footprint and easily tweakable C sources make Lua a perfect candidate for porting it on embedded systems or small microcomputer systems (microcontrollers, etc.). Many parts of the standard Lua distributions can be stripped off, reducing the core Lua engine in the ~100kB range.
[/LIST]
I think the first is necessarily true, since there is a system in place that, at least to me, looks really hard to bend in the desired direction. The second it not, it depends on how you do it.
The current implementation only runs python because it is a binding to a python virtual machine and python is the only language developed for it. At least that I know of. Of course it is a horrible choice nowadays but back in the stone age there weren’t many multi language, open source runtimes around (mono first release is 2004, java became gpl in 2007).
If you target mono or java (or possibly LLVM, via LLI, kind of intriguing but I never tried that) instead of the python runtime, you write one interface - which is what blender currently does, it’s just spread all over the place - and you get all the languages supported by that runtime for free.
Again though, the chances to break some existing script in the process is, imo, quite high. If you want to avoid that, you have to keep the current interface, call it legacy and hope for the new one to become mainstream.
Well, you’re not going to see many people telling that their programming language is garbage :D. Certainly, if you’re going to add another mono-language runtime you’ll face the same problem that the current implementation has. And you definitely add more code to maintain - one to bind python, one for lua…
This is the current official stance on using another scripting language in Blender:
A: Currently Python is serving our needs quite well as a scripting language.
Python has its limitations, other language/runtime combinations undoubtedly have their strengths. But Blender is primarily for artists - not an SDK/API to support developers preferred technologies.
Another factor is the effort to support/maintain embedding multiple languages (supporting Python is already giving us enough work / bugs to fix).
That said, the option is always open to embed other language/runtimes, for now though it doesn’t seem worthwhile.
See more in-depth discussion here:
- 2009 discussion: http://lists.blender.org/pipermail/bf-committers/2009-February/022669.html (thread view)
- 2013 discussion (specifically about Lua): http://lists.blender.org/pipermail/bf-gamedev/2013-September/000031.html
Short version: patches welcome… but that should probably come with a promise to help maintain it, too.
Would much rather see a C/C++ api than another scripting language. What we need is something to move and process data fast. Even if the api was very limited, it would be welcome. Native access to data structures. For example, to facilitate faster file IO, or procedural meshes.
Multi-million tri meshes are soooo painful in python, even as glue for a module written in C.
Thank Fweeb it is useful.
Although it is fast but the cycle time how to compile and debug it takes too long and can make errors. So Lua is reduced to time but in addition there are instant for the result and can be programmed on the fly. That is the advantage and disadvantage between the two programming.
.net core looks very promising in my opinion. The drawback is always, that there is no support for the actual languages. E.g. IronPython is not 100% identical to Python and it will very likely never be. The same is true for every Lua implementation for .net I have seen so far.
blender 2.7x series is ending, 2.8 is planned (with a lot more node stuff i think), so maybe better wait with it.
and see how game logic will evolve in a new blender 2.8x series.
Maybe… one could make something that translates lua script to a node system for blender.
If your into coding maybe try to find people who are working on the (future to be) game engine.
Lubos cycles game engine, uses nodes that write haxe, and his graphics backend uses Kha,
this seems VERY flexible, and apparently can deploy to any platform?
including html 5, apparently very fast as well.
http://luboslenco.com/notes/#3d_game_engine_intro_logic_system
The issue isn’t that there aren’t better languages for Blender (though I agree Lua is one, that’s not the point). The issue is that the Blender Foundation has decided on & invested in Python. Whilst I think there is a few Python aficionados in the core development team, even if there wasn’t, there isn’t going to be a change for X reasons:
Writing API’s is not fun, takes a lot of work, takes a lot of testing, and requires rewriting all the old scripts. This is not a job anyone is going to volunteer for because, frankly, it sucks proverbial backside. Remember, any change is going to require someone to implement, test, and maintain the change across the entire suite of Blender scripting functionality. That’s a hug task and one without much room for “interesting” development.
There is no real call for it amongst the artists. With the game engine dying a (slow, painful, highly vocal) death - the advantages of using a faster, cleaner, and more memory efficient scripting language are diminished. When it comes to the kinds of things chewing up memory and performance, outside the game engine, the kinds of improvement a new scripting engine could bring are eclipsed by functionality chewing up gigabytes of memory and minutes of CPU. Shaving some megabyte or milliseconds just isn’t worth the effort in that context.
Blender Foundation/Institute retraining. Let’s face it, the core developers of the Blender Foundation are hired by the same person running the Blender Institute. Without a compelling reason to change, I cannot help but think Ton would judge the effort of changing the scripting interface to Blender an unwise diversion of time & money that would be more productively used making the films he wants to make &/or improving the tools needed to make them. I’d agree with him… and I’d personally love to be using Lua in Blender.
so, what is kha and where can we find it? Thanks
Apart for what has been said up until now, python is the standard de facto of the vfx industry (not 3k though, yet).
For a DCC application seems mandatory to support it as primary scripting language.
Other languages are great, but python is the only one which has been widely accepted.
L.
i think the only way would be to use LLVM. but as BTolputt said it’s a huge task todo something like that and the ressources for the blender development is very low. to see a new blender core API it would take +3 years easy.
It wouldn’t actually be that much work, since the Python API is largely auto-generated from RNA definitions. There’s also a C++ RNA API (which Cycles uses) that isn’t exposed to users (yet). However, nobody even wants to support the C++ backend, which would be more important than yet another scripting backend. Without a maintainer, it’s not going to happen.
Yes please
I cannot understand a word that goes on from the transform.c file at all