From: Stuart B. <stu...@ya...> - 2007-12-28 14:16:45
|
Hi All,=0A=0AWith a lot of help from Time Moore, I've been working on imple= menting random scenery objects for OSG.=0A=0AThe first attempt at this is n= ow available as patch to simgear (simgear.patch) and new source file (simge= ar/scene/tgdb/SBModelBin.hxx), from http://www.nanjika.co.uk/flightgear/ran= dom.tar.gz=0A=0ANotes:=0A1) There are no trees yet, as the billboard animat= ions don't work completely on OSG. I'll probably look at this next.=0A2) I'= m using OSG 2.2 for this on a moderately powerful machine. Unless I have OS= G_DATABASE_PAGER_DRAWABLE=3DVertexArrays set as an environmental variable, = FG never gets past the "loading scenery objects" stage. However, with this = set I'm not noticing and real frame-rate drop. I suggest that you set this,= though it may not be required with OSG SVN.=0A3) The model density is high= er than plib for the same materials.xml file. I'm still working out why thi= s is the case, but it doesn't have a huge impact as models are shared.=0A= =0AAssuming it passes muster, I suggest that this is applied to SVN HEAD. T= hose who find that the random models cause too much of a performance drop c= an simply switch it off by setting /sim/rendering/random-objects=3Dfalse. A= lternatively, we could simply swich it off in the preferences.xml file for = the short term.=0A=0AComments are very welcome, as this is my first attempt= at OSG programming.=0A=0A-Stuart=0A=0A=0A=0A=0A=0A=0A _______________= ____________________________________________=0ASupport the World Aids Aware= ness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.co= m/forgood/ |
From: Curtis O. <cur...@gm...> - 2007-12-28 14:38:45
|
On Dec 28, 2007 8:15 AM, Stuart Buchanan <stu...@ya...> wrote: > Hi All, > > With a lot of help from Time Moore, I've been working on implementing > random scenery objects for OSG. > > The first attempt at this is now available as patch to simgear ( > simgear.patch) and new source file (simgear/scene/tgdb/SBModelBin.hxx), > from http://www.nanjika.co.uk/flightgear/random.tar.gz > > Notes: > 1) There are no trees yet, as the billboard animations don't work > completely on OSG. I'll probably look at this next. > 2) I'm using OSG 2.2 for this on a moderately powerful machine. Unless I > have OSG_DATABASE_PAGER_DRAWABLE=VertexArrays set as an environmental > variable, FG never gets past the "loading scenery objects" stage. However, > with this set I'm not noticing and real frame-rate drop. I suggest that you > set this, though it may not be required with OSG SVN. > 3) The model density is higher than plib for the same materials.xml file. > I'm still working out why this is the case, but it doesn't have a huge > impact as models are shared. > > Assuming it passes muster, I suggest that this is applied to SVN HEAD. > Those who find that the random models cause too much of a performance drop > can simply switch it off by setting /sim/rendering/random-objects=false. > Alternatively, we could simply swich it off in the preferences.xml file > for the short term. Hi Stuart, This is great! Random objects is a feature I really miss in the OSG version. Here are a couple of thoughts for whatever they are worth. 1. In the original implementation, the randomness was seeded with some element from the triangle the objects. The way the random object pattern was always fixed. This was critical for multi-PC setups so that the exact same set of random objects appeared on each display. This is pretty critical for higher end cockpit setups, otherwise they start looking pretty silly when objects don't cross your monitor boundaries as you fly. 2. The random seed could have probably been better chosen because there were areas where you'd get 5 water towers in a straight line. I never chased that one down, but I always suspected it was related to the choice of random seed. 3. One thing I didn't like so much about the original implementation was that all the objects lived within a small radius around your aircraft. This was especially apparent with forests. I don't know if this is possible to fix, but I once had a 1/2 baked idea that seemed hopeful at the time. What I would love to see is some sort of statistical distribution where a few objects exist even at a far distance, and then as you get closer and closer, more and more of the objects fill in. I was thinking that this would be more natural looking and you wouldn't notice the spotlight of trees following beneath you as much. So my 1/2 idea was something along the lines of creating a scene graph node that stored the object plus a (possibly long) list of locations. When the node is drawn, the list of locations is traversed, but only part way through based on distance from the viewer. The closer you are to the node, the further down the list of locations you traverse. So the idea/hope would be that at a distance you'd see only a very few scattered objects. As you fly closer, those objects remain, but new ones are slowly filled in. As you get closer and closer, you get a denser cover of objects, but there is no hard line where the objects all suddenly appear or disappear. I have no idea if this would be easy or hard to implement, but you'd likely have to get down into the guts of OSG to do it. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d |
From: Chris M. <cme...@sp...> - 2007-12-28 16:00:46
Attachments:
signature.asc
|
On Fri, 28 Dec 2007 08:38:48 -0600 Curtis Olson wrote: > > 2. The random seed could have probably been better chosen because there > were areas where you'd get 5 water towers in a straight line. I never > chased that one down, but I always suspected it was related to the > choice of random seed. This was something that drove me nuts too. But it shouldn't be a problem with the seed, at least not exclusively. Patterns like this in the output of a random number generator are almost always the fault of a poorly-implemented random number generator -- a linear or multiplicative congruential generator with poor choice of multiplier or modulus. The ones that come with C or C++ standard libraries almost always fit into this category. It's a natural tendancy of these generators for N-tuples of randomly generated points to lie on (N-1)-dimensional surfaces in the N-dimensional space (so 2-D points, such as random lat/lons, will lie on 1-D surfaces, or lines). I haven't yet learned C++, but I learned C this past year, and on that level they should probably look pretty similar; so maybe I'll use looking into what FG does now as a tutorial. -c --=20 Chris Metzler cme...@sp... (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear |
From: Christian M. <mail@ChristianMayer.de> - 2007-12-28 20:06:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Chris Metzler schrieb: > On Fri, 28 Dec 2007 08:38:48 -0600 > Curtis Olson wrote: >> 2. The random seed could have probably been better chosen because there >> were areas where you'd get 5 water towers in a straight line. I never >> chased that one down, but I always suspected it was related to the >> choice of random seed. > > This was something that drove me nuts too. But it shouldn't be a problem > with the seed, at least not exclusively. Patterns like this in the > output of a random number generator are almost always the fault of a > poorly-implemented random number generator -- a linear or multiplicative > congruential generator with poor choice of multiplier or modulus. The > ones that come with C or C++ standard libraries almost always fit into > this category. This might be a case where the great BOOST Project might help us: http://www.boost.org/libs/random/index.html For those that don't know Boost yet (is there anyone left?): Boost is the "playground" where new C++ libraries get developed that might become part of the next C++ standard. Using their stuff is almost like using official C++... CU, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHdVdcoWM1JLkHou0RCNG1AJ0dacPg5cgrhe82PJRVp5LrE1zDzwCfd9PL UaIC/PCcBc4gDnvoXmbNKNY= =jeu7 -----END PGP SIGNATURE----- |
From: Erik H. <er...@eh...> - 2007-12-29 09:23:20
|
Christian Mayer wrote: > This might be a case where the great BOOST Project might help us: > > http://www.boost.org/libs/random/index.html One thing to keep in mind when using random generators is that it would be realy nice (if not required) to generate the same output on all supported platforms. That means everybody in a multi player environment would see the same objects at the same location. That was the main motivation for using the one that is included in SimGear instead of a system supplied version. Erik |
From: Norman V. <nh...@ca...> - 2007-12-29 09:58:52
|
Erik Hofman writes: > > Christian Mayer wrote: > > > This might be a case where the great BOOST Project might help us: > > > > http://www.boost.org/libs/random/index.html > > One thing to keep in mind when using random generators is > that it would > be realy nice (if not required) to generate the same output on all > supported platforms. That means everybody in a multi player > environment > would see the same objects at the same location. > > That was the main motivation for using the one that is included in > SimGear instead of a system supplied version. I would like to point out that the Simgear random number generator is one of the Boost::Random variants http://www.boost.org/libs/random/random-generators.html#mersenne_twister Note there is now a faster implementation available from the original authors http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html """ SFMT is a new variant of Mersenne Twister (MT) introduced by Mutsuo Saito and Makoto Matsumoto in 2006. The algorithm was reported at MCQMC 2006. The article will apper in the proceedings of MCQMC2006. (see Prof. Matsumoto's Papers on random number generation.) SFMT is a Linear Feedbacked Shift Register (LFSR) generator that generates a 128-bit pseudorandom integer at one step. SFMT is designed with recent parallelism of modern CPUs, such as multi-stage pipelining and SIMD (e.g. 128-bit integer) instructions. It supports 32-bit and 64-bit integers, as well as double precision floating point as output. SFMT is much faster than MT, in most platforms. Not only the speed, but also the dimensions of equidistributions at v-bit precision are improved. In addition, recovery from 0-excess initial state is much faster. See Master's Thesis of Mutsuo Saito for detail (submitted). """ Norman |
From: Stuart B. <stu...@ya...> - 2007-12-28 17:14:17
|
--- Curtis Olson wrote: > Here are a couple of thoughts for whatever they are worth. > > 1. In the original implementation, the randomness was seeded with some > element from the triangle the objects. The way the random object pattern > was always fixed. This was critical for multi-PC setups so that the exact > same set of random objects appeared on each display. This is pretty > critical for higher end cockpit setups, otherwise they start looking pretty > silly when objects don't cross your monitor boundaries as you fly. I've "fixed" this by using a hardcoded seed, so everyone will see the same set of random objects at the moment. > 3. One thing I didn't like so much about the original implementation was > that all the objects lived within a small radius around your aircraft. This > was especially apparent with forests. I don't know if this is possible to > fix, but I once had a 1/2 baked idea that seemed hopeful at the time. > > What I would love to see is some sort of statistical distribution where a > few objects exist even at a far distance, and then as you get closer and > closer, more and more of the objects fill in. I was thinking that this > would be more natural looking and you wouldn't notice the spotlight of trees > following beneath you as much. Currently, there is a single LoD node for each random object, which is referenced multiple times within the tile. Creating a different LoD node for each instance of the object would probably have too much of a performance hit. However, I've put together a workaround/hack that gets us most of the way there without costing us too much. For each object, we create (say) 3 LoD nodes with different LoD distances - 1x, 1.5x and 2x. By randomly choosing between the different LoD nodes when we generate the instances (with a distribution favouring the standard LoD value), we get a variety of LoDs. I've had a play, and it looks quite convincing, though as we currently don't have trees, the effect is quite subtle. I've uploaded a new patch which includes this feature, along with some changes that Andy and Csaba suggested on IRC to http://www.nanjika.co.uk/flightgear/random.tar.gz. -Stuart __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com |
From: Heiko S. <aei...@ya...> - 2007-12-28 17:22:56
|
--- Stuart Buchanan <stu...@ya...> schrieb: > --- Curtis Olson wrote: > > Here are a couple of thoughts for whatever they > are worth. > > > > 1. In the original implementation, the randomness > was seeded with some > > element from the triangle the objects. The way > the random object pattern > > was always fixed. This was critical for multi-PC > setups so that the exact > > same set of random objects appeared on each > display. This is pretty > > critical for higher end cockpit setups, otherwise > they start looking pretty > > silly when objects don't cross your monitor > boundaries as you fly. > > I've "fixed" this by using a hardcoded seed, so > everyone will see the same set of > random objects at the moment. > > > 3. One thing I didn't like so much about the > original implementation was > > that all the objects lived within a small radius > around your aircraft. This > > was especially apparent with forests. I don't > know if this is possible to > > fix, but I once had a 1/2 baked idea that seemed > hopeful at the time. > > > > What I would love to see is some sort of > statistical distribution where a > > few objects exist even at a far distance, and then > as you get closer and > > closer, more and more of the objects fill in. I > was thinking that this > > would be more natural looking and you wouldn't > notice the spotlight of trees > > following beneath you as much. > > Currently, there is a single LoD node for each > random object, which is referenced > multiple times within the tile. Creating a different > LoD node for each instance > of the object would probably have too much of a > performance hit. > > However, I've put together a workaround/hack that > gets us most of the way there > without costing us too much. For each object, we > create (say) 3 LoD nodes with > different LoD distances - 1x, 1.5x and 2x. By > randomly choosing between the > different LoD nodes when we generate the instances > (with a distribution favouring > the standard LoD value), we get a variety of LoDs. > I've had a play, and it looks > quite convincing, though as we currently don't have > trees, the effect is quite > subtle. > > I've uploaded a new patch which includes this > feature, along with some changes > that Andy and Csaba suggested on IRC to > > http://www.nanjika.co.uk/flightgear/random.tar.gz. > > -Stuart > Hi, Nice to hear, though I'm generally not a fan of this AutoGen-thing: for me it looks funny when objects in sight suddenly appear and disapear... I'm more a fan of Sebastian Bechthold's idea... But this means one step ahead to the first FGFS-OSG-Release! Question: is there any plans to add the "imposter"-technologie by OSG? It could improve that AutoGen a lot. Regards HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set |
From: Stuart B. <stu...@ya...> - 2007-12-29 17:36:24
|
--- Stuart Buchanan wrote: > I've uploaded a new patch which includes this feature, along with some changes > that Andy and Csaba suggested on IRC to > > http://www.nanjika.co.uk/flightgear/random.tar.gz. A new version of the patch is available from the above location, including the following improvements: - <heading>random</heading> now supported. - Simple quad-tree to improve culling based on the centre of the object distribution, which should provide a small performance improvement. This area is almost certainly ripe for improvements. - Update to sg_random from Andy which allows independant pseudo-random number lists. This means that the random objects will be placed in the same location across sessions and (untested) machines without affecting random number generation elsewhere. I will probably have limited time to work on this in the near term, so if it could be reviewed and included in CVS, I'd be grateful. -Stuart ___________________________________________________________ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ |
From: Stuart B. <stu...@ya...> - 2007-12-31 17:17:37
|
--- Stuart Buchanan wrote: > --- Stuart Buchanan wrote: > > I've uploaded a new patch which includes this feature, along with some > changes > > that Andy and Csaba suggested on IRC to > > > > http://www.nanjika.co.uk/flightgear/random.tar.gz. Further updates available at the above location: - Improved quad trees (256 leaves rather than 4) with LoD to improve performance. Works well with the 3-D tree patch. - Better use of pseudo-random numbers - previously some objects were co-located because they used the same MT seed. Whoops. Happy Hogmanay* everyone! -Stuart * Scots word for the new year celebrations. __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com |
From: Tim M. <ti...@re...> - 2008-01-06 15:16:49
|
Stuart Buchanan wrote: > --- Stuart Buchanan wrote: >> --- Stuart Buchanan wrote: >>> I've uploaded a new patch which includes this feature, along with some >> changes >>> that Andy and Csaba suggested on IRC to >>> >>> http://www.nanjika.co.uk/flightgear/random.tar.gz. > > Further updates available at the above location: > - Improved quad trees (256 leaves rather than 4) with LoD to improve performance. > Works well with the 3-D tree patch. > - Better use of pseudo-random numbers - previously some objects were co-located > because they used the same MT seed. Whoops. > I've checked this work in, with a change to use an independent quad tree builder class. Thanks very much for the contribution; it's good to have another OSG hacker in the house. I did some cleanup to the code, notably changing various osg::Matrix objects to be stack allocated instead of heap allocated. There remains a fairly serious performance problem with this code, most visible if you pan to the south at KSFO: culling time explodes. The extra polygons themselves aren't the problem, so I suspect that the LOD nodes on each object are expensive. I have in mind another approach that I'd like you (Stuart) to take a look at: at each of quad tree leaves, have one LOD node with ranges corresponding to the different ranges of the objects in that node. Then, add the object (that part *below* its own LOD node) to each LOD range in which it is visible. This might suggest a different way of returning random models from the materials library. Hit me up on IRC if you want some help on the details. Tim |
From: Erik H. <er...@eh...> - 2008-01-07 15:09:02
|
Tim Moore wrote: > I've checked this work in, with a change to use an independent quad tree builder class. > Thanks very much for the contribution; it's good to have another OSG hacker in the > house. With the latest version of FlightGear I got it to hang while loading the scenery objects and I have the feeling this patch is responsible for this. Does anybody see the same behavior? Erik |
From: Tim M. <ti...@re...> - 2008-01-07 15:24:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erik Hofman wrote: > Tim Moore wrote: > >> I've checked this work in, with a change to use an independent quad tree builder class. >> Thanks very much for the contribution; it's good to have another OSG hacker in the >> house. > > With the latest version of FlightGear I got it to hang while loading the > scenery objects and I have the feeling this patch is responsible for this. > > Does anybody see the same behavior? > > Erik > If you are going to enable random objects, I recommend using OSG 2.3 or later. Otherwise, set the environment variable OSG_DATABASE_PAGER_DRAWABLE=VertexArrays Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHgkQkeDhWHdXrDRURAgzEAJ0XXXQ/YvTSqNYoGqLLpt4m7g3zjgCfeIAH uu2EUsAb5LsjiuuAZ9HCNnY= =i2mT -----END PGP SIGNATURE----- |
From: Erik H. <er...@eh...> - 2008-01-08 08:34:46
|
Tim Moore wrote: > If you are going to enable random objects, I recommend using OSG 2.3 or later. Otherwise, > set the environment variable OSG_DATABASE_PAGER_DRAWABLE=VertexArrays Installing OSG 2.3.1 did indeed do the trick but it's still slower at startup than I was used to. I think I'll disable random object for now. Thanks for the help Tim. Erik |
From: Curtis O. <cur...@gm...> - 2008-01-07 16:09:36
|
On Jan 7, 2008 9:24 AM, Tim Moore <ti...@re...> wrote: > If you are going to enable random objects, I recommend using OSG 2.3 or > later. Otherwise, > set the environment variable OSG_DATABASE_PAGER_DRAWABLE=VertexArrays Hi Tim, Is there a way to work around this in our code? Right now OSG 2.2 is the most recent "stable" release and until they hit 2.4, this is going to quickly turn into a FAQ for us. Just for my own interest/understanding, can you give a brief explanation of the problem? I'd love to start understanding OSG better. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ |
From: Tim M. <ti...@re...> - 2008-01-07 16:45:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Curtis Olson wrote: > On Jan 7, 2008 9:24 AM, Tim Moore <ti...@re... > <mailto:ti...@re...>> wrote: > > If you are going to enable random objects, I recommend using OSG 2.3 > or later. Otherwise, > set the environment variable OSG_DATABASE_PAGER_DRAWABLE=VertexArrays > > > Hi Tim, > > Is there a way to work around this in our code? Right now OSG 2.2 is > the most recent "stable" release and until they hit 2.4, this is going > to quickly turn into a FAQ for us. > This policy can be set from C++ code, and perhaps it should be set if using an older OSG version than 2.3. I didn't think it was really necessary before, but random objects are another story. > Just for my own interest/understanding, can you give a brief explanation > of the problem? I'd love to start understanding OSG better. OSG compiles geometry into OpenGL display lists. This action needs a graphics context, which means doing it in the graphics thread for all practical purposes. To avoid impacting the frame rate when new scenery is paged in, the OSG DatabasePager passes several objects per frame to the graphics thread for compilation. Unfortunately there are bugs in 2.2 that cause shared models, such as the scenery models and random objects, to be recompiled for each instance of the model. This is mostly noticeable in fg at startup when the whole world is paged in, but the large number of random objects (thousands) really tickles this bug. I submitted fixes for OSG which are in 2.3. The "OSG_DATABASE_PAGER_DRAWABLE=VertexArrays" forces OSG to not use display lists; this solves the problem at the cost of lower overall performance. I suppose that we shouldn't expect users of CVS FlightGear to track OpenSceneGraph from SVN. OSG 2.3.1 is available as a tarball; I don't know if it's available as a binary download. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHglc/eDhWHdXrDRURAuvAAJ9It+EQDcKi1YUaE8Kg5aJUcUp54wCfS5qp p/dUPERnPlcE2NO2wI9okzk= =kqZV -----END PGP SIGNATURE----- |
From: Curtis O. <cur...@gm...> - 2007-12-31 17:45:57
|
I get this compile fault when I try to build the patch ... :-( matmodel.hxx:38:25: error: osg/BillBoard: No such file or directory I believe I have the official OSG-v2.2 installed. Thanks, Curt. On Dec 31, 2007 11:17 AM, Stuart Buchanan <stu...@ya...> wrote: > > --- Stuart Buchanan wrote: > > --- Stuart Buchanan wrote: > > > I've uploaded a new patch which includes this feature, along with some > > changes > > > that Andy and Csaba suggested on IRC to > > > > > > http://www.nanjika.co.uk/flightgear/random.tar.gz. > > Further updates available at the above location: > - Improved quad trees (256 leaves rather than 4) with LoD to improve > performance. > Works well with the 3-D tree patch. > - Better use of pseudo-random numbers - previously some objects were > co-located > because they used the same MT seed. Whoops. > > Happy Hogmanay* everyone! > > -Stuart > > * Scots word for the new year celebrations. > > > > __________________________________________________________ > Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d |
From: Frederic B. <fre...@fr...> - 2007-12-31 18:10:13
|
Selon Curtis Olson <cur...@gm...>: > I get this compile fault when I try to build the patch ... :-( > > matmodel.hxx:38:25: error: osg/BillBoard: No such file or directory It should be osg/Billboard ( notice the second upper case B that is not correct ) -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer |