Scenery LOD ideas for FlightGear: Difference between revisions

Jump to navigation Jump to search

Scenery LOD ideas for FlightGear (view source)

Revision as of 07:37, 21 May 2020

8,246 bytes removed ,  21 May 2020
m
should be updated/merged
m (clarify)
m (should be updated/merged)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{Out of date}}
== 02/2014 (F-JJTH) ==
{{Mergeto|Scenery LoD}}
 
 
'''F-JJTH:''' Looking at [http://forum.flightgear.org/viewtopic.php?f=5&t=22119 your topic about the framerate dropdown because of the new scenery] I would ask you to test the following patch:
 
http://pastebin.com/p5HXirn5
<syntaxhighlight lang="diff">
diff --git a/simgear/scene/tgdb/obj.cxx b/simgear/scene/tgdb/obj.cxx
index edb35f2..767c930 100644
--- a/simgear/scene/tgdb/obj.cxx
+++ b/simgear/scene/tgdb/obj.cxx
@@ -40,6 +40,7 @@
#include <osg/Referenced>
#include <osg/StateSet>
#include <osg/Switch>
+#include <osgUtil/Simplifier>
#include <boost/foreach.hpp>
@@ -1213,6 +1214,25 @@ SGLoadBTG(const std::string& path, const simgear::SGReaderWriterOptions* options
    terrainGroup->setName("BTGTerrainGroup");
    osg::Node* node = tileGeometryBin->getSurfaceGeometry(matlib);
+
+    bool simplifierState = false;
+    double ratio        = 0.001;
+    double maxLength    = 1000.0;
+    double maxError      = 1000.0;
+    if(options){
+        SGPropertyNode* propertyNode = options->getPropertyNode().get();
+        if (propertyNode) {
+            simplifierState = propertyNode->getBoolValue("/sim/rendering/terrain/simplifier/enabled", simplifierState);
+            ratio = propertyNode->getDoubleValue("/sim/rendering/terrain/simplifier/ratio", ratio);
+            maxLength = propertyNode->getDoubleValue("/sim/rendering/terrain/simplifier/max-length", maxLength);
+            maxError = propertyNode->getDoubleValue("/sim/rendering/terrain/simplifier/max-error", maxError);
+        }
+    }
+    if(simplifierState) {
+        osgUtil::Simplifier simplifier(ratio, maxError, maxLength);
+        node->accept(simplifier);
+    }
+
    if (node)
      terrainGroup->addChild(node);
 
</syntaxhighlight>
 
http://pastebin.com/zn0W31HV
<syntaxhighlight lang="diff">
diff --git a/preferences.xml b/preferences.xml
index da8416c..3b701c3 100644
--- a/preferences.xml
+++ b/preferences.xml
@@ -58,6 +58,14 @@ Started September 2000 by David Megginson, david@megginson.com
                        <season type="string" preserve="y">summer</season>
                </startup>
                <rendering>
+                      <terrain>
+                              <simplifier>
+                                      <enabled type="bool">false</enabled>
+                                      <ratio type="double">0.001</ratio>
+                                      <max-error type="double">1000.0</max-error>
+                                      <max-length type="double">1000.0</max-length>
+                              </simplifier>
+                      </terrain>
                        <materials-file>Materials/regions/materials.xml</materials-file>
                        <rembrandt>
                                <enabled type="bool">false</enabled>
</syntaxhighlight>
 
Then start FG with '''--prop:/sim/rendering/terrain/simplifier/enabled=true'''
 
Every params take effect at run-time as soon as you reload the scenery after changing the value, but I've experimented a lot of value and the default values are fine.
For information the expected result is to have less vertex:
 
[http://clement.delhamaide.free.fr/osg/ http://clement.delhamaide.free.fr/osg/]
 
Of course less vertex = less detail... but I think it's more reasonable to give a "low-vertex-scenery" for those who don't have the requiered hardware.
 
Also keep in mind that this patch has only a positive effect (at least I hope) on FPS, not on RAM (the whole BTG file is still loaded in RAM)
 
Well, let me know if it improve the situation.
 
 
The number of vertex should be definitely reduced. My screenshots (wireframe) are showing that osg::Simplifier works fine.
But maybe the simplification is not enough important for seeing a positive effect.
 
I will give a try tomorrow at KSFO, are you able to confirm me that enabling osg::Simplifier reduce the number of vertex (or not). A simple test is:
* Start FG
* Enable wireframe
* Look at outdoor
* Take a screenshot
* Enable osg::Simplifier from property tree
* Reload scenery
* Take a screenshot
 
Then compare the 2 screenshots and yo will immediately see if the effect is here
 
'''Hooray:'''
I have worked through quite a few OSG docs, and I think we can make this work - ideally, you would push your changes to gitorious, so that we can both work on them. I also asked poweroftwo (osgEarth) to have a look, because he's more familiar with the scenery/terrain and OSG side of things (also CC'ing Stuart and Zakalawe and the TG guys, so that they're aware of this).
 
I would really love to see this implemented as a custom SimGear class, something like "LODManager" that is property-driven.
We could then use it for 1) terrain, 2) main aircraft models (cockpit!) and 3) AI objects to expose a property-driven interface to customize LOD at runtime.
 
