Re: [Flightgear-devel] Shader based random trees and improved random objects

On Tue, 22 Jan 2008 21:45:32 -0600 "Curtis Olson" <[EMAIL PROTECTED]> wrote: > On Jan 22, 2008 9:36 PM, Syd&Sandy wrote: > > > Just gave the patch a try , amazing ! And this time it has hardly any > > effect on my framerate ... > > Cheers > > > It would be very tempting to commit it to cvs ...

Re: [Flightgear-devel] Shader based random trees and improved random objects

On Jan 22, 2008 9:36 PM, Syd&Sandy wrote: > Just gave the patch a try , amazing ! And this time it has hardly any > effect on my framerate ... > Cheers It would be very tempting to commit it to cvs ... Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ --

Re: [Flightgear-devel] Shader based random trees and improved random objects

On Tue, 22 Jan 2008 22:04:31 + (GMT) Stuart Buchanan <[EMAIL PROTECTED]> wrote: > Hi All, > > I've been working on a shader-based approach to creating random trees with > help > from Tim Moore. > > Here's a screenshot of what I've managed to achieve so far: > > http://www.nanjika.co.uk/fli

Re: [Flightgear-devel] Shader based random trees and improved random objects

On Tue, 22 Jan 2008 18:40:56 -0600, Curtis wrote in message <[EMAIL PROTECTED]>: > On Jan 22, 2008 4:04 PM, Stuart Buchanan > <[EMAIL PROTECTED]> wrote: > > > Hi All, > > > > I've been working on a shader-based approach to creating random > > trees with help > > from Tim Moore. > > > > Here's a

Re: [Flightgear-devel] Shader based random trees and improved random objects

On Tue, 22 Jan 2008 20:04:07 -0600 "Curtis Olson" <[EMAIL PROTECTED]> wrote: > On Jan 22, 2008 7:52 PM, Syd&Sandy wrote: > > > looks pretty impressive ! > > The first try with the un-billboarded trees killed my framerate (30 to 8 > > ) unfortunately. Im trying the patch but now get an error , so

[Flightgear-devel] ..swap sizing, was: configure/make/run on MacOS X

On Tue, 22 Jan 2008 18:40:24 -0700, Hans wrote in message <[EMAIL PROTECTED]>: > > Ron Johnson wrote: The old "you need 2x RAM for swap" rule is hard > > to forget. > > I never really understood the rationale for that rule. It seems > like a system with more RAM would need less swap, not more.

Re: [Flightgear-devel] Shader based random trees and improved random objects

On Jan 22, 2008 7:52 PM, Syd&Sandy wrote: > looks pretty impressive ! > The first try with the un-billboarded trees killed my framerate (30 to 8 > ) unfortunately. Im trying the patch but now get an error , so maybe > something here is out of date ... > > In file included from mat.hxx:48, >

Re: [Flightgear-devel] Shader based random trees and improved random objects

Stuart's trees (with Tim's help) are very cool. Here's one more video before I'm done playing with them for the night ... http://www.youtube.com/watch?v=d_VPtzexsg0 Curt. On Jan 22, 2008 7:09 PM, Curtis Olson wrote: > On Jan 22, 2008 7:09 PM, Georg Vollnhals wrote: > > > THIS is incredible.

Re: [Flightgear-devel] Shader based random trees and improved random objects

On Tue, 22 Jan 2008 19:09:40 -0600 "Curtis Olson" <[EMAIL PROTECTED]> wrote: > On Jan 22, 2008 7:09 PM, Georg Vollnhals wrote: > > > THIS is incredible. > > Due to the lower video resolution, the high standard cockpit and outside > > aircraft view, the "head shaking" and the wooded landscape it l

Re: [Flightgear-devel] configure/make/run on MacOS X

fwiw, I didn't have trouble with 10.4, but the cards I've used with it were ATI and Intel, not nvidia. So my experience doesn't preclude your hypothesis. On Jan 22, 2008 4:03 PM, Ulrich Hertlein <[EMAIL PROTECTED]> wrote: > Hi all, > > it appears that I've got this one cornered: when I turn off t

Re: [Flightgear-devel] Shader based random trees and improved random objects

On Jan 22, 2008 7:09 PM, Georg Vollnhals wrote: > THIS is incredible. > Due to the lower video resolution, the high standard cockpit and outside > aircraft view, the "head shaking" and the wooded landscape it looks like > real! > This tree coverage improvement is a further big step forward for FG.

