Spring + decoupled renderer

[child]

Hi folks,

After a long time I have finally tinkered with the spring codebase again. Many moons ago I was looking into abstracting the modelformats and ultimately implent a new model format. But in the end I pretty much got turned off by the sheer amount of work to get the interfaces done and thinking about messing with the cluttered rendering code set my frustration-level to new unknown heights.

But I have always loved TA and I occasionally play BA. So it happened that contributing something back to the community was always on my list of things to do. Anyway I started out with a s3o-exporter for Maya which I wrote from scratch to get myself a bit dirty(if someone is interested, I have compiled it for maya6, pm me).
I discovered again how limited the fileformats and the spaghetti-renderer are.

So I got down to business with the .76b1 codebase once and for all:
- All opengl calls are gone
- All content fileformats are gone (models, textures, maps)
- Lua opengl stuff is gone
- Ogg vorbis is gone(temporarily, didnt want to compile another dep)
- lots of minor hacks

A high priority was to keep all the gamelogic intact as much as possible.
Every change I made(except for some lua calls) are marked by comments in the code.

Still, it's a huge mess. For me it's the first step of implenting a new renderer and new/updated fileformats into spring. I'm going to tackle everything step by step till I eventually arrive ingame with a unit on a terrain.

In the end I hooked up the lightweight Horde3d renderer(opengl 2.0). Spring starts up now, the window is setup by SDL, the opengl-context is handled by Horde3d and spring runs the pregame script-selection. Unfortunately, there is no eye-candy yet, so it's just a black screen.

Right now I plan my next step, which will be the reimplementation of the necessary 2d elements for CPreGame based on Horde's Overlay and Font capabilities.

Since this is a major but promising undertaking I wonder if anyone here wants to join the adventure.

On top of that I want to know what you(the developers) think about what I'm doing here. Ideally I don't want this to become a fork, so let me know what springs to your mind.

[imbaczek]

You need to show some patches, even if they're not complete. What you're up to seems to be a rather difficult and intrusive task and the earlier you get input from other devs, the better (less wasted work, etc.)

[Licho]

Wow! .. but how will it replace say lua opengl?
Do you want to provide new interface based on the engine?

[Argh]

I just read what they have, and it sounds like all they have is export plugins for software most of us would have to pirate:

# Export the model from your favorite modelling software using a Collada exporter
There are very good ones available for 3d Studio Max and Maya

I don't want to discourage you... but I think that announcing, "Hey, I have this great idea for Spring! It starts by making every game and piece of content developed currently completely obsolete!" is not going to sell.

We have man-decades invested in our model and animation formats. The "gamelogic" you kept intact is a lot less important, other than the timing loop and communication stuff, than the content formats. I'd rather see you destroy, and have to rebuild, the "gamelogic", so that the infamous "spaghetti renderer" could become something that could be modernized and have more model formats added on, than see you just blithely toss our work aside.

[child]

Ok, one thing at a time.

You need to show some patches, even if they're not complete.

Yep, I'm doing this tomorrow morning and post it here for review.

What you're up to seems to be a rather difficult and intrusive task and the earlier you get input from other devs, the better (less wasted work, etc.)

Yes, that's why I posted here.

Wow! .. but how will it replace say lua opengl?
Do you want to provide new interface based on the engine?

Well, it really depends on how the details are set in stone in the end.
As I see it right now, Luaopengl serves a niche. The engine can't cope with the demands mod-developers have when it comes down to nice graphical effects and their rendering. That's were Luaopengl steps in. It basically extends/overwrites the hardcoded drawing routines. With the new renderer this shouldnt be necessary. Instead Lua could be used to work directly with the the new renderer. In the end this should result less critical lua-code for the same quality of graphics.

I just read what they have, and it sounds like all they have is export plugins for software most of us would have to pirate:

Errm, that's not true. I took my time choosing the renderer carefully.
Horde3D has a standalone ColladaConverter which takes collada-files and converts them to the optimized format for the engine. Collada itself is an open xml schema for exchanging 3d assets between applications and it's maintained by the Khronos Group(http://www.khronos.org/collada/). If you take a look around you will find collada-exporters for *every* mainstream 3d modeling software.
On the for-free-side you will find Milkshape and Blender. Check this out: click me

I don't want to discourage you... but I think that announcing, "Hey, I have this great idea for Spring! It starts by making every game and piece of content developed currently completely obsolete!" is not going to sell.

We have man-decades invested in our model and animation formats. The "gamelogic" you kept intact is a lot less important, other than the timing loop and communication stuff, than the content formats. I'd rather see you destroy, and have to rebuild, the "gamelogic", so that the infamous "spaghetti renderer" could become something that could be modernized and have more model formats added on, than see you just blithely toss our work aside.

