TGE using Ogre3d
by Ryan C. Scott · 01/27/2009 (4:04 pm) · 20 comments
My experiences thus far with combining Ogre3d in TGE as a rendering engine have been, well, educational.
My plan has been to use the structure of TGE with Ogre3d as the rendering engine. Initially the course was to get TGE and Ogre running side by side and then port things to Ogre one by one until it was possible to actually "Ogre-ize" everything. Failing that, which I'll explain in a moment, I decided to get TGE ported to Ogre by having the TGE objects create and manage corresponding Ogre nodes/entities. This was far more successful, but reached a wall.
I'm writing this quick little note in case someone else out there undertakes this task.
1. The Goal: TGE and Ogre3d running in the same application each with their own window.
Outcome:
Initially this looked promising, but in the end it turned out that TGE's use of the OpenGL context doesn't play nice with Ogre (or I would imagine anything else that's expecting to have an unmolested OGL context).
2. The Goal: Ogre3d in place of TGE's rendering system with all of the other existing TGE mechanisms/systems in place.
Outcome:
I managed to get Ogre to hijack the OpenGL context from SDL, which allowed me to continue using all of the current input code/system.
Likewise, using the Editable Terrain Manager (ETM) in Ogre I hooked into TerrainData and had it export it's heightmap to ETM so that the geometry in the Ogre scene mirrored that of the TGE scene (sans textures).
By hooking into TSShapeInstance I had boxes floating around where each shape would be. I could move around in the world and shoot projectiles and all that crap.
This method gave me the added bonus of being able to run a dedicated server and connect both my stock and Ogred binaries for testing and troubleshooting.
Unfortunately, I came to the point where in order to continue down this path, I was going to have to, at the lowest level, export the geometry (and in the case of TSShapeInstance the animations as well) of every object and create manual objects in Ogre with that. I could have just made duplicate meshes from the same source material for the Ogre side and then used those, but that would mean that every piece of geometry in the scene would be duplicated and that all animations would end up being skinned twice, which was bound to result in a *completely* worthless setup. The TGE side will always need to have the DTSs loaded in order to manage its collision system.
Given that my overall desire was to have the basic TGE game structure and scripting, Ogre3d for rendering, and Bullet for physics, I decided to skip my "Intermediate" ports and go straight for the end. I'm in the middle of gutting TGE and it's been an adventure. Conflicting overloaded new/delete operators was a real treat... I'm talking conflicting like "I've never seen this compiler error before" sort of conflicting... like "I'm not even calling or referring to that anywhere in my code" sort of conflicting... to the extent that it may just be strangeness with GCC.
I've opted for not porting the TGE GUI system as well. While I think it's a fine system I just couldn't think of a reason that would justify that sort of pain.
If you're undertaking something similar, know these things:
* Ogre3d has a few conflicting class names so you will not be able to implicitly use their namespace.
* To translate to Ogre3D's coordinate system do this: Ogred( tge.x, tge.z, -tge.y )
* You /will/ have to find a way to either tie your TGE shapes into ogre (by creating manual objects and skinning/animating them yourself) -or- your Ogre shapes into TGE (by doing the whole convex/collision/etc. thing that TGE uses to manage collisions). In addition, interior spaces become problematic given that they are handled differently by both systems.
* For most of the lower level TGE components, porting one of them will necessitate porting all of them... enjoy that...
** A good deal of the backend stuff comes out relatively cleanly, but again, it's mostly all or nothing.
I'll post again when I've reached my next milestone.
Love,
-ryan
My plan has been to use the structure of TGE with Ogre3d as the rendering engine. Initially the course was to get TGE and Ogre running side by side and then port things to Ogre one by one until it was possible to actually "Ogre-ize" everything. Failing that, which I'll explain in a moment, I decided to get TGE ported to Ogre by having the TGE objects create and manage corresponding Ogre nodes/entities. This was far more successful, but reached a wall.
I'm writing this quick little note in case someone else out there undertakes this task.
1. The Goal: TGE and Ogre3d running in the same application each with their own window.
Outcome:
Initially this looked promising, but in the end it turned out that TGE's use of the OpenGL context doesn't play nice with Ogre (or I would imagine anything else that's expecting to have an unmolested OGL context).
2. The Goal: Ogre3d in place of TGE's rendering system with all of the other existing TGE mechanisms/systems in place.
Outcome:
I managed to get Ogre to hijack the OpenGL context from SDL, which allowed me to continue using all of the current input code/system.
Likewise, using the Editable Terrain Manager (ETM) in Ogre I hooked into TerrainData and had it export it's heightmap to ETM so that the geometry in the Ogre scene mirrored that of the TGE scene (sans textures).
By hooking into TSShapeInstance I had boxes floating around where each shape would be. I could move around in the world and shoot projectiles and all that crap.
This method gave me the added bonus of being able to run a dedicated server and connect both my stock and Ogred binaries for testing and troubleshooting.
Unfortunately, I came to the point where in order to continue down this path, I was going to have to, at the lowest level, export the geometry (and in the case of TSShapeInstance the animations as well) of every object and create manual objects in Ogre with that. I could have just made duplicate meshes from the same source material for the Ogre side and then used those, but that would mean that every piece of geometry in the scene would be duplicated and that all animations would end up being skinned twice, which was bound to result in a *completely* worthless setup. The TGE side will always need to have the DTSs loaded in order to manage its collision system.
Given that my overall desire was to have the basic TGE game structure and scripting, Ogre3d for rendering, and Bullet for physics, I decided to skip my "Intermediate" ports and go straight for the end. I'm in the middle of gutting TGE and it's been an adventure. Conflicting overloaded new/delete operators was a real treat... I'm talking conflicting like "I've never seen this compiler error before" sort of conflicting... like "I'm not even calling or referring to that anywhere in my code" sort of conflicting... to the extent that it may just be strangeness with GCC.
I've opted for not porting the TGE GUI system as well. While I think it's a fine system I just couldn't think of a reason that would justify that sort of pain.
If you're undertaking something similar, know these things:
* Ogre3d has a few conflicting class names so you will not be able to implicitly use their namespace.
* To translate to Ogre3D's coordinate system do this: Ogred( tge.x, tge.z, -tge.y )
* You /will/ have to find a way to either tie your TGE shapes into ogre (by creating manual objects and skinning/animating them yourself) -or- your Ogre shapes into TGE (by doing the whole convex/collision/etc. thing that TGE uses to manage collisions). In addition, interior spaces become problematic given that they are handled differently by both systems.
* For most of the lower level TGE components, porting one of them will necessitate porting all of them... enjoy that...
** A good deal of the backend stuff comes out relatively cleanly, but again, it's mostly all or nothing.
I'll post again when I've reached my next milestone.
Love,
-ryan
#2
01/27/2009 (4:20 pm)
@Ben: Thanks. As soon as I get something worth seeing (i.e. visually) I'll toss it up. 
#3
01/27/2009 (4:25 pm)
I'm sure a lot of people would be interested to see this progress. 
#4
01/27/2009 (6:43 pm)
Didn't the prairie game guy "Can't remember his name" do this already by wrapping them in python or something? 
#5
If I remember well though, Joshua's TGE/Python binding has nothing to do with Ogre.
01/27/2009 (6:57 pm)
What a distinguished, acute, and precise comment, James.If I remember well though, Joshua's TGE/Python binding has nothing to do with Ogre.
#6
01/27/2009 (7:06 pm)
Ogre + TGE has been done before, but I don't believe that that code is available anywhere... 
#7
Great project though. One can certainly learn A LOT about Torque, Ogre, general programming, rendering code, and so on.
Thanks for the blog post =)
01/27/2009 (8:05 pm)
Most likely because of the difference between TGE license and Ogre license. You can't really distribute TGE (closed source) with Ogre (open source) freely.Great project though. One can certainly learn A LOT about Torque, Ogre, general programming, rendering code, and so on.
Thanks for the blog post =)
#8
www.garagegames.com/community/blogs/view/14036
But yeah bummer it was never made public.
01/27/2009 (8:07 pm)
yeah TGB for GUI, TGEA for netwroking and systems, and Ogre for renderingwww.garagegames.com/community/blogs/view/14036
But yeah bummer it was never made public.
#9
Good times :)
... and yeah, I did some work with TGB/TGEA/Ogre3D whilst wrapping them as Python modules. Python rocks.
01/27/2009 (8:16 pm)
Ogre3D is LGPL and can be combined with TGE if you mind your linkage. Qt is also due to go LGPL with version 4.5Good times :)
... and yeah, I did some work with TGB/TGEA/Ogre3D whilst wrapping them as Python modules. Python rocks.
#10
The other thing is Ogre also offers a commercial license now so if you want to static link you can still distribute it and keep the source closed if you get that license. Not sure what the cost is, but I would imagine not too bad.
I've considered doing this with TGEA since I think the Ogre rendering engine is much more efficient than GFX2, and the way TGEA does things would make it a fairly straightforward integration I think.
But alas, too many things on my plate to do more than think about it now :P
01/28/2009 (4:43 am)
Yeah, as long as you're dynamically linking to Ogre and don't put any Torque code in the Ogre DLL, you'll be fine license-wise.The other thing is Ogre also offers a commercial license now so if you want to static link you can still distribute it and keep the source closed if you get that license. Not sure what the cost is, but I would imagine not too bad.
I've considered doing this with TGEA since I think the Ogre rendering engine is much more efficient than GFX2, and the way TGEA does things would make it a fairly straightforward integration I think.
But alas, too many things on my plate to do more than think about it now :P
#11
I'm just guessing that you really like ogre but you are missing all the editor, physics, collision etc... that torque has built in. I guess what I'm really asking is what does Ogre have when it comes to rendering that Torque does not?
01/28/2009 (7:33 pm)
Its a pretty cool endeavor, but what I don't get is... why? Whats wrong with the way Torque renders the scene? Is it a design issue? Performance?I'm just guessing that you really like ogre but you are missing all the editor, physics, collision etc... that torque has built in. I guess what I'm really asking is what does Ogre have when it comes to rendering that Torque does not?
#12
Even compared to TGEA it has a lot of things that TGEA doesn't have that would be great. It has a much more robust material system that allows you to setup per-light passes and customize the names of constants that are passed in to the shaders, plus it supports pretty much all shader languages not just HLSL and GLSL. It has the Compositor framework for layered rendering passes with post-processing effects, material "schemes" and visibility masks which makes it easy to setup things like z-passes. It has 4 different types of built-in dynamic shadows plus integrated texture shadows which allows you to integrate the shadow texture right into your material shaders.
There's really too many things to list here.
Obviously Torque has things that Ogre doesn't have, like the editor and limited physics support, which you mentioned.... but that's probably the point of integrating Ogre with Torque rather than just using Ogre. When they're working together, you can have it all :P
01/28/2009 (8:12 pm)
Ogre has lots of things that Torque doesn't have, especially since I think he's talking about TGE and not TGEA. Even compared to TGEA it has a lot of things that TGEA doesn't have that would be great. It has a much more robust material system that allows you to setup per-light passes and customize the names of constants that are passed in to the shaders, plus it supports pretty much all shader languages not just HLSL and GLSL. It has the Compositor framework for layered rendering passes with post-processing effects, material "schemes" and visibility masks which makes it easy to setup things like z-passes. It has 4 different types of built-in dynamic shadows plus integrated texture shadows which allows you to integrate the shadow texture right into your material shaders.
There's really too many things to list here.
Obviously Torque has things that Ogre doesn't have, like the editor and limited physics support, which you mentioned.... but that's probably the point of integrating Ogre with Torque rather than just using Ogre. When they're working together, you can have it all :P
#13
TGEA seems fine to me, the frame rates are good, the effects are pretty nice too. Its worth the price of upgrading to TGEA if TGE does not have what you want. If you take the amount of time you spend on the endeavor of porting the Torque game code to use the Ogre rendering engine (even at minimum wage) ... I'm sure its more than $295.00.
So the real question is... is Ogre really that much better than TGEA?
01/28/2009 (8:20 pm)
@Gerald, right. I get the point of wanting to port Torque game code. I just don't know enough about Ogre to know why anyone would want to spend so much time trying to use a different rendering engine. Is TGE really that bad? TGEA seems fine to me, the frame rates are good, the effects are pretty nice too. Its worth the price of upgrading to TGEA if TGE does not have what you want. If you take the amount of time you spend on the endeavor of porting the Torque game code to use the Ogre rendering engine (even at minimum wage) ... I'm sure its more than $295.00.
So the real question is... is Ogre really that much better than TGEA?
#14
It remains to be seen if T3D will make any of this stuff any easier. Hopefully :D
And, some people have much more time to spend than they have money to spend, which I would imagine is a good reason to want to do this for TGE.
01/28/2009 (8:28 pm)
It depends on what you want to do. If you want lots of eye candy, Ogre is definitely that much better than TGEA, as far as rendering goes. You can do all of the same things in TGEA if you put your mind to it, but if you're going to be putting in a lot of special effects, the time you'd save by doing them in Ogre rather than trying to hack them into TGEA would probably more than make up for the time integrating it in the first place.It remains to be seen if T3D will make any of this stuff any easier. Hopefully :D
And, some people have much more time to spend than they have money to spend, which I would imagine is a good reason to want to do this for TGE.
#15
Also, I'm replacing the physics with the Bullet library; so at this point I'm having to rip up so much of the engine that I'm going to have a hell of an adventure one way or the other.
If TGEA were going to do exactly what I wanted but wasn't as snazzy on the graphics front I wouldn't be bothering. But things like rigid body physics in TGE or TGEA are just not very robust. I had a door that would get blown off of its hinges that would crash the engine when it collided with the door frame...
01/29/2009 (1:24 am)
I purchased TGEA 1.8 and I was shocked at some of the problems it has (under OSX at the very least). The lack on Linux support is problematic for me too.Also, I'm replacing the physics with the Bullet library; so at this point I'm having to rip up so much of the engine that I'm going to have a hell of an adventure one way or the other.
If TGEA were going to do exactly what I wanted but wasn't as snazzy on the graphics front I wouldn't be bothering. But things like rigid body physics in TGE or TGEA are just not very robust. I had a door that would get blown off of its hinges that would crash the engine when it collided with the door frame...
#16
01/29/2009 (1:26 am)
Oh and my framerates were bad. I don't think it's too much to ask to run at 30fps or above in really modest scenes. 
#17
EDIT: about the rendering of shapes... shouldn't it just be possible to let TSShape do all its magic, but use an Ogre renderable object to actually render the triangles? Forgive me if I'm oversimplifying it - I've got little experience with Ogre, and you have my deep respect for digging so far into Torque's guts ;)
01/29/2009 (7:23 am)
This is realy fascinating... I had a look at OGRE, and I've got in the back of my head to use for projects in the future. I never thought of combining it with Torque! Seems like a great way to go about giving TGE a graphical upgrade. And for free, in terms of money at least ;)EDIT: about the rendering of shapes... shouldn't it just be possible to let TSShape do all its magic, but use an Ogre renderable object to actually render the triangles? Forgive me if I'm oversimplifying it - I've got little experience with Ogre, and you have my deep respect for digging so far into Torque's guts ;)
#18
I have been thinking of using the existing TS code to write an exporter so I can get my DTS models and animations into the Ogre format (or Blender or something readily available as an intermediate format).
01/29/2009 (1:27 pm)
@Daniel: Yeah, certainly that would be possible. I was going down that path, but my end goal involved removing so much of the engine anyway that I couldn't see a reason to port it. Same with interiors.I have been thinking of using the existing TS code to write an exporter so I can get my DTS models and animations into the Ogre format (or Blender or something readily available as an intermediate format).
#19
I've got OGRE into TGEA but let's be honest here, their shape/mesh files are a mess to handle. You export "scenes" where all meshes are standalone and incase you got the same mesh name inside two of your scenes, things will go fubar.
As a pet project I'd love to use a Manual object and skin it myself, and just load our DTS files as before. They're not the slickest to use either, but so far I'm really suprised it's so cumbersome with mesh files when everything else is such a breeze.
Did you get anywhere with that? Thanks!
09/17/2009 (8:03 am)
A shot in the dark here incase you're still watching this thread (you have no email listed).I've got OGRE into TGEA but let's be honest here, their shape/mesh files are a mess to handle. You export "scenes" where all meshes are standalone and incase you got the same mesh name inside two of your scenes, things will go fubar.
As a pet project I'd love to use a Manual object and skin it myself, and just load our DTS files as before. They're not the slickest to use either, but so far I'm really suprised it's so cumbersome with mesh files when everything else is such a breeze.
Did you get anywhere with that? Thanks!
#20
I have since switched to using Unity3D, initially with plans to come back to this, but it's handled everything I've thrown over it so well that I'm not sure I will.
I've thought about putting up my code for it, but it's in a pretty fantastic state of disarray at the moment. I'll put my email in my profile in case anyone wants to get a hold of me.
09/25/2009 (7:39 pm)
Hi anyone still listening. A quick update. I got Ogre in place with their editable terrain manager, a basic pass at some terrain manipulation tools, and pixel lighting shaders for that as well. I integrate Caelum to get a day/night system in place, and Bullet for the physics (which still has some tunneling problems).I have since switched to using Unity3D, initially with plans to come back to this, but it's handled everything I've thrown over it so well that I'm not sure I will.
I've thought about putting up my code for it, but it's in a pretty fantastic state of disarray at the moment. I'll put my email in my profile in case anyone wants to get a hold of me.
Associate Ben Garney
I'd love to see screenshots/video!
Good luck, and let us know how this turns out for you.