Spring RTS Engine

CreateUnitDisplayList: Produces a single continuous display list from a Unit's Pieces.

Input: UnitID. Output: named display list. Would be nice to be able to add basic information to each triangle via multitexparam, for certain types of simulations.

This would allow for dynamic objects to be created and manipulated via script, then displayed very efficiently.

RenderDisplayList: a special, engine-specific rendering mode, much like the DrawUnit() pass. Would allow named display lists to cast shadows, etc. like Unit and Feature geometry, and make use of the shader system (as opposed to having to be set up from scratch as now).

I am aware that some of this is "possible" atm. I am specifically asking for a much greater level of automation, engine-side, and the shadow side of things is non-trivial.

tbh it sounds as if this has arisen from a lack of structure and design on your own code, rather than a need for it in the engine code.

I would say that such requests are problematic in that anything that increases automation within the engine requires immense customizability or it will limit some people.

But either way what you are requesting doesn't sound quite right. I imagine having a single display list containing all the pieces of a unit would be problematic in that it would result in a static pose unless animated via vertex shaders.

Any further speculation on my part would require greater knowledge of springs internals, as such I oppose this more in terms of the basic premise, than based on API abilities.

This is about having data input of a specific type. Since we have three different model parsers already in the engine (3DO, S3O, OBJ) I presume that building a secondary function call that returns X.obj as a display list Y (triangle strip) is not a particularly difficult request. Why I want it like that is not important, and neither is this a specialized request- I just want to be able to say, "hey, Spring, read this file, return a display list" so that I can have display lists built by hand and ready to manipulate in various ways.

The render side requires a bit more explanation, I suppose. As just one example, if this could be done, expensive, multipart Unit meshes for buildings could be rendered in a single pass, other than translucent surfaces, and only revert to rendering in the normal multiple-mesh method when being destroyed, which would speed them up quite a lot.