First of all, i never stated anywhere that all the content that exists right now will become invalid. Under the hood I'd like to see some changes in terms of resourcehandling but the plan is that all older formats are supported in one way or the other. S3O-models could be perfectly parsed into the scenegraph-hierarchy that Horde3d supplies. With a few necessary changes under the hood of the COB-compiler things will be just fine. The same goes for the 2 map-formats. On top of that you will have the engine's format for skinned meshes with skeletal animations.
And when I say that I kept the game-logic intact as much as possible, I meant to say that I don't want to rewrite the engine from scratch. The logic includes everything that makes your mods startup in the first place. Given that the random Opengl calls are gone from the game's classes, it will be easier to isolate and update areas that need a gentle coder's hand. All that without worrying about the possibility of breaking the rendering with all the statechanges involved.

To clearify this: I detached all formats from spring in order to make things easy on me. This does NOT mean I want to dump all the old formats. Dude, I'm not crazy(well, not that much). They will come back as they were, just piece by piece.

Zeewwww, this was a long post I hope you can bare with me. Next time I keep it shorter.
Anyway, gimme your doubts and thoughts. Afterall I'm an honest person and I can take honest critism.

Edit: The forum eats my manual link when I preview my post

[Tobi]

Great work you're doing there.

A few points tho, are you currently just hacking on one working copy, or do you keep a private version control repository? If you're just hacking, then it's even more important to make patches etc. and submit them, but I guess I could recommend using some kind of version control (ie. git-svn) to manage your patch set.

I took a very quick look at Horde3d, and while the samples look nice I noticed a few points:

• The package doesn't seem very polished on Linux side of thing, probably we need a Spring person to fix it up or something (makefile needs CFLAGS to compile with any optimization and makefile doesn't have install target..)
• It isn't in Ubuntu, I'm assuming it isn't in any major linux distribution.
• It requires OpenGL 2.0. This doesn't have to be bad per se, but I'm currently not fully aware of the % of people playing Spring that already have an OpenGL 2.0 capable graphics card. I know for myself that it'd make laptop vs desktop testing impossible because my laptop's graphics chip only supports OpenGL 1.4 or 1.5 IIRC.

That said, if you ripped out all graphics stuff, are you, in re-adding a renderer, taking dependencies etc. into account? (IOW refactoring interfaces where needed, maybe even defining where the boundary between simulation and rendering lies exactly) It would be a major improvement if simulation+networking code can really be compiled as separate (dynamic link) libraries, and the rendering/UI part on top of that is almost hot-swappable, so we could even open the door to people writing a rendering engine for Spring in e.g. XNA or C# + OpenGL when proper bindings for this simulation/networking library are created. If you take that route, then it really doesn't matter if you (temporarily) only have support for OpenGL 2.0.

Either way, I guess I should hurry up a bit with looking at git, since that could make life for you (and us) so much easier with all these refactors

[LordMatt]

Could someone briefly summarize in semi-layman's terms why this would be good for spring?

[Frans]

from what i gather... opengl 2.0, and new model formats?

[SwiftSpear]

child: you seem really knowledgeable about the specifications of you're work, so I'm going to trust you to know well enough to not drop engine support for the majority of our playerbase. What exactly would the OpenGL 2.0 stuff do that currently can't be done, or can't be done well enough, in spring? If we are talking about dropping support for systems, where exactly is that line being drawn?

[Forboding Angel]

I'm just guessing here, but it would probably allow for more speed, better quality of renders, and possibly a lot more flexability.

As I said tho, that's just me guessing.

[Argh]

It'd also allow for a new animation format, using Horde3D's own system, which supports full IK with all of the bells and whistles, and stuff like shaders would be better-supported. So, we could finally have an IK system. That would deliver huge benefits for non-mechanical animations, as well as supporting shaders directly in the pipeline.

Plus, there would be substantial speed benefits from a cleaner renderer- a lot of Spring's rendering is tied up in various places in the game engine code, as child points out, which creates the "spaghetti renderer" problem.

Once those things got into the code (stuff like the FALL event, hard-coded SFX, all sorts of weird intersections of 3DO and S3O) it's become more and more difficult to separate them. And they eat a lot of CPU along the way. This would go around that, and give the graphical side a complete overhaul, with a clean slate.

In theory, this is a major step in a good direction.

I'll take child's reassurance that we're not going to see our content get abandoned at face value- I didn't take enough time to read through Collada's specifications, so I assume he's right, and we're going to be OK importing meshes from stuff we already have. But I have to assume it's going to be months before we see much that actually works.

[smoth]

I'll take child's reassurance that we're not going to see our content get abandoned at face value-

I don't trust it and do not want to be forced into a specific editor or recreated my content. However, it is his private project.

I eye this pensively

[KDR_11k]

Lua OGL is not just for prettyness. Fibre looks like ass but the GL is necessary to run it.

Argh: For christ's sake, DO NOT USE IK IN AN RTS! That stuff already causes a huge performance hit with 3-4 objects using it, if you used it in Spring you'd make SupCom look low-spec in comparison. If you want IK then bake it into your animation, especially if it's just a static movement anyway. IK is something that should stay in your animation program, only FK belongs into the game.

[child]

Here we go.

First of all, here's something for the very brave, a patch for the codebase with all my changes. I'm not sure if it's a good idea to supply it as a single file but anyone interested can take a quick peek:
http://devel.g0dsoft.com/files/tas_no_o ... de3d.patch
About the patch:
- "unit->model->height/radius" all over the place is routed to "unit->getModelHeight() / getModelRadius()". Basically a quick fix till I have an interface up.
- some lua-specific things concerning opengl&models are disabled without fancy comments.
- all opengl code is still there but commented. serves as reference
- all dependencies related to graphics(except SDL) are gone(Devil, libjpg,...). Ogg vorbis is onboard again.
- horde3d was hooked in as a quick hack. I'm going to rewrite that completely.
- rts.vcproj will only compile under debug. I didnt bother with release-mode
- You need the Horde3d 0.13 libs and dlls(http://devel.g0dsoft.com/files/Horde3DSDK_0.13.0.zip) . Just stick them into the vclibs-folder inside a new dir called "horde3d". You should see that in the project settings for debug-mode
- it's a huge mess and nowhere near done

@Tobi:
Indeed, OpenGL 2.0 is the biggest argument against Horde3d. On the pro-side there is the completely customizable(all xml) render-pipeline and material system. I also like the slim resource-managment and the scenegraph-system.

It's also not my intention to drop half of the playerbase because opengl 2.0 becomes a requirement. I dunno, maybe gathering HW-specs via the lobby is a possibility. Then there would be some real numbers we could face. So far I always took the Steam Hardware Survey results for a reference. But I guess it would be plain wrong to apply those %-numbers to this community. Odds are that we need to support a lot of pre-2.0 cards. In this case we have to think about alternatives. There is still Ogre3d, but it's massive and comes with it's own huge set of files.

Anyway, back on topic. About the renderer:
At the beginning I was thinking about hooking up Horde3d directly into sim and game. But you got me thinking. I feel that clear interfaces are in order. It's a better solution. I will put some thought into this.

@SwiftSpear: OpenGL 2.0 enables a completely shader-based renderpipeline. Those are slim and very powerfull. Complex shaders, post-processing effects, GPU-particles, complex lights and surface materials(normalmaps,...), etc. I hope I dont sound like an ad when I say that it means less boundaries for modders in terms of designing their content. But I'm not sure yet where to draw the line. We need real numbers from the community. Till then I can only make assumptions and no real decisions.

@KDR_11k: I think I remember reading somewhere in the forum that you use luaopengl to render lines between the buildings. If there would be a way to draw lines via LUA without opengl I'm sure Fibre would work the same way. (I have to admit that I could be completely wrong about this since I have read about Fibre but never actually looked at it. Which is a damn pity.)

About IK:
In my opinion there is nothing wrong with IK in RTS's. All modern RTS's use them. But usually only for critical models. For example, the huge walkers in Universe at War and the Protos Walkers in Starcraft2 make use of them. Otherwise those units just wouldnt work in terms of visual quality.


Gah, I just can't make it short. Another long post. I hope you guys didnt fall asleep

Edit: Just noticed my nick here in the forums is still "child" and in the patch most of my comments are prefixed with "dazKind" which is the nick I use the most nowadays. Sadly, I can't change my nick in my profile. If some forum-moderator could take of that it would be killer. If that's not possible it's ok.

[lurker]

First!

- You need the Horde3d 0.13 libs and dlls(http://devel.g0dsoft.com/files/Horde3DSDK_0.13.0.zip

404

I don't think I told you you are awesome yet.

[child]

404

Ups, forgot to rename the file on the ftp. Fixed.

I don't think I told you you are awesome yet.

Thx for the motivation

[MelTraX]

Link works for me.. And this really sounds great..

[lurker]

This should be able to give you a partial cross-section of graphics data:
http://www.jobjol.com/springmark.html

[imbaczek]

skimmed over the patch. looooots of work to do left... it's kinda scary to see a 300kB patch that consist mainly of start comment/end comment lines

As for opengl 2.0 - as long as it works on Intel 945, I'm fine with that. That's the lowest end of the low end currently, lots of notebooks have it (including my development box.)

[MelTraX]

OpenGL* 1.4 plus extensions is the latest version currently supported by the Intel® Graphics Media Accelerator Drivers.

(http://www.intel.com/support/graphics/i ... 021517.htm)