Well, from what Josh described in his dev blog, it will have to be implemented at the time the new engine for Sins 2 is created...

I guess we will keep waiting and I will keep track of Limit Theory's progress...

The title says it all.

[MOD] The Sins Optimization Project: Rebellion 1.1 (Updated 11/19/12)

I assume you have steam, so just log on and it'll update you to the current version automatically and it'll work for sure.

So, I was talking to IstakuMesk tonight, and he says he's dramatically increased performance by optimizing his particle effects, most interestingly by using animated textures to do the work several particles would have to do previously. With these optimizations he was able to add higher poly ships (and if you've seen his work in the model thread you know how crazy they can get), more weapon points, larger fleets and still have a better framerate than he did previously.

Granted, he mostly uses his own custom particle effects, so perhaps they were much more intensive than vanilla ones, but it seems pretty clear that there is some potentially huge performance increases if someone who knows what they're doing with particles can optimize them (and not just fixing their reference locations). It's a huge job, and sadly I am too ignorant of particles right now to do anything about it, but it might be something to think about.

Yeah I was talking to Krdax the other day about secret hush hush stuff, and he had the interesting claim that (at least on his system), animated textures were significantly increasing his ram hit. I think the thing to take away from that is that a good animated texture sheet needs to be, at minimum, around 1024x1024 if not larger. For some cluttered projects this may simply not be viable. I planned for this ahead of time.

I gut the base game's directory. Any meshes or textures I don't use that I can safely remove gets deleted. This should be standard practice for any mod riding the ram limit. It's easy to do for the end user, and can probably be automated in a .bat file. Alternatively, I think you could replace them with 0kb files in the mod, but I haven't tried it yet.

Retribution makes extensive use of unique textures (I have over 300 individual textures dedicated to particles alone) for particles. My textures are higher resolution, my ships are considerably higher poly, I use larger unit counts and have significantly more guns per ship than in Salvation. Yet I've managed to increase the project's performance to the point where I can run a four-way fleet fight on high (for the project) unit counts with fps significantly higher and more consistent than Salvation in a two-way fight on low unit counts. As anyone who saw the original project knows, my fps was shit in all but the smallest fights. When you finally see Retribution I don't think you will recognize sins except for the skybox. We'll see if I can keep the quality more consistent than the old project.

My small ships average 40k triangles. Polies haven't been relevant in major performance crunching in games for about a decade now (the vertex buffer was more or less the issue in wc3, for example). Control panel based forced AA murders sins performance, though. Keep that in mind. So does windowed.

Particles in sins will be your biggest cpu concern after pathing-related nonsense. I discovered this through rather extensive testing between Salvation's beginning and present day. I run a lot of tests. I'm a testing kind of guy. The one conclusion I made in regards to Salvation's particles when I began Retribution was that they were trash. Not just how they looked, but how they performed. Little did I realize just how bad they were.

Drag, size oscillator - stay away from these unless mandatory. Drag is kind of funky but it's also a cpu drag and I guarantee an animated texture will result in a superior effect. Size oscillator is something you should be a bit careful with. It's not bugged, like drag, but I used it extensively for the Undead in Salvation and it is in large part responsible for the UD slowdowns you see in Salvation. Krdax informed me that some modifiers actually leak memory. The only modifiers you generally need are Fade and Inflate, but color oscillator is handy too. All fine tuned animation should be done through crossblending and texture animations. I try to keep my actual systems very simple. Remember, all CPU activity is competing with each other, and particles are generally going to be CPU limited in sins.

Explosions are tough. I'm still working on mine. They're shaping up, but I don't like showing unfinished content publicly, so I won't. Take my word for it - Salvation's explosions sucked, Ret's are better but still got a ways to go. Those sparks in Salvation's explosions are particle murder. Drop the cluster texture, go for individuals (use the random sheet already in sins), and spawn only a handful. I don't let my explosions go over 60-70 particles peak and try to stick around 30 concurrent. Both peak and concurrent matter, of course. As a reference, a vanilla capital is something like 150 and one of the Bailknight capital is something absurd like 300. Managing these numbers isn't just about performance, it's about keeping particles from vanishing.

Trails. I use fake trails now. I absolutely despised those unavoidable gaps with my missile trails. Particle trails don't update fast enough for my long-ranged high-speed projectiles. Spamming particles and elongating them just doesn't work for me. So what I do is I have trails attached to the emitter but with reverse speeds, and live very shortly. All of the Anahn missiles ditched trails entirely, I just give them missile bodies with engine graphics now.

Bloom and additive blend very readily. Therefore, plan ahead and avoid spawning a lot of particles at once. Avoid noisy textures so they don't mesh with each other (or take advantage of that behavior).

My huge muzzle flashes for the Anahn rely on a set of animated textures, a flash, and sometimes a secondary flame or a set of bailknight-esque TEC sparks. For my average Anahn gun I try to stick to 4-6 particles peak for a muzzle flash. My most expensive muzzle flashes using a very nice fire sheet I ripped from Tera peak at around 15-20 for the most absolute expensive ones. My old Salvation muzzles often used up to 30-40 because I couldn't get a good fire stream with static textures without spawning a lot of them. They looked ugly as shit regardless. Absolutely do not spawn sparks, much less sparks with drag, on rapid fire guns like Bailknights does. They look a little silly, and they all add up with a lot of ships firing at once. If you need sparks, make a animated sheet. I've got a few I can share if you want but they aren't perfect for this purpose.

The most consistently expensive particle system in Salvation was, according to the Dev exe, the shells. Yes, the shells with only 2 particles. The thing was, with ships averaging 100 guns, firing in bursts of up to 12 every few seconds per gun, those shells added up. This is why my projectiles all move extremely fast (and not just because they fire slugs at 3/4 the speed of light in canon) - to reduce how many weapons are up at once. Minimum speed of 11000 or so for Anahn bullets. For the Xy and Undead, this is less necessary, because they have less guns. Thus, I can ration more particles to them. Old UD plasma torpedo - 200 particle uptime. New one - 15. Mostly because I gutted the trail and gave it a fake one and ditched the sparks.

No animated textures there, just a shockwave-esque texture with reverse inflation, a shitty looking flare I'll probably scrap or change, and the fake trail. The bloom handles my glow for such a small projectile.

The library of textures I've built up comes from dozens of games and many of them are either hand made or significantly edited to suit my purposes. I'm not an artist, but I do know how to make some custom fireballs in 3ds max. I just don't have the tools currently. I might make some of them public when the project is done, but I'd like to keep a few little secrets a surprise for the big show should it get finished.

^ Afterburn and FumeFX are the primary 3ds max plugins used to make animated sheets. Somewhere I think a commercial cd or set of cds exist of such texture sheets, but my belgian grips aren't limitless and I have yet to locate such a valuable resource. I did, however, use these to create sheets for Brood War. Here's a gif of one of them.

Significant problem, however - in my experience sins has a texture frame limit of around 20. Around this point the particles tend to flip out and roll over or just break and make strange squares. So, a good chunk of my resources don't work, and to make a high-detail set like that gif above would be a total waste. Therefore, a good particle system in sins would make use of several such texture sheets. The end result of a sheet looks a lot like this.

Keep in mind, that image above has some frame clipping. Don't be an intern. Fade those out if it happens - they look horrible.

Well, I don't like making big posts too often. My developer series will cover a good chunk of my testing, my analysis, my particle creation, and a whole lot of swearing, when it is public. Until then, I did post a small particle-related video in my Retribution thread if you want to learn more.

For the record, my environment (and conditions for my performance) are rather different from standard sins. I can't make any guarantees that employing a huge revision like what I do would have a similar return in vanilla. I can only say that it made an enormous difference in my own project under very heavily scrutinized tests.

Interesting indeed. Too bad i suck at particle forge. I do agree the vanilla particles are what take up the biggest chunk of the resources. We have huge textures in rebellion for some of them for example the Advent loyalist Titan uses 3 1024x1024 sheets just for its normal ring effect. Add 2 more sheets for it firing. I reduced those ridiculously large textures down to 512x512 for TSOP, and converted them to DDS. However seeing what you wrote about the particles themselves now things are making much more sense.

How much memory does a single combined sheet save vs the original configuration with multiple sheets? I wanted to combine the unit build, cursor over, pressed, and disabled sheets into one texture (very similar to what you did to the SoA 2 UI Fist0)

Stage 2 of Player_Portrait_1.xcf which will be DDS

Showing how to best fit multiple brushes into wasted space. This will allow the moving around of brushes on the other sheets to make room for other large brushes on wasteful sheets.

Black area is brush size, rust is unused and brush spacing

All the small brushes are from BackdropInGame.dds and the 3 large emblems are from BackdropFrontEnd.dds.

The goal now is to get rid of this POS sheet all together

OK, that POS Buttons_Backgrounds2.dds above is now gone 

Also fit the large Artifacts Research Backdrop on here and now have 1024X1024 empty space on Research.dds

Anyone care to comment why the hell the original BackdropInGame.dds is over 16 mb? That is the 4 planets worth of textures they got rid of.   Mine is 4 mb, and with the other sheets I got rid of I am heading over 20 mb which now I can start to replace the stuff they got rid of. 

Just wait till you see my ship textures critique. 

Well, I definitely would have shrunk the bumps 1st and da if necessary and left the cl if at all possible. 

And I don't have a clue what they used to shrink the texture, or no idea about the 1st bitmap but what they did is horrible IMHO.

And this is just a test, I would go 768x768 on all the frigates, 512 for fighters and 1024 for caps. Also, if I do shrink, I will keep the high def areas on another sheet to keep them nice, like on that compare areas bottom right details.

I am going to have to rebuild my entire game from scratch, and I am so disappointed I dont know if I am even going to share it. 

So if we leave the vanilla rebellion ship textures alone these UI changes will save a S**T Ton of memory, because we will be using fewer UI textures correct?

Something i noticed. The 1.5 patch changed the planets to spherical UV mapping (something ive been pushing for all this time, and did with limited success in early versions of TSOP). However they kept the same 2048 resolution. Effectively doubling the resolution of the planet textures without changing the memory usage. The original planet textures were 2048, but the original textures only used 1024 of space on the sheet. There is a huge amount of waste on those textures. So the original pre_1.5, and Trinity planets are actually 1024 in resolution.I can accept the 2048 resolution as long as "All" of the texture is being used.

Now if only they can do the same thing with the original Skybox textures. Which are also have a lot of "waste". The new rebellion skybox's are spherically mapped. IMO Stardock should replace all of the remaining original skybox's with new versions based on the originals, but spherically mapped like the other Rebellion skybox's. I tried to spherically map the original skybox's but the results were disastrous. Seams, and pole pinch was a huge issue.

Back to the Rebellion ship textures. "IF" i should decide to restore the Rebellion ships back to original Trinity resolutions. How would that impact the game? Other than Rebellion ships using the memory of Trinity ships. Also if it is decided to restore the Ships to Trinity standard. The camera zoom extents will have to be restored to trinity standard as well.

2,049 kb x 3 tga sheets = 6147 kb

768 x 768 dds = less then 1 mb 

When I hooked up the new brush links I found a load of empty space and used stuff

Not sure but I have a feeling that this is SD, trying to go by IC example and failing badly.

Button sheets, they make one, copy it and make grey scale, copy it again and make brighter for cursor over, copy again and move sheet down 1 px and right 1 px for push. All to save 30 mins of work.