Board index FlightGear Development Effects and shaders

Volumetric grass (was 3D textures and volumetric data)

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: Volumetric grass (was 3D textures and volumetric data)

Postby Thorsten » Tue Sep 12, 2017 6:36 pm

Okay, after trying to digest the explanations and sleeping over it:

There seems to be no clean solution as geometry shaders aren't natively part of #120, they're enabled as extensions which makes their use a bit hacky in the first place.

So we have two solutions it seems

1) dumb down the shader to cope with varying instead of flat (Emilian seems to prefer that)

This will almost certainly make performance worse - the crucial question is by how much? If we lose 2-3 fps under nvidia but make it work fine on radeon, we all win. If we lose 10+ fps on nvidia, we make it theoretically good, but it won't be useful by anyone, so an nvidia-only feature is preferable.

2) Try to trick our way through, relying on the goodwill of the drivers

It seems to be the case that Richard can run it, so we just need to find a way to make it run on both nvidia and radeon (I won't break any sweat over intels at this point, as it's going to be likely unusable slow anyway).

I lack the data to decide what's the better option - Richard, I'd need to know the framerate hit you experience for this? Also, assuming we'd declare it #130 (I seem to remember nvidia usually plays along) - does it run on radeon?
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Volumetric grass (was 3D textures and volumetric data)

Postby icecode » Tue Sep 12, 2017 6:48 pm

This will almost certainly make performance worse - the crucial question is by how much?


Not by much, but we are gonna be passing another variable to the fragment shader. You remember that we tried to send as few variables as possible to the fragment shader to have more layers available. I can't try the code right now to see how much of a reduction we're talking about, but I suppose it won't be critical. In my opinion we should just change it to varying float and save ourselves the headaches.
icecode
 
Posts: 708
Joined: Thu Aug 12, 2010 1:17 pm
Location: Spain
Version: next
OS: Fedora

Re: Volumetric grass (was 3D textures and volumetric data)

Postby Thorsten » Tue Sep 12, 2017 6:51 pm

Well, we can do the number of layers from the distance by doing the same calculation that is done by the geo shader in the fragment shader as well - in a way we're passing redundant information.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Volumetric grass (was 3D textures and volumetric data)

Postby icecode » Tue Sep 12, 2017 6:55 pm

I think that would definitely decrease performance noticeably, you'd be doing the LOD per-fragment instead of per-triangle. Not even per-triangle, but per "original" triangle, i.e. without accounting for the extruded ones.
icecode
 
Posts: 708
Joined: Thu Aug 12, 2010 1:17 pm
Location: Spain
Version: next
OS: Fedora

Re: Volumetric grass (was 3D textures and volumetric data)

Postby icecode » Tue Sep 12, 2017 7:01 pm

Well, good news is that after looking at the code upstream I don't see g_num_layers being used anywhere :mrgreen: I was using that to change the grass color, so it wouldn't look bad at large distances, but you probably removed it since you didn't need it for the "aggressive alpha" method.
icecode
 
Posts: 708
Joined: Thu Aug 12, 2010 1:17 pm
Location: Spain
Version: next
OS: Fedora

Re: Volumetric grass (was 3D textures and volumetric data)

Postby Thorsten » Tue Sep 12, 2017 7:24 pm

Ah - that would make things easier...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Volumetric grass (was 3D textures and volumetric data)

Postby Richard » Tue Sep 12, 2017 10:37 pm

Thorsten wrote in Tue Sep 12, 2017 6:36 pm:It seems to be the case that Richard can run it, so we just need to find a way to make it run on both nvidia and radeon
Richard, I'd need to know the framerate hit you experience for this?

Also, assuming we'd declare it #130 (I seem to remember nvidia usually plays along) - does it run on radeon?


if I add a #version 130

it complains like this:
Code: Select all
FRAGMENT glCompileShader "e:/temp/fgdata/Shaders/grass-ALS.frag" FAILED

