Tree mod that improves FPS?

Hi
as trees seem to impact the FPS a lot, is there a mod that improves the FPS while still maintaining a good look and a plentiful depiction of trees?

I don't know of any mods that actually improve fps, but there are some tree settings in the config menu that you could play with (you've probably tried this, but I thought I'd mention it).
Also, if you hit the 'T' key that takes away some of the trees/terrain detail in incremental stages which improves fps.

Sorry, I guess you have to pay for more detail in fps terms, and it's not always an option to splash out on expensive computer upgrades!

David(jolly)

I guess it could be modded in some way - a lot of work involved though!

Hi all.
Lowering the density (directly from BMP maps?) while grouping several trees together, could maybe benefit the framerate a little bit?
In the case of woods and forests at least, you may gain some speed and keep the visual appearance acceptably consistent...
Don't know if it'd work equally well with isolated ones.
And interpenetrations of large "clumps" would need further tests for sure.
The count of sprite instances rendered looks to me like the single major performance factor when it comes to trees here.
Not textures detail per-se, imho.
If anybody will ever try this, I'd be glad to profile the results.
Best regards and thanks as usual for the hard work.

I don't think that the trees are the real problem, as I am only seeing a gain of two-FPS with the trees removed.

Now, if I removed the trees, and all of the fields of crops the gain is plus twenty, but this gain will drop as soon as both armies start moving.

The biggest impact on FPS is the road-calculations, and then the LOS calculations.

My Opinion Only!

I also agree with "r59" combining the trees into a single texture doesn't seem to affect the FPS. So, instead of showing one tree, you could use two trees per sprite. I don't think that it changes the file size either.

The Simple Fix : Change the "D - Column" in the mapname.csv - to a higher number, since this affects the density of the trees that will appear on the map.

davinci

We cannot expect big gains by tweaking just vegetation files, unluckily.
I'd also say +5fps, at best?
The translucent quads sorting occuring under the hoods (on CPU) is also a limiting factor, performance-wise.
Maybe with ATOC (order-independent transparency) things would improve slightly, but who knows.
The real "meat" of graphical state changes comes from units sprites, however.
Giant numbers involved there. Whether it be good or evil (the first I think ).
And also tempting paybacks by managing (even minimally) redundant situations, on paper...
There exists well-known solutions for these problems: sorting by state-keys in queues, batching, etc.
Improving pathfinding and LOS, on the other hand, is a more time consuming affair, normally.
Because recognizing the bottlenecks and planning workarounds, require a broader understanding of game-specific problems.
Both plates are a bit too much overweighted right now, imho.
And everything coming mostly at the expense of CPU cycles (GPU seldomly works).
It's easiness of solutions that are different, though, as said above.
Many oldies (wargamers, history enthusiasts, etc.) won't be able to play SOW decently with their even older rigs.
This is the only clear fact!
I've said countless times to my dad (and friends) he doesn't know what he's missing.

Thanks for the feedback.
Makes me wonder what system one should have to have all the eye candy and still good FPS.
My graphic card is surely outdated and if the prices wouldn't have run that silly in the past 15 months I likely would have upgraded long ago, my CPU(Ivy 3570) seems still good just like 8GB of RAM still look good enough for almost everything.

r59 wrote: Improving pathfinding and LOS, on the other hand, is a more time consuming affair, normally.
Because recognizing the bottlenecks and planning workarounds, require a broader understanding of game-specific problems.

I don't think that this is possible with SOWGB - this is "Hard-Coding" into the game.

The Previous Game of TC2M used a different type of path-finding, the units marching would stay completely on the roads, even if the roads turned.

This game doesn't do that, the code was changed to increase the FPS which causes the units to swing wide leaving the road-system.

Now the Flag-bearer and the units closer to him will stay on the road, but the end of the columns will serve off of the road on curves.

This Game is all about "Giving and Taking" and for the most part it works alright.

I doubt that a Mod will work since everybody has a different configuration such as CPU, GPU, Memory, etc...

So, the best way around this is to increase the number in the "D-Column" in the Mapname.csv file.

Now, adding more than one tree to a Sprite will work at times, but the downside to that is that this will draw trees where you don't won't them, such as on roads and such!

davinci

I remembered about this thread lately, while coding my little replacement for the game "shrubbery" renderer (supporting 1 frame x 1 angle only atm).
It's still very far from optimal and it'd absolutely require a bit of photoshopping to keep the current high quality standards... which I cannot afford right now, unfortunately.
Just to name a few criticalities, I had to decompress to TGA and compress back to build the mipmapped DDS texture atlas.
I didn't add proper padding at edges to avoid bleeding artifacts either.
The grass texture you'll see in foreground in my screenshots is especially bad and problematic, having basically no solid areas. That will cause sorting issues with units. So it's advisable to replace that with several smaller (and possibly almost spherical) clumps, translucent just at contours and providing a good solid mask to assure depth writing/sorting.
But the list goes on...
In all cases, even this brute force approach shows evident speed gains.
It basically involves one texture atlas and two draw calls in total, one for the alpha test rendering pass first, and only then blending (ZWrite off) to sharpen the edges.


There's one "giant" static vertex buffer and a smaller dynamic index buffer (staged/no_overwrite locking technique, but uses 32-bit indices instead of the common 16-bits, though).
The visible subset is streamed in after SIMD-accelerated sphere frustum culling performed at the original shrubbery grid level (16x16 tiles, each one extending 16384 map units). Testing each quad doesn't make a lot of sense in this case imho. Testing only chunks is much cheaper overally.
Notice that there's no maximum drawing distance and fading implemented yet.
So waaay more billboards showing up compared to any vanilla scene (look at the horizon)...
i.imgur.com/BAf8P0t.jpg (original, steady 15fps)
i.imgur.com/zwa8LWM.jpg (patched, steady 29fps)
The count of draw calls in the histogram "slightly" diverging from the order of magnitude we got used to (tens of thousands)...
i.imgur.com/SoyeLlc.jpg (original)
i.imgur.com/vB0mJcb.jpg (patched)
Both taken from a debug build of the DLL.
The second one is also outdated and instrumented by NVidia Nsight, so FPS are certainly underestimated.
My video card is a rather old GTX770 (released on May 2013).
With some FXAA added from the NVidia Driver Panel, I think I'll be happy with the results for next 24 hours.
Seriously, it's just a base from which to start.
That’s all for now.
Bye everyone.

r59 wrote: It's still very far from optimal and it'd absolutely require a bit of "PhotoShop" to keep the current high quality standards... which I cannot afford right now, unfortunately.

I came across something on the Internet or YouTube that will allow you to use Photoshop on a "Trial Basic" but I think that it said that you have to renew the Trial every 7 days.

But, it did claim to be "Free".

You can probably do a Google Search for it....I think that it was "PhotoShop 7"

davinci

Hi Dav!
I explained me badly. Sorry for that.
It's not the editing software per-se my problem.
I meant to say I had no time to do the necessary "homeworks" so far in order to preserve the expected textures visual quality.
Too much work for my poor skills, too little fun.
But I'm confident somebody will come to the rescue, at some point.

I'm going to c.c. a PM reply to MTG that details a little more the nature of one problem originating from my "faults".

As I wrote yesterday on the NSD forum, the "shrubbery" rendering is now reduced to 1 big draw call x 2 passes (all quads are drawn twice).
During the first pass, any billboard texture's alpha channel is interpreted as a "cutout".
It makes or it doesn't make contribution to the screen buffer. There's no in-between.
Below a given alpha threshould (I'm probably going to define the value on a mapname.ini file basis, now it's shared), the pixel is discarded.
Otherwise, if the test is passed, the color data is written, and the depth value of the quad in the scene as well in the corresponding depth buffer.
The second pass draws exactly the same quads (at exactly the same position, not even slightly closer) then.
All the depth values written in the previous step, will now allow rejecting "duplicates" fairly early in the rendering process. Which a good thing, performance-wise.
During this step, depth values are not updated anymore (and this helps too).
Now, the problem with that grass texture used in the Richwol map, is it requires a very low cutoff threshold to make a significant contribution for the first rendering stage.
With a rather typical 0.75 value (expressed in normalized 0-1 range, not 0-255), it draws just a few a couple spikes per billboard!
You can see that well in the 1st wireframed screenshot.
The units rendering code is not unified with my shrubbery display system at the moment.
They will get their chance to draw always AFTER mine.
And even with several of such grass quads in front of camera, you are likely going to see units through them.
Which looks totally unnatural, of course.
I can surely lower the cutoff value a bit.
Here's a screenshot with it set to 0.55. It's enough to make the officer appearing behind.

However, you see it, the edges there will become much less smoothed becase the 2nd alpha-blended pass will make a marginal contribution.
So, to a large extent, it's a matter of trading-off the two things.
But now you should be able to appreciate that, providing smaller grass billboards (densifying from the csv's terrain table brush at the same time), textured with a more solid alpha coverage and translucency limited to edges, would certainly help a bit here too.

P.S. This afternoon I switched from axis-aligned billboards to viewplane-aligned billboards.
See www.ssucet.org/~jhudson/15/2802/billboards/#slide-11
See www.ssucet.org/~jhudson/15/2802/billboards/#slide-12
This is more consistent with the original implementation.
Otherwise you'd see stonewalls "warping" badly when moving very closely and changing suddely the relative angle to them.

I'm almost done with this...
It's not as elegant as the solutions I had originally thought, but it does the job.
I might even release it right now, if nobody has anything to object, of course.
But I'd prefer getting some help to build slightly better grass textures (and atlas packing) for this Richwol Map test scene, first.
So we could get rid of those annoying artifacts at billboard bounds and raise a bit the AlphaCutoff threshold (now defined in mapname.ini) to sharpen the edges.
It's better to reserve transparency to anti-aliasing now...

In the coming weeks/months, I'd also like to put some energy and spare time to overcome the other monstrous and non-bypassable climb (units sprites) on this bumpy road to the promised land where good performances reign supreme over endless and thick meadows. Who cares about blood.

Poetic moment, but it's post-processing effects fault.
Reshade looks like a possible way to spend those extra milliseconds, by the way.


Ciao.