Re: [Flightgear-devel] Shader based random trees and improved random objects

Curtis Olson schrieb: > On Jan 22, 2008 4:04 PM, Stuart Buchanan > <[EMAIL PROTECTED] > > wrote: > > Hi All, > > I've been working on a shader-based approach to creating random > trees with help > from Tim Moore. > > Here's a screenshot of what I've man

Re: [Flightgear-devel] Shader based random trees and improved random objects

On Jan 22, 2008 4:04 PM, Stuart Buchanan <[EMAIL PROTECTED]> wrote: > Hi All, > > I've been working on a shader-based approach to creating random trees with > help > from Tim Moore. > > Here's a screenshot of what I've managed to achieve so far: > > http://www.nanjika.co.uk/flightgear/forest.jpg

Re: [Flightgear-devel] configure/make/run on MacOS X

Hi all, it appears that I've got this one cornered: when I turn off texture compression (SGSceneFeatures::setTextureCompression) everything works as advertised. It looks like there may be a bug in either the 10.4.x/nvidia OpenGL driver or in OSG handling of texture compression - I suspect the fo

Re: [Flightgear-devel] Shader based random trees and improved random objects

On Jan 22, 2008 4:04 PM, Stuart Buchanan wrote: > Hi All, > > I've been working on a shader-based approach to creating random trees with > help > from Tim Moore. > > Here's a screenshot of what I've managed to achieve so far: > > http://www.nanjika.co.uk/flightgear/forest.jpg I don't recommend a

[Flightgear-devel] Shader based random trees and improved random objects

Hi All, I've been working on a shader-based approach to creating random trees with help from Tim Moore. Here's a screenshot of what I've managed to achieve so far: http://www.nanjika.co.uk/flightgear/forest.jpg A patch which includes both the shader trees and improvements to the random object p

Re: [Flightgear-devel] valgrind diff no 2 and 3

till busch wrote: > * f_interpolate in NasalSys was leaky (valgrind) This leak is real, but the patch isn't legal C++, at least as of the last time I read the standard. You can't initialize a stack array with a dynamic value, it has to be known at compile time. This is a gcc extension. Better

Re: [Flightgear-devel] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug

On Tue, 22 Jan 2008, Torsten Dreyer wrote: > - What are the configurations of the two machines? Both machines are x86 running Debian testing. Acer notebook: Intel Pentium M (1.60GHz), 1 gb ram, ATI Radeon Mobility X700 (PCIE) dektop: AMD Athlon(tm) XP 3200+, 1 gb ram, some nvidia > - Are they

Re: [Flightgear-devel] RFCs on the FG wiki

* Stuart Buchanan -- Tuesday 22 January 2008: > If not, I wonder whether I should just move them to somewhere > less prominent in the wiki with a disclaimer, as they are > currently more prominent than they deserve to be, IMHO. Good idea. I see all the same problems that you do. And I find it qui

Re: [Flightgear-devel] RFCs on the FG wiki

On Jan 22, 2008 11:29 AM, Stuart Buchanan wrote: > Hi All, > > While looking through the FG wiki, I noticed that someone (username > "MILSTD") has > been writing a whole bunch of "RFCs" on a variety of topics. > > Some of these link to on-list discussions, but most are really just one > persons >

[Flightgear-devel] RFCs on the FG wiki

Hi All, While looking through the FG wiki, I noticed that someone (username "MILSTD") has been writing a whole bunch of "RFCs" on a variety of topics. Some of these link to on-list discussions, but most are really just one persons wish-list/opinion, as far as I can tell. He/she has obviously p

Re: [Flightgear-devel] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug

> We were using the current version of gcc in Debian testing (4.1.2, I > believe?), but the same problem occurred with the debian packaged 1.0.0, > the ubuntu packages, and older versions as well. > > As said in another mail, the stability issues improved with the small > patch posted on this lis

Re: [Flightgear-devel] valgrind diff no 2 and 3

hi curt, why i think that this shouldn't impact performance: 1. afaik the database pager now runs in its own thread 2. most texture-data will be loaded before the screen gets bright 3. i assume adjacent tiles will have similar materials (in real world, changes to ground material aren't abrupt) -