Board index FlightGear Development Effects and shaders

optimizing random trees: strong effect on performance ?

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

Re: optimizing random trees: strong effect on performance ?

Postby stuart » Thu Nov 12, 2015 10:54 pm

Absolutely Hooray - I agree. I'm certainly not trying to belittle abassign's question - more trying to highlight areas we've already looked at.
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: optimizing random trees: strong effect on performance ?

Postby Thorsten » Fri Nov 13, 2015 7:48 am

I only mentioned it to support the notion that some of our end-users may have a valid point despite not being able to find the right words or even just provide actionable information to begin with.


It's the kind of argument 'we can't absolutely rule out X, so we have to take X into account' (here: 'We can't rule out that the report might have a valid point, so we should investigate it thoroughly'.)

This argument is wrong in real life, because in real life probabilities and finite resources come into play. It is true that we can't absolutely rule out that someone's workplace will still be there the next day (because a meteorite might fall on it and destroy it). That doesn't keep anyone I know from going to work, because the probability of the event is reasonably small.

In real life, scenarios become actionable only if their expectation value (seriousness if event occurs times probability that it occurs) gets sufficiently large. The reason for that are finite resources - if you would for instance build a plane which can withstand a meteorite impact in-flight because you want to consider all eventualities, that plane would fly nowhere.

So, the fact of the matter is that meteorites impact on Earth and do damage - no doubt about that. The consequence of that however is still not that we need to harden everything.

Similarly, even if the odd user complaint now and then turns in the end out to lead to something real, the consequence is still not that we spent lots of time taking each and every of them seriously and doing an in-depth investigation. The reasonable thing to do with limited resources is run a plausibility check and investigate those which look either very serious or actionable.

In the event at hand:

'X is slow' is a sentence without real meaning. Rendering is always slow compared with computing flight dynamics, because it's easily two to three orders of magnitude more instructions to be executed. Computing the integral of x^3 + 1/(x-1) is numerically more costly than 1+1. There's nothing odd about that.

The notion of whether something is slow or not requires you to have a default expectation what it should be. Knowing how numerical math is done, I can understand why an integral is more costly than 1+1, and my alarm bells go off if I see 1+1 being more expensive.

So, should trees be expensive?

Quick test at a tropical island:

Rendering the bare terrain of the island gives me 27.000 vertices inside the view frustrum. Covering all with vegetation at coverage 3.9 gives me 4.340.000 (!) vertices inside the view frustrum.

So, hell yes - the pretty palm trees completely dominate the vertex count of the scene we're trying to render, they're in fact more than 99% of the vertex count in my test case - wherever comes the notion that they should be cheap? In fact, given how many vertices they actually add, their impact on framerate is remarkably small (if you would add random models of the same vertex count, you'd be lost).

Trees are known to be an expensive feature - which is why they're optional in the first place and not on a high density by default.

So the alleged 'problem' is that a feature which may increase your vertex count by two orders of magnitude actually has a notable performance footprint? Personally, I find it a near miracle and a testimony to the abilities of the people who wrote that code in the first place that adding that many vertices doesn't completely floor us.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: optimizing random trees: strong effect on performance ?

Postby erik » Fri Nov 13, 2015 1:11 pm

Once (10 years ago maybe) I saw a demo which uses billboarding to improve forest rendering. At that time it was impressive. Searching for this technique for OSG I found:
http://www.atlantis-press.com/php/downl ... p?id=10804

It turns out billboarding increases the frames just by 40%.
Turning off shadows gains another 15% and turn of swaying yet another 21%, according to this paper:

Code: Select all
Full detailed models: 43 frame
Full billboard models: 60 frame

Shadow: 49 frame
No shadow: 57 frame

Swaying: 47 frame
Non swaying: 57 frame


Then again, given that, like Thorsten mentions, 99% of the vertices is trees Billboarding might make an impact.

Erik
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2245
Joined: Thu Nov 01, 2007 2:41 pm

Re: optimizing random trees: strong effect on performance ?

Postby Hooray » Fri Nov 13, 2015 1:25 pm

I don't remember the exact context, but at some point we were discussing OSG object instancing on the forum, and using that in conjunction with PagedLOD:

http://3dcgtutorials.blogspot.com/2013/ ... graph.html
http://3dcgtutorials.blogspot.com/2013/ ... rt-ii.html

I guess that Stuart and Thorsten would be in the best position to determine if that may be applicable/useful here or not (at all).

Regardless of that, I would suggest to disable any non-tree related features and then dump the scenegraph to a file and view the whole thing in osgviewer/fgviewer standalone, and see if running osgconv on the .osg file has any noticeable effect or not: http://trac.openscenegraph.org/projects ... zerOptions
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: optimizing random trees: strong effect on performance ?

Postby Thorsten » Fri Nov 13, 2015 1:29 pm

Trees are instanced objects and positioned only in the vertex shader - I'm not sure how meaningful the osgViewer result for them would be in this context.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: optimizing random trees: strong effect on performance ?

Postby erik » Fri Nov 13, 2015 1:33 pm

Looking at it instancing has the drawback that it needs one rotation for every tree. Which seems unnecessary, for trees it is sufficient to create one instance facing the viewer and position it all over the scene.

Erik
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2245
Joined: Thu Nov 01, 2007 2:41 pm

Re: optimizing random trees: strong effect on performance ?

Postby Hooray » Fri Nov 13, 2015 1:41 pm

http://osghelp.com/?p=98
GenTrees is a utility to create an instancing object that renders many trees. You can use shape files or geometry shapes to define where trees should be planted (using a texture atlas)
https://code.google.com/p/sigmaosg/wiki/GenTrees



psadro_gm mentioned in another thread recently how trees are positioned using the LOD callback, so that could be the right location to get a tree-only scenegraph that only contains the relevant statesets for random buildings/vegetation, to see what these nodes look like at the .osg level, i.e. if there is any "low-hanging fruit" to optimize this at the scenegraph level.

Subject: Synthetic terrain
psadro_gm wrote: it may be faster to create the mesh directly from the scenegraph in c++ space. we already do this in the LOD callback to place the random trees and buildings. We then have a triangle mesh.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: optimizing random trees: strong effect on performance ?

Postby Thorsten » Fri Nov 13, 2015 4:25 pm

I believe we had billboarded trees before changing to the current solution of two crossed quads.

psadro_gm mentioned in another thread recently how trees are positioned using the LOD callback, so that could be the right location to get a tree-only scenegraph that only contains the relevant statesets for random buildings/vegetation, to see what these nodes look like at the .osg level, i.e. if there is any "low-hanging fruit" to optimize this at the scenegraph level.


Please note that trees are not positioned like normal objects - before the vertex shader they don't have any distinct orientation or coordinate. The tree coordinates are actually passed via gl_Color and the orientation via gl_FogCoord. and their size is given by gl_Normal. If you don't run the vertex shader, you won't see much of a forest. Before the vertex shader, they're just ten (the LOD groups for fading them in and out) arrays of quads at the same place.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: optimizing random trees: strong effect on performance ?

Postby erik » Fri Nov 13, 2015 6:52 pm

The solution opted in the paper was to use Billboarding based on LOD further away and keep the closest trees as two crossed quads.
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2245
Joined: Thu Nov 01, 2007 2:41 pm

Re: optimizing random trees: strong effect on performance ?

Postby Hooray » Fri Nov 13, 2015 7:33 pm

I still have not seen any compelling data that there really IS a problem with the trees ... anyway, since we've moved on to discuss different papers/approaches:

Here's a related osg-users discussion covering buildings/vegetation in a PagedLOD flightsim, emphasizing culling: http://www.mail-archive.com/osg-users@l ... 48545.html

osg::Image based hardware-instancing is said to be capable of providing roughly ~1M STATIC trees at 30 hz: http://www.mail-archive.com/osg-users%4 ... 69269.html

For dynamically-updated models, it is said to be still around 2k: http://www.mail-archive.com/osg-users%4 ... 69279.html

For buildings, the suggested approach is to build a texture atlas (I think I saw commit messages from Stuart suggesting that is already done in SG): http://www.mail-archive.com/osg-users%4 ... 69824.html

And this is one of the more recent discussions about osg impostors to simplify rendering of millions of primitives: http://www.mail-archive.com/osg-users%4 ... 63981.html

And here's a discussion covering vertex reduction using ogsWorks: http://forum.openscenegraph.org/viewtopic.php?t=5700
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: optimizing random trees: strong effect on performance ?

Postby stuart » Sat Nov 14, 2015 12:11 am

Hi All,

Erik - I seem to recall doing an experiment with billboarded distant trees a couple of years back. I think I came to the conclusion that there wasn't a significant perf benefit vs. the memory overhead of having multiple definitions for each tree both in memory and in requiring the GPU to load a different state-set to process the different tree types.

Hooray - Impostors were certainly unstable last time I checked, and IIRC they would be a replacement for the shader-based geometry rather than a technique we can use on top.

I'd need to look back in the archives, but I wouldn't be surprised if we were rendering 1M trees at 30Hz on current hardware. IIRC there are some logs output about the number of generated trees if you want to take a look.

That's not to say that there aren't techniques out there, but a lot of work was put into the technique to minimize memory occupancy and maximize GPU utlization. We could probably improve on the former with some bit-stuffing.

I've had three generations of computers now using random trees and they've never had a significant perf impact. I'd be very surprised if anyone with a reasonable graphics card (non-integrated) is finding them a significant bottleneck on performance. I'd expect cloud density to be an order of magnitude more of an impact.

That said, I suspect that we could be more efficient in areas where there are multiple different tree types defined. Effectively each tree type requires the GPU to load a new state before processing. We could simplify this with a texture atlas and shader parameters rather than separate effects for each tree definition. Whether this is significant would be worth someone experimenting on.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: optimizing random trees: strong effect on performance ?

Postby Thorsten » Sat Nov 14, 2015 7:59 am

I've had three generations of computers now using random trees and they've never had a significant perf impact. I'd be very surprised if anyone with a reasonable graphics card (non-integrated) is finding them a significant bottleneck on performance.


Let's just say that you can easily move the slider up to a value where they become the performance bottleneck. Especially as you are approaching realistic forest densities and play a bit with the distance cuts, they get very heavy.

It's like with many features. The terrain mesh isn't a problem for 16 km visibility, but for 250 km visibility it will be. Clouds aren't an issue in fair weather, but rendering multiple layers of intricate strato- and altocumulus drawn to large visibility range will be. Trees at default setting in normal terrain aren't an issue, but when rendering dense forests in Canada they will be. Having one airplane with half a million vertices in the scene isn't much of an issue - having ten of those trying to do an MP flight will be.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: optimizing random trees: strong effect on performance ?

Postby erik » Sat Nov 14, 2015 10:53 am

stuart wrote in Sat Nov 14, 2015 12:11 am:Hi All,

Erik - I seem to recall doing an experiment with billboarded distant trees a couple of years back. I think I came to the conclusion that there wasn't a significant perf benefit vs. the memory overhead of having multiple definitions for each tree both in memory and in requiring the GPU to load a different state-set to process the different tree types.


Clear, then it looks like we have the best and optimal situation now.

Erik
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2245
Joined: Thu Nov 01, 2007 2:41 pm

Re: optimizing random trees: strong effect on performance ?

Postby Johan G » Wed Nov 18, 2015 5:32 pm

Some posts was split off to the new topic Documenting development dead ends.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: optimizing random trees: strong effect on performance ?

Postby stuart » Thu Nov 19, 2015 3:19 pm

Hi All,

I've been thinking about this a bit more since I wrote my post regarding previous experiments with single-quad trees.

With the (relatively) recent changes to use PagedLOD for loading scenery objects (including trees) it should be possible to write something that generates single-quad trees for larger distances and cross-quad trees for shorter distances without as much of a memory occupancy hit - as some trees will never be in close enough range to require generation and crossed-quads.

So, I think there may be some worthwhile investigation to do here.

I'm currently concentrating on HLA Integrationm so if anyone else wants to get their hands dirty in the code, they are very welcome ;)....

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 6 guests