Re: [Flightgear-devel] trees
Syd, We fixed that bug a while back, I hope J. Could you rebuild with the latest FG/SG and try again with the latest FGDATA? I really hope that fixes it! Vivian From: syd adams [mailto:adams@gmail.com] Sent: 18 June 2013 19:16 To: FlightGear developers discussions Subject: [Flightgear-devel] trees No one else has mentioned this so maybe its time for a make clean , but this is what Im seeing after the recent tree updates : http://imagebin.org/261806 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On Tue, Jun 18, 2013 at 8:22 PM, Vivian Meazza wrote: Syd, We fixed that bug a while back, I hope J. Could you rebuild with the latest FG/SG and try again with the latest FGDATA? I really hope that fixes it! Me too! Syd - if it doesn't fix it, can you let me know the following: 1) Are you seeing this for all forested areas (e.g. around KHAF)? Or is this specific to explicitly placed trees in the scenery? 2) Any errors on the console? 3) What rendering settings do you have? Thanks, -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees have gone
I checked for changes in materials.xml and related. But I can’t find any relevant new or changed code, unless my own changes from last summer ... I didn’t check for textures/terrain/shader use for a long time, maybe there are some issues introduced by myself (?) weeks or months ago? Doesn’t matter, no one cares about ;-) Cheers, Yves Am 05.05.11 18:21, schrieb HB-GRAL: Hi all I noticed with git from today that there are no trees at all on some forest types. You can see it around KSFO, where you see forest base textures with and without trees. Looks like some forest types have trees, others don’t. Are there some changes in materials.xml ? (sorry if this is stated already somewhere else, I couldn’t find older posts about this topic in the list). Cheers, Yves -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees rendered too large?
On Sat, Feb 13, 2010 at 2:55 AM, Gijs de Rooy wrote: Hi Rob, I was trying to get a good screenshot which demonstrates this, but I can't find the right arrangement of objects to prove my point at the moment. If you take the UFO, you can place any object at any place... ;) Do we know what the size of the trees are right now? Just looking out my window, I estimate that an average tree around here could be 20-25m tall. But of course trees come in all shapes and sizes. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees rendered too large?
its all configurable in the material.xml file... wood-coverage4000.0/wood-coverage tree-textureTextures/Trees/mixed-summer.png/tree-texture tree-varieties8/tree-varieties tree-range-m alias=/params/forest/tree-range-m/ tree-height-m25.0/tree-height-m tree-width-m15.0/tree-width-m (this is a section for MixedForestCover) -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees rendered too large?
The tree heights are about right for the areas I fly in , although maybe just a bit too wide for pines ... -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees rendered too large?
Curtis Olson wrote: On Sat, Feb 13, 2010 at 2:55 AM, Gijs de Rooy wrote: Hi Rob, I was trying to get a good screenshot which demonstrates this, but I can't find the right arrangement of objects to prove my point at the moment. If you take the UFO, you can place any object at any place... ;) Do we know what the size of the trees are right now? Just looking out my window, I estimate that an average tree around here could be 20-25m tall. But of course trees come in all shapes and sizes. The standard conifers we defined for the Landmass and EvergreenForest terrain are 25m high +/- 50%, and 15m wide, so that's pretty close. Most of our other trees are around the same height - some are 20m. Those interested in playing around with the settings can change the height by modifying the self-explanatory tree-height-m and tree-width-m tags in materials.xml. -Stuart -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees rendered too large?
On 13/02/10 20:24, Rob Shearman, Jr. wrote: Am I the only one who feels like the trees in FlightGear are HUMONGOUS? In some aircraft and near some buildings I just feel like the trees are towering way over some of these larger objects that ordinary trees -- at least, not the ones in suburbia that I'm used to -- just aren't tall enough to eclipse like that. Perhaps if you put some numbers on it it would be easier to judge, have a look around your town and see what sort of usual height trees are. Then compare into FG by looking at how many stories high the usual tree is. I guess around here, mature garden trees (shade, ornamental) would be 1 to 2 stories (5 to 10 meters), fruit trees usually 1 story at most. Pines, gums however much higher, at a guess, a good 20 meters. Poplars similar height, but usually only found as windbreaks in parks and such. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees rendered too large?
Hi Rob, I was trying to get a good screenshot which demonstrates this, but I can't find the right arrangement of objects to prove my point at the moment. If you take the UFO, you can place any object at any place... ;) Cheers, Gijs _ Alles over Windows http://www.windows.nl/About.aspx-- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Syd Adams wrote Hi Tim , just did another update . clouds still hide trees on the horizon , but the trees themselves work like they did before ... thanks On 11/24/09, syd adams adams@gmail.com wrote: I'll give it another try after work ... I should have mentioned that this was the git version I compiled (next branch), Im having trouble getting myself to do cvs up lately , except for data :)... I have an NVidia Geforce 6200 , AMD Athlon 2800+ , not the best , but has done fairly well , I average 25 - 35 with trees /3d clouds enabled. Cheers On 11/24/09, Tim Moore timo...@redhat.com wrote: On 11/24/2009 10:23 AM, Tim Moore wrote: On 11/24/2009 07:53 AM, syd adams wrote: I'll try again ... attached an image so the first email didnt go through . The trees are now thinner here , and knocking my framerate down by 10 fps with the same options I ran before . Trees are being hidden now by the tree texture in front ... they come into view as you fly past and you can distinctly see the tranparent rectangle of the nearest tree ... http://imagebin.ca/view/nP1gTV9m.html http://imagebin.ca/view/worbbHbL.html I gather from the cvs logs that this is a known issue , or is it just me ? Cheers Can you check that your simgear and flightgear are up-to-date? The transparent parts of the tree polygon should not be obscuring geometry behind them. If you still have the problem, tell me what hardware you're running on. Thanks, Tim Whoops, I forgot to check in something. Please update simgear and try again. It's not just on the horizon either: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/low-clouds.png Vivian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On 11/24/2009 07:53 AM, syd adams wrote: I'll try again ... attached an image so the first email didnt go through . The trees are now thinner here , and knocking my framerate down by 10 fps with the same options I ran before . Trees are being hidden now by the tree texture in front ... they come into view as you fly past and you can distinctly see the tranparent rectangle of the nearest tree ... http://imagebin.ca/view/nP1gTV9m.html http://imagebin.ca/view/worbbHbL.html I gather from the cvs logs that this is a known issue , or is it just me ? Cheers Can you check that your simgear and flightgear are up-to-date? The transparent parts of the tree polygon should not be obscuring geometry behind them. If you still have the problem, tell me what hardware you're running on. Thanks, Tim -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On 11/24/2009 10:23 AM, Tim Moore wrote: On 11/24/2009 07:53 AM, syd adams wrote: I'll try again ... attached an image so the first email didnt go through . The trees are now thinner here , and knocking my framerate down by 10 fps with the same options I ran before . Trees are being hidden now by the tree texture in front ... they come into view as you fly past and you can distinctly see the tranparent rectangle of the nearest tree ... http://imagebin.ca/view/nP1gTV9m.html http://imagebin.ca/view/worbbHbL.html I gather from the cvs logs that this is a known issue , or is it just me ? Cheers Can you check that your simgear and flightgear are up-to-date? The transparent parts of the tree polygon should not be obscuring geometry behind them. If you still have the problem, tell me what hardware you're running on. Thanks, Tim Whoops, I forgot to check in something. Please update simgear and try again. Tim -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Hi Tim , just did another update . clouds still hide trees on the horizon , but the trees themselves work like they did before ... thanks On 11/24/09, syd adams adams@gmail.com wrote: I'll give it another try after work ... I should have mentioned that this was the git version I compiled (next branch), Im having trouble getting myself to do cvs up lately , except for data :)... I have an NVidia Geforce 6200 , AMD Athlon 2800+ , not the best , but has done fairly well , I average 25 - 35 with trees /3d clouds enabled. Cheers On 11/24/09, Tim Moore timo...@redhat.com wrote: On 11/24/2009 10:23 AM, Tim Moore wrote: On 11/24/2009 07:53 AM, syd adams wrote: I'll try again ... attached an image so the first email didnt go through . The trees are now thinner here , and knocking my framerate down by 10 fps with the same options I ran before . Trees are being hidden now by the tree texture in front ... they come into view as you fly past and you can distinctly see the tranparent rectangle of the nearest tree ... http://imagebin.ca/view/nP1gTV9m.html http://imagebin.ca/view/worbbHbL.html I gather from the cvs logs that this is a known issue , or is it just me ? Cheers Can you check that your simgear and flightgear are up-to-date? The transparent parts of the tree polygon should not be obscuring geometry behind them. If you still have the problem, tell me what hardware you're running on. Thanks, Tim Whoops, I forgot to check in something. Please update simgear and try again. Tim -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees
John Wojnaroski wrote: My apologies to all the tree-huggers out there ;-) but how does one disable all the trees? Great for mountains and forests scenery tiles; however last month when I was up at Ames don't recall all that lumber around the runway and know that NASA will not care for all the trees around KDFW when they start the research phase of the project. Regards JW Hi John, Setting tree-coverage to 0 in the materials.xml file should do it . Haven't tried myself , I like it as dense as possible :). Cheers, Syd - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees
Behalf Of Syd Sent: 14 April 2008 08:03 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Trees John Wojnaroski wrote: My apologies to all the tree-huggers out there ;-) but how does one disable all the trees? Great for mountains and forests scenery tiles; however last month when I was up at Ames don't recall all that lumber around the runway and know that NASA will not care for all the trees around KDFW when they start the research phase of the project. Regards JW Hi John, Setting tree-coverage to 0 in the materials.xml file should do it . Haven't tried myself , I like it as dense as possible :). Cheers, Syd Nothing like doing things the hard way :-). Try --prop:sim/rendering/random-vegetation=false I use it and it works here. Vivian - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees
Vivian Meazza wrote: Behalf Of Syd Sent: 14 April 2008 08:03 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Trees John Wojnaroski wrote: My apologies to all the tree-huggers out there ;-) but how does one disable all the trees? Great for mountains and forests scenery tiles; however last month when I was up at Ames don't recall all that lumber around the runway and know that NASA will not care for all the trees around KDFW when they start the research phase of the project. Regards JW Hi John, Setting tree-coverage to 0 in the materials.xml file should do it . Haven't tried myself , I like it as dense as possible :). Cheers, Syd Nothing like doing things the hard way :-). Try --prop:sim/rendering/random-vegetation=false I use it and it works here. Vivian Well , ok , that is easier , forgot about that one ... Syd - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees
Syd wrote: Vivian Meazza wrote: Behalf Of Syd Sent: 14 April 2008 08:03 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Trees John Wojnaroski wrote: My apologies to all the tree-huggers out there ;-) but how does one disable all the trees? Great for mountains and forests scenery tiles; however last month when I was up at Ames don't recall all that lumber around the runway and know that NASA will not care for all the trees around KDFW when they start the research phase of the project. Regards JW Hi John, Setting tree-coverage to 0 in the materials.xml file should do it . Haven't tried myself , I like it as dense as possible :). Cheers, Syd Nothing like doing things the hard way :-). Try --prop:sim/rendering/random-vegetation=false I use it and it works here. Vivian Well , ok , that is easier , forgot about that one ... Syd Thanks, BTW, was at a conference last week on PC-based simulations. One presenter from AFRL (Air Force Research Labs) did a survey of major flight sim programs. The three top systems were MSFS, X-Plane, and Flightgear. FG matched up nicely in all areas except documentation, but it was cut a little slack being an OSS program.The presenter was reviewing the 1.0 version. Curt will get a copy of all the presentations; might want to excise that portion and post it Since Curt was having all kinds of fun cruising the Pacific, I had to expand on FG capabilities not discussed. Since the docs are thin in some areas some of the features of FG were not covered. However, while presenting the use of FG and JSBSim on the 747 project, I was able to fill in and add some areas that were not covered, most notably the transition to OSG and AI stuff. Another interesting tidbit, during the RedHat presentation on virtual machines a show off hands from the audience showed a majority (60%) were linux users interesting. John - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Hi! I just notice a blog entry about a company that specializes in tree-simulation for games. As the blogger points out it would be cool to se trees bending when approaching with a helicopter. http://simflyer.blogspot.com/2008/02/holy-foliage-batman.html /nisse On 2/8/08, Stuart Buchanan [EMAIL PROTECTED] wrote: --- Ron Jensen wrote: I had to manually create a random-objects entry in preferences.xml to get the trees to show up: This shouldn't be required, as /sim/rendering/random-vegetation defaults to true. Perhaps you you previously set /sim/rendering/random-vegetation to false? OTOH, we should include it in the preferences.xml file so people can change it easily, so thanks for the patch. -Stuart Index: preferences.xml === RCS file: /var/cvs/FlightGear-0.9/data/preferences.xml,v retrieving revision 1.261 diff -u -r1.261 preferences.xml --- preferences.xml 30 Jan 2008 16:48:04 - 1.261 +++ preferences.xml 8 Feb 2008 05:27:40 - @@ -52,6 +52,7 @@ bare userarchive=y3/bare /static-lod random-objects type=bool userarchive=ytrue/random-objects + random-vegetation type=bool userarchive=ytrue/random-vegetation horizon-effect type=bool userarchive=yfalse/horizon-effect point-sprites type=bool userarchive=ytrue/point-sprites enhanced-lighting type=bool userarchive=yfalse/enhanced-lighting - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ 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 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Nils-Erik Svangård E-Mail: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] Skype: schweingaard Mobil: +46-(0)70-3612178 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
--- Ron Jensen wrote: I had to manually create a random-objects entry in preferences.xml to get the trees to show up: This shouldn't be required, as /sim/rendering/random-vegetation defaults to true. Perhaps you you previously set /sim/rendering/random-vegetation to false? OTOH, we should include it in the preferences.xml file so people can change it easily, so thanks for the patch. -Stuart Index: preferences.xml === RCS file: /var/cvs/FlightGear-0.9/data/preferences.xml,v retrieving revision 1.261 diff -u -r1.261 preferences.xml --- preferences.xml 30 Jan 2008 16:48:04 - 1.261 +++ preferences.xml 8 Feb 2008 05:27:40 - @@ -52,6 +52,7 @@ bare userarchive=y3/bare /static-lod random-objects type=bool userarchive=ytrue/random-objects + random-vegetation type=bool userarchive=ytrue/random-vegetation horizon-effect type=bool userarchive=yfalse/horizon-effect point-sprites type=bool userarchive=ytrue/point-sprites enhanced-lighting type=bool userarchive=yfalse/enhanced-lighting - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ 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 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stuart Buchanan wrote: | --- Tim Moore wrote: | Hi Stuart, | I've checked in your first patch with my cleanup. I haven't had a chance to | play with | the second patch; if you're up for it, you should integrate it with what's now | in CVS; I | don't think it will be too hard. Otherwise you can leave it for me, but that | won't | happen for at least a week. | | I've now integrated my second patch with the CVS code to create a new patch | against CVS. This includes | - a separate property (/sim/rendering/random-vegetation) to control whether the | trees are displayed or not (the default is true) | - pseudo-random tree size variation (up to +/- 50%) | - pseudo-random tree texture variation. | | It is available from http://www.nanjika.co.uk/flightgear/trees.tar.gz. | | It hasn't had a huge amount of testing, but the changes are fairly | straightforward. This has been checked in. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHq5HfeDhWHdXrDRURAo9OAJ47NZhi1bLXDlgX5F+Pra8QdmYVBQCgkmJQ 9Il3Rgz+x4jalTUFuVsSKu0= =pbsm -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On Fri, 2008-02-08 at 00:18 +0100, Tim Moore wrote: | I've now integrated my second patch with the CVS code to create a new patch | against CVS. This includes | - a separate property (/sim/rendering/random-vegetation) to control whether the | trees are displayed or not (the default is true) | - pseudo-random tree size variation (up to +/- 50%) | - pseudo-random tree texture variation. | | It is available from http://www.nanjika.co.uk/flightgear/trees.tar.gz. | | It hasn't had a huge amount of testing, but the changes are fairly | straightforward. This has been checked in. Tim I had to manually create a random-objects entry in preferences.xml to get the trees to show up: Index: preferences.xml === RCS file: /var/cvs/FlightGear-0.9/data/preferences.xml,v retrieving revision 1.261 diff -u -r1.261 preferences.xml --- preferences.xml 30 Jan 2008 16:48:04 - 1.261 +++ preferences.xml 8 Feb 2008 05:27:40 - @@ -52,6 +52,7 @@ bare userarchive=y3/bare /static-lod random-objects type=bool userarchive=ytrue/random-objects + random-vegetation type=bool userarchive=ytrue/random-vegetation horizon-effect type=bool userarchive=yfalse/horizon-effect point-sprites type=bool userarchive=ytrue/point-sprites enhanced-lighting type=bool userarchive=yfalse/enhanced-lighting - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
--- Tim Moore wrote: Hi Stuart, I've checked in your first patch with my cleanup. I haven't had a chance to play with the second patch; if you're up for it, you should integrate it with what's now in CVS; I don't think it will be too hard. Otherwise you can leave it for me, but that won't happen for at least a week. I've now integrated my second patch with the CVS code to create a new patch against CVS. This includes - a separate property (/sim/rendering/random-vegetation) to control whether the trees are displayed or not (the default is true) - pseudo-random tree size variation (up to +/- 50%) - pseudo-random tree texture variation. It is available from http://www.nanjika.co.uk/flightgear/trees.tar.gz. It hasn't had a huge amount of testing, but the changes are fairly straightforward. As people have noticed, currently the different tree textures are merely colour variations on the current shapes. It would be great if someone who knows their way around GIMP could spend a little time improving the tree textures. I'm sure this would improve the realism greatly for minimal effort Comments are very welcome as always. -Stuart __ 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 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Quoting Stuart Buchanan : As people have noticed, currently the different tree textures are merely colour variations on the current shapes. It would be great if someone who knows their way around GIMP could spend a little time improving the tree textures. I'm sure this would improve the realism greatly for minimal effort Are you aware of this tool : http://dryad.stanford.edu/ -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Em Qua, 2008-02-06 às 16:57 +0100, Frederic Bouvier escreveu: Are you aware of this tool : http://dryad.stanford.edu/ Or this one: http://arbaro.sourceforge.net/ Diogo - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Stuart Buchanan writes: As people have noticed, currently the different tree textures are merely colour variations on the current shapes. It would be great if someone who knows their way around GIMP could spend a little time improving the tree textures. I'm sure this would improve the realism greatly for minimal effort http://vterrain.org/Plants/index.html - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Am Sonntag, den 03.02.2008, 00:17 +0100 schrieb Tim Moore: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stuart Buchanan wrote: | --- Stuart Buchanan wrote: | --- Stuart Buchanan wrote: | Hi All, | | Just a quick note to mention that I've now implemented random tree height, | and | multiple textures as suggested by Curt. Screenshot here: | | http://www.nanjika.co.uk/flightgear/forest2.jpg | | Still some work to be done, but it is looking more realistic. | | Tim - I've been cleaning up my code a bit, so unless you've already started, | I'd | hold off trying to kick my previous patch into shape for CVS. I should have a | new | patch fairly soon. | A patch for this is now available from | http:/www.nanjika.co.uk/flightgear/trees.tar.gz. Hi Stuart, I've checked in your first patch with my cleanup. I haven't had a chance to play with the second patch; if you're up for it, you should integrate it with what's now in CVS; I don't think it will be too hard. Otherwise you can leave it for me, but that won't happen for at least a week. This is really impresive! FlightGear experiences some great development these days. Is there a possibility to replace the 3d Model of the trees? I didn't notice any .ac file for them. I'm pretty happy with the results. My test area is KHAF, and I can mostly maintain 60Hz with an NVidia 8800 GTS. With 400k random trees in the scene graph, that's pretty reasonable. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHpPoneDhWHdXrDRURAvQqAJ9Fheuyr50UKdUdcuRXsYBbuyZ+QwCfTIIb SeJoO/fkFccI1uQyzvsFh68= =tY7X -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stuart Buchanan wrote: | --- Stuart Buchanan wrote: | --- Stuart Buchanan wrote: | Hi All, | | Just a quick note to mention that I've now implemented random tree height, | and | multiple textures as suggested by Curt. Screenshot here: | | http://www.nanjika.co.uk/flightgear/forest2.jpg | | Still some work to be done, but it is looking more realistic. | | Tim - I've been cleaning up my code a bit, so unless you've already started, | I'd | hold off trying to kick my previous patch into shape for CVS. I should have a | new | patch fairly soon. | A patch for this is now available from | http:/www.nanjika.co.uk/flightgear/trees.tar.gz. Hi Stuart, I've checked in your first patch with my cleanup. I haven't had a chance to play with the second patch; if you're up for it, you should integrate it with what's now in CVS; I don't think it will be too hard. Otherwise you can leave it for me, but that won't happen for at least a week. I'm pretty happy with the results. My test area is KHAF, and I can mostly maintain 60Hz with an NVidia 8800 GTS. With 400k random trees in the scene graph, that's pretty reasonable. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHpPoneDhWHdXrDRURAvQqAJ9Fheuyr50UKdUdcuRXsYBbuyZ+QwCfTIIb SeJoO/fkFccI1uQyzvsFh68= =tY7X -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
hi stuart, i have missed you on irc today. and i wanted to tell you that indeed the second patch is much better in terms of memory usage. it saves 80 megs of allocations compared to your first patch :-) and considering it looks even prettier than the first one... congratulations! -till On Monday 28 January 2008, Stuart Buchanan wrote: The current patch is a bit better for memory usage IIRC, but it is still quite hefty - a side-effect of generating all the trees at once for the tile. -Stuart - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Hi! It would be cool with a scalable fractal forest, where every tree differs or is copied (depending on hardware). And then you can hook up that system with free weaterservices like weatherunderground, and simulate treemovments based on local weather :D That could work for other weather in realtime also, rain when it actually rains, and dynamicly loading a snow layer texture if its below zero. ;) /nisse On 1/28/08, Ulrich Hertlein [EMAIL PROTECTED] wrote: Quoting Stuart Buchanan [EMAIL PROTECTED]: Currently I create a 32x32 quadtree across the extent of the trees within the tile. If there are trees at each corner of the tile, that effectively means ... Alternative approaches and any comments would be gratefully received. As I understand it you have a group of 32x32 LOD nodes for each tile. Have you tried using a quad-tree instead of a single node? That may help tremendously with the cull performance. /ulrich - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Nils-Erik Svangård E-Mail: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] Skype: schweingaard Mobil: +46-(0)70-3612178 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
--- Tim Moore wrote: Curtis Olson wrote: | Definitely ... we could vary them in shape and appearance, not just | color. There is much that can be done. Already supported. The current patch allows different shapes and appearance. The reason that the trees currently just vary by colour is entirely due to my level of artistic ability. If you have a look in the data/Textures/Trees/ directory you will see that the .rgb files are actually a strip of different trees, evenly distributed along the x-axis. You can change them in any way you want, as long as you ensure that they are evenly spaced, and you update the tree-varieties tag in materials.xml to match. In fact, it would be great if someone with some artistic skill could work on the textures. You can even vary the distribution of the different tree types by including similar textures multiple times. | (I haven't dug much in the code for these trees, but ...) it appears | that the random locations are computed as areas come into view (or come | close enough to the viewer.) So each time a new chunk of trees are | added, I see a blip in the frame rates. If there are a lot of chunks | that need to be added, that translates into a lot of blips. Would it be | possible to compute the locations of the trees when the tile is loaded | (in the load thread) and always have these structures available when | needed? Now that we can have such wide tree coverage, we'll be burning | the memory for these structures anyway. Previously, David's code only | built the random object structures for areas close by because having all | the random object structures for all the tiles in memory simultaneously | would be a huge waste. I suspect the plib based random object scene | graph structures were much more wasteful than the structures needed by | the OSG shader based approach. The locations are computed when the tile is loaded. I think the blips you're seeing are caused by compiling a new shader program per chunk of trees. That problem should go away when the code is integrated into cvs. I think the current patch has already fix this. A single osg::Program which includes the Shaders is instantiated the first time any trees are generated, and re-used after that point... unless OSG is doing something particularly silly, or my code is bugged. The blips are more likely due to the generation of the huge number of trees when the tile is loaded. I haven't counted them, but we must be generating hundreds of thousands for some tiles. BTW - the current patch is more efficient in this respect as well. -Stuart ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
--- Curtis Olson wrote: In this case the trees aren't so much loaded ... there's only one small texture that defines the trees (or group of randomized tree images.) What does need to be done is that a set of random locations needs to be generated across the surface of each tile ... and this needs to happen sometime after the terrain is loaded. Right now this appears to be done in the main render thread once the polygons get within some visible distance (although the behavior of this is slightly weird and you can be ontop of an area before the trees are actually generated.) The tree locations are generated when the tile is loaded, not when they come into view. The tree visibility is a problem I'm still trying to solve. Currently I create a 32x32 quadtree across the extent of the trees within the tile. If there are trees at each corner of the tile, that effectively means that the tile is split into a straightforward 32x32 grid. Each rectangle in the grid is a LoD node with a range of 8000m, under which are all the trees within that space, within a Group node. So, all the trees in the rectangle become visible when you get within 8000m of the center of the rectangle. I _think_ that sometimes the center of the rectangle is more than 8000m from the edge, which is why you can be ontop of the area before they appear. However, in some cases I've see the area I am on top of _not_ have trees, even though the areas to either side do, or the visibility of the trees depends on the direction I'm looking. I'm not sure the reason for this - it could be that the LoD loader is catching up, or something. BTW - could someone tell me the maximum size of a tile, in km? If people want to experiment with different settings: - TreeBin.hxx line 57 (#define SG_TREE_QUAD_TREE_SIZE 32) defines the size of the grid. - materials.xml line 96 (tree-range-m8000/tree-range-m) defines the LoD range for the trees. I'm thinking of changing the approach so that instead of working out the extent of the grid from the set of trees, we simply create a NxN grid across the tile, put the trees in appropriately, and then remove the empty nodes. This would have the advantage of improving performance when the tile is loaded: Currently we iterate through the list of trees twice - once to work out the extent of the grid, and then again to place the trees in the correct rectangle. Alternative approaches and any comments would be gratefully received. -Stuart ___ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
hi since i'm already much into memory-stuff i'll add my 2 cents... On Sunday 27 January 2008, Curtis Olson wrote: ... Would it be possible to compute the locations of the trees when the tile is loaded (in the load thread) and always have these structures available when needed? Now that we can have such wide tree coverage, we'll be burning the memory for these structures anyway. from my first research it seems like we are burning *lots* of memory for the trees. enabling trees results in about 137 mb of aditional allocations. with trees, valgrind reports 818 mb of allocations. this count is the figure i get from starting fg, waiting for the scenerey to be loaded and letting it run for another 10 frames before exiting with fgOSExit(0). also it is important to note that the figure shows all memory that is being allocated (on the heap, as far as i can tell). so it also shows temporary allocations. i don't have the time to dig deeper here right now. i just wanted to make these firures visible for those concerned. also note that this is with the first tree implementation (one-texture-version), i haven't tried the current one yet. ... On Sunday 27 January 2008, Curtis Olson wrote: One of the reasons (I think) that OSG start up times are so long is that the loading is getting interleaved with the FDM and everything else, but we aren't actually showing the view until the loader has loaded enough data. So there is much wasted effort at the beginning until enough terrain is loaded and the splash screen is removed and the terrain actually drawn. This code has grown really complex over the years, but at some point, now that we are using OSG, it might be worth revisiting some of these earlier design choices. They made sense for a plib world, but perhaps not for an OSG world with better threading support. you are very much right on this one. probably a week ago i have modified the main loop do delay everything else until the scenery is loaded. startup time is a lot better this way (14 vs. 11 secs on the fast machine) -- and from my impressions it doesn't seem to break anything. i will dig deeper into this if noone oppoeses. might take some time though, as we just got our second son :-) i think flightgear could really benefit from a rewrite or restructuring of Main. also since we are not near a release yet (is that right?), we do not need to fear this. all together i believe we have a lot of people running cvs versions. cvs can move fast until the next release is being prepared. regards, - till - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
--- Stuart Buchanan [EMAIL PROTECTED] schrieb: In fact, it would be great if someone with some artistic skill could work on the textures. You can even vary the distribution of the different tree types by including similar textures multiple times. Sebastian Bechthold had nice trees in a package some time ago- can be found somewhere in the german forum. Maybe he is reading it, so he can provide it again... I have a copy, but without his permission I won't upload it... HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Ihr erstes Fernweh? Wo gibt es den schönsten Strand? www.yahoo.de/clever - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Quoting AJ MacLeod : On Monday 28 January 2008 11:02:11 Stuart Buchanan wrote: The current patch is a bit better for memory usage IIRC, but it is still quite hefty - a side-effect of generating all the trees at once for the tile. By all means we should be careful about needless memory usage / wastage (and perhaps features that demand lots of memory should be disabled by default.) At the same time, memory is extremely cheap, (mostly) easy to upgrade and modern PCs are generally equipped with huge amounts of it. If nice new features require lots of memory to work well and are optional, I don't see any particular problem... Don't forget that if you run a 32-bit system, a process is limited to 2Gb of virtual memory, not matter the actual physical memory. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On Monday 28 January 2008 11:02:11 Stuart Buchanan wrote: The current patch is a bit better for memory usage IIRC, but it is still quite hefty - a side-effect of generating all the trees at once for the tile. By all means we should be careful about needless memory usage / wastage (and perhaps features that demand lots of memory should be disabled by default.) At the same time, memory is extremely cheap, (mostly) easy to upgrade and modern PCs are generally equipped with huge amounts of it. If nice new features require lots of memory to work well and are optional, I don't see any particular problem... Cheers, AJ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
--- till busch wrote: hi since i'm already much into memory-stuff i'll add my 2 cents... On Sunday 27 January 2008, Curtis Olson wrote: ... Would it be possible to compute the locations of the trees when the tile is loaded (in the load thread) and always have these structures available when needed? Now that we can have such wide tree coverage, we'll be burning the memory for these structures anyway. from my first research it seems like we are burning *lots* of memory for the trees. enabling trees results in about 137 mb of aditional allocations. with trees, valgrind reports 818 mb of allocations. this count is the figure i get from starting fg, waiting for the scenerey to be loaded and letting it run for another 10 frames before exiting with fgOSExit(0). also it is important to note that the figure shows all memory that is being allocated (on the heap, as far as i can tell). so it also shows temporary allocations. i don't have the time to dig deeper here right now. i just wanted to make these firures visible for those concerned. also note that this is with the first tree implementation (one-texture-version), i haven't tried the current one yet. The current patch is a bit better for memory usage IIRC, but it is still quite hefty - a side-effect of generating all the trees at once for the tile. -Stuart __ 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 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
* Maik Justus -- Monday 28 January 2008: The texture is scaled (mip mapping?), and therefore the new alpha value is interpolated between the original values resulting in semi-transparent values. You could set the alpha threshold appropriately: $ man glAlphaFunc (or whatever the OSG equivalent is) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On Jan 28, 2008 2:18 PM, Maik Justus wrote: The transparency--bug appears only, where the alpha channel of the texture is neither 0 nor 100%. Therefore I changed the alpha channel to be only zero or 100%. But the problem is not solved. The texture is scaled (mip mapping?), and therefore the new alpha value is interpolated between the original values resulting in semi-transparent values. If it would be possible to exclude the alpha channel of the tree-textures from the interpolation, the transparency problem could be solved fully without any sorting (just by changing the textures). If it is not possible: sorting of the triangles within each tree would help in many cases. If you removed the transparency entirely then I believe that the edges of all the trees will develop aliasing artifacts ... kind of like if they were drawn with polygons. And as the mipmapping switches levels you might see additional odd artifacts. I'm pretty sure that if Stuart/Tim switch around the draw order so that the terrain is drawn first, then the problem will all but go away. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Hi Stuart, Stuart Buchanan schrieb am 28.01.2008 10:25: If you have a look in the data/Textures/Trees/ directory you will see that the .rgb files are actually a strip of different trees, evenly distributed along the x-axis. You can change them in any way you want, as long as you ensure that they are evenly spaced, and you update the tree-varieties tag in materials.xml to match. The transparency--bug appears only, where the alpha channel of the texture is neither 0 nor 100%. Therefore I changed the alpha channel to be only zero or 100%. But the problem is not solved. The texture is scaled (mip mapping?), and therefore the new alpha value is interpolated between the original values resulting in semi-transparent values. If it would be possible to exclude the alpha channel of the tree-textures from the interpolation, the transparency problem could be solved fully without any sorting (just by changing the textures). If it is not possible: sorting of the triangles within each tree would help in many cases. Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Stuart wrote Sent: 26 January 2008 21:18 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] trees --- Stuart Buchanan wrote: --- Stuart Buchanan wrote: Hi All, Just a quick note to mention that I've now implemented random tree height, and multiple textures as suggested by Curt. Screenshot here: http://www.nanjika.co.uk/flightgear/forest2.jpg Still some work to be done, but it is looking more realistic. Tim - I've been cleaning up my code a bit, so unless you've already started, I'd hold off trying to kick my previous patch into shape for CVS. I should have a new patch fairly soon. A patch for this is now available from http:/www.nanjika.co.uk/flightgear/trees.tar.gz. Note that there are some additional new files for the tree textures and some re-organizing of the code - see the included README. Doh! I didn't notice that I had changed the FlightGear source too... The patch below adds the appropriate property value check, and I've updated the tarball and README to include it. At some point I'll need to add a setting to the preferences.xml file too, but first we need to decide whether the trees should be on by default (like the random objects) or not. Any opinions? The patch is broken here - there is some corruption in simgear.patch which causes the file to appear empty when it is read by the patch utility, or by Vi etc. Csaba provided me with a complete patched Simgear source (thanks) so I was able to compile and run fg. The trees look very nice, and, at least in the numbers I saw, have a minimal impact on frame rate (2-3). I would think that on could be the default mode. Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Stuart Sent: 27 January 2008 10:42 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] trees --- Vivian Meazza wrote: The patch is broken here - there is some corruption in simgear.patch which causes the file to appear empty when it is read by the patch utility, or by Vi etc. Csaba provided me with a complete patched Simgear source (thanks) so I was able to compile and run fg. The trees look very nice, and, at least in the numbers I saw, have a minimal impact on frame rate (2-3). I would think that on could be the default mode. It looks like the checked in source to mat.hxx has some strange characters on lines 70, 111, 218, 240, 290. In each case they appear on the line above a block comment. vi thinks they are ^L characters. The simgear.patch file doesn't change them, though it does include one of them to provide context information for the patch utility on line 120. I wonder if that is what is causing the problem? According to the CVS browser, they've been in there since the original check-in of the file (4 years ago, but Curt). Anyone any idea why they are there? If there isn't any particular reason for them to be there, could someone with CVS access remove them? I'd provide a patch, but it looks like that doesn't work particularly well :) Yes, I guessed that the ^Ls might be the culprit, but couldn't prove it. And the rest of the patch was fine, just simgear.patch failed Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On Jan 27, 2008 8:00 AM, Maik Justus wrote: Yes, that did it. There is a problem with the draw ordering leading to a transparency bug. It seems, that the trees are done by only two triangles, intersecting each other. Due to the intersecting none of the two possible orderings are correct. At least one of the two triangles need to be separated into two triangle (along th intersection line). I suspect that depth sorting a million trees might be prohibitive from a performance standpoint. We may have to live with the issue, or switch to billboarded trees, or come up with something clever that only sorts nearby trees? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: | On Jan 27, 2008 8:00 AM, Maik Justus wrote: | | Yes, that did it. There is a problem with the draw ordering leading to a | transparency bug. It seems, that the trees are done by only two | triangles, intersecting each other. Due to the intersecting none of the | two possible orderings are correct. At least one of the two triangles | need to be separated into two triangle (along th intersection line). | | | I suspect that depth sorting a million trees might be prohibitive from a | performance standpoint. We may have to live with the issue, or switch | to billboarded trees, or come up with something clever that only sorts | nearby trees? | You've got that right. The approach I'm taking in integrating Stuart's work is to not depth-sort the trees at all. Instead: crank the alpha test value up draw the trees after the terrain so the sky doesn't appear to poke through the terrain. Ultimately we might want to change the tree texture maps a bit. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHnNKQeDhWHdXrDRURAupLAJ9b6eIKiXWNxWNCNVSfPSBG7DFuuQCbBbXK YKV62Zril030bDvol48fucw= =q6R7 -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On Jan 27, 2008 12:50 PM, Tim Moore [EMAIL PROTECTED] wrote: You've got that right. The approach I'm taking in integrating Stuart's work is to not depth-sort the trees at all. Instead: crank the alpha test value up draw the trees after the terrain so the sky doesn't appear to poke through the terrain. That's a good point. If the terrain is drawn first, then the blue-sky fringe around the trees will all but go away. Ultimately we might want to change the tree texture maps a bit. Definitely ... we could vary them in shape and appearance, not just color. There is much that can be done. (I haven't dug much in the code for these trees, but ...) it appears that the random locations are computed as areas come into view (or come close enough to the viewer.) So each time a new chunk of trees are added, I see a blip in the frame rates. If there are a lot of chunks that need to be added, that translates into a lot of blips. Would it be possible to compute the locations of the trees when the tile is loaded (in the load thread) and always have these structures available when needed? Now that we can have such wide tree coverage, we'll be burning the memory for these structures anyway. Previously, David's code only built the random object structures for areas close by because having all the random object structures for all the tiles in memory simultaneously would be a huge waste. I suspect the plib based random object scene graph structures were much more wasteful than the structures needed by the OSG shader based approach. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Curtis Olson writes: (I haven't dug much in the code for these trees, but ...) it appears that the random locations are computed as areas come into view (or come close enough to the viewer.) So each time a new chunk of trees are added, I see a blip in the frame rates. If there are a lot of chunks that need to be added, that translates into a lot of blips. Would it be possible to compute the locations of the trees when the tile is loaded (in the load thread) and always have these structures available when needed? note I haven't dug into the code either The standard way of doing this is to time limit the loader Thread. Eg loading trees only a few per frame as time allows. perhaps into a temporary data object. The OSG LOD loader thread is an example of how to do this Cheers Norman - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
* Curtis Olson -- Sunday 27 January 2008:
Would this speed things up:
find / -name '*.ac' -exec osgconv {} /`basename {} .ac`.osg \;
(i.e. create a model.osg in / for every model.ac on your hard drive?)
Could be, but I wouldn't want that. This has the potential to
break a lot. The problem at the moment is that, indeed, fgfs
searches for a cow.osg and even picks that up from the dir that
the OSG_FILE_PATH variable points to, although the requested
*.ac version is right there! fgfs would just have to pick it,
not ignore it. And the cow.osg version in OSG_FILE_PATH (if set
to the OSG data dir, which is necessary to make the OSG demos
work) is the chrome shaded high-poly cow, halfway sunk in the
ground.
m.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
* Curtis Olson -- Sunday 27 January 2008: One of the reasons (I think) that OSG start up times are so long is that the loading is getting interleaved with the FDM and everything else, but we aren't actually showing the view until the loader has loaded enough data. One can show the view immediately with --prop:sim/sceneryloaded-override=true but still, OSG takes a lot longer to finish loading scenery objects. Maybe that's because it scans the whole harddisk for instances of cow.osg ... ;-) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: | On Jan 27, 2008 12:50 PM, Tim Moore [EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] wrote: | | You've got that right. The approach I'm taking in integrating | Stuart's work is to not | depth-sort the trees at all. Instead: | | crank the alpha test value up | draw the trees after the terrain so the sky doesn't appear to poke | through the terrain. | | | That's a good point. If the terrain is drawn first, then the blue-sky | fringe around the trees will all but go away. | | Ultimately we might want to change the tree texture maps a bit. | | | Definitely ... we could vary them in shape and appearance, not just | color. There is much that can be done. | | (I haven't dug much in the code for these trees, but ...) it appears | that the random locations are computed as areas come into view (or come | close enough to the viewer.) So each time a new chunk of trees are | added, I see a blip in the frame rates. If there are a lot of chunks | that need to be added, that translates into a lot of blips. Would it be | possible to compute the locations of the trees when the tile is loaded | (in the load thread) and always have these structures available when | needed? Now that we can have such wide tree coverage, we'll be burning | the memory for these structures anyway. Previously, David's code only | built the random object structures for areas close by because having all | the random object structures for all the tiles in memory simultaneously | would be a huge waste. I suspect the plib based random object scene | graph structures were much more wasteful than the structures needed by | the OSG shader based approach. The locations are computed when the tile is loaded. I think the blips you're seeing are caused by compiling a new shader program per chunk of trees. That problem should go away when the code is integrated into cvs. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHnPINeDhWHdXrDRURAiyMAKDPjTN+BN1bdoCVtlt7c2UNTXRlFwCfZiPr k3jqdy9BAQZbWmTToeRn2r8= =4Ehq -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Hi All, Just a quick note to mention that I've now implemented random tree height, and multiple textures as suggested by Curt. Screenshot here: http://www.nanjika.co.uk/flightgear/forest2.jpg Still some work to be done, but it is looking more realistic. Tim - I've been cleaning up my code a bit, so unless you've already started, I'd hold off trying to kick my previous patch into shape for CVS. I should have a new patch fairly soon. Two other questions for Tim, or anyone else familiar with OSG/OpenGL: 1) For the diffuse lighting, presumably I should calculate the normal when creating the geometry, and it will appear as gl_Normal in the shader right? 2) I've been finding it impossible to work out how to pass in generic attributes into the shader. I've managed to bind an attribute to a location using program-addBindAttribLocation(textureIndex, 1); but I can't seem to set the attribute afterwards. I should be able to use glVertexAttrib... functions, but they don't compile on Visual Studio. Any ideas ? -Stuart ___ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Hi All, Just a quick note to mention that I've now implemented random tree height, and multiple textures as suggested by Curt. Screenshot here: http://www.nanjika.co.uk/flightgear/forest2.jpg Still some work to be done, but it is looking more realistic. That looks very impressive! Really nice. Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Stuart Buchanan a écrit : Hi All, Just a quick note to mention that I've now implemented random tree height, and multiple textures as suggested by Curt. Screenshot here: http://www.nanjika.co.uk/flightgear/forest2.jpg Still some work to be done, but it is looking more realistic. Impressive Tim - I've been cleaning up my code a bit, so unless you've already started, I'd hold off trying to kick my previous patch into shape for CVS. I should have a new patch fairly soon. Two other questions for Tim, or anyone else familiar with OSG/OpenGL: 1) For the diffuse lighting, presumably I should calculate the normal when creating the geometry, and it will appear as gl_Normal in the shader right? According to the orange book, yes 2) I've been finding it impossible to work out how to pass in generic attributes into the shader. I've managed to bind an attribute to a location using program-addBindAttribLocation(textureIndex, 1); but I can't seem to set the attribute afterwards. I should be able to use glVertexAttrib... functions, but they don't compile on Visual Studio. Any ideas ? Why not using osg::Geometry::setVertexAttribArray instead of raw gl functions ? Standard OpenGL under windows is 1.1. Extensions have to be loaded manually. OSG should do it for you. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
--- Stuart Buchanan wrote: Hi All, Just a quick note to mention that I've now implemented random tree height, and multiple textures as suggested by Curt. Screenshot here: http://www.nanjika.co.uk/flightgear/forest2.jpg Still some work to be done, but it is looking more realistic. Tim - I've been cleaning up my code a bit, so unless you've already started, I'd hold off trying to kick my previous patch into shape for CVS. I should have a new patch fairly soon. A patch for this is now available from http:/www.nanjika.co.uk/flightgear/trees.tar.gz. Note that there are some additional new files for the tree textures and some re-organizing of the code - see the included README. -Stuart ___ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederic Bouvier wrote: | Stuart Buchanan a écrit : | 2) I've been finding it impossible to work out how to pass in generic attributes | into the shader. I've managed to bind an attribute to a location using | program-addBindAttribLocation(textureIndex, 1); but I can't seem to set the | attribute afterwards. I should be able to use glVertexAttrib... functions, but | they don't compile on Visual Studio. Any ideas ? | | | Why not using osg::Geometry::setVertexAttribArray instead of raw gl | functions ? Standard OpenGL under windows is 1.1. Extensions have to be | loaded manually. OSG should do it for you. Stuart's trying to use attributes to set state before calling a display list, so the array functions aren't usable here. The easiest thing would be to use osg::Drawable::Extensions and look at the OSG source code for examples of using it. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHm2pJeDhWHdXrDRURApDuAKCpwW4QeDLyXlvkraF5Mjdmm+e6PwCeOIDt uTqUK5Oa63xFl69f6ppa4sk= =7u9W -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Stuart, Stuart Buchanan a écrit : --- Stuart Buchanan wrote: Hi All, Just a quick note to mention that I've now implemented random tree height, and multiple textures as suggested by Curt. Screenshot here: http://www.nanjika.co.uk/flightgear/forest2.jpg Still some work to be done, but it is looking more realistic. Tim - I've been cleaning up my code a bit, so unless you've already started, I'd hold off trying to kick my previous patch into shape for CVS. I should have a new patch fairly soon. A patch for this is now available from http:/www.nanjika.co.uk/flightgear/trees.tar.gz. Note that there are some additional new files for the tree textures and some re-organizing of the code - see the included README. I applied your new patch and I don't have trees, although they were working with the last one. It seems to me that there is a missing bit for flightgear because the setUseRandomVegetation function is never called and stay to false. Maybe there is a patch to options.cxx sitting on your disc. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
For everybody, to apply the 2nd Stuart's patch ; don't forget adding the TreeBin.cxx and TreeBin.hxx in the file : simgear/scene/tgdb/Makefile.am The patch : Index: Makefile.am === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/tgdb/Makefile.am,v retrieving revision 1.7 diff -u -r1.7 Makefile.am --- Makefile.am 13 Dec 2007 23:30:25 - 1.7 +++ Makefile.am 26 Jan 2008 18:55:17 - @@ -18,7 +18,8 @@ SGTexturedTriangleBin.hxx \ SGTriangleBin.hxx \ SGVertexArrayBin.hxx \ - GroundLightManager.hxx + GroundLightManager.hxx \ + TreeBin.hxx libsgtgdb_a_SOURCES = \ apt_signs.cxx \ @@ -28,6 +29,7 @@ SGOceanTile.cxx \ SGReaderWriterBTG.cxx \ SGVasiDrawable.cxx \ - GroundLightManager.cxx + GroundLightManager.cxx \ + TreeBin.cxx INCLUDES = -I$(top_srcdir) Then, if you want to test quickly the Trees feature : Index: tileentry.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/Scenery/tileentry.cxx,v retrieving revision 1.64 diff -u -r1.64 tileentry.cxx --- tileentry.cxx 20 Dec 2007 23:20:52 - 1.64 +++ tileentry.cxx 26 Jan 2008 18:56:36 - @@ -273,6 +273,7 @@ options-setMatlib(globals-get_matlib()); options-setCalcLights(is_base); options-setUseRandomObjects(use_random_objects); +options-setUseRandomVegetation(true); osg::Node* node = osgDB::readNodeFile(path, options.get()); if (node) geometry-addChild(node); Now, we need to correct all terrains... to have trees working ; and add corn (with or without OGM) field, wheat field... Le samedi 26 janvier 2008 à 19:29 +0100, Maik Justus a écrit : Hi Fred, Hi Stuart, Frederic Bouvier schrieb am 26.01.2008 19:22: Stuart, Stuart Buchanan a écrit : --- Stuart Buchanan wrote: Hi All, Just a quick note to mention that I've now implemented random tree height, and multiple textures as suggested by Curt. Screenshot here: http://www.nanjika.co.uk/flightgear/forest2.jpg Still some work to be done, but it is looking more realistic. Tim - I've been cleaning up my code a bit, so unless you've already started, I'd hold off trying to kick my previous patch into shape for CVS. I should have a new patch fairly soon. A patch for this is now available from http:/www.nanjika.co.uk/flightgear/trees.tar.gz. Note that there are some additional new files for the tree textures and some re-organizing of the code - see the included README. I applied your new patch and I don't have trees, although they were working with the last one. same here (but your new screenshot looks great). Maik It seems to me that there is a missing bit for flightgear because the setUseRandomVegetation function is never called and stay to false. Maybe there is a patch to options.cxx sitting on your disc. -Fred - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
--- Stuart Buchanan wrote:
--- Stuart Buchanan wrote:
Hi All,
Just a quick note to mention that I've now implemented random tree height,
and
multiple textures as suggested by Curt. Screenshot here:
http://www.nanjika.co.uk/flightgear/forest2.jpg
Still some work to be done, but it is looking more realistic.
Tim - I've been cleaning up my code a bit, so unless you've already started,
I'd
hold off trying to kick my previous patch into shape for CVS. I should have
a
new
patch fairly soon.
A patch for this is now available from
http:/www.nanjika.co.uk/flightgear/trees.tar.gz.
Note that there are some additional new files for the tree textures and some
re-organizing of the code - see the included README.
Doh! I didn't notice that I had changed the FlightGear source too...
The patch below adds the appropriate property value check, and I've updated the
tarball and README to include it.
At some point I'll need to add a setting to the preferences.xml file too, but
first we need to decide whether the trees should be on by default (like the
random objects) or not.
Any opinions?
-Stuart
Index: Scenery/tileentry.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Scenery/tileentry.cxx,v
retrieving revision 1.64
diff -u -r1.64 tileentry.cxx
--- Scenery/tileentry.cxx 20 Dec 2007 23:20:52 - 1.64
+++ Scenery/tileentry.cxx 26 Jan 2008 16:18:54 -
@@ -266,6 +266,9 @@
{
bool use_random_objects =
fgGetBool(/sim/rendering/random-objects, true);
+
+bool use_random_vegetation =
+fgGetBool(/sim/rendering/random-vegetation, true);
// try loading binary format
osg::ref_ptrSGReaderWriterBTGOptions options
@@ -273,6 +276,7 @@
options-setMatlib(globals-get_matlib());
options-setCalcLights(is_base);
options-setUseRandomObjects(use_random_objects);
+options-setUseRandomVegetation(use_random_vegetation);
osg::Node* node = osgDB::readNodeFile(path, options.get());
if (node)
geometry-addChild(node);
___
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On Sat, 26 Jan 2008 07:30:09 -0600, Jon wrote in message [EMAIL PROTECTED]: Hi All, Just a quick note to mention that I've now implemented random tree height, and multiple textures as suggested by Curt. Screenshot here: http://www.nanjika.co.uk/flightgear/forest2.jpg Still some work to be done, but it is looking more realistic. That looks very impressive! Really nice. ..aye. Warrants its own release, 1.1, sea level rise or no sea level rise. Tweaks would be allowing larger open clearings, more trees in tighter and larger clusters, and let tree height depend on altitude, you'll see the each tree getting small at the tree limit, size depends on wind and snow coverage. Shape, too, is affected by prevailing wind and wind protection. Why do I have these eerie images of emerging forestry etc simulators? ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederic Bouvier wrote: | Stuart Buchanan a écrit : | 2) I've been finding it impossible to work out how to pass in generic attributes | into the shader. I've managed to bind an attribute to a location using | program-addBindAttribLocation(textureIndex, 1); but I can't seem to set the | attribute afterwards. I should be able to use glVertexAttrib... functions, but | they don't compile on Visual Studio. Any ideas ? | | | Why not using osg::Geometry::setVertexAttribArray instead of raw gl | functions ? Standard OpenGL under windows is 1.1. Extensions have to be | loaded manually. OSG should do it for you. Stuart's trying to use attributes to set state before calling a display list, so the array functions aren't usable here. The easiest thing would be to use osg::Drawable::Extensions and look at the OSG source code for examples of using it. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHm8YOeDhWHdXrDRURAvD3AKDDbFKR9CcgPkIQ6PpUERoVjwfn1ACgso62 zXGPCej0n7pk9jyZjVqHlmg= =6QjO -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stuart Buchanan wrote: | --- Curtis Olson wrote: | Hi Guys, | | Again, I love and very much appreciate your efforts on the trees. They are | really awsome. | | Low level flying through the hills has become much more fun... | | On the subject of diffuse shading ... I am tempted to argue that we don't | need it. In real life, trees are composed of a myriad of surfaces in all | directions. Picking one single normal is most likely going to be wrong | especially in relationship to the aribitrary surface we paste the tree | texture on top of. I think going without a surface normal and without | diffuse lighting will be just fine ... as long as we can have the ambient | lighting be representative of the scene. | | I've been wondering the same thing. Currently we're using the full ambient | lighting, which is accurate for the scene. So, as the sun goes down, the trees | get darker. | Yeah, but the trees will be just as dark on the side away from the sun. Since you have to specify a normal-per-vertex anyway, you can arrange it to simulate the shading of a cylinder, or point the normals in random directions. | I've no idea what the performance implications of adding diffuse lighting, but | I'd personally prefer more trees to better lighting. It will be very cheap; one dot product in the vertex shader. Or you could use a 3D noise texture to choose the normal and do lighting in the fragment shader. This project could become an endless, if fun, time-sink; there are a lot of papers out there on generating CG tree and forests. | | Currently, is the problem that we can only have one single tree type for all | surfaces in the scene, or is it only one tree type per surface? | | We currently have a single tree type (and shader) per type of forest per tile, I | think. As Tim has pointed out, the current architecture is very inefficient. | | It should be possible to remove that limitation so that each forest has a variety | of trees - I've already added support for this in the material library. I just | need to work out how to pass the shader an array of textures, and how to use the | noise function for the texture to be selected. Sounds simple, but writing shader | code has been much harder work than I expected. As Curt suggests in another mail, you can put all the tree textures in one texture and choose the texture based on another attribute value. There's still that 4th value passed to glColor4fv that isn't used... Also, you could have more than one forest object per tile, each with a completely different set of models and /or textures. | | At any rate, I think they are great, and will generate a lot of excitement | in the FlightGear community. (Until this new feature becomes the baseline | and everyone will say, ho-hum, yeah, trees, and completely forget their | previous life without them ...) :-) | | Well, look how quickly we've become used to random objects again :) | | -Stuart -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHl3dQeDhWHdXrDRURAjtBAJwMtc3aJoqVj7yWEGZbXAVayp97qwCgskvm td9d5JhnPbUvfA2s4OVTWYA= =poks -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
