I'm curious, suppose I had a model which was too high of a polygon count (this is hypothedical! ) and I wanted to offset that by reducing the texture size.
No, I'm not talking about any model you've seen from me yet, they all work fine...
Anyway, I've got this unit that's 950 polygons, I was really shooting for something more like 500-700, but the source material it came from was a very detailed model and I didn't want to wreck it too much. Could I make up for this by reducing the texture size from 512 or so to 256? Which is more demanding on the engine, a high resolution texture or a high polygon model?
The thing is... Todays graphics cards can handle alot of pollygons. I mean... loads. Millions. I'm sure we worked it all out somewear that its CPU pathfinding thats laggingh the game not the moddels. Was it SJ that said he was thinking 1000 polly moddels would be fine for lvl 2 units? Or somthing like that. And you can see alot of units in Spring... just as many as you'd have ships im sure, and I take it this is a kickarss ship you doing that you wont have billions of anyway. (space station maybe? who knows, i love you space stuff...) Anyway, on teh otehr hjand not everyone has lots of graphics ram. Some people may only have 64meg!!
So I'd say, better models and lower teh texture, rather than teh otehr way around.
its the particle effects, the smoke particularly that does it for my FX5200, however our family PC now has a freaking awesome card which i will probs steal! w00t!
My models tend to be about 1000 polygons on average, but this is in a mod where battles won't consist of hundreds of such units. Probably. All my fighter textures are 512x512 DDSs, which I hear is easier on the ram. Larger ships are 1024x1024, and a couple will be 2048x2048... they'll be the exception, not the rule though. I'm also experimenting with reducing texture size to 256x256 and seeing if I can get by with those.
However, in any case, G/E/M is not going to be a small mod by any means. I'm estimating a download of, at the very least, 50 megabytes. However, with some patching routines I've learned about, people should only have to download such large files rarely.
Caydr wrote:However, with some patching routines I've learned about, people should only have to download such large files rarely.
yay!
*Celebrates Caydr*
And about the number of polys in a model, i recall some developer saying 3k as a fair number. Correct me plz if im wrong (and you can find the link hehe)
As a matter of principle I would say that you should always aim for under 750 polies on a unit for TAS no matter what. Units that you will commonly have more then 10 of in the same screen at once should generally be under 300. Spring generally isn't known for it's poly count issues because TA modelers were always very stingy on thier modeling counts. But I guarentee you if you try to push the limits they will bite you back.
Always do all the tricks to help keep your poliage down, you should never skimp on deleting unused faces or minimizing facecounts on shperical or round objects. But at the same time don't sacrifice quality for polycount unless you are really pushing what looks like the technical limits.
Just remember that Quake 3 models generally were around 1000 polys iirc. Now, on the one hand, we're talking way, way more models onscreen than Quake3, but on the other hand, Quake 3 was a long time ago.
Masse wrote:well some quake 3 models were 3000 polys... but u could run quake 3 with any computer anyway
You would only have 1 of those on screen at any given time though...
Most computers can easily run about 100 thou polies on screen with well written rendering engines. It's acctually partical effects, lighting, and other rendering teqniques that really suck up FPS.
I've had six hundred 1000-triangle G/E/M fighters onscreen at one time Only problem comes when they try to pathfind.
So as a lower limit, we can assume that Spring can handle:
600x1000= 600,000 triangles onscreen at one time without massive slowdown, on my computer which is by any modern terms, ancient.
Each of those units has a 512x512 texture, and there were 6 different textures in all. Make of that what you will... I'm not sure how this sort of thing is worked out. Maybe since there were just 6 textures, no problem.
Note though, that this was with shadows DISABLED. With shadows ENABLED, I can't get even 100 fighters onscreen without a very noticable decrease in performance. I'd say that's a result of hastily-implemented lighting - after all, if you remember back to pre-0.4, it was only a week or so that shadows were worked on apparently. Any work that complex which was done in a week must be able to be optimized quite a bit, I imagine.
This issue, of course, isn't isolated to GEM. I get 300+ frames per second with shadows off just looking at a bare map with no units. With shadows on, I get about 35 FPS. That's nearly 9/10ths of my GPU power being dedicated solely to processing lighting.
Actully, if i recall, shadows are all down to teh graphics card. Newer cards have sprcial build in rutines taht handle shadows that spring taps into, but if you dont have a crad of such, it realy hits performance. I THINK anyway, i cant definatly remember...
Masse wrote:well some quake 3 models were 3000 polys... but u could run quake 3 with any computer anyway
1. Quake is FPS and FPS dont show as many object as RTS per time. Example of how RTS could be heavy, you can play blitzkrieg. THe developer limit it to 600 triangle (comparable to 300 quad) in most lv1 unit
2. when u says 'polys' please be specific if it triangle or quad as the math is different
heh... i was just correcting the 1000 polys thing that was said
but caydr seems to know somewhat how many polys spring (his comp) can handle... and its seems to be allot
) and I wanted to offset that by reducing the texture size.
