[SoC 2008] Interactive Run-time Scene Editor

[Petya2164]

Hello everyone!

Sinbad mentioned that the community is open for new project ideas concerning the GSoC 2008. So I would like share my thoughts, looking for feedback.

I'm not really a forum guy, but I've been working with OGRE for the past few months, and I believe I understand its concept.
It profoundly changes game development by trying to suppress the procedural nature of rendering APIs and introducing declarative semantics to describe everything.
Yesterday I had conversation with my game developer friend about the future of the game development itself.
We envisioned that in 10 years the boundaries between rendering engines and 3D modeling tools(Maya,Blender...) will disappear. This will give developers the possibility of interactivity, which could greatly reduce development time.

Personally I hate, when I have to recompile my program code after adding one entity, and run the app again to see the results.
What if we had the chance to change our scene run-time. Add new entities, alter parameters, choose new materials/shaders, just like we do it in 3DSMax for example.
For this purpose I imagine a Creator Console, a special GUI which gives this functionality during development. The developer can freeze the game any time and make modifications to the scene, and continue execution.
All this I'm saying requires some sort of interpreter and scripts. I'm aware of certain projects in Python trying to accomplish something like this.
But interpreted languages tend to be real slow, compared to native code, and speed is very important in real-time apps.
I read somethere that everything that can be done in script, can be done in code as well. But vice versa, it is not true.
I think an all-purpose scripting system which enables script-changing/swapping at run-time (combined with a proper GUI) would be greatly beneficial for Ogre and the entire game development community.
I think the following script parser would be a great point to start:
http://www.ogre3d.org/wiki/index.php/Al ... ipt_parser

Moreover, when a development cycle ends, it should be possible to compile real C++ code from the scripts, and see how fast it can be.
So consider the scripted version the "Debug" and compiled C++ version the "Release" edition.
This feature enables developers to take advantage of the interpreted approach, and still they don't give up speed in the end.


I know my thoughts are not crystal-clear for you, but I hope that some of you will reflect to my ideas.
I do believe that this is the very future of game development.
And I would like to work on something like this in the coming summer.

Looking forward to your response.

Thanks,
Peter

[Assaf Raman]

Basically what you want is to have a scripting engine the uses OGRE. So I guess that most of the work will be exposing OGRE to that new (or existing) scripting engine.
Is that true?

[Petya2164]

Yes.
But that would just be the first part of my work.

Note that certain features are currently exposed to the scripting engine.
I mean the material, particle system, compositor and shader scripting mechanisms. Material scripts are key assets in Ogre development.

But all of these mechanisms lack the possibility of run-time changing.
I imagine my work could be combined with the Artist friendly material and shader editor proposed in the other thread by skatehead.

Basically all I want to do is to empower the declarative nature of Ogre,
thereby facilitating interactive development to a level that has never seen before.

What do you think about it?

[sinbad]

There's a few things to bear in mind here:

1) This has already been done in one form or another, although you might not be aware of it. Scripting language binding has been around for a while, probably the most mature is Python-Ogre but there have been others for Lua, Ruby etc.

2) As regards speed, since Ogre is doing most of the heavy lifting, and it's compiled, it's not a particular issue - I know of several real-world projects using Python-Ogre and they have few issues with performance. You can always precompile Python if you want. To be honest, if you think you can create a scripting environment that's richer and faster than Python in a summer, you're probably wrong, sorry.

3) This is not a core feature to Ogre. Ideally we're looking for projects that improve on Ogre's core feature set, that is real-time 3D rendering. Content creation, scripting extensions etc are great too, and we encourage those as add-on projects, but they're not core, and as such are going to be less preferable as GSoC projects. That doesn't mean we won't pick one, but if there are 2 projects with similarly skilled applicants, we'll pick the core one first.

Sorry to rain on your parade a little here, because your principles are completely sound - scriptable interaction with Ogre is indeed very valuable and that's exactly why so many people use the existing script add-ons. However for the reasons I've stated above this isn't a particularly appropriate GSoC project, in my view. I know you don't want to hear that, but I'd rather you know my honest opinion now, that way you have time to think about alternative ideas if you want.

[Petya2164]

Thank you very much for your honest opinion!

And yes, I'm aware of Python's capabilities, and I think it's a wonderful language, and I don't wanna recreate it at all.
Scripting is absolutely secondary for me.
The core of my idea is the interaction with your game in development at run-time. It's like a God mode, and I haven't seen anything supporting it.
I still believe this is the way of the future, and Ogre may widen its scope towards this approach.


But if your primary objective is to improve the core rendering capabilities then I will try to choose something from the original Ideas list.
The GPU-based font system is quite cool for me.
To tell you truth, I always liked the revolutionary, innovative ideas.
That's why I'm in Game Development.

[zoombapup]

Actually, this is pretty much how Unity works.