Thoughts about further development
Posted on:September 02 2006
Next to the items I already plan to add into irrEdit I'm just thinking about is adding the possibility to access mesh data via the scripting interface. People would be able to write their own mesh or map exporters with this functionality, as script. And scripts have a very nice advantage over binary plugins: You don't have to update them with a new release, they simply work. That's also the reason why I don't support plugin .dlls in irrEdit currently: irrEdit now is in the beginning and its C++ interface changes a lot. To be honest: binary .dll plugins already work in irrEdit. But I didn't make them available for the public yet, and I would like to stay with this for some time. Lets first get the basics to work. So the question now is: Would people be interested in the possibility to write their own exporters as scripts? Or is the built in .irr and .dae exporting functionality enough already?
BTW: irrEdit 0.4 saved scenes might not work with irrlicht 1.1 currently, due to a change I did to the format, sorry. But the irrlicht version checked in the SVN works.
BTW: irrEdit 0.4 saved scenes might not work with irrlicht 1.1 currently, due to a change I did to the format, sorry. But the irrlicht version checked in the SVN works.
Comments:
steve
Quote2006-09-02 12:49:00
I'd also advise trying to keep the interfaces as consistent as possible between script and native API - that way it encourages the prototype / native combo working. XSI does this very well, the script and C++ API are direct parallels. In contrast Max has significant differences between script and native which means it's harder than it should be to switch from one to the other.
steve
Quote2006-09-02 12:53:00
same time tho steve, blender exporters are just written in python, and they still seem to have acceptable performance...
buhatkj
Quote2006-09-02 19:08:00
Acceptable maybe, but since you can't compare them to native versions do you really know what you're missing? ;)
It really depends on how much work you do in the exporter. Having had direct experience writing relatively complex exporters in quite a few modelling tools now, it can make a difference. If all you're doing is simplistically iterating over data and dumping it out to a file, no biggie. But if you start doing smart exporters which do things like rationalising / grouping meshes to improve batching, auto-welding, sorting out seams, optimising animation etc (which many modellers don't do on their own simply because they're not oriented towards realtime assets), it really can make a difference.
It really depends on how much work you do in the exporter. Having had direct experience writing relatively complex exporters in quite a few modelling tools now, it can make a difference. If all you're doing is simplistically iterating over data and dumping it out to a file, no biggie. But if you start doing smart exporters which do things like rationalising / grouping meshes to improve batching, auto-welding, sorting out seams, optimising animation etc (which many modellers don't do on their own simply because they're not oriented towards realtime assets), it really can make a difference.
steve
Quote2006-09-02 19:21:00
that's right. And it was the same for me in Maya: First I wrote the plugin in MEL, then in C++, it's really a nice way to write stuff. :)
I think the biggest performance trouble I'll have is not the scripting language itself but the implementation of the functions in C++: Currently I am checking and validating and converting lots of data for every call behind the scenes. Going to improve this a bit using reference counting, eliminating the validation and I think everything should be usable well. IMO the squirrel VM is fortunately a very fast one.
I think the biggest performance trouble I'll have is not the scripting language itself but the implementation of the functions in C++: Currently I am checking and validating and converting lots of data for every call behind the scenes. Going to improve this a bit using reference counting, eliminating the validation and I think everything should be usable well. IMO the squirrel VM is fortunately a very fast one.
niko
Quote2006-09-02 23:06:00
For the export/import bit - I would prefer both. I come from a Maya background and the difference in "native vs scripted" for advanced plugins is often drastic (I have coded both my thesis project and several 'real-time optimising' exporters, so I have experience in this). I tend to find it easiest to code the C++ versions and then wrap them in script when I'm done.
On the subject of script wrapping - I was wondering about your experience with Squirrel VM, Niko. I am currently looking at Lua & Stackless Python as scripting environments for my project, both because of their co-routine support. However, integrating Python is a nightmare and Lua (while better) is also difficult. I'm debating whether it might be easier to put coroutines into squirrel...
--EK
On the subject of script wrapping - I was wondering about your experience with Squirrel VM, Niko. I am currently looking at Lua & Stackless Python as scripting environments for my project, both because of their co-routine support. However, integrating Python is a nightmare and Lua (while better) is also difficult. I'm debating whether it might be easier to put coroutines into squirrel...
--EK
Eternl Knight
Quote2006-09-03 02:23:00
Scratch that - Squirrel already has coroutine support, which then brings me to how easy is it to integrate and use?
--EK
--EK
Eternl Knight
Quote2006-09-03 02:26:00
Add comment:
|
|
Possible Codes
| Feature | Code |
| Link | [url] www.example.com [/url] |
| Bold | [b]bold text[/b] |
| Quote | [quote]quoted text[/quote] |
| Code | [code]source code[/code] |
Emoticons
 |  |  |  |  |  |  |  |
 |  |  |  |  |
The trouble with scripting languages is that they don't scale particularly well to manipulating large volumes of data. Certainly I see significant speedups when porting export routines to native code. However, they're great for interactive experimentation, API exploration, and low-volume things. So it's good to have both.