FRAGMENT Shader "e:/temp/fgdata/Shaders/grass-ALS.frag" infolog:
Fragment shader failed to compile with the following errors:
WARNING: 0:32: deprecated130(#55) "varing" is deprecated since GLSL1.3. We suggest usage of "in/out"
ERROR: 0:32: error(#138) "varying in" supported in geometry shaders only
WARNING: 0:33: deprecated130(#55) "varing" is deprecated since GLSL1.3. We suggest usage of "in/out"
ERROR: 0:33: error(#138) "varying in" supported in geometry shaders only
ERROR: 0:37: error(#110) Invalid Directive: varying
ERROR: 0:38: error(#110) Invalid Directive: varying
ERROR: 0:39: error(#110) Invalid Directive: varying
ERROR: 0:40: error(#110) Invalid Directive: varying
ERROR: error(#273) 6 compilation errors.  No code generated


so taking the advice if I change to

Code: Select all
in vec2 g_rawpos;                  // Horizontal position in model space
in float g_distance_to_eye;        // Distance to the camera. Layers were disregarded


It works fine. I'm not seeing anything much in terms of frame rate drop turning the overlay shader on off with the version above, or with the original #120 mods.

Half of this was rendered with the overlay shader on, the rest without. See if you can tell when I changed it (I know I can't tell)

Image

So either of the two changes work fine.

Code: Select all
#120
varying vec2 g_rawpos;                  // Horizontal position in model space
varying float g_distance_to_eye;        // Distance to the camera. Layers were disregarded
varying float g_layer;                   // The layer where the fragment lives (0-1 range)
varying flat int g_num_layers;

#130
in vec2 g_rawpos;                  // Horizontal position in model space
in float g_distance_to_eye;        // Distance to the camera. Layers were disregarded
flat in float g_layer;                   // The layer where the fragment lives (0-1 range)
flat in int g_num_layers;
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Volumetric grass (was 3D textures and volumetric data)

Postby Thorsten » Wed Sep 13, 2017 5:46 am

I guess we just go with the #120 version and kick the flat int - I've checked that changing varying in -> varying works for me, so we ought to be fine.

Thanks for testing!
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Volumetric grass (was 3D textures and volumetric data)

Postby Richard » Mon Sep 18, 2017 7:14 am

Unfortunately the version committed to FGData doesn't work. The version below does work.
Code: Select all
--- a/Shaders/grass-ALS.frag
+++ b/Shaders/grass-ALS.frag
@@ -29,9 +29,10 @@
 
 uniform float osg_SimulationTime;
 
-varying in vec2 g_rawpos;                  // Horizontal position in model space
-varying in float g_distance_to_eye;        // Distance to the camera. Layers were disregarded
-flat in float g_layer;                   // The layer where the fragment lives (0-1 range)
+varying vec2 g_rawpos;                  // Horizontal position in model space
+varying float g_distance_to_eye;        // Distance to the camera. Layers were disregarded
+varying flat float g_layer;                   // The layer where the fragment lives (0-1 range)
+
 


Can you try it on nVidia - it's pushed to my clone of fgdata: https://sourceforge.net/u/r-harrison/fg ... 2b4c8412f/
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Volumetric grass (was 3D textures and volumetric data)

Postby Thorsten » Mon Sep 18, 2017 7:55 am

Unfortunately the version committed to FGData doesn't work


I know that - but since this was very close to the release date (which I didn't know precisely) and I had no chance to get people testing for whom it worked before, I decided to go with the version 'as is' to the release and commit the non-trivial changes afterwards (I didn't like the scenario of breaking it for everyone else except you...) - you would have gotten the ping to test later today or tomorrow.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Volumetric grass (was 3D textures and volumetric data)

Postby Thorsten » Mon Sep 18, 2017 11:04 am

... and that was rather wise, because your version doesn't work for nvidia.

I've now pushed something that does work for me and ought to work for you as well - please give it a try!
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Volumetric grass (was 3D textures and volumetric data)

Postby Richard » Tue Oct 03, 2017 5:46 am

The stock FGData now works.

However 5H1NOB1 reported that the F-14, whilst parked on the grass I get this Image (canopy open to illustrate the problem, with canopy closed no grass is visible at all).

I tried it and confirm that I have the same problem. If I remove the interior glass it works fine. Lat 37.708872, Lon -122.225955, Alt 13.870603, Heading 268. KOAK

The strange thing is that when on the runway the grass is visible.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Volumetric grass (was 3D textures and volumetric data)

Postby Thorsten » Tue Oct 03, 2017 6:07 am

There's some z-ordering weirdness which I have not yet tracked down. It would seem this needs to go into a different render bin - and tentatively putting the other overlays into the standard bin seems to have resulted in something useful, so maybe you want to experiment a bit with that.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Volumetric grass (was 3D textures and volumetric data)

Postby vnts » Thu Jan 04, 2018 12:01 am

Screenshot looks stunning: )

Just a quick/random experiment, thought I may as well post (done on an old nightly):

Proof of concept (re)implementing double quad trees in geometry shader. The other grass method is limited to people who know the XML tweak. Triangles in mesh coloured by unique random number blending red to blue: img, img. . (Some funkyness due to using same pass as grass). Number of quads generated roughly based on triangle area 1 quad, 2 quads. Idea is 3 tri vertex positions in model space are pretty much enough to generate a unique seed by mixing bits w/o numerical instability I got last time (addition works for mixing). Allows density & random property variation.

Thought came as a mixing volumetric and old double quad grass looks great. Adds 'volume'. Then wondered if there was benefit in additional toggleable vegetation layers for undergrowth (plants/small trees/large bushes/regrowth in tree-fall clearings). If I understand correctly, 2 quad grass looks bad in rembrandt(?) and no way to change effect or have scenery layers based on renderer.
I guess (?) even crowds on airports or beaches, or grazing animals on grass fields with noise based movement may work with quads (placing discrete items via shells using a 'grid seed' probability might be too expensive- 3rd branch&texture with height as alpha).

Just a random experiment (just following math/logic, &conceptual understanding).

"shader extruding a couple of shells"

"since one can use both (noise) and (1-noise) to generate two mutually exclusive bump patterns on the same geometry"

In 1st screenshot far terrain shows the first pass, without shells. May be (?) possible to draw contents of shell in the normal terrain pass at a performance hit - even with shells off.

Testing results for anyone wanting to fine tune: Fiddling with NVIDIA control panel. 'Enhancing per application settings' for transparancy AA especially, &AA helped reduce noisy-ness at range. Transparency AA matters more for grass than (larger) terrain bumps. 4x AA requested by default? What about transparency AA? Not sure if users will know about that or suspect it helps (there may be a detailed AA select FG setting I don't know about, doesn't seem to be one in GUI).

(Transparency AA is applied to all alpha surfaces (?) - clouds&trees. Beware the supersampling variety (TRSSAA) is -expensive-. Google suggests the driver overrides & bruteforce renders specific surfaces to separate supersampled buffer(?) - then rescales&composits to the framebuffer. Interesting, hypothetically if effects framework supported writing to multiple buffers or an intermidiate buffer/texture - might do to save&reuse scattering intermediates in sceenspace in 2nd pass when rendering shells or trees. Anyway, if engine was able to select rendering to supersampled buffer by surface, like grass shells only, it may be be cheaper.)

@Lots of Performance talk reading both threads.

Looked up a bit on GS speed on google while experimenting. Seems some (old) results say geometry shader pipeline is additionally slow due to assumptions about the old flow not being able to be held(???) - maybe less with recent drivers(?). Maybe outdated now.

Just a thought, since 1:1 primitives are output there might (?) be an alternate way of using vertex shader instancing in some form. If there's any benefit at all, it would be geometry shaders are slower somehow? on worst case hardware that is still fast enough to run. Not sure if possible, worth gain, or requires engine work.

Some redundancy between 2 passes. Also (randomly) wondered if there was any magic trick to reuse vertex transform data between 2 passes (same shader&draw calls close together(?) to exploit post transform cache).But not useful if fragment limited on worst case. Marginal systems not often vertex limited?

Maybe more controls in-line with performance cost of effect might help..to tweak shell seperation, or view/fade distance (maybe also based on view angle of shell. Also aliasing noise can maybe be avoided (?) by angle subtended by a pixel versus angle subtended by grass blade or noise detail wavelength - based on FOV/resolution. Since grass blades use thresholding of a smoothly varying noise function perhaps(?) there's some way so fragment centers perspectively just outside the threshold can be made faded in and coloured by the % of likely coverage to anti-alias without needing transparency supersampling AA for the whole scene).

The procedural texturing is so detailed (e.g. Norway) that shell based terrain is not really needed unless intending to fly low to see 3d-ness of bump geometry (no bump normal shading atm? or possibly expensive. maybe a 2nd noise lookup close to threshold can fake shadows too). Adjusting LODs helps (detailed and rough can be reduced <4 km(?) depending on flatness&view-range while bare lod can be large). Workflow using different setting profiles for flight&craft profiles isn't cued or directed in UI, so people with somewhat recent GPUs may just be running unnecessary LODs or AA for satisfactory FPS/visuals.

At any rate next time people update GPUs & sync with steady tech progress it should run fine @ 1080p (& newcomers without use for GPU power previously will have a new usecase).

Kind regards,
vnts
vnts
 
Posts: 409
Joined: Thu Apr 02, 2015 1:29 am

Re: Volumetric grass (was 3D textures and volumetric data)

Postby vnts » Sat Feb 10, 2018 12:42 am

Since next release is close.. Some random screens with all grass types @ LOWI (while messing with grass shaders a while back, on old nightly). Maybe 1 or 2 useful for promotion (as placeholders until something better). When I found FG a little while ago, wondered at 1st impressions. I noticed that articles&reviews all used quick & convenient media: old v2.10 screenshots from front page gallery (e.g. Google: 1st gallery image link). Maybe(?) helpful to reinstate with recent screens without rough edge cases & include cues many images exist. (And maybe(?) helpful to refresh and make prominent the link to feature list&unique features. Incl. NASA testing of jsbsim accuracy & numerical stability IIRC ..).

Also wanted to post misc. glitches on Etna etc. No thread in dev section & wasn't sure posting bug screenshots is appropriate for other thread. Recent nightly (~2 Febr).

(Very quick) Tests:

1. Clouds & (non)occlusion of plume(z-order?).

2. Vegetation: translucency (Hawaii). Couldn't decide if it's intentional (to help blend in). Posting just in case.

3. Aerosol: volcanic plume/condensation in vortices etc/smoke: don't normally take colour of sunlight after outscattering like clouds do in FG eg, eg? screen. Also randomly wondered if ALS lightsource @ ejected lava center of mass would work.

4. Volcano:disabling by UI toggle doesn't switch off. Plume particles messed by time accel(Just something I noticed). Test: Kiluaea, max activity. People that notice volcano entry in menu can't know which volcanoes are simulated yet without searching for thread (or release changelog I guess)?

Very short test - win nightly issues right now (Build: 2909 ~2nd/02/18. Startup crash on EC135/130@KSFO/ENBR/PHNL. Tested: UFO/c172p works. 2890 from ~14th/01/18: fine - even with 2909 data folder.).

I'm mostly still unfamiliar/new, all of these could just be my settings/setup, or normal, or known. If these aren't reproducible it's probably me, my apologies.

Misc glitches. Overall effects are stunning & evocative screen :mrgreen: .

Kind Regards
vnts
 
Posts: 409
Joined: Thu Apr 02, 2015 1:29 am

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 2 guests