Tree mod that improves FPS?

[r59]

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)...
https://i.imgur.com/BAf8P0t.jpg (original, steady 15fps)
https://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)...
https://i.imgur.com/SoyeLlc.jpg (original)
https://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.

[Davinci]

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

[r59]

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. :whistle:

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 https://www.ssucet.org/~jhudson/15/2802 ... /#slide-11
See https://www.ssucet.org/~jhudson/15/2802 ... /#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.

[con20or]

In all cases, even this brute force approach shows evident speed gains.

Sounds great to me - following this thread with interest.

[r59]

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.