subject:"\[Flightgear\-devel\] trees"

Re: [Flightgear-devel] trees

2013-06-18 Thread Stuart Buchanan

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

2013-06-18 Thread Vivian Meazza

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

[Flightgear-devel] trees

2013-06-18 Thread syd adams

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 have gone

2011-05-05 Thread HB-GRAL

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

[Flightgear-devel] Trees have gone

2011-05-05 Thread 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

Re: [Flightgear-devel] Trees rendered too large?

2010-02-16 Thread Stuart Buchanan

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  and  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?

2010-02-16 Thread adams . syd

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?

2010-02-16 Thread syd adams

its all configurable in the material.xml file...

 4000.0
 Textures/Trees/mixed-summer.png
 8
 
 25.0
 15.0

(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?

2010-02-16 Thread Curtis Olson

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?

2010-02-13 Thread Gijs de Rooy


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 rendered too large?

2010-02-13 Thread James Sleeman


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

[Flightgear-devel] Trees rendered too large?

2010-02-12 Thread Rob Shearman, Jr.

Hello developers...

This one's been bothering me for a while, and 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.  But with 2.0.0 looming, here's a 
quickie to consider.

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.

Is it just the difference between trees close to the city versus ones in rural 
or naturally forested land, or am I right that they are just rendered much 
larger than they really should be?

Obviously it looks pretty much okay from the air -- but on approaches where 
there are some randomly generated trees partially obscuring the final, and 
moreso once on the ground, I feel like this is obvious.

Opinions?  Thoughts?  If the consensus is agreed, is there time to adjust the 
size of the models before the release is re-packaged and ready?

Cheers,
-R. (MD-Terp)

 Robert M. Shearman, Jr.
Transit Operations Supervisor,
University of Maryland Department of Transportation
also known as rm...@umd.edu



  --
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

2009-11-25 Thread Vivian Meazza

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  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  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

2009-11-24 Thread syd adams

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  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  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

2009-11-24 Thread syd adams

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  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

2009-11-24 Thread Tim Moore

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

2009-11-24 Thread Tim Moore

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

[Flightgear-devel] trees

2009-11-23 Thread syd adams

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

--
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

2008-04-14 Thread John Wojnaroski

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  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

2008-04-14 Thread Syd

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  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

2008-04-14 Thread Vivian Meazza

> 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  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

2008-04-14 Thread Syd

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  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

[Flightgear-devel] Trees

2008-04-13 Thread John Wojnaroski

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


-
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

2008-02-27 Thread Nils Erik Svangård

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 @@
> >  3
> > 
> > true
> > +   true
> > false
> > true
> > false
> >
> >
> >
> > -
> > 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

2008-02-08 Thread Stuart Buchanan

--- 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 @@
>  3
> 
> true
> +   true
> false
> true
> false
> 
> 
> 
> -
> 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

2008-02-07 Thread Ron Jensen

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 @@
 3

true
+   true
false
true
false



-
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

2008-02-07 Thread Tim Moore

-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

2008-02-06 Thread Norman Vine

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

2008-02-06 Thread Diogo Kastrup

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

2008-02-06 Thread Frederic Bouvier

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

2008-02-06 Thread Stuart Buchanan

--- 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

2008-02-05 Thread Ralf Gerlich

Hi there!

Today I finally had a chance to try your trees patch. All I can say:
Holy s..., this is awesome! Thanks!

Cheers,
Ralf

-
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

2008-02-03 Thread Detlef Faber

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

2008-02-02 Thread 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.

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

2008-01-30 Thread till busch

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

2008-01-29 Thread Nils Erik Svangård

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

2008-01-28 Thread Ulrich Hertlein

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

Re: [Flightgear-devel] trees

2008-01-28 Thread Curtis Olson

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

2008-01-28 Thread Melchior FRANZ

* 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

2008-01-28 Thread Maik Justus

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  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

2008-01-28 Thread Frederic Bouvier

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

2008-01-28 Thread 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...

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

2008-01-28 Thread Stuart Buchanan

--- 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

2008-01-28 Thread Heiko Schulz


--- 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

2008-01-28 Thread Stuart Buchanan

--- 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 (8000) 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

2008-01-28 Thread till busch

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

2008-01-28 Thread Stuart Buchanan

--- 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  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

2008-01-27 Thread Tim Moore

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Curtis Olson wrote:
| 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.
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

2008-01-27 Thread Melchior FRANZ

* Melchior FRANZ -- Sunday 27 January 2008:
> The problem at the moment is that [...]

This isn't really the cause for the long startup time, though, as
this is also the case when that variable is unset. And, of course,
OSG doesn't search the whole harddisk. :-}  But it could be something
related. Not that it matters. I have no problems with the HEAD branch
temporarily working sub-optimally, as long as it's caused by
work-in-progress.

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

2008-01-27 Thread Melchior FRANZ

* 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

2008-01-27 Thread Curtis Olson

On Jan 27, 2008 2:00 PM, Melchior FRANZ wrote:

> 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 ...  ;-)


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?)

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

2008-01-27 Thread Melchior FRANZ

* 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

2008-01-27 Thread Curtis Olson

On Jan 27, 2008 1:21 PM, Norman Vine wrote:

> < 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

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.)

Instead, I was suggesting that it might be better and maybe even simpler to
create this list of random tree locations in the tile loader after the base
geometry is loaded, but before the tile is connected into the scene graph.

But certainly limiting the number of cpu cycles the tile loader thread
consumes per frame would be a good thing, as long as it can keep up with
your rate of motion.

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.

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

2008-01-27 Thread Norman Vine

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

2008-01-27 Thread Curtis Olson

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

2008-01-27 Thread Tim Moore

-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

2008-01-27 Thread Curtis Olson

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

2008-01-27 Thread Maik Justus

Hi Stuart,

Stuart Buchanan schrieb am 26.01.2008 22:18:
> --- 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.
>
>   
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).
> 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.
>
>   
If it don't affect slower PCs with older graphics hardware I will 
suggest "on" as default. But if it causes frame rate drop on older 
hardware while nothing is displayed, off should be the default.
Maik
> 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_ptr 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
>
>   


-
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

2008-01-27 Thread Vivian Meazza

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

2008-01-27 Thread Stuart Buchanan

--- 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 :)

-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

2008-01-27 Thread Vivian Meazza

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

2008-01-26 Thread Tim Moore

-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

2008-01-26 Thread Arnt Karlsen

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

2008-01-26 Thread Stuart Buchanan

--- 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_ptr 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

2008-01-26 Thread Nicolas

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

2008-01-26 Thread Maik Justus

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

Re: [Flightgear-devel] trees

2008-01-26 Thread Frederic Bouvier

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

2008-01-26 Thread Timothy Moore

-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

2008-01-26 Thread Stuart Buchanan

--- 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

2008-01-26 Thread Frederic Bouvier

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

2008-01-26 Thread Jon S. Berndt

> 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

2008-01-26 Thread Stuart Buchanan

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

2008-01-23 Thread Tim Moore

-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

73 matches

Mail list logo