Spring RTS Engine

Hi, I'm slightly new to 3D modelling (and completely new to actually using those models in games), so there are one or two things that I don't know about.
Basically, I've made a few C&C (Tiberian Sun) models with the intention of putting them into Spring so I can teach myself how to mod spring, and what I want to know is what's a normal number of polygons/faces that a model in spring should have?
My current model has 2316 faces (there are a lot of curved surfaces on it). If this is too many for normal spring play, how should I reduce it?

edit: I should add that it's a normal-sized hovercraft type vehicle.

show us a picture of the model, that'll help

What we do for spring you would call "low poly modeling". Generally that means under 1000 for most units. With low poly modeling you tend to not use curved surfaces whenever possible, and when you do use curved surfaces make them as few faces as possible (as few sides as possible to retain the look needed). Otherwise, we kindof have to see the model to guess where wasted poli's are.

SWS infantry are 700-900 tris (mainly in the heads/guns but also to make joints appear as good as possible considering the limitations) and most other units are no more than 1500-1600. Some buildings get up to around 2k, and the Imperial commander is several thousand, but since each Imperial player only gets one, that's acceptable.

You should always try to shoot for as small a polycount as possible. Spring can smooth curved surfaces, so hexagonal or octagonal barrels etc are usually all you need (depending on the size of the gun). Of course, if the unit is dominated by a smooth, round surface, you can put the extra detail in. Also, many details need only be textured in; modelling them in can create unnecessary work when wrapping and texturing which provides no benefit since no one will likely ever see such details.

Really, though, you just need to consider the unit's size in game and its role (which includes the amount a player will build on average, or if there is a limit to the number a player can build). You generally want to keep small L1 stuff below 1000 triangles, and try to keep L2 stuff below 1500-2000. L3 stuff and special/very limited units for any level can be higher, but you also want to keep a degree of consistency.

Of course, if you have a mod that only has a dozen units played at a small, tactical level, you can pump in much more detail. It really just depends on how the mod is designed.

i use 1000 as a general guide for l1 stuff

tip: spring should now supports LOD (Level of Detail) of models (you need some lua to do so). So if your 3d program supports/helps to create multiple version of your unit (I heard blender should do so) you can use much more polies, so first create a high poly model (~3k) and then reduce it to (<1-2k). So you can always create different levels of details of your unit, if you need them

so i too you use 1000-1100 triangle lvl1 units.
but some where i readed, a tip (upspring tutorial?) for the lovest unit 200, lvl2 400, planes 600, commander 1000. sorry if i qoute not correct.
but sure im new here too :) so good luck for the learning, and the creating

Heh.

Whatever it needs to look good.

I have several t1 units that have 2k polies. *Remembers his buggy with two infantry >___<

Most of my vehs have 500-1k polies, and, the higher teched stuff has no more and no less, because its all in how they look, not how many polies they have.

How they look as in, is this unit larger, does it have more weaponry, etc.

I can still use gatling guns with cube barrels on t3, and tank wheels that are 8 wheels.

Somebody, please clarify how lua controlled unit LOD works. Thanks.

Generally the polygon limit should depend on how many of the unit you expect in play on average and how large it is. A unit that will have only 1-2 on the battlefield at a time can easily have 3000 or even much more polygons but something you want to have hundreds of should stay in the 100-200 range. Of course it also depends on the needed details for a unit, a borg cube wouldn't need 6000 polies even if it's the only unit in the game.

Also think about the user you want. Do you want your mod to be playable on a GeForce 256 or a Riva TNT? Keep it in the low hundreds even for rare units and tens for common ones. Do you want it to be meant for newer cards like the 8800? Feel free to use 1k on swarm units.

I have ~200-1800 for my units. Use what is appropriate for your detail levels.

JK, the LOD system you speak of has to be done in lua and is done by switching the models shown, it isn't some automatic spring code. He will have to make several versions of his models and have lua switch them out.

Not true. Spring has an inbuild LOD system, the only problem is you have to load the models with lua into it.
(btw, you also can add shaders, change materials, etc. with this new rendering system )

If you are interested, trepan already wrote a test luaRule. (sorry, I don't want to link to other's webhosts)

JK, the LOD system you speak of has to be done in lua

