Spring RTS Engine

Purpose: Make Spring more playable to the slower pc players, and make it more fancy for great pc players.

Plan: Default the mods to have ModelQualityControl[or some other name] to 0. But if you can assign high, low, and medium models, which would be named Frog:LQ.s3o, Frog:MQ.s3o, and Frog:HQ.s3o [which would make it = 1 if it could models for all of them, otherwise default to all :LQ or found models]. Where ":LQ", ":MQ", and ":HQ" would define whether it's low, medium, or high quality respectively.

Syntax wise there are few to none times that those terms would be used in sequence so there would be no conflicts. It would still be model=Frog.s3o in Frog.fbi, and based on settings would change the clientside model to the set quality.

Conflicts with current mods: None, it would just use the model it finds normally, most likely this would be a pregame thing which would add a few seconds to load times, but would be worth it in reducing lower specced players and making the high specced players happy.

what a crazy idea that hasn't been done to death

you've really come up with some original thingsin your time aWAY

modern games need texture space more then more tris.

the map format would be a better place to start.

Well, based on players using presumably onboard video cards on the lower specs, they rely on their system ram for shared video ram, and based on what I'm hearing, most of them keep above 1gb of ram, texture space is only a conceivable problem if you have a 64mb video card or a low texture fillrate to my knowledge.

Models? *Shakes head*

Models don't cause lag at all compared to things like map inefficiency and effects and lua.

Experiencing bad lag?

If you've got a card with 256 mb of texture memory or less, turn your shadows down or off. Grass should always be disabled, I don't like grass. Map LOD can bring up frames a lot, but, in my opinion, it looks funny to watch it from anything but the standard RTS view.

Check the lua, disable it if it lags you up.

Cut down on particle usage in effects. (Player-side is just turning max particles down)

Ground decals should be about 1 or 0. Mine is on 1 so I can still see other decals like tank tracks.

Maybe an option for using half the texture size or something (which could be done easily, instead of remodeling something) and load that, instead. Low detail textures would save a lot of video ram.

rc, LOD is an old concept.

I'm basing this entirely on my older pcs where even on low the game ran at 7-10fps and could not even run CA or commander shooter without lagging horribly.

"Even run" CA? O_o

CA is full of lua and custom effects... It shouldn't run too well on an ancient computer.

rcdraco wrote:I'm basing this entirely on my older pcs where even on low the game ran at 7-10fps and could not even run CA or commander shooter without lagging horribly.

Draco, you know everything and obviously I know nothing. I bow to your superior knowledge based on no knowledge on what is actually going on.

rcdraco wrote:...models, which would be named Frog:LQ.s3o, Frog:MQ.s3o, and Frog:HQ.s3o...

Well, first of all, all of those are invalid file names on Windows...

Was about to mention that...

Windows is stripping out the : sign. It works on Linux though.

Use + I guess, just some extremely underused symbol to divide it so there will be no conflicts...

okay, thanks for the file naming convention. Lets talk about that some more

Wait, what about engine support? And actual good-looking models? If you can make a model that looks good and causes lag due to 100000 tris and has a texture and you make an lod patch for spring maybe we should look at this thread and consider your ideas... that are 100% original btw...

LOD'ed units are already possible using lua
(you just have to know how to do it )

Here's my original test script for unit LODs and
custom materials:
http://trepan.bzflag.bz/spring/lua/unit_rendering.lua

I haven't tried it in a very long time, so it may
not be working anymore (as an example, the
dev who added in alpha threshold didn't account
for the lua material/lod code; other such changes
may have happened since last I tested).

IIRC, there are two significant items missing from the
lua material / lod code (written, but not committed):

1. Better shader uniform handling
- automatic binding of custom uniforms
- automatic binding of 'engine' uniform (ex: unit speed)
(this can be worked around using the UnitDraw() call-in)

2. The lua VBO class
- allows for much faster loading of custom model formats,
probably even faster than the native engine model loading.
- allows for the use of GL VBOs (with vertex buffers as the
fallback). Could be used with UnitDraw(), or have the
VBO binding added to the lua material (not implemented,
not even in the uncommitted code)


Part of my reason for posting this is to explain that the
LOD code does not work on stages like 'low' / 'medium' / 'high'.
It is based on 'length-per-pixel' (LPP), which is a fairly accurate
way to represent the amount of detail required by a particular
model, at a particular world space distance, with a given field
of view. The LPP value represents the number of world space
units that are drawn into a screen pixel for an object at a given
distance. For a fixed FOV, this can be translated into a distance
factor (easier for most folks to work with).

So ... rather than start with statically defined model levels
(low / medium / high), use a numerical measure like LPP (or
distance values, which could be converted into LPPs)You could
set up a few different types of user controls:
- minimum LPP per model (aka: 'closest' LOD to use)
- maximum vertices per model
- maximum vertices per frame
(relying on previous frame factor to adjust)
- weighted cost factors for model LOD levels
(again, relying on previous frame to adjust)

I may be mistaken, but I also think that I added the occlusion
test GL extension into the lua interface before going my merry
way. That can also be used as a cost factor for those folks that
can use advanced fragment shaders (where the per-pixel rendering
cost is higher).

For different quality textures, low / medium / high may be the
way to go. With very little work (iirc), Spring could also be
setup to automatically downsample the current textures. You
could throw in a few controls like this:
1) TextureMaxArea: 262144 (512*512)
2) TextureMaxSize: 1024
3) TextureQualFactor: 0.5 (applied per dimension)
-- these probably shouldn't be applied to texture atlases

</end-random-musings>


P.S. That's definitely an older version of my unit_rendering.lua
script, it doesn't even test the UnitDraw() functionality.

ZOMG, you actually released it, finally. In a thread I didn't read until now

Meh... I will take a look at this asap, see whether I can make it work again...