Evening + Blender

[innovati]

Hello all, I am a strong believer in open-source software, but a probelm I see here, that's causing a lot of senseless coding that could be avoided (exponentially reducing the amount of bugs) is that although everybody is using OGRE, it's just a graphics engine. I think it should always stay as a grpahics engine, don't get me wrong, but everybody who starts a project has to then add physics, sound, and all that.

So....for 50 projects started, that's the same thing being coded (at varying levels of efficiency). Why all this duplicate code? If we unify our needs and our codebase, we could become so much more efficient.

I call all of you who strive to have the latest, cutting edge libraries and open-source tools to group together and form a game engine and framework.

Me and my friend have dubbed it: Evening.

Evening should be a full game engine, with everything, that uses OGRE for the graphics. To each community involved in the many parts of this project, there will be questions asked, code made and connections established.

What it sohuld look like:

OGRE (using OpenGL primarily) for the graphics, ODE for the physics, OpenAL for the sound, and other lesser libraries in their respective places. The idea isn't to debta which library is better/preferred, but which suits our purpose best. The criteria being: free open-source software, well documented, helpful community/userbase.

The games could then be written on-top of that core using your favorite programming language.

I'd like to take this one-step further though. One thing that's lacking is a really good Scene editor. Wou;dn't it be nice to have a scene editor that was also your game IDE, a modellor, and had all of thes elibraries natively inside of it too? So your game would be identical in and out of the editor?

Enter Blender. Loved and hated, but ultimately the only viable open-source and free modellor there is for the purposes of this project. What if we were to strip out of blende the current blender engine, fit it with a new User Interface, but still using the same themes for a unified suite. Add in our other libraries as modules (so they can easily be changedwithout affecting the integrity of the rest of the code) and be able to directly import data natively from blender. This would also allow you to use blender plugins directly in the editor.

Yes, what I am proposing is essentially taking Blender, and make the game-blender a fork of it, a seperate program with it's own UI, and using OGRE, ODE and other heavy-weight libraries as it's core.

This way, also, it would be easier to develop modules for use with OGRE through this app, easy ot manage and program games in the provided IDE environment, be 'big' enough for any application, but also be able to do things like randomly generate a model in Make:Human, use the GIMP core (a plugin to be added) to not only paint a texture for it, but also use the GIMP core in a seperate plugin called Gbrush, to use a special set of organic brushes to paint a detailed height-map on the model, then add hair and clothes (dynamic and controlled by ODE) and put it in a randomly generated terrain that has been painted and textured by another script for the GIMP based on it's topography, and then the model is displayed in Evening, with all of the features you've enabled for the game.

What do you think of the idea? This work encopmasses many of the scripts that are being written now, we would have to take the code and make it a plugin for it. I'm thinking the Mesh tree script (could easily be better than SpeedTreeRT) the particle editor from spannerman and others, and numerous terrain editors and skyboxes and such.

Sorry for the dis-jointed article, and the lack of screenshots or even a better explanation. One's on my website, but it was taken down by my web hosts yesterday because I asked for SSH access and they didn't want to give it to me (even though it is advertised and I'm paying for it). So feel free to ask me, or use Instant Messengers to talk to me. PM me if you aren interested.

We're going to make this thing, just wanted some community support. We're not trying to steal OGRE and re-name it, please be sureof that, we love OGRE, we just want to make a program that is so much more that OGRE - the complete open-source game IDE with all of the raw tools available as plugins.

[monster]

Have you looked at Yake?
http://www.yake.org/

This seems to encompass many of the ideas you're talking about and is already a fair way down the track. Rather than yet another game engine being started, how about contributing to the Yake effort?

[_mental_]

This sounds alot like what the yake team are doing.

[edit]I see monster beat me to it [/edit]

[innovati]

as far as the framework and engine part are concerned, I think our philosophies are almost identical, but the key part is the creation of the level editor/GDE/IDE based on blender. The gameblender people have been saying for ages that for it to work they need a fork, I see this as that fork. Instead of trying to make it blender+Evening (yake), I think our goal will be to maintain compatibility natively with blender formats of course, but to play down the modelling. That would be done in blender before you send it into Evening.

I think that what we all really want here in the OGRE community, as well as in the Blender community is this kind of unity, like a marriage between the two. This kindof unity that will solve the problem of a good, flexible, powerful scene editor, and the problem of gameblender.

I had peeked at Yake's website, but seeing no immediate application, I assumed it was in a planning state, or a pre-alpha. I have downloaded it and will check it out for sure, thanks for the pointer there.

You have brought up an excellent revalation to me - my idea was having the libraries be modular; if the physics engine can be interchangeable, why not the graphics libraries. Why not have the Evening (new gameblender) support OGRE, Axiom and Yake? Or there are even those who prefer Open Scene Graph to OGRE.

Anybody interested in helping making it work? I think mire development will begin sometime in the second half or April.

[Clay]

Axiom, Yake, Ogre, but no PyOgre? Blender uses python natively for all scripting, it would seem like an obvious choice... =)