Not true. Spring has an inbuild LOD system, the only problem is you have to load the models with lua into it.

and is done by switching the models shown, it isn't some automatic spring code.

Spring has an inbuild LOD system, the only problem is you have to load the models with lua into it.

He will have to make several versions of his models and have lua switch them out.

Yeah true, you basically said what I did with different words. MOVING ON!

Again not true.

smoth wrote: and is done by switching the models shown, it isn't some automatic spring code.

smoth wrote:He will have to make several versions of his models and have lua switch them out.

It is automated! And no, the switching isn't done with lua! And again no, you only have to load your LODs once!

for fucks sake jk...

and is done by switching the models shown, it isn't some automatic spring code.

Yeah, it isn't he has to use lua to tell spring what models to fucking switch out.

He will have to make several versions of his models and have lua switch them out.

It is automated! And no, the switching isn't done with lua! And again no, you only have to load your LODs once!

Oh really? It is automated? As in he will not have to CREATE the "lods" which are different versions of the fucking model? Or perhaps it merely understands what details are unimportant through some mega awesome model reduction algorithm?

No, you have to make the sepperate models for the LOD, you HAVE to USE LUA to LOAD the fucking models so it knows what represents what level of LOD, otherwise spring would just select the models on it's own. If there was some awesome automatic lod all of us would already be using it. However, there isn't spring "lod" currently goes from no animation on a stationary model to some sort of sprite. That is not loading lod levels. It isn't automatic, you have to create the lod level models you have to tell though lua how to load said models.

LOL, QUOTEWAR!

SwiftSpear wrote:LOL, QUOTEWAR!

Considering how Spring's nasty bottlenecks are pathfinding, scripting, and targetting, I wouldn't stress for a second about polycounts.

Although I do find it frustrating that my dusty old 2Ghz machine struggles processing the same pathfinding, scripting, and targetting that a 200 Mhz machine could handle just fine in OTA. But that's a topic for another day.

For one thing, OTA maps were as a general rule, much smaller.

OTA maps were very much flat, with a min height of generally 165 (give or take a few) to right about 255. If you look at ota heightmaps, it becomes obvious assuming you know beforehand that OTA heightmaps use 255 levels.

Pathing for that is, heh, easy.

Scripting, give or take, and depending on how much is run at one time, has a negligable performance hit in OTA, comparitavely.

THe thing that had the most performance hit in ota was (dingdingding), Graphics... Specifically polygon counts.

Actually, I've seen little correlation between map size and pathing CPU usage, in my tests. Which was somewhat surprising. Forb is right on, however, when he refers to flatness being an issue. Most CPU-friendly maps are, well, flat. This has two major effects:

1. The larger the flat (or negotiable) paths are, the easier it is for the pathfinder to find a valid path when searching.

2. More interestingly... the more wide flat spaces you've got in a map, the larger the total polycount savings in the LODMesh code used in SMD.

One of the things I tried recently, just because I saw it in Snipa's settings for good FPS with a GeForce 6600, was that he actually kept the grass on (I generally don't, I'm zoomed out too far to see it) but he turned the LOD for the maps down to the lowest setting.

I tried it, and was very surprised at the FPS gain. It was huge. Not just minor- we're talking 50+ FPS here. I dunno if the polycount just bloats that much, if turned back up to 80% or so (doubt it), so I'm kind've stumped about why this should be the case. Based on all of Jelmer's shots he's shown me about what SMD does as it does LOD meshes, I'm still finding it hard to believe that the relatively low number of polygons added to the scene, when I have maybe 25-30K in units also running around, really made that big of a difference, but it certainly seems to matter a lot.

At any rate... to answer the original question: yes, polycounts matter. They just aren't the end-all here- there are a lot of different factors which add up in Spring game designs, and you should be careful to optimize stuff where you can. All of this stuff about LODs is, imo, pretty darn premature. I'm still not entirely convinced that anybody will want to use them to increase details at ... what... silly-level, screenshot-zoom? There's no point in having 10K, FPS models for anything else, frankly, and when you're farther away... there's a practical limit on how much won't just turn into noisy junk. Bumpmaps and other shaders are the way to go, because they'd add reasonably-low polycount per render pass, based on mip-level, but we don't have the Gadget to work with yet, Trepan's still working on it.