weired idea: pyogre/wxpython based game development tool

This idea just came up while experimenting using wxpython and pyogre:

We could create a tool comparable to blenderGame engine, which means that we load ogre scenes into this editor, reposition meshes and textures, lights and cameras, particles etc and then create "logic bricks" by adiing python code fragments and generate python source at the end.

It could be a tool where in the middle of the screen would be the pyogre main window while outside the main window wxpython offers a scene tree, property panels etc.

You then load scenes from exported blender files (i.e. ogre scenes) into the scene tree and see all objects in the middle pyogre viewer.

Then you position and change values of objects and add some logic codes by adding python source.

At the end you can save the scene and export it as pure pyogre python source for further coding (such as networking etc.), which means the tool generates python source from exported and reworked ogre scenes.

With the time there could be new plugins adding particles etc. to the scene tree.

What you think ?

Bernd

I've actually had a similiar idea for a couple of weeks now. I'm using Virtools for my master's thesis, which does basically what you describe. And while Virtools is pretty cool, there are things about it I'm not that fond of (yet - I haven't really worked with it that much yet). It is a very interesting way to program though, and it is quite intuitive for games (and simulations).

For example, today we made a "Building block" (a piece of code represented by a graphical box with some parameters basically) that by simply drag-n-dropping it on an object on the window, and attaching some animations to it (it had to be a character model), we could make it walk around by using the arrow keys. Add a building block "Set As Floor" to the ground and the character will follow it. Add "FollowCamera" building block to a camera and it will automatically track the character you just made.

Makes for very fast prototyping, and there have been a couple of commercial games done with Virtools so it isn't just for prototyping either.

sounds like this mac program (check out the scripting vid). Which I hope Yake will become similar

http://otee.dk/gallery/movies.html

That looks quite similar to Virtools indeed! Too bad the videos were of such poor quality (320x200 or something, very difficult to read any of the interface text).

Not THAT expensive either, $250 for an indie/small biz license. Too bad it's just for Macintosh.

The question is, can we make an open source tool that is as good - or better - than Unity/Virtools? The key to doing this I believe is (partly) looking at them (and other similar tools) and looking at what they do right and wrong.

Here's more about them
VT: http://www.devmaster.net/engines/engine ... .php?id=46
Unity: http://www.devmaster.net/engines/engine ... php?id=256

I might want to help with this once I have learned both libraries a little better. It seems like it would be a boon to go ahead and add ODE to the mix.

Have the original posters made any progress on the subject ?

I thought about the same thing when reading the PyOgre tutorials.
Precisely, I thought of including a pyCrust widget next to a PyOgre render window : the new pyCurst enables startup scripts so it should be feasible to create a nice tutorial/experimenting context. (especially with the popups windows that offers the choices of existing method and attributes...)

Fosk

Eventually my "Golem" game engine will include either a standalone editor or (ideally) an in-game editor with CEGUI for the more complicated editing tasks. The biggest problem right now is figuring out how the art pipeline works (I'm learning how to use Blender). Once I understand that and get all the importing/exporting automated, I don't think an editor will be much trouble.

Same for any editor you may want to create. Python and Ogre make it all very easy once you know what you want to accomplish.

(That wasn't a very helpful post. Sorry if I'm being self-indulgent.)

Hello,
I have started investingating the use of wxPython coupled with PyOgre but hit a rock at the very begining.

I simply started to work on the "wxDemo.py" file, included with PyOgre and noticed the lines :
animationState = sceneManager.createAnimationState('CameraTrack')
animationState.enabled = True
However, since there is no frame listner to increment the animation, nothing moves on the demo (appart for the sky..)
I decided that it would be a good exercice for the beginner that I am to try to fix the problem by applying elements from the animation tutorial.

I defined the following class :

class MyFrameListener(ogre.FrameListener):
　　def __init__(self, animationState):
　　　　ogre.FrameListener.__init__(self)
　　　　self.animationState = animationState

　　def frameStarted(self, frameEvent):
　　　　self.animationState.addTime(frameEvent.timeSinceLastFrame)
　　　　return True


and added after the two lines quoted above :


FListener=MyFrameListener(self.renderWindow, self.camera,animationState)
self.root.addFrameListener(FListener)


with this code, PyOgre crashes on the creation of the FListener object. The error given is :

AppName: python.exe AppVer: 0.0.0.0 ModName: unknown
ModVer: 0.0.0.0 Offset: 011d4ccc

Does anyone have an idea of what I am doing wrong? Is it a misuse of PyOgre from my part or is it an incompatibility between PyOgre and wxPython ?

Fosk

Well, you passed renderWindow and camera to MyFrameListener.__init__(), but they aren't in the MyFrameListener.__init__() parameter list. Not sure why Python didn't complain about that.

Kind of an afterthought, but you should verify the validity of the FListener variable before you send it to addFrameListener(). Ie, if FListener is not None: etc...

HTH,

The renderWindow and camera was a typo when I copied the code to the forum.
I still don't know why the program crashed but managed to get around the problem :

first of all, instead of subclassing a wx.app as in the demo, I subclassed a wx.PySimpleApp which enables the print statements to work, and the errors to be printed. (I thus figured out that the real error with my framelistener was a recursion limit overflow)
But then I also realised that I did not need to use any frame listener nor to redefine the MainLoop method as done in the demo.
I just set up a wx.timer in my application that calls an Update function every 0.033 second. This update function does the job of adding time to the animationStates and to ask Ogre to render a frame.

If someone is interested, I could try to write a simple example to show the basics how to use Ogre and wxPython with a timer like this.At first glance, it seemed more elegant to me, but if it has some shortcomings, I would be very happy to hear about it.

I would very interested in an article, hopefully on the wiki, that shows how to use PyOgre and wxPython. I am currently working on an Application that uses OSG and wxWidgets and I use a wxTimer to tell OSG to update the scene at a fixed rate. Ideally I want to create a thread manager with OSG in its own thread, along with other threads for networking, that throttles the rate of execution of each thread based on load and priority.

I had a problem using a seperate thread (like a Timer) to handle the rendering when making changes to the render window, like resizing. Ogre can't handle other threads making changes when it is in the middle of rendering a frame. I had to make a flag "canRender" that I would switch off before a resize, then back on.

I haven't had such problems with wx.Timer to this date. However, I haven't done extensive testing yet. As I understand wx.Timer, it does not use a separate thread but only generates a TimerEvent at regular intervals which are then taken care in the same thread (if I'm not mistaken).
Resizing the window did not seem to have any influence on PyOgre.

Ogre can't handle other threads making changes when it is in the middle of rendering a frame. I had to make a flag "canRender" that I would switch off before a resize, then back on.

You probably want to take a look at Mutex's and a little more in depth read of thread safety.

I'm aware of how to make thread safe applications, I was just doing a simple solution for the problem.

Anyone still interested in setting up a wxpython/python-ogre scene modeler as an openSource project ?

Here is a suggestion for a mix of wxpython and python-ogre:


The 3D view in the middle is a python-ogre subwindow, while the rest would be wxpython based.

Anyone interested ?

Regards
Bernd

I think this would be a very useful project. There is already a similar C++ Project named GOOF doing the same. There should be a new release in August and I think wrapping it would be easier. If you want to drive your own project showing the power of PythonOgre I would help you.

Hello SiWi,

nice hearing of you

>>> If you want to drive your own project showing the power of PythonOgre I would help you.
Thank you very much !!

My suggestion is, that we discuss about the goals of the project first to establish a common target, so: What are the main goals and core features the modeler should achieve and offer from your point of view ?

Suggestions & Ideas:
The question for some python-ogre users is, how to setup a pipeline. Maybe this project could help them by doing the initial design.
A) The "Python-Ogre Modeler" could load a blender file (.blend), display the scene in the python-ogre 3D view as much as blender content is displayable and then converts the blender content as a bunch of asset files and generate python stub source files (which should be runnable without further changes showing the blender scene)
B) a programmer could therefore create a python-ogre stub application from a blender file and then start to develop his/her game or application coding in python using the assets and source which were created
C) in later versions there could be more "loaders" for 3DS, MAYA, Cinema4D or whatever people would like ...
D) provide features to update asset files and sources when the original blender/modeler files change ...