[psyclonist]

Heya,
as Yake was mentioned twice I thought I step in

as far as the framework and engine part are concerned, I think our philosophies are almost identical, but the key part is the creation of the level editor/GDE/IDE based on blender.

We're developing at least two editors (often as widgets):
- a c++ reflection based editor for properties, events etc
- a scene editor for placing game/application object instances (but definitely not modelling )
- (planned:) a reflection based visual editor for designing behaviour by connecting events, conditions etc. things like that.

I had peeked at Yake's website, but seeing no immediate application, I assumed it was in a planning state, or a pre-alpha.

Submarine ROV simulator, Virtual Campus... among others

I know, we don't have a 'screenshots' or a 'featured projects' page. I like it that way, currently

(...) if the physics engine can be interchangeable, why not the graphics libraries.

Actually, I find abstracting physics engines easier than abstracting graphics engines. Anyway, you probably guess it but this is what we've done at Yake, too

Anybody interested in helping making it work? I think mire development will begin sometime in the second half or April.

Sorry, can't But, of course, I'm always open to discuss techniques, ideas, ... maybe we can share a few tools.

-psy

[sinbad]

I agree that given your (correct) emphasis on not reinventing the wheel, you should join the existing projects like Yake rather than starting afresh. Yake has been going for a long time and despite the lack of information on the main website, you can see lots of activity in the forums. Yake is the project which spawned Octopus (3DS scene editor), I see no reason why an equivalent tool could not be be made for Blender too.

You should also get in touch with reimpell, who has been our Blender maintainer for ages and has already done a lot of work on a Blender scene exporter.

[innovati]

@ Sinbad: of course, stated in my mission was not to have duplicate code, so to not use/modify Yake would be hipocritical wouldn't it.

Thanls for the suggestion for contacting Reimpell for his work with the blender exporter, we were already planning to do that but we got busy (one of Andy's computers crashed so he had to reinstall, typical windows) and haven't had time yet.

@Clay: sorry about PyOGRE there, I wasn't sure whether or not PyOGRE was the entire engine ported to python or if it was a python wrapper for OGRE. Python is used in blender almost exclusively for things like this - it would be stupid not to include PyOGRE

[psyclonist]

innovati: Sent you a more elaborate PM.

-psy

[Clay]

@Clay: sorry about PyOGRE there, I wasn't sure whether or not PyOGRE was the entire engine ported to python or if it was a python wrapper for OGRE. Python is used in blender almost exclusively for things like this - it would be stupid not to include PyOGRE

PyOgre is a binding, so it runs all 3D stuffs in C++.

[reimpell]

Yes, what I am proposing is essentially taking Blender, and make the game-blender a fork of it

Developing the glue to combine prominent open source projects into a modifiable game engine is a honourable goal. Unfortunately, at least at the moment and imho, Blender is not very suited for this task.

Blender's way of defining materials has little overlap with the way it's done for interactive 3D-graphics today. In particular, you can't use custom fragment and vertex shaders. You probably have to add a special "game engine material" to Blender for this purpose.

Similarly, Blender's particle system differs significantly from Ogre's. The same is true for billboards. At least I haven't found a reasonable way to map Blender's particles and billboards to Ogre's.

Also, we are all coddled by the clear design of Ogre, which btw isn't a matter of course for such a complex project and something, Ogre's core developers can really be proud of. If you dig through Blender's source you will find that Blender is not in such a good position. E.g. look at the Yafray integration or the scattered properties that define a material. The Blender developers are aware of this situation and are working hard to change this. E.g. see the recent changes on the transformation code or the planned animation system rewrite. But this makes it questionable if it's not too early for a fork.

Anyhow, these are only my personal opinions and I hadn't stated them if I hadn't been triggered above. They should not hold you back to prove me wrong.

[RoundSparrow]

Personally, I think Blender is a great thing..

But it is stupid for us to be putting more logic (material editors) into that side... we should be builidng Ogre-based Material Editors that are neutral of the 3d modeling tools.

3D Modeling tools still have a LONG WAY before they get down to a sane market. $7000/$3000/$500 still dominates the market...

[innovati]

Reimpell, you're still thinking of taking what blender does and translating it all to OGRE. You're pointing out that Blender engine and OGRE engine don't translate back and forth.

What if blender used the OGRE engine as it's central engine, there is no translation taking place, everything is made natively in OGRE, using the former blender tools, adapted for OGRE. If blender can make a GUI for their engine, why can't we translate the GUI to OGRE for making OGRE games? (as opposed to blender games)

[Clay]

What if blender used the OGRE engine as it's central engine, there is no translation taking place, everything is made natively in OGRE, using the former blender tools, adapted for OGRE. If blender can make a GUI for their engine, why can't we translate the GUI to OGRE for making OGRE games? (as opposed to blender games)

Is this where you are going with it? Simply using blender's interface to drive ogre? Reimpell brought up some good points. It sounds like you would be spending a huge amount of time gutting Blender and replacing the engine's parts with Ogre. That's not a trivial task in the slightest.

If that's the case you might want to think about a product with a better user interface to start with and maybe working from there. I dunno it just sounds like a lot of work to force blender into something it's currently not. I think if all of the current tools for Ogre were unified into one toolset (scene editing, mesh/material view/editing, terrain generation, terrain splatting, etc, etc) you would acomplish everything other than actually creating and editing the models right? Aside from creating/editing the models, what does hacking blender give you over an almagated toolset?

[spookyboo]

I agree with Clay. Just start fresh.
My thoughts are going to an Eclipse type of editor framework running on Ogre. This framework will provide all editor basics and can be expanded with modules/plugins. The plugins can be provided be the Ogre community and must be created in a standardized manner. This way everyone can work on their own plugin, without thinking too much about the editor/framework itself.

Setting up such a framework needs some carefull thinking and (community) agreement about the design.

[reimpell]

What if blender used the OGRE engine as it's central engine, there is no translation taking place, everything is made natively in OGRE, using the former blender tools, adapted for OGRE. If blender can make a GUI for their engine, why can't we translate the GUI to OGRE for making OGRE games? (as opposed to blender games)

With my above post, I tried to sketch the amount of work that has to be done in such an adaption process. Blender's internals are 'data oriented' (see Blender Architecture). Therefore adapting Blender's algorithms almost equals a complete rewrite. If you plan to do so and use Blender's GUI libraries you should be aware that they are also subject to change (see Window Manager).

[psyclonist]

I agree with Clay. Just start fresh.
My thoughts are going to an Eclipse type of editor framework running on Ogre. This framework will provide all editor basics and can be expanded with modules/plugins. The plugins can be provided be the Ogre community and must be created in a standardized manner. This way everyone can work on their own plugin, without thinking too much about the editor/framework itself.

Setting up such a framework needs some carefull thinking and (community) agreement about the design.

Interesting. I'm working on a cross-platform editor. It's not designed to be used for modelling but mainly for scene editing (importing, instancing and editing of game entities, for example). Plugin-driven. One of those plugins is a C++ reflection based entity property editor. Another one could be a collision geometry editor, for example. The editor itself provides simple interfaces to access the UI (add toolbars, setting pages, dockable dialogs...) and to access the scene (accessing viewports as well as scene contents etc) as well as common functionality (scene navigation, zoom, pan ...).

It's still in an early stage and I didn't plan to announce or release it in the near future but as we're discussing this topic again, I though I could dare mention it.

Sorry for hijacking! If there's any interest at all, we can start a new thread.

I'm interested in this topic but am not convinced Blender would be the ideal choice. And personally, I don't need a modeller-meets-world-editor-which-can-do-everything editor. I try to concentrate on the functionality that other applications don't provide in a practical manner.

-psy

[spookyboo]

I am working on the same. My editor however doesn´t have an open structure and because it´s not my main goal it is coded rather .. eh .. straightforward. There are more people working on something similar, so I guess people need these kind of tools.

[nfz]

Yes, I have been hiding in a closet too, building an editor for the resources used in Ogre and other parts of my project. Someday all these editors being built by many individuals will come out of their closets and storm the ogre development scene and there will be much rejoice and confusion. But until then, back into my closet I go.

[monster]

...back into my closet I go.

All these people who are coming out of the closet, or are too shy to.
I think maybe I've stumbled across the wrong forum here.

[spookyboo]

I have given this a thought. A scene editor (in my opinion) should run under Ogre and CEGUI and should contain the following components:

1) The editor framework, which is responsible for saving and loading projects, registering plugins and menu-items and provides some common functions (i.e. a dialogbox for loading files etc.). It should also have a deploy function that exports the project data to a .scene format.

