LOD models (Good for infantry and other high detail units)

[centurion-1]

Hi!
This is pretty much ripped straight from Rome Total War. Basically what i would like are some unit .fbi tags where you could define as well as the default object .3do and .s3o based on view distance from the unit.
It would be something like

Code: Select all

object=ntinfantry.s3o
object500=ntlowinfantry.s3o

Where 500 is the distance from the viewer, ie camera, in Spring lenght units just like radarrange,weaponrange etc. Preferably this would be freelydefinable but a number of steps would be just as well, like 200, 400, 600 etc.
The reason this would be great is that one could splurge with the polies some even on units that will appear in great numbers, ie. infantry without worring about slowdowns. The issue is a concern for me, for my current 900-triangle soldiers can be a slowdown factor in great numbers and the details are not visible anyways from far away but when you zoom in close to watch the action I'd hate to see boxmen (ie 200 triangle soldiers).

I hope this is seriously considered and it is important as well in the future when maps can get bigger and friendly units in the distance are rendered many at once. Another game that uses LOD models to great effect is Operation Flashpoint, a game with long view distance and it works great.

[KDR_11k]

Well Spring does have an LOS system already but it's pretty buggy, units turn into a single solid color for me which makes it impossible to see whose side they are on.

[centurion-1]

Well, this would be alot more robust and also forgiving of highpoly models ( = the future)

[SinbadEV]

Next version wil have iconic lodding... which will be a good start

[hrmph]

Great idea.

[Argh]

Yeah, I'm really looking forward to that, it should help the NanoBlobs "experience".

[AF]

The new lod system in jelmers sm3 map format is much much better than the current one. Try out the dev build in the downlaods page.

[Das Bruce]

The new lod system in jelmers sm3 map format is much much better than the current one. Try out the dev build in the downlaods page.

We're talking models not maps AF.

[smoth]

Yeah, I'm really looking forward to that, it should help the NanoBlobs "experience".

actually, the icons can have their distance set by the user argh, so if you wanted to really prove a point set the distance really low, that way you can prove without a doubt that the models are not the cause then maybe people will listen to us :).

[AF]

no, zaphods new renderer renders untis differently. If you zoom out you can see a set of stages inbetween normal view and unit icons where the mdoels have less detail but you can make them out better than in the current build.

[GrOuNd_ZeRo]

The main problem with slowdowns is NOT the polies on the models, it's infact the pathfinding, Spring is VERY intensive with pathfinding and uses up alot of processor power.

LODs will only curb the slowdowns a little, i'll confirm this with some low poly units to make sure.

[edit]

Hmm, it doesn't matter if the model is 300 polies or 50 polies, a large number of units make the FPS drop significantly.

if the units are out of view they don't slow down as much...

[jcnossen]

AF: I really haven't touch the unit rendering code. It's only a map renderer.

[Wolf-In-Exile]

I'm hoping this could be done as well. Even if it isn't dynamic LoD, I wouldn't mind making the lower poly models manually.



Far as I know, FPS is affected by a couple of things.

1) Individual unit polycount

2) Pathfinding

3) Number of units onscreen

4) Animations

In this case, i'm guessing the animations and number of units onscreen are the bigger factors resulting in slowdown.

[Gnomre]

From what I understand, more unique pieces in the model tend to slow the game down more than large poly counts (though that isn't to say large poly counts will have no effect). Of course, this often closely ties in to the script, since they slow the game down too as they get heavier in complexity.