High poly + low poly
Moderator: Moderators
-
FoeOfTheBee
- Posts: 557
- Joined: 12 May 2005, 18:26
High poly + low poly
How possible would it be to make a mod with high and low poly versions that would allow players with different versions to play with each other? What would you have to do to avoid errors when players have equivalent but not identical models?
What about fiddling with the unit LOD distance in the settings?
What about having the high poly version as LOD0 and the low poly as LOD1? And a checkbox in the settings for using low-poly models. It would load the lowpoly LOD1 models as LOD0 instead.
Of course, I don't know anything about Spring's LOD system so I'm just talking out of my ass here.
What about having the high poly version as LOD0 and the low poly as LOD1? And a checkbox in the settings for using low-poly models. It would load the lowpoly LOD1 models as LOD0 instead.
Of course, I don't know anything about Spring's LOD system so I'm just talking out of my ass here.
-
Warlord Zsinj
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
Most professionally-made games these days feature multiple LODs. Until LOD-on-the-fly becomes much more practical (nowadays, it's strictly a raytracer thing, much like many of the features we see now in games, like shaders) then it's going to be the best way to get really high performance out've things, but have them look gorgeous up close. The question, to my mind is... does the Spring LOD feature have anything to do with this? My guess is "no", and that the LODs are how many tris are used for terrain meshes only... it'd be nice to have at least two LODs per model, for professional-grade titles, but we can probably all live without.
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
OMG, you want me to make 2 of every model in my mod!?!?!no
The models range from ~400->~600 for the mechs in the mod with one unit being >1,200. Good enough for my crappy nvidia pci card, good enough for you
.Also, the OTA models which are featured in many mods are QUITE low poly. Although I personally would like it if we could specify one model for spring and another for OTA. As it stands we would need two seperate mods to do this.
I honestly do not think that the extra polys on many of the models will hurt. ESP considering other games that are out nowadays. Personally I think the way the models are textured in the OTA .3do format is HORRIBLE for memory. If we were able to have UVWmapped to override 3do in spring. Then I could UVWmapp the models in my mod and leave the 3do files in there saving me the time and frustration over having OTA and spring VERSIONS of the mod. Also this would allow an option to use the OTA model instead.
ALot of games are starting to utilise the LOD feature now, as a way to preserve performance by dropping poly counts of units viewed at a distance.
It would be a great idea for any game that uses distance scaling or is capable of using that Lod progression to actually utilise it.
Regardless of the initial poly count levels at LOD0, you can dramatically reduce the strain on a system such as Spring that deals with massive ammounts of units being rendered at one time on the screen.
The only reason not to do it is lack of time to pour into the development of the product, or just pure laziness.
The rewards in performance that can be saved or gained is worth the effort by at least 10 fold, not to mention the level of quality in the up close models can be up in excess of 1000 poly or more without consequence, as long as it steps down at a distance.
If there was an easier way to use the LOD feature in Spring, or a better Model format to use, there should be no reason not to put in the work.
I have done the LOD process myself while working at a mod for BattleField1942, and even now while working on a Halflife2 Mod team, and yes it can be alot of work but its well worth it and almost necessary with these newer high poly games.
Here is an example of a Prop I made for my Hl2 mod.
And all of these models share the same UVmapping and texture.
It would be a great idea for any game that uses distance scaling or is capable of using that Lod progression to actually utilise it.
Regardless of the initial poly count levels at LOD0, you can dramatically reduce the strain on a system such as Spring that deals with massive ammounts of units being rendered at one time on the screen.
The only reason not to do it is lack of time to pour into the development of the product, or just pure laziness.
The rewards in performance that can be saved or gained is worth the effort by at least 10 fold, not to mention the level of quality in the up close models can be up in excess of 1000 poly or more without consequence, as long as it steps down at a distance.
If there was an easier way to use the LOD feature in Spring, or a better Model format to use, there should be no reason not to put in the work.
I have done the LOD process myself while working at a mod for BattleField1942, and even now while working on a Halflife2 Mod team, and yes it can be alot of work but its well worth it and almost necessary with these newer high poly games.
Here is an example of a Prop I made for my Hl2 mod.
And all of these models share the same UVmapping and texture.
Last edited by MR.D on 20 Jan 2006, 21:32, edited 1 time in total.
When gnome proposed the different terrain different model code, he ahd implemented, I suggested ti be adapted for exactly this. But the SY's said that no mods had made high poly untis and there was no demand for it.
Currently spring will make models less detailed automatically, but from what i have sene ti is a 3 stage process, full detail, far away and very stripped down and ugly looking, or not shown at all.
Currently spring will make models less detailed automatically, but from what i have sene ti is a 3 stage process, full detail, far away and very stripped down and ugly looking, or not shown at all.
Switfspear, let's examine the facts though. TA has, by ANY standard, very very low polygon models. Agreed?
When I play Spring with shadows off, I get 300 FPS. When I play with shadows on, I get 30-40 depending on the zoom level. If there's any serious action going on, it's more like 20. This is with, at the very most, let's be outrageous and assume someone has gotten 300 units onscreen at one time. 300 units times 80 - no, no, wait, let's assume these are all bulldogs or, hell, krogoths for that matter. Let's say they have, on average, 150 faces. Anyone who's modded TA knows that this is quite high for an OTA model. For reference, look at this link which provides a fairly accurate guide: http://urc.tauniverse.com/info.htm
You'll notice that only extreme cases, like Krogoths, are the only unit which it would be considered to have 200 faces on, while the rest are more in the range of 75.
Now, back to my numbers. Let's assume that each of these 300 models has 150 faces. 45,000 quads being rendered, or 90,000 triangles if you prefer, and that's assuming that they are somehow unfolded and have every single face turned toward the camera (spring uses occlusion culling does it not?).0
What you propose, then, is to have a mod which... what, actually undercuts TA's average polygon count, so as to improve performance with shadows? Am I right on this? Even if the mod actually managed to have equal polygons per unit as TA, you are still looking at 30 frames per second at best, regardless of what's onscreen, and far far less if there's the promised hundreds of fighters on both sides. BUT WAIT! No, there's not just fighters, there's star destroyers, there's corellian corvettes, there's dreadnauts, there's interdictors, there's calamari cruisers. (boy, those things are just a massive curved surface. good luck making that 150 polygons) Are these ones going to be 150 faces too? No? Let's make an estimate. I'll randomly guess that a corellian corvette has 400 faces, and a star destroyer with any kind of detail whatsoever will be at least 600. Since when were star wars mods about fighter combat - which at best will deliver a random outcome in such numbers of combatants, even were things perfectly balanced? The mod will inevitably feature starships of all shapes and sizes, and I would guess that you'll have at least 10 involved in a decent sized fight.
So you intend to play at 10-20 frames per second. And how many fighters did you say were involved? Oh, well, that'll bring the framerate down to about 2-3 if you actually intend to move them at any time. Hmm... Interesting choice. But wait. Turn off shadows, and you've got 100-200 frames per second and a drop to the same postively abysmal 2-3 FPS when they try to move. Hmm... Something seems wrong here.
Since shadows are too inefficient to play with turned on in any budget, mainstream, or even mid-high-end computer, they should be removed from the equation. Now you've got hundreds, thousand of fighters and star destroyers and whatever else onscreen and a pretty damn good framerate to boot, since they're somehow each only 150 polygons. Try to move them. 2 frames per second. Ok, so excessively large number is out as well, especially in air units (just my experience there, other classes may also be very hard on the endine). So... what are we left with? In a best case scenario, you won't get shadows, and you won't get more than 300-400 units moving simultaneously without a noticable drop in performance. So, given that now shadows and excessive numbers are ruled out, what have we got to work with?
An ideal situation would see battles consisting of a maximum of 100 large units per side, plus 100 or so small ones. Pathfinding is getting a little chuggy, but we can bear through that, and besides, I bet you'll be down to half that number of units in no time. And what is our graphics card doing at this moment? Ah, it's twiddling its thumbs doing nothing at all. Why not give it a job? Like, for instance, high detail models and textures? Why, now we have the entire system cooperating - the CPU for AI and movement, the ram for textures, the GPU for the graphics. Equally distributed load, no bottlenecks, just a really kickass looking firefight.
100 big ships per side? That's more than can even be effectively managed in a combat situation. In other words, battles should ideally consist of far fewer units but there's plenty of processing room left over should a battle drag on and grow in size. So what do you get? You get G/E/M.
When I play Spring with shadows off, I get 300 FPS. When I play with shadows on, I get 30-40 depending on the zoom level. If there's any serious action going on, it's more like 20. This is with, at the very most, let's be outrageous and assume someone has gotten 300 units onscreen at one time. 300 units times 80 - no, no, wait, let's assume these are all bulldogs or, hell, krogoths for that matter. Let's say they have, on average, 150 faces. Anyone who's modded TA knows that this is quite high for an OTA model. For reference, look at this link which provides a fairly accurate guide: http://urc.tauniverse.com/info.htm
You'll notice that only extreme cases, like Krogoths, are the only unit which it would be considered to have 200 faces on, while the rest are more in the range of 75.
Now, back to my numbers. Let's assume that each of these 300 models has 150 faces. 45,000 quads being rendered, or 90,000 triangles if you prefer, and that's assuming that they are somehow unfolded and have every single face turned toward the camera (spring uses occlusion culling does it not?).0
What you propose, then, is to have a mod which... what, actually undercuts TA's average polygon count, so as to improve performance with shadows? Am I right on this? Even if the mod actually managed to have equal polygons per unit as TA, you are still looking at 30 frames per second at best, regardless of what's onscreen, and far far less if there's the promised hundreds of fighters on both sides. BUT WAIT! No, there's not just fighters, there's star destroyers, there's corellian corvettes, there's dreadnauts, there's interdictors, there's calamari cruisers. (boy, those things are just a massive curved surface. good luck making that 150 polygons) Are these ones going to be 150 faces too? No? Let's make an estimate. I'll randomly guess that a corellian corvette has 400 faces, and a star destroyer with any kind of detail whatsoever will be at least 600. Since when were star wars mods about fighter combat - which at best will deliver a random outcome in such numbers of combatants, even were things perfectly balanced? The mod will inevitably feature starships of all shapes and sizes, and I would guess that you'll have at least 10 involved in a decent sized fight.
So you intend to play at 10-20 frames per second. And how many fighters did you say were involved? Oh, well, that'll bring the framerate down to about 2-3 if you actually intend to move them at any time. Hmm... Interesting choice. But wait. Turn off shadows, and you've got 100-200 frames per second and a drop to the same postively abysmal 2-3 FPS when they try to move. Hmm... Something seems wrong here.
Since shadows are too inefficient to play with turned on in any budget, mainstream, or even mid-high-end computer, they should be removed from the equation. Now you've got hundreds, thousand of fighters and star destroyers and whatever else onscreen and a pretty damn good framerate to boot, since they're somehow each only 150 polygons. Try to move them. 2 frames per second. Ok, so excessively large number is out as well, especially in air units (just my experience there, other classes may also be very hard on the endine). So... what are we left with? In a best case scenario, you won't get shadows, and you won't get more than 300-400 units moving simultaneously without a noticable drop in performance. So, given that now shadows and excessive numbers are ruled out, what have we got to work with?
An ideal situation would see battles consisting of a maximum of 100 large units per side, plus 100 or so small ones. Pathfinding is getting a little chuggy, but we can bear through that, and besides, I bet you'll be down to half that number of units in no time. And what is our graphics card doing at this moment? Ah, it's twiddling its thumbs doing nothing at all. Why not give it a job? Like, for instance, high detail models and textures? Why, now we have the entire system cooperating - the CPU for AI and movement, the ram for textures, the GPU for the graphics. Equally distributed load, no bottlenecks, just a really kickass looking firefight.
100 big ships per side? That's more than can even be effectively managed in a combat situation. In other words, battles should ideally consist of far fewer units but there's plenty of processing room left over should a battle drag on and grow in size. So what do you get? You get G/E/M.
Last edited by Caydr on 20 Jan 2006, 21:18, edited 1 time in total.
L.O.D., is not new I know for a FACT that the had it back in '98.
Please resize that image, it is messing up the thread.
Also, the 3d0 format does not allow the usage of L.O.D., so even if I
wanted to I cannot. But as far as lazyness.. I think that is a bit wrong
also In a bf 1942 mod the vehicles and characters might be about
20-40... but in an RTS we have MANY MANY MODELS. I have currently,
82 units in my mod. I do not desire to build LOD for >82 models. ESP
when most of them are <500 polies. I do not believe the poly count is
what is hurting us.
lets assume EVERYTHING in the mod is 600 polies(because the models
have a middle range about there)
So, 500 units @ 600 polies each: 300,000 polies... with 3 teams.... 900,000
Anyway, modern video cards can EASILY handle this number. The main
slowdown as far as rendering is the shaddows, pathing and the MASSIVE
terrain map. I am sure the collision model is somwhere in there also.
So, even if we could I still do not think LOD is the answer. Also you have
to consider that again, my mod is one of the few mods with a heavy poly
count. I am sure SWTA has a moderately high poly count.
However, we do not have any really high poly counts...
In fact my game runs slower when I have 80 dominators firing
when compaired to 300 of my models. I really do no see the issue with
the poly count. Maybe in something like G.E.M. but at the moment we
really do not NEED L.O.D.
Also HL2 has a HUGE poly count on it's models as well but MOST spring
models are not NEAR that high a poly count.
Please resize that image, it is messing up the thread.
Also, the 3d0 format does not allow the usage of L.O.D., so even if I
wanted to I cannot. But as far as lazyness.. I think that is a bit wrong
also In a bf 1942 mod the vehicles and characters might be about
20-40... but in an RTS we have MANY MANY MODELS. I have currently,
82 units in my mod. I do not desire to build LOD for >82 models. ESP
when most of them are <500 polies. I do not believe the poly count is
what is hurting us.
lets assume EVERYTHING in the mod is 600 polies(because the models
have a middle range about there)
So, 500 units @ 600 polies each: 300,000 polies... with 3 teams.... 900,000
Anyway, modern video cards can EASILY handle this number. The main
slowdown as far as rendering is the shaddows, pathing and the MASSIVE
terrain map. I am sure the collision model is somwhere in there also.
So, even if we could I still do not think LOD is the answer. Also you have
to consider that again, my mod is one of the few mods with a heavy poly
count. I am sure SWTA has a moderately high poly count.
However, we do not have any really high poly counts...
In fact my game runs slower when I have 80 dominators firing
when compaired to 300 of my models. I really do no see the issue with
the poly count. Maybe in something like G.E.M. but at the moment we
really do not NEED L.O.D.
Also HL2 has a HUGE poly count on it's models as well but MOST spring
models are not NEAR that high a poly count.
Ok let's clear this up...
there is no lod on moving units, the difference in framerate caydr shows is probably caused by changing from a fillrate/pixel shader limited situation to a vertex/cpu limited situation.
shadows are so slow, because the algorithm requires that the scene is rendered from the light origin, and then from the actual camera position. I know how the algorithm works, but I'm guessing about how it is implemented in spring. It's probably a good guess though, because it explains the low framerate somewhat: 0 heavy cruisers in screen still requires 100 cruisers to actually be drawn in the shadow buffer.
there is no lod on moving units, the difference in framerate caydr shows is probably caused by changing from a fillrate/pixel shader limited situation to a vertex/cpu limited situation.
shadows are so slow, because the algorithm requires that the scene is rendered from the light origin, and then from the actual camera position. I know how the algorithm works, but I'm guessing about how it is implemented in spring. It's probably a good guess though, because it explains the low framerate somewhat: 0 heavy cruisers in screen still requires 100 cruisers to actually be drawn in the shadow buffer.
Uhhm... hm. I guess I drew too many conclusions, but I thought I heard spring automatically made LoDs during the s3o conversion. Guess I was wrong. It kind of made sense since when soomed right in on my ship I'd have 65 FPS, and the farther I zoomed out the faster it got.
I've got a 3ghz intel, underclocked to 2.8ish. Also a radeon 9800 pro and a gig of ram.
I've got a 3ghz intel, underclocked to 2.8ish. Also a radeon 9800 pro and a gig of ram.
Adding in LOD progression into Spring could really add some visually impressive units in instead of just being forced to low poly though, that was the point in my post.
In that way you're not limited to creating simple 1000 poly or less units, you can create those high quality objects and not sacrifice performance because it will be scaling those models down VIA code that allows it.
Caydr has just proven that Polycounts aren't a huge issue, but when all the other effects are added in even over the simple units it causes massive strain.
Creating a better model subsystem could open the whold mod community up to alot more creativity and visual artistry.
It wouldn't need to be a crazy system to introduce some nice features like LOD/shadow/collision geometry.
A better animation system wouldn't hurt either..
In that way you're not limited to creating simple 1000 poly or less units, you can create those high quality objects and not sacrifice performance because it will be scaling those models down VIA code that allows it.
Caydr has just proven that Polycounts aren't a huge issue, but when all the other effects are added in even over the simple units it causes massive strain.
Creating a better model subsystem could open the whold mod community up to alot more creativity and visual artistry.
It wouldn't need to be a crazy system to introduce some nice features like LOD/shadow/collision geometry.
A better animation system wouldn't hurt either..
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Shadows lag me way more in AA then they do in XTA. It's a differance of nearly 30 FPS. The only massively notable differance is the high poly models used in AA... it makes sense in retrospective that spring isn't properly rendering off screen models with shadows on, because large games will dip to 5 FPS or less and get worse and worse as time goes on. With shadows off my CPU easily eats large game action with no relevent FPS loss.
[edit] LODs would massively improve preformance from my experiance of how well shadows handle high poly units in spring.
[edit] LODs would massively improve preformance from my experiance of how well shadows handle high poly units in spring.
An Updated Model Format, would be a pain initially for all teams I'm sure..
but you have to set a standard eventually, and using
LOD/Shadow/Collision Meshes instead of live shadow Raytracing and speherical collision boxes could be soooo much better not only for performance but game physics and quality.
but you have to set a standard eventually, and using
LOD/Shadow/Collision Meshes instead of live shadow Raytracing and speherical collision boxes could be soooo much better not only for performance but game physics and quality.