2) A project component, which is a representation of a scene and contains the data of that scene. Each project type is related to a specific scenemanager. This means, that several project types are possible.

3) Plugins, which are developed by a 3rd party group (the community). A plugin contains a process component and a data component. The data component is project specific. The process component is data independent and is registered at the editor framework. Some plugins can be generic and are used within all project types, other plugins can be specific and therefor limited to specific project type (i.e. a terrain texture plugin). A plugin must be able to have (limited?) access to Ogre, the framework and CEGUI

The tricky part is how these components communicate with each other.

- Communication between the plugin process and data components is the responsibility for the 3rd party supplier.
- Communication between the framework and the project component deals with passing the data that must be saved and loaded. My opinion is, that the editor framework is responsible for loading and saving. The project component must therefore pass the data in a formalised way. The project itself doesn´t have to know about the way the framework loads and saves the data.
- All data within a project component is scattered in all those plugin data components. This means that a plugin data component also must pass the data in a formalised way. The plugin is therefore responsible for creating the data structures that must be saved and for creating objects based on the data that is received after loading a project.

The benefit of this approach is that nobody has to develop a complete editor on its own. If a first version of the framework is ready, people can already start developing plugins for it (I can name a few). The key element is to get the interfacing clear from the start.

[tin_]

Interesting thread and idea, innovati, sorry for hopping in and hijack it a bit further

Our aproach is quite different (sorry for repeating this) - we are in progress of providing a toolset (or rather an integration middleware) that uses existing tools for the scene editing and we set the whole game specific workflow on top of that - we try to put them together as seemless as possible. The scene editor can be any existing modelling package (or even a custom application like any scene editor existing for Ogre so far). The properties of the game entities are abstracted in a way that they can be accessed without knowing what your specific repository is. It can be Attributes in your scene, a custom Tool, a hand-edited XML-file, an Excel document, a reflection-based solution like psyclonists - just name it. Thats pluggable - use Maya attributes if you want to, use Zentrale, well use whatever you think for your game workflow is best. The exporters that write the data out of the modellers are plugins themselves that are not modeller specific. We only need one plugin to gather data in Maya for example and with this one plugin we have all formats (2 so far and a preview) on our hand. It's even possible and planned (although not implemented yet) to export Meshes to a running Ogre-Application (i.e. your game).

