REBELLION POLY COUNTS

We already know the counts for the Trinity models. We just need counts for the new Rebellion meshes. Fear not. There will be a TSOP for Rebellion.

Oh cool.

I was thinking for Rebellion and people that are making their "dream mods" with full blown models and factions having a cheat sheet would be good so they realize in design how much they are pushing things in the model mesh and texture departments.

Obviously the lower the poly count of your models the better, but not so ridiculously low that they look boxy, and stupid in game. A good modeler can make a mesh as detailed as possible with the lowest poly count possible. You dont need a 10,000 triangle model when 2000 triangles along with good texturing, and bump mapping will look exactly the same (or in some cases BETTER) in game. Use the LOWEST poly count possible to portray your art.

You will also have to take into consideration how many of your models will be on the map at the same time. If only a few will be on the map you have more room to play with poly wise. On the other hand if thousands of models will be on the map then you need to budget the polys accordingly.

Strike Craft should not be higher than about 700 triangles. Trinity strike craft vary between 500 to 700 tri's

Frigates in Trinity average 1500-2500 triangles. Though again in Trinity there are some frigates in the 3000's. The vasari trade ship is in the 3000's. Which is why we reduced the poly count for trade ships, and constructors in TSOP. 3000 is TOO HIGH for a non combat NPC that spawns in the hundreds.

Trinity Cap ships average between 3000-5000 tri's (trinity meshes). Which is reasonable considering there is a limit to how many cap ships there are in game. I am assuming that the new Rebellion cap ships are similar in poly counts.

The highest poly count ive seen for a Structure is 7000 tri's (tec hangar defense). Considering how the AI spams structures i would go MUCH lower if possible.

10000 for super units like starbases, and novaliths. A fully upgraded Advent starbase is over 13,000 tri's. Again i would go much lower if possible, because of the AI spam.

The Titans i have no clue of their poly counts yet. But from what i see in game the number looks big.

Corvettes i would say dont go higher than 1500, but i dont know the actual corvette poly count yet.

I will have to re-import every mesh into 3dsmax again to get an accurate count. TBH i dont want to do that.

I think modders should focus way more on texture optimization than polygon counts when it comes to memory consumption - for example, due to the organic look of my models they have a consistently high polygon count (between 10 and 20 000 tris), but the mesh file increase is negligible (in text format it comes to about 4Mb per model, 1Mb per model in binary) compared to the amount of memory that can be saved by optimizing textures so that they are of the lowest resulution possible while still maintaining a quality look. A single set of 2048x2048 textures will cost you 15Mb of memory, while that same texture set reduced to 1024x1024 resolution will drop the memory requirement to only 3.9Mb! 

Considering that modern systems will rarely have an issue with a shitload of polygons on screen, I'd say that a good UV space optimization + texture optimization is the single most important thing to consider when making new assets. Polygon reduction is secondary - good if you can pull it off, but I wouldn't fret too much about it as long as you don't go overboard on every single model.

There is also the overall fleet cap on all ships in the game, so if a modder needs to use high polygon models, they can then work around any possible issues by designing the faction so that it uses more powerful but less numerous fleets. From the memory requirements issue it makes no difference, but might help keep the framerate steady on older systems.

That is true. Textures play a much bigger role in game performance than meshes do. I try not to use anything higher than 1024x1024 if i can. Obviously there will be exceptions for cap ships, and super units. Units that need a higher resolution. However for units that will be on the map in the thousands the same rule of thumb is true. Less is More. I can live with a little loss of quality for increased game performance. As long as that loss isn't an eyesore.

Basically i study the mesh, and texture of the Vanilla Sins ship that i am replacing. Then i try to go equal to, or go less than the poly count of the vanilla mesh with my model. Then i use the same size texture that was on the Vanilla model. If i can get away with a lower resolution i will do it. As long as it don't look like crap in game. I usually experiment with different resolutions until i find the best in both performance, and quality. Still i will not go over the resolution of the vanilla sins ship i replaced.

I'm just curious, but will reducing polycounts/texture size be as effective this time around? Before with the 2GB limit issue yeah it worked great, even on a 10 player huge map with maxed fleets I rarely see it much above 1.5 GB. Its the CPU that gets maxed out that kills the frame rate and makes it unplayable now. When I reduced most of my settings to try and fix the lag my RAM usage actually went down to 800 MB but didn't do squat to help the frame rate.

Granted with large mods the 2GB limit might still be an issue, so if that's why you're doing these things I see, but it still doesn't seem as bad as early diplomacy was.

Sins was made for a Single Core system running 32 bit windows XP. That is why we are having so many problems now. Our hardware out grew the game.

CPU usage will always be a problem for Sins. While lower poly counts are always good thing. We dont want to make models so ridiculously low that they look stupid in game. Same can be said for Textures. The lower the resolution the better, but not so low that everything looks like a pixilated game from the 90's.

CPU has to deal with meshes, and textures, but its your graphics card that handles the brunt of that. Everything in sins is loaded into memory for instant access. Which is why we see sins using 1.8+ gigs on max settings. Which is also one of the reasons why we have the 32bit 2 gig issue. CPU deals with everything that is on the map. Ships Stuctures, NPC's (trade/refinery ships) Strike Craft, Planets, Roids, Etc. Etc. It has to deal with AI. It has to deal with every units movement. On top of that it has to deal with all the weapon calculations, buff, debuffs, and all the particle effects. Just because we zoom out to galaxy view that does not mean anything. Everything is still happening as if you were zoomed up close. Its all happening with just ONE core of your CPU. Unfortunately the Dev's said that will never change. So modders must plan accordingly.

Yeah, unfortunately, that was a bit of a bad design decision. If the player doesn't see it, it doesn't have to be as detailed. But, no point lamenting that.

Using a Large Address Aware patch on the executable can help with memory - in fact I've been using it for a long time. But I'd rather avoid having to ask players to patch their game with third party tools just so they can play my mod. Which is why this talk about Rebellion maxing out the engine on its own is worrying me - I'd love to have Invasion run with Rebellion.

Yes, I understand. I was just wondering if RAM really is still the main enemy here, because on my system I'm not having a whole lot of trouble with it. CPU is the main issue as far as I'm concerned, and I was under the impression that all you can really do is have less stuff in the game. And short of reducing mine/fighter/trade ship numbers, I didn't think there is a lot of things we could do to help without hurting gameplay.

By all means smaller textures/meshes are a good thing, I'm just wondering if it will really have a noticeable impact on CPU usage?

A lot of things have a pretty significant impact on sins CPU, including particles using things like force effects and the aforementioned mines/fighters. In Black Sun I made a major effort to isolate and find cpu bottlenecks, and ultimately I ended up massively revising a ton of particles, accelerating all weapons, etc.

I netted back quite a lot of performance in doing this, and RAM was certainly never an issue in Black Sun, as I had gutted the game's textures and at some points the project was down to 500-600mb usage despite many models averaging 10mb+ a piece, all particles having unique textures, and nothing being converted to .bin. Granted, I can't exactly convert Black Sun to rebellion as I have no idea how I'd even approach that, so the performance may be different, but in a single-threaded game everything is your enemy. Particles being calculated outside of the culling range and stuff all contribute.

Yeah---intended for textures to be an assumed part of the equation there.

I think even having a game total--sound, meshes, textures, etc. in each category would be enough of a guideline.  It's primarily a problem for the epic and bells & whistles type mods.

Just thinking along the lines of, "Oops--I have added a LOT of stuff--better cut back".

Ram is not the "true enemy" of modding sins. Despite the 2 gig brick wall. Which we can find ways to work around. CPU, or lack of it is the real enemy. Also lack of cpu, and ram "speed" plays a part in it too.

Design around that. Sins engine is quite robust when it comes to the amount of stuff on and off screen, so as I said - if you have complex high-poly meshes, design your faction with fewer deployable ships (higher fleet supply cost).

So basically if your models average 2x vanilla poly count, design your faction so that it can deploy only half the total ships a vanilla faction can and make them 2x more powerful. Problem solved, at least as far as your framerate/polygon count is concerned.

I chose the Iron Engine to mod, because it CAN handle higher than normal poly counts for an RTS. Without the need for making LOD meshes. Which the engine doesnt use. Like Manshooter said the meshes themselves aren't really an issue as long as you don't go overboard. Its the Textures you have to be careful with.

That's actually a great design point and exactly the sort of thing I was hoping to see conveyed.

Great feedback here guys.  My hope is that we'll hook some new modders into Sins.