What is your idea about the application ?

Regards
Bernd

How are you going to handle asset conversion? Right now Ogre does this by having the tools export to its format, not import their formats.

Hi Game_Ender,

as far as I understand the ogre design pipeline, most modeler programs are mainly used to model and export meshes. The python programmer then brings all things together inside the python 3D application code by adding textures, lights, cameras etc. manually and sorting everything into trees programmatically.

Regards
Bernd

So you basically want to do a scene editor.
1.You want to import whole scenes from blender&co. and you want to be allowed to edit them.
2.You want to convert the scenes into PythonOgre code.
Did I understand this points correctly?
The first thing is that Ogre has already a format for scenes(.scene) with a .blender importer. Of course it would be cool to convert the .blender files into PythonOgre code, but how could we benefit from it? You can use the .scene files in your code very easy. If you want to load scenes, edit them and save them again this is what GOOF does. Of course it would be good to make a second application like this, because there isn´t much work made on GOOF anymore and it would show the powers of PythonOgre. I would help you making such a scene editor. I have only one problem with your idea and this is converting the code to PythonOgre source. If we want to do a .scene editor we should base it on the .scene fomat, because of:
1. I think we would not benefit of Python Code, because I think it´s much easier to load a .scene file with a few lines of code.
2. The whole Ogre community could profit from the Editor not only the PythonOgre community.
Also I think the sceneeditor should have support for Physic. I could do this part. And I don´t know if it is best to base the editor on WxPython. I think it would be easier with existing PythonOgre Gui Solutions.

