Planned rendering engine rewrite

[FLOZi]

I'd support dropping 3do right now if there were a batch mode for Upspring's conversion process. I'm all in favour of dropping (mostly TA originating) anachronisms in the code, much more than many content developers.

But I'd much rather s3o stay in and native, without any batch conversions or client side post processing or anything (which is just asking for someone to delete them or them get corrupted and cause sync headaches).

[SpliFF]

I think the best course of action you could take right now is to...

And do the debating afterward.

You know you're absolutely right. I should have listened to BrainDamage from the start and just said nothing. This thread sags under the weight of a million false assumptions. So here's the deal.

I'm not going to answer any more posts. I'm going to come back here in a week or two with a tool that converts 3DO/S3O to assimp models automatically. We can then look at the results and decide if they are acceptable or not and the process transparent enough.

[Argh]

I should have listened to BrainDamage from the start and just said nothing.

No, because then you'd still be thinking that you'd be re-packing archives, and we would still be asking a lot of pointed questions, only you'd have more time invested already, so it probably would have been uglier

I think that this was the right call, tbh. Now we're all on the same page and you can come back triumphant when it's ready to actually test something.

I'd support dropping 3do right now if there were a batch mode for Upspring's conversion process.

Hrmm.

I was thinking at one point about merging everything together to force UpSpring to re-create a faux atlas, then saving geometry so that it'd all share it in the end.

Crazy, but it would *probably* not be a complete waste of time.

[smoth]

Your answer argh:

I'm not going to answer any more posts.

[Forboding Angel]

Spliff, what you aren't realizing is the fact that we aren't in your head. The entire workflow for modding is looking like it will be undergoing a significant change. The rest of us just want to know what will work, what won't work, etc and if there will be something to help us along the way. The converter for example, if this change was implemented and no converter existed so it was necessary to do everything all over by hand... I would be on here hunting for some serious ass to chew.

However, you seem to have explained things quite well so far.

Theoretically, the old workflow would still be viable. I maek model in wings, export piece by piece, import into new and improved upspring, spit out a 3ds+lua, presto!

Except it would be even easier because many of the annoying ass upspring bugs would be fixed.

(Btw, if you want to 100% drop 3do support, I'm your biggest fan)

Peanut: You know what pesto is?
Jeff Dunham: Pesto. It's the stuff that goes on salad and pizza...
Peanut: No. Pesto.
Jeff Dunham: What?
Peanut: It's a magician with a harelip.
Peanut: Pethto!
Peanut: Da da da! Pethto!
Jeff Dunham: What if someone here has a harelip?
Peanut: Thorry!
Jeff Dunham: Oh, stop it!

[AF]

Id like a converter even if the rendering refactors are not implemented

[Pxtl]

Oooh.... yeah, I could see the maps being a bigger problem than mods. I mean, we've broken old maps before and because of that there were good, successful maps never returned into circulation - the Mars remake, for example.

[Neddie]

Thank you for responding to my post, SpliFF.

[jK]

I know I come across as someone who wants to put others down, but this is not the case. It's just that it seems to me that you can't review the whole project of a new modelrenderer, so your engine experience is limited and your OpenGL experience, too. I know you can learn all this, but still I think such a huge project as this is a very hard start into spring development.
So I just don't want that your spent/waste a lot of time on something that is just a v1.1 of the old one.

If you really want to write a new renderer, here my idea of it (perhaps it may help you):
_____________________________________________________

My whole idea was to use something like a SceneGraph (if you want some info about those check this):

The SceneGraph

• default camera
  • above water
    • opaque (runtime sorted (means just a small size of the items gets sorted with each update) the materials to reduce GL state changes)
      • material "normal"
        • mesh "commander_arm"
          • draw and use transformation at index a
          • draw and use transformation at index b
        • mesh "commander_foot"
          • draw and use transformation at index c
          • draw and use transformation at index d
      • ...
    • 1bit transparent
      • ...
    • alpha transparent (items in here get sorted by their camera distance)
      • ceg "myBoom"
        • draw and use transformation at index ...
      • material "glas"
        • mesh "cockpit_window_of_fighter"
          • draw and use transformation at index ...
      • material "ghost"
        • mesh "commander_arm"
          • draw and use transformation at index ..
      • ...
  • on watersurface
    • ... (contains the same datastructs as 'above water')
  • underwater
    • ...
• reflective water
  • above water
    • ...
  • on watersurface
    • ...
  • underwater
    • empty! (we don't need to draw underwater in reflective pass)
• shadow
  • above water
    • ...
    • alpha transparent (for shadows this doesn't need to get sorted!)
      • ...
  • ...
• cubemap reflection
  • ...
• my custom lua camera
  • ...

So as you can see it groups the whole rendering, which makes the implementation of the single instances (mesh rendering, ceg rendering, ..) much easier. Also some containers need special handling as the z-sorting of the alpha transparent stuff, sorting the materials to reduce GL state changes etc. One unsolved problem are LODs in this system


Also the whole system shouldn't access the synced data to get the piece/instance locations, instead the synced data should send a command to the renderer when an animation starts, so the whole system can handle the animations itself (in an unsynced way).

Animations & Hierarchy Handler

• object id=1 name="unit1_base"
  • animations
    • rotate axis={0,1,0,1}, angle=pi, speed=1
  • sub pieces
    • object id=2 name="unit1_arm"
      • animations
      • sub pieces
    • object id=3 name="unit1_leg"
      • animations
      • sub pieces
• object id=4 name="unit2_windmile"
  • animations
  • sub pieces
    • object id=5 name="unit2_rotor"
      • animations
        • spin axis={0,1,0,1}, speed=1, accel=.1
      • sub pieces
• object id=6 name="feature1_tree_base"
• object id=7 name="feature1_tree_treetop"
• object id=8 name="ceg1"
• object id=9 name="ceg2"
• ...

Info about Piece TransformationMatrices
Also instead of doing

Code: Select all

  glPushMatrix(unitMidPosMatrix)
    glPushMatrix(parentPieceMatrix)
      glPushMatrix(matrixOfTheToDrawPiece)
        DrawPieceMesh()
      glPopMatrix()
    glPopMatrix()
  glPopMatrix()

each piece should save its own ModelView->PieceSpace matrix, so the above could become something like (not that the matrix is really pushed, instead it should be send via VBOs or similar to the GPU, see below)

Code: Select all

  glPushMatrix(ModelView2PieceSpace)
    DrawPieceMesh()
  glPopMatrix()

So any animation in a parent piece should get processed in all it's subpieces too.
Now matrices should only computed on demand, to do so we need to save the matrices somewhere so the CPU and GPU can access them. To support different and future methods to access such data in the shaders (pseudo-instancing, instancing+bindableuniform, instancing+texturebuffer, ...), it's the best to abstract such a container -> one CVertexData interface and add various implementations as CVBO,CVertexArray,CPBO,CTextureBuffer(,CDisplayList).
Also it may be a good idea to duplicate the data in the SysRam, so we don't need to download a matrix from the VideoRAM just to update an animation. Instead we could load the current matrix from the sysram, update it, and then sending the new one to the GPU.

VertexData array

• object id=1
  • 9 or 16 floats to save the matrix
• object id=2
  • 9 or 16 floats to save the matrix
• ...

This VertexData array can now be a VBO that is bound to an Uniform or a texturebuffer which fetched in the vertex shader (the object id needs to send to the shader somehow too!), or it can even be a just a SysRam array which is used for Pseudo-Instancing:

Code: Select all

  CVertexData* data = VertexData;
  CMatrix4x4* m = GetMatrix( data[myObjectID] );
  glVertexAttrib(transformMatrixLoc, m);

  DrawMesh();

_____________________________________________

Puhhh ...
This is a vague description of my idea, may it help you.

[SpliFF]

it'll take me a while to absorb all that, don't be offended if I don't reply in detail straight away. I'll be working on UpSpring for a while anyway so there's no need to rush a 1.1 rewrite if we can do a 1.2 or plan for 2.0. Still, there are limits on how much I want to change so just because something is a good idea doesn't mean I'll do it.

One thing every project I've worked on has taught me is to be cautious about ambitious ideas unless you know how committed your teammates are to the implementation. I fully accept your Gl-foo and C-foo is superior to my hamster-style but if you've really been planning this thing for a year and you haven't done it yet then where does that leave me? With ideas I really can't implement.

All of my planning so far involves relatively straight-forward changes to specific parts of the engine I've had time to study while I was integrating assimp. Very little of that involves messing with the Camera code and overall scenegraph. It's unlikely I could really implement what you've described in a way you would be happy with.

To be honest with you I'm perfectly content with a 1.1 rewrite. It's more in keeping with my abilities and it will help pave the way to better changes down the line. That's why I say I'm happy to abstract classes but not implement actual derived classes if they aren't an immediate priority. That's why I say I'll expose the data for animations but not actually implement them. If it turns out I overlooked something then hopefully 1.2 can resolve that, if not then at least we probably won't be any worse off than we are now.

I've been pushing my assimp stuff regularly to my github branch, which has allowed BD to complete and fix things I couldn't do myself. If I continue this process with a rendering branch then there's nothing stopping contributions, feedback or forks from yourself, zerver, bd and anyone else with a vested interest in this.

The VertexBuffer class is definitely going in. It's how i plan to implement PBO/VBO rendering (GL 2.0) without losing support for displaylists (GL 1.4).

[Argh]

A couple of things:

1. CEG can be largely replaced already; a P.O.P.S.-like design for most of the billboarded systems should make it practical to handle events the way that I'm doing now via Lua, meaning that we can use FBOs and GLSL to drive all of the motion simulations for particle systems (in fact, it's so efficient, we could get rid of a lot of the semi-redundant particle classes now in Spring).

Major computational savings to be had there; CEG and most of the particle systems in Spring are very slow.

For that matter, use the same stuff to drive projectiles. The only real difference between a P.O.P.S. particle obeying physics constraints and, say, a cannon's shell is that P.O.P.S. is billboarded, so the vertexes aren't getting rotated in the shader. There's no really good reason (imo) to have projectiles not use this sort of system.

2. I totally agree with a synced update to an unsynced rendering system, but my feeling is, why not go farther?

Treat all display lists / VBO as particles in a specialized particle system- a Unit's states could be written to very small FBOs, or to a largish indexed one (a 1024^2 bitmap could hold all the Piece position states of even the largest game states, I would think).

I think that with 4 bitmaps, all the important states could be recorded for physical simulation:

Type, Texture1, Texture2, Texture3
Position
Velocity
Rotation Speed

IOW, all synced code for Unit motion would do is what I'm doing with P.O.P.S.- an event that is then printed to the FBO, which then uses the GPU for all state changes. No synced code except for updates; no unsynced fixed-function stuff other than handling the FBOs and loading the relevant display lists into memory once during each pass. And it'd make sorting a lot less painful- model is lazy-loaded, it's geometry is read and entered into the "list of lists".

I was thinking that maybe I'd prototype this idea sometime after P.U.R.E. 1.3 comes out- I think that this is the way to go, from a technical standpoint. I think that assimp should just be used to move the data from 3DS or OBJ or whatever into an internal formatted display list (I don't see the need for VBO, it'd just be static lists, and display lists are faster), and a Unit would just declare a Type associated with a Piece, and the rest would be up to synced updates and unsynced, GPU-driven behavior.

[smoth]

argh if pops is so good, take your work apply it to the engine cegs and submit a patch.

[Argh]

Not if, lol.

[AF]

Pops

Argh, we have yet to see any major outing of pops, or 3rd party adoption, and little documentation and examples. So you shouldn't be telling us its better regardless of wether it is or isn't because thats your opinion. What we want are measurable reproducible facts with like for like comparisons.

Eitherway Pops is irrelevant here, Pops and CEG are the tops of the skyscraper, yet we're talking about redesigning the foundations here, suggesting we use pops because it worked well optimized for foundations 1.0, doesnt mean the same holds true of future foundations 2.0

Derailing

Instead of treating this as a thread about anything and everything related to rendering, instead focus on the rendering engine, in the engine, in c++. Lua has no business here, and what knowledge you have of it is irrelevant. By discussing it you are actually derailing the thread by talking about something similar but unrelated, and its pissing off quite a few people

Progress

I know many already know this or where to find it, but for those who are curious and are wanting to look at SpliFFs work so far, and others, you can find the branches on github here:

Spring
Upspring

[smoth]

Not if, lol.

start a new thread in dev.. maek patch.

[Argh]

I am not making a patch. I do not know C++, I don't have time to drop everything and learn it, and it's more useful to just keep pushing forward with Lua that can be translated back again fairly easily. I mean, hello, for the most part, Lua is just calling C++ stuff that is already in Spring.

Try the demos, maybe try reading the code. You guys seem to think there's a massive difference between Lua OpenGL and C++ OpenGL. There isn't, when we aren't talking about UnitRendering, and the shader and logic are both portable.



So I'll try to explain what *should* be done, in the simplest terms.

What is a Unit animation?

It's some display lists, using coordinates for a centroid, that are moved / rotated in time. Right now, it's being done with the CPU, except for the final part, where it's either piped to LuaUnitRendering or to the ARB shader.

What is a P.O.P.S. particle system?

It's a display list, using GLSL to move the system's members over time, using the GPU for all simulation, with the CPU only providing updates which are written to several FBOs that are updated by a GLSL shader.

So... basically, instead of doing all of the stuff P.O.P.S. does with some FBOs and GLSL, maybe just do rotation / translation?

If none of that makes sense... you really need to sit down with the demos I released, run them, and read the source, which is very well commented.

[Pxtl]

It's the same problem as World Builder - you keep raving about this awesome tool you've got, but I don't think you've ever sat down and made a nice Wiki page of "Here's how to use it". Remember that you aren't offering a new feature, but simply an alternate approach to an existing feature, which means that the existing feature is already better documented than yours and can get help from more sources... so people choosing between the default approach and your "improved" approach are probably going with the one they know how to use.

Now, I know that this kind of thing suffers from the 90/10 rule, so obviously it's a PITA to make up-to-date docs, but if you really want people to start adopting your packages, you need to show them a workflow.

[Argh]

<sigh>

With World Builder... I will make documentation after 1.3, when it quits being something that has to be integrated with a project. It's really stupid-simple to use, though, anybody who can read should be able to figure it out.

As for P.O.P.S, we're not talking about it's current uses (many and cool as they are- everything from smoke that obeys light levels in a map to smarter systems for Unit dust FX to explosions that can react to terrain to a true 3D starsphere).

We're talking about the principles behind it. It's a very different way to do sim.

Agents with minimal CPU setup and maximum GPU sim are the obvious wave of the present tech.

Engines like Crysis (hell, probably their previous engine) do crowds that are probably using a fancier version of what I'm talking about here. They probably also use it for IK-based character animation, but I don't know how that is done.

Meh, I'm interested what jK thinks about doing it this way. I don't see any major problems other than reading the vectors for guns, or getting positions back from the FBO if a callout requests it- everything else can be tracked by COB (i.e., did a visual behavior finish? Yes, and we know it because COB says so).

[smoth]

argh:

new thread in dev..

[Argh]

Not happening.