I just recap the Z Workflow here to show that we have many different possibilities (and projects underway) on how to approach such a workflow. We won't agree on "one way to do it", because every way has its pros and cons.
But we might be able to agree on things like file formats (e.g. in what way should one save game entity information? physics information? Material attributes besides their graphical representation etc.) and general interoperabilities. It would be great if someone using yake can import data generated with another tool thats not yake aware per se (for example).

Lets say innovati succeeds in converting blenders engine to Ogre - why shouldn't his editor (or any other sceneditor around) be able to use psyclonists reflection plugin? Or Zentrale? Or different file based formats?

I hope thats worth a thought

[psyclonist]

The benefit of this approach is that nobody has to develop a complete editor on its own. If a first version of the framework is ready, people can already start developing plugins for it (I can name a few). The key element is to get the interfacing clear from the start.

Yes.

I've put a bit of though into this already and got a few example interfaces ready. I'd be interested in a joint effort if it aims neither too low or too high

On a side note, I doubt that cegui would be the right choice this case. While it's an excellent tool for in-game GUIs and even small-scale editors (the particle editor comes to mind) the most important disadvantage is that it's missing quite a few important widgets (menus, toolbars, rollouts etc) and other common windowing functionality (docking...) when compared to regular GUI toolkits (e.g. FOX).

Maybe we can find the right level between 'specific' and 'generic'. After all, we all want to get something done, and not discussing specifications for months

-psy

EDIT: wrote this while you posted, _tin. will read it.

[psyclonist]

tin_: Can you elaborate a bit more on the workflow and what kind of plugins you're using? It's hard for me to visualise what it would be like to use your tools.

I doubt it's possible to use a common file format "to rule them all" (i.e. game engines) on the level you're working on. While that may work in certain places for materials and the like (though I still doubt it even here), it most likely won't work for entities. Do you want to abstract inter-entity communication, too? Signals? Events? IPC? Script bindings? Entity components? Or just a few of their attributes? "Entity" design can vary very widely, from component based architectures with pluggable AI and integrated replicated/duplicated networked objects and similar things to very simple designs. Maybe I didn't get it really what you're aiming it and I'm missing something? I'd be pleased to hear more about the "Way of Z"?

-psy

[tin_]

psyclonist: Heres a very little technical overview - not in-depth nor up-to-date, but it might do it: http://www.tzi.de/~tin/Z%20Workflow.html

Oh, and my post was not meant about one format to "to rule them all", I know thats not possible nor maintainable. I'm talking more about an container format, with some standard entity attributes and attributes-groups predefined (like Event triggers script, signal/event-mapping) and lots of headrom for custom project/problem-specific attributes. For sure no game engine can read the file and "go" from scratch, thats not remotely what I mean - but every editor package could at least edit them. The attributes should be classified into an ordering semantical structure that helps displaying/finding/comparing them. Also they have a implementation context that can be bound to a specific implementation in a target game engine (like AI, Networking, Messaging etc.). Lets say you have different AI middlewares - your Attributeset for AI can be different for each Target middleware.

Zentrale (the entity editor) is more or less metadata-agnostic, it just delivers the means to manipulate, write and find them (where the writers can be target specific).
But I won't go into deeper details regarding Z in this thread, I better use the one glateur already opened

Yes, I know that the entities differ a lot, but there are many common things people have to have for even the most basic things - and so they start over and over again with the n-th editor (oh, we need audioemitters! Oh, and triggerboxes! And Events! You know the drill).
I think it is possible to give the basics and enough place for specific and advanced solutions. At the end of the day, it's attributes attached to entites - the semantics have to be provided by the programmer or by the game engine that dares to load that stuff

Such a container format should make it a lot easier for the developer to get to the data he needs to implement the behaviour of his entities and ensure that this data can be edited by artists in various ways. I've seen to many great engines (both graphic or game engines) that were great from a technical point of view, but lacked content as the specific strengths of that engine couldn't be used/controlled by an artist. Especially for starters thats a big problem.

Well, at least that's my 2c