P.S: Nice to see more German/Bavarian PythonOgre users.
If you don´t know Dinglfing, it´s near Landshut.

GOOF is not a scene editor. It has an editor but GOOF games to be a framework for making games. Please see the wiki for more information.

I know this. But still I think it´s important to mention that GOOF has an existing scene editor solution included.

Hello there !

so the question is, what kind of wxpython/python-ogre project would bring a benefit to the community ?

IMHO, it should be a mix of wxpython and python-ogre to demonstrate the power and integration of both worlds.

@SiWi (Apropos Dingolfing):
Als Frangge wass mä scho, wou sainä Nachbärn heäkumma

Regards
Bernd

Ok if you also want to show the power of wxPython, let´s go for this combination. We should start concrete planning.
@BerndWill: Nidabaian ned mid Obabain verwechsln is scho a leistung.

Hi SiWi,

just sent a PM to you.
Did you receive it ?

Regards
Bernd

I recieved it, but I think thats very offtopic.
OnTopic: Some time ago there was the idea to make a framework for procedural content generation. The idea came up that we would need an Editor enviroment for it first. We could integrate the procedural content generation later so we should do a very extendable design/interface at this project.
What design ideas do you have?

Hello SiWi,

what you mean with "procedural content creation" ?
Can you give some examples of what you want to create or achieve ?

I agree on the idea, to load the exported .scene and .xml files and materials from the blender export directly as a scene graph.

It would be fun to export a blender scene, start the wxpython-ogre viewer and show the scene graph as a tree viewing the scene parameters, mesh positions, light colours and material properties !?

By the way: Do you know irrEdit (http://www.ambiera.com/irredit/) ? I think this is the way it could go:




What you think ?

Regards
Bernd

I'd just like to suggest that this be cross-platform. There are precious few tools for the linux community, and it doesn't sound like this would take an inordinate amount of work to port over to Linux/OSX. Just a suggestion, but I know I wouldn't be the only one who would appreciate this.

I'd just like to suggest that this be cross-platform.

If your proposed tool is wxPython/Python based, this shouldn't be a issue...

I've got quite a lot of experience with wxPython, having used it for several projects at work. I'd be glad to lend a hand if needed, sadly my time is quite limited, but I'll gladly help out in a 'consultancy' role

Hi Bernd, nice to see that you are still there.
I know IrrEdit and I also think it could be like this.

I'd just like to suggest that this be cross-platform.

If your proposed tool is wxPython/Python based, this shouldn't be a issue...just because you use cross platform libraries doesn't mean it's cross platform. I'm running into issues in porting a piece of software written in wxPython and python-ogre that works in windows but not linux. Overall you're right it's not an issue so long as you develop on both platforms simultaneous so you can deal with problems when they arise and not down stream and you have to restructure the program.

some examples I can think of: openFrag, Yake, python-ogre, roreditor all claim to be cross platform, and python-ogre is the only that actually is, and the linux version is still alpha.

Hello,

I've been thinking the same basic idea might meet the needs of prototyping 3D games.

I didn't find this thread at the time (shame on me), and wrote a sample in the thread that I did find:

http://ogre3d.org/phpBB2addons/viewtopic.php?t=5822&highlight=pythonogre+editor

Why PythonCard? Since I have no experience with wxPython aside from PythonCard, I'll say that PythonCard has a lot of samples included. Also, it's resource dictionary structure and run-time options have made it my tool of choice anytime I program Python-Ogre. Now, I use PythonCard (from PyCrust really) shell as a scratch pad to try out what will happen in Python-Ogre. Since I'm a novice at Python-Ogre, it's been wonderful to get instant feedback in the rendering window while coding in real-time.

Technically I don't embed the Ogre rendering window into a wx frame, I run it separately, to allow me to run most any Ogre application by this manner. Also, from comparison with the Demo_WX.py included with Python 1.0+, the frame rate of the ogre window running separately is faster.

Python-Ogre and my steps toward tools are the foundation of my MFA thesis (http://runesinger.com). Is anyone interested in collaborating on game editor tools? I'm a designer by trade, so creating usable tools is in my nature, but programming with quaternions and ray-polygon intersection queries is not my strongest suit.

One line at a time,

-- Ethan