The first thing that we could change is using SGPropertyChangeListener or property objects so that properties can be changed at runtime, without requiring a  manual scenery-reload.
 
I think we would only need to subclass osgUtil::Simplifier and make it derive from SGPropertyChangeListener, too - would that work ?
 
<syntaxhighlight lang="cpp">
class SGLODManager : public osgUtil::Simplifier, SGPropertyChangeListener
{
// implement the osgUtil::Simplifier & listener interfaces here
};
 
</syntaxhighlight>
The question is we can modify the visitor after it's been applied, or if that requires changes on the OSG side.
 
It also seems that we can use some OSG machinery to simplify textures, too.
 
 
'''Stuart:'''
 
Now, this is very interesting. I need to have a bit of a play with it to see what the CPU cost of the simplification is, but at first glance, it should be straightforward to build scenery LoD by using this for the distant scenery, and simply re-loading the BTG file (which is fairly cheap) at closer range as part of the PagedLoD system we've got for trees etc.  Obviously there's a bit of a problem at the edges, but because the scenery tiles have straight-ish edges and are single-sided, I suspect the visual artifacts will be minimal.
 
Hooray - I'm not sure there's much value in tying this to a SGPropertyChangeListener, as its not something that can be dynamically changed.  I 99% sure the visitor goes through the OSG tree modifying the data itself, so the original data is no-longer available afterwards.  Effectively it's a destructive transformation.  So, to apply some new setting would require loading the BTG file from disk again. 
 
(An alternative would be to have a different type of visitor that creates a new OSG sub-tree with cloned data, but that obviously increases memory occupancy.)
 
I'm also not sure of the implications of applying it to aircraft,  but it should be easy to try out at least. 
 
-Stuart
 
'''Hooray:''' Right as is, it's definitely destructive and it ''will'' require a tile reload obviously (supported by Robert Osfield's comments on the osg list) - I was referring to doing the reload automatically, instead of having to run a corresponding fgcommand (we're currently using your rendering dialog and its "reload scenery" button for this. For instance, see the OSG demo code using the simplifier - i.e. see [http://www.rozengain.com/blog/2011/02/16/openscenegraph-level-of-detail-management/] - there are several LOD nodes created which can be selected. Obviously, at the cost of increased memory consumption (so this may be a no-go for scenery) - but it may still be a useful feature for developers/power users (especially to come up with good numbers/heuristics), but also help with Aircraft/Cockpit/AI related LOD management. So, I'm all for coming up with a wrapper in SimGear that we can add to the terrain/tile manager, but also use in the main aircraft/cockpit and for AI models. Using a different type of visitor pattern may not be feasible for scenery I guess, until we have some way to tell how much RAM is actually being consumed. That being said, some folks on the osg list mentioned that CGAL could be used inside an OSG Simplifier, as CGAL has extensive mesh simplification support which can also be run in a background thread (I guess psadro_gm & papillon81 know more about that?) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:35, 19 February 2014 (UTC) 
 
 
 
= Ideas (2012) =
= Ideas (2012) =
Moving forum discussion to the wiki:
Moving forum discussion to the wiki:
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/67849...124806"

Navigation menu