graphics engine upgrade? perhaps?
-
Tank Program
- Forum & Project Admin, PhD
- Posts: 6712
- Joined: Thu Dec 18, 2003 7:03 pm
graphics engine upgrade? perhaps?
I was browsing the web and I found this object oriented graphics rendering engine, which looks like something we might be able to use in the long run... check it out. http://www.ogre3d.org/
I actually had the same thought a while back 
It has a hell of a lot of dependencies, though. I'm just letting my magic software installer download and compile it.
Three crucial questions we need to answer before we consider to switch:
- Are the interfaces easy to handle for us programmers?
- Does it help our mod artist with their work or how easy is it to create content loadable with the engine?
- Does it run on low-end hardware if you don't use advanced features?
Skimming through the docs, I have only found things I like so far:
- It is only a rendering engine; it does not tell you how your game world needs to be organized
- Materials and such are defined as textfiles, just as I was planning to do anyway
- Mesh exporters for Max, Milkshape and Blender seem to exist
Mmm. Still compiling the dependencies...
It has a hell of a lot of dependencies, though. I'm just letting my magic software installer download and compile it.
Three crucial questions we need to answer before we consider to switch:
- Are the interfaces easy to handle for us programmers?
- Does it help our mod artist with their work or how easy is it to create content loadable with the engine?
- Does it run on low-end hardware if you don't use advanced features?
Skimming through the docs, I have only found things I like so far:
- It is only a rendering engine; it does not tell you how your game world needs to be organized
- Materials and such are defined as textfiles, just as I was planning to do anyway
- Mesh exporters for Max, Milkshape and Blender seem to exist
Mmm. Still compiling the dependencies...
-
Tank Program
- Forum & Project Admin, PhD
- Posts: 6712
- Joined: Thu Dec 18, 2003 7:03 pm
Installation did not work too well for me. Everything seems to be put into the right place, but I can't yet run any of the samples. Perhaps I'll need to read the docs, some file copying is required and I took a guess
The good news so far is that the download size overhead does not seem to be too severe. The binaries of the shared libraries gzipped together weigh in at 1.3Mb, that would be tolerable. I don't know about all the dependencies ( would we need them in the distribution or are they only needed for development? ), but I feared a bigger download.
The good news so far is that the download size overhead does not seem to be too severe. The binaries of the shared libraries gzipped together weigh in at 1.3Mb, that would be tolerable. I don't know about all the dependencies ( would we need them in the distribution or are they only needed for development? ), but I feared a bigger download.
-
Tank Program
- Forum & Project Admin, PhD
- Posts: 6712
- Joined: Thu Dec 18, 2003 7:03 pm
To tell you the truth, z-man, if you were to show up and say "I've slapped python bindings on the network code and written a proof-of-concept dedicated server", I'm there.z-man wrote:I've installed the SDK under windows ( really painless, a big plus ) and ran most of the samples. Quite impressive! Total zip file of all required binary files is still < 3mb. Of course, advanced effects will be a good way to bring the 500FPS back down to earth
As soon as AA has any amount of code in Python, I'm there. (I'm really excited about this OGRE thing and I'm hoping it'll work out, we "as in you" get to offload all the rendering bugs onto this other library that has significant commercial support and numerous livelihoods attached, so that all future rendering bugs will be a matter of representation rather than actual rendering, and that leaves the network code and the actual game logic as the only things left in the game to be dealt with, which makes the game a prime candidate for a massive rewrite in Python. In fact, if you were able to slap python bindings on the existing rendering engine and the network code, I'd be interested in tackling a rewrite of the game logic in Python)Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
Compiling right now, here's what I've got for dependencies:
Allegro (one of the dependencies has this for a dependency)
DevIL
zziplib
And NVidia's CG compiler
Of these, we can reasonably expect someone to have all but the CG compiler available for their distribution (since I'm on Mandrake and I was able to urpmi all except the NVidia package). All in all, not *too* bad, but there would have to be substantial benefit from using OGRE for users to find it a reasonable imposition. Of course, Windows users are probably immune since you can bundle the dll's in the installer.
Allegro (one of the dependencies has this for a dependency)
DevIL
zziplib
And NVidia's CG compiler
Of these, we can reasonably expect someone to have all but the CG compiler available for their distribution (since I'm on Mandrake and I was able to urpmi all except the NVidia package). All in all, not *too* bad, but there would have to be substantial benefit from using OGRE for users to find it a reasonable imposition. Of course, Windows users are probably immune since you can bundle the dll's in the installer.
Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
-
Tank Program
- Forum & Project Admin, PhD
- Posts: 6712
- Joined: Thu Dec 18, 2003 7:03 pm
About the benefits of using it... Didn't z-man say once that the current 3d representation was just a 2d world with an extra dimension for the camera slapped on? Therefor sorta making things tricky? Well, this would be a true 3d environment, and probably make the whole map rewrite thing go smoother too.
More possible benefits:
- we could scrap the material/mesh system reimplementation since Ogre probably has exactly what we need
- the same for other systems: we'd get shadows, skeletal animation, hierarchical culling, well tested 3d vector classes, particles and a UI system for free
- better 3d-card compatibility: In Windows, it will be possible to use Direct3d for rendering if OpenGL does not work
The main downside is that using a full-featured external engine makes the project bigger. We would need to actually use the new features offered to us, our users won't accept blowing up the download size or total compilation time just because it makes development easier for us. They'll want to profit, too. Of course, they'll indirectly profit from easier development because they'll get more game features sooner, but that won't be enough. Edit: I just noticed that's exactly what Lucifer was saying.
Whether FPS would go up or down with the same content is unclear. On the one side there's the added complexity and overhead of a full 3d engine, on the other hand the speed benefits from minimizing render state changes and culling. My guess would be that it will benefit framerates.
About the dependencies: I'm not sure, but I think the cg toolkit is only really needed for development.
I've got things to run on Linux, too. Somewhere I got the info that the gentoo install is broken, so I just unmerged ogre, deleted all libs manually and installed version 1.0.0 from source. Works flawlessly with fluid fps for the basic demos ( 30fps is not bad for a GeForce2go in 1600x1200 ).
If you ( talking to the other gentooers here ) want to install it, just use "emerge -o ogre" to get the dependencies and install ogre itself manually. If you want a GUI graphics mode selection tool, pass "--with-cfgtk=gtk" to its configure script. Edit: cotrary to my statement from an earlier post, no file copying is required.
- we could scrap the material/mesh system reimplementation since Ogre probably has exactly what we need
- the same for other systems: we'd get shadows, skeletal animation, hierarchical culling, well tested 3d vector classes, particles and a UI system for free
- better 3d-card compatibility: In Windows, it will be possible to use Direct3d for rendering if OpenGL does not work
The main downside is that using a full-featured external engine makes the project bigger. We would need to actually use the new features offered to us, our users won't accept blowing up the download size or total compilation time just because it makes development easier for us. They'll want to profit, too. Of course, they'll indirectly profit from easier development because they'll get more game features sooner, but that won't be enough. Edit: I just noticed that's exactly what Lucifer was saying.
Whether FPS would go up or down with the same content is unclear. On the one side there's the added complexity and overhead of a full 3d engine, on the other hand the speed benefits from minimizing render state changes and culling. My guess would be that it will benefit framerates.
About the dependencies: I'm not sure, but I think the cg toolkit is only really needed for development.
I've got things to run on Linux, too. Somewhere I got the info that the gentoo install is broken, so I just unmerged ogre, deleted all libs manually and installed version 1.0.0 from source. Works flawlessly with fluid fps for the basic demos ( 30fps is not bad for a GeForce2go in 1600x1200 ).
If you ( talking to the other gentooers here ) want to install it, just use "emerge -o ogre" to get the dependencies and install ogre itself manually. If you want a GUI graphics mode selection tool, pass "--with-cfgtk=gtk" to its configure script. Edit: cotrary to my statement from an earlier post, no file copying is required.
Since Ogre only handles rendering, backwards compatibility of the network system and configuration files would be no issue. Content backward compatibility is, but no big one: the meshes need to get reexported into the ogre format or converted ( I suppose it won't be hard to write a converter from ase to ogre's format ) and material scripts need to be written for the textures. Since, apart from scaling, textures are handled always the same by the current code, this only has to be done once and can then be copied over to all moviepacks/texturepacks.Your_mom wrote:backwards compatibility?
- I would sign to betatester's immidiatly if it would be possibleWell, there's no planning ( or deciding ) yet. I think we should first wrap up the bugfixes in 0.2.7.x ( two months minimum ). Then we could hack together a prototype to learn the engine and to throw away later ( one week? Hard to estimate ). Hacked in the same sense that the whole game is hacked, the prototype code would have rendering specific code scattered all over the place. There probably won't be a menu, the game would start immediately.
On second thought, since the prototype will be thrown away anyway, we could start it off the current code base as well. We'll learn the same and gather the same performance characteristics data.
Lucifer: from the ogre wiki I read
On second thought, since the prototype will be thrown away anyway, we could start it off the current code base as well. We'll learn the same and gather the same performance characteristics data.
Lucifer: from the ogre wiki I read
PyOgre is not yet finished on Unix, though; we may want to roll our own here. And it uses boost.python which i personally find quite a nightmare. The Ogre people seem to prefer Lua.Python programs can use Ogre via the PyOgre Ogre add-on. There is also a work-in-progress library for embedding Python scripts in C++ Ogre applications.