[Release] Change unit geometry/Multiple UV maps

[Pressure Line]

This is a release of the gadget written in response to this thread about attaching pieces from one unit onto another.

Lets get what this gadget does NOT* do out of the way first:
-does not allow player unit customisation (player cannot click a button to put a Bulldog turret on a stumpy)
-does not allow a unit's geometry to change over time (growing extra arms, different guns etc in response to XP gain)

Code: Select all

Contents
1) Introduction
	1.1) What this gadget does do
	1.2) What this gadget does NOT do
2) Setting up the reciving units
	2.1) Gadget config file
3) Setting up the source units
	3.1) The source unit is a unit
	3.2) The source unit can have more than one piece
4) Help & Troubleshooting
	4.1) Debug mode

--------------------------------------------------------------------------------
1) Introduction
--------------------------------------------------------------------------------

1.1) What this gadget does do
	By default Spring parses the s3o models and sends them to the gpu as OpenGL
	displaylists to be drawn on-screen. This gadget simply generates an alternate
	displaylist from another s3o model and replaces the default displaylist with
	the alternate. This alternate displaylist does not have to share textures with
	the unit it is being put on.

1.2) What this gadget does NOT do
	*Allow you to change unit appearance mid-game
	*Change anything other than unit appearance

--------------------------------------------------------------------------------
2) Setting up the reciving units
--------------------------------------------------------------------------------

2.1) Gadget config file
	The gadget loads a list of units, what pieces need to be changed and what
	to change them with from the config file. The format for the config is:
	
		targetUnitDefName = {
			{sourceUnitDefName1,sourcePieceName1,targetPieceName1},
			{sourceUnitDefName2,sourcePieceName2,targetPieceName2},
			...
			{sourceUnitDefNameX,sourcePieceNameX,targetPieceNameX},
		},
	
	The sourcePieceName can be the same for multiple targetPieceNames.
	The sourcePieceName MUST be unique, only one displaylist can have
	any given name, so be creative.

--------------------------------------------------------------------------------
3) Setting up the source units
--------------------------------------------------------------------------------

3.1) The source unit is a unit
	This means it needs a valid unitDef and script. The unitdef values do not
	have to make sense, they only need to be valid. The script can be any script
	that will load.
	
3.2) The source unit can have more than one piece 
	The source unit can have multiple pieces, in any type of hierarchy. The pieces
	must have their origin points set correctly to work properly on the target unit.
	
--------------------------------------------------------------------------------
4) Help & Troubleshooting
--------------------------------------------------------------------------------

4.1) Debug mode
	The gadget has an internally triggered 'debug' mode. When enabled, the gadget
	prints messages to the console and infolog. The enable/disable this mode find
	the debug mode switch in the main gadget file.

*just because it does not currently do something does not mean it cannot be modified to do so, but I am probably not going to do it.

TO DO:
-Finish optimising, (jK your model loading logic had an error)

Screenshots and further info in next post...

[Pressure Line]

Here is a model I pulled from *somewhere* on the Internet. Don't ask about license status, because I simply don't know.



And here is the main texture:

And the wheel texture:


This setup is fairly typical, but until now, for Spring games, totally useless. The gadget replaces the geometry and texture of the wheels in the original stryker.s3o model (textured cubes, Spring auto-hides empty pieces, and for the tiniest fraction of a second the units spawn retain all their original geometry) with the wheels from the strykerwheels.s3o file.

↓↓↓ Comments, questions, bugs all go here ↓↓↓

[FLOZi]

My boner, it is bonering.

[Beherith]

Congrats PL, thats some very nice work!

[PicassoCT]

Years of - this aint possible, and then out of nowhere, a Pressuredrop, and we are in space!

A++

The problem is, its so deep inside you, that the trouble for old spring-niks is to get used to the idea, that this is suddenly no longer nil.

[smoth]

Thanks so much for the help pl, I look forward to playing with this next weekend!

[Kloot]

Years of - this aint possible

Nobody ever said this (swapping piece display lists) *wasn't* possible.

The *correct* characterization would be

Years of - nobody bothered to put any of the age-old existing Lua API pieces together

[jK]

TO DO:
-Finish optimising, (jK your model loading logic had an error)

specify please

edit:
and yeah, good job

[FLOZi]

Years of - this aint possible

Nobody ever said this (swapping piece display lists) *wasn't* possible.

The *correct* characterization would be

Years of - nobody bothered to put any of the age-old existing Lua API pieces together

With an added caveat that 1 or 2 people in particular would have been able to do this in a matter of minutes.

One might argue that it would have been if people were interested enough to badger about it, mind.

[smoth]

I am happy it got done. Many of our local idea guys didn't help and frankly I am thrilled PL rose from the dust and JK gave the pointers to see this get done.

So again, thanks guys! this will be super helpful.

PL:
any reason why I cannot later add new parts into the display list? I obviously would have to modify this but beyond just that you have not gotten around to it, is there a technical reason?

[FLOZi]

I am happy it got done. Many of our local idea guys didn't help and frankly I am thrilled PL rose from the dust and JK gave the pointers to see this get done.

So again, thanks guys! this will be super helpful.

PL:
any reason why I cannot later add new parts into the display list? I obviously would have to modify this but beyond just that you have not gotten around to it, is there a technical reason?

I don't see any reason why it couldn't be modified to do it. The thing I find more unfortunate is that you can't just use empty pieces in the 'base' unit; I guess that means you never got show/hide commands working, PL?

[smoth]

we have to have 2 verts for vector?

[Pressure Line]

any reason why I cannot later add new parts into the display list? I obviously would have to modify this but beyond just that you have not gotten around to it, is there a technical reason?

¿que? You mean add geometry into an existing displaylist? possible, sorta, but messy. Also remember that this is essentially run per unitDefID so any changes you make to a displaylist of a given name will affect every unit of that type [kinda]

If all you wanted was to have an upper arm (for ex) for a specific gun on a specific mech, you could just store it as a piece in the same s3o as the gun (or anywhere you choose, it doesn't really matter) and have the gadget change the upper arm geometry & texture as a separate entry in the config table

we have to have 2 verts for vector?

The thing I find more unfortunate is that you can't just use empty pieces in the 'base' unit; I guess that means you never got show/hide commands working, PL?

It works fine, that line was to save myself from endless "I used your lua, and instead of drawing 'Z' it draws nothing" questions. You'd just have to be sure to "show pieceName;" (or the lua equivalent) for every empty piece that was going to recieve geometry. In the testmod I have used cubes.

specify please

It was loading every piece that had been defined as a sourcepiece in a particular sourceunit, even if only 1 of the sourcepieces was being used at the time

eg: i have 2 pieces in the 'tankturrets.s3o' model, m1a1turret and t80turret. If i build a T80, i don't need the M1A1 turret displaylist to be loaded too, your code was doing this.

[SpliFF]

What about performance?

The objection to adding this support engine side is due to the cost of changing texture during a rendering pass. Last I checked the engine optimises texture changes as:

Code: Select all

for texture in [all distinct unit textures] do
    change texture
    for unit in [list of units with the same texture] do
        for piece in unit do
            render piece

The texture only changes once per distinct texture so if you have 1000 peewees and 1000 raiders there is still only 2 texture changes. Your code adds per-piece texture changes as follows:

Code: Select all

for texture in [all distinct unit textures] do
    change texture
    for unit in [list of units with the same texture] do
        for piece in unit do
            -- your display list
            change texture
            render piece
            change texture back

In the same scenario as above you now have a minimum of 4002 texture changes (2 per unit x 2000 units plus 2 per texture) and that assumes you are only changing one piece per unit.

Any chance of seeing a side-by-side FPS comparison of a 1000 units with this code and without? I'm curious to see how big a factor texture changes really play.

[Pressure Line]

What about performance?

The objection to adding this support engine side is due to the cost of changing texture during a rendering pass.

Last I checked the engine optimises texture changes as: blabla

If *I* was going to impliment this in the engine I would untie the renderer from having to do the whole unit in one hit. Make it get a list of PIECES with a given texture, render those, move onto the next texture etc

More of a change in granularity in what it renders per-pass than anything.

Things would also be made a lot simpler if there was a call:

Spring.UnitRendering.SetPieceMaterial
( number unitID, int piece, int lod, string MaterialType, userdata Material | table Material )

Done at the same time.

[SpliFF]

I've proposed rendering pieces in a single pass before before. Kloot is of the view that the performance hit would be unacceptable and I lack any data to dispute the claim.

What I do know is there are factors that make rendering whole units desirable and one of those factors is that units tend to have whole-unit effects like cloaking that are currently rendered in one pass. Switching to per-piece rendering would require a more sophisticated arrangement of passes like:

Code: Select all

shared effect pass
  shared texture pass
    render pieces

It will probably mean more state changes and will definitealy cause issues with the current implentation of unit shaders and PreUnit / PostUnit rendering. You have to remember that spring has a number of state changes wrapped around each unit and these would need to be restored each time a piece from a common texture pass is rendered. This will probably result in a very high number of state changes and a huge FPS hit.

Since the change would also be a lot of work and potentially mod-breaking, a very strong argument with supporting FPS data would be a pre-requisite I'd think.

[Pressure Line]

I'm guilty of oversimplifying matters, there is obviously more to it than a simple re-factoring of the rendering logic blocks. Perhaps I should start learning C++ lol

edit: a further musing, perhaps per-piece would be excessive and over-granulating it. per material (coupled with a way of setting a material per piece, either in Lua or an ASSIMP meta-file) would surely be sufficient. still more complicated than 1 unit = 1 material,but perhaps easier to manage than splitting the unit into its component dlists then seeing which ones belong to a certain texture. I dunno really

[Erik]

This doesn't use the texture 2?
I tried to use the text 2 alpha layer to achieve transparency but it doesn't work. Works fine on the dummy unit though.

Edit: It also works fine on shadows: