Re: [Flightgear-devel] Coordinate conventions

If you're referring to coordinates in the multiscreen support, they are OpenGL coordinates: x to the right, y up, z comes out of the screen. Tim On Thu, Mar 3, 2011 at 10:16 PM, wrote: > What are the coordinate conventions used for eye position offsets in 2.0? > > standard right-hand rule or so

Re: [Flightgear-devel] File sizes in fgdata, clean up needed?

I've been threatening for some time to break up the aircraft portion of fgdata into several repositories by using some git magic. It's true that the current repository size is out of hand. I would encourage people to check in their "source" files whenever possible. I'd also encourage people to add

Re: [Flightgear-devel] Texture cache (was: Adventures in dds)

On Mon, Mar 21, 2011 at 10:03 PM, Lauri Peltonen wrote: > Hi. > > Inspired by the talk in the dds thread about cloud performance and other > things, I did some quick grepping through the source about textures. I > found out FG/SG has at least 5 different way of storing textures: > It is important

Re: [Flightgear-devel] [OT] Best pratice for debugging multi threaded programs?

On Mon, Mar 21, 2011 at 3:04 PM, Holger Wirtz wrote: > Hi all, > > sorry - a little bit off-topic (in fact not so much as you might think, > it's for a third-party software for FG): > > Has anyone some hints/websites/programs for debugging C -based multi > threaded programs (exactly: glib based C

Re: [Flightgear-devel] Stuttering at 1 Hz rate

On Sat, Mar 26, 2011 at 6:27 AM, Robert wrote: >> Indeed the jitter is caused by Nasal's "garbageCollect" method. Simple >> test: add a printf (apply attached "patch" to simgear) and you should see >> the "stutter" is synchronized with it. > > True! The text is printfed with every jitter. > >> >>

Re: [Flightgear-devel] OSG caching (was: Texture cache)

On Sun, Apr 3, 2011 at 3:41 PM, ThorstenB wrote: Maybe someone could do some tests when changing the setting >>  (SGPagedLOD.hxx:56) from "CACHE_NONE" to "CACHE_IMAGES" or even to >>  "CACHE_ALL" (then recompile/install sg+fg). Would be interesting to >> know >>  how this

Re: [Flightgear-devel] OSG caching

On Sun, Apr 17, 2011 at 6:10 PM, ThorstenB wrote: > On 16.04.2011 21:16, Anders Gidenstam wrote: >> If I'm not mistaken the particles issue has been around since we got >> particles, so it is apparently not that bad (leak and race >> condition) in practice. > Ok, thanks! I've create a bug issue as

Re: [Flightgear-devel] GIT source

> > The code will test the pixels in the overlap region, adjust the RGB values > based on position and then apply a gamma correction. > > Any thoughts or examples from the community of a basic template and a > howto for adding a fragment shader would help. > > Thanks > Jack &g

Re: [Flightgear-devel] [patch] Improved forests

On Thu, Jul 28, 2011 at 8:33 AM, Gene Buckle wrote: > On Thu, 28 Jul 2011, Stefan Seifert wrote: > >> On Thursday 28 July 2011 01:00:10 Hal V. Engel wrote: >> >>> But there is one minor and very common issue with the code that should be >>> fixed.  In the for loop >>> >>> for (..; ..;  j++) >>> >>

Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository

On Tue, Aug 2, 2011 at 11:39 AM, Francesco Angelo Brisa wrote: > Any news about a possible separation of aircrafts data from the fgdata > folder ? > I am afraid this topic is sligtly falling into the "forget about it" folder > :-( > > > Cheers > Francesco > Some of the inertia -- on my part -- com

Re: [Flightgear-devel] new An-2

Hi Yuri, I chose the An-2 as the aircraft that I would delete first from the fgdata repository and move to its own repo, and I am about to do that. I can check your new work into the new repository. Should I remove the Tutorials directory? Are they now completely broken? Tim On Mon, Aug 8, 2011 a

Re: [Flightgear-devel] new An-2

I have created the ac-an2 repository, which includes only the An-2 (duh), and deleted the an2 from fgdata. Tim On Fri, Aug 12, 2011 at 11:19 AM, Tim Moore wrote: > Hi Yuri, > I chose the An-2 as the aircraft that I would delete first from the > fgdata repository and move to its own re

Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository

I've started the first phase of trimming down fgdata. I've removed the an2 from fgdata and put it in its own repository called "ac-an2" under the Flightgear project. I'm going to proceed with moving other aircraft which haven't been touched in a while into their own repos as well. When we get down

Re: [Flightgear-devel] [SPAM] Re: Proposal: Move airplanes to an SVN repository

On Fri, Aug 12, 2011 at 1:23 PM, Emilian Huminiuc wrote: > On Friday 12 August 2011 14:02:16 Tim Moore wrote: >> I've started the first phase of trimming down fgdata. I've removed the >> an2 from fgdata and put it in its own repository called "ac-an2" under >

Re: [Flightgear-devel] new An-2

On Fri, Aug 12, 2011 at 4:31 PM, Alex Romosan wrote: > Tim Moore writes: > >> I have created the ac-an2 repository, which includes only the An-2 >> (duh), and deleted the an2 from fgdata. > > so where is the new repository? is there a way of integrating it with > t

Re: [Flightgear-devel] Shader menu structure

First of all, apologies for tuning out over the last year+. I have been keeping an eye on things from afar, and am quite impressed with all the goings on in the FlightGear world. This post did catch my eye... On Thu, Jul 12, 2012 at 2:54 PM, Renk Thorsten wrote: > > Admittedly, I can't really la

Re: [Flightgear-devel] Rendering passes question

On Wed, Jul 18, 2012 at 8:27 AM, Renk Thorsten wrote: > > May I ask yet another dumb question? > Yes, although this isn't a dumb question. > In the first rendering pass of default terrain rendering, we use default.vert > and terrain-nocolor.frag as shaders. I have so far mindlessly copied the >

Re: [Flightgear-devel] Rendering passes question

On Thu, Jul 19, 2012 at 1:16 PM, Renk Thorsten wrote: >> This is an optimization to avoid running really expensive shaders on >> geometry that will be hidden from view. The GPU has an "early Z" >> capability and won't run a fragment shader if it knows the result will >> be discarded. > > But that

Re: [Flightgear-devel] Rendering passes question

On Thu, Jul 19, 2012 at 6:09 PM, James Turner wrote: > > On 19 Jul 2012, at 14:32, Tim Moore wrote: > >>> Do we really not run the terrain fragment shader when the terrain is seen >>> through the cockpit floor (my system seems to slow down even though no >>>

Re: [Flightgear-devel] Rendering passes question

On Fri, Jul 20, 2012 at 10:23 AM, Frederic Bouvier wrote: > Hi Tim & James, > >> De: "James Turner" >> >> On 20 Jul 2012, at 07:22, Tim Moore wrote: >> >> > We could use the stencil buffer without copying anything: render >> > the n

Re: [Flightgear-devel] Rendering passes question

On Fri, Jul 20, 2012 at 9:59 AM, James Turner wrote: > > On 20 Jul 2012, at 07:22, Tim Moore wrote: > >> We could use the stencil buffer without copying anything: render the >> near scene first, setting stencil bits, then enable the stencil test >> for the far scene.

Re: [Flightgear-devel] Rendering passes question

On Sat, Jul 21, 2012 at 10:42 AM, Mathias Fröhlich wrote: > > Hi, > > On Thursday, July 19, 2012 15:32:01 Tim Moore wrote: >> The depth-pass-only pass is a well known optimization, but the fact it >> is not helping implies that our bottleneck is not in fragment >>

Re: [Flightgear-devel] Functions to textures?

On Wed, Jul 25, 2012 at 12:16 AM, Chris Forbes wrote: >> Somewhat inversely, I'm also wondering if a simple texture1D() lookup might >> not be faster than evaluating the light function e / pow((1.0 + a * exp(-b * >> (x-c)) ),(1.0/d)) three times to get an (rgb)-triplet. > > That depends a lot on

Re: [Flightgear-devel] Switching from PUI to osgWidget

On Wed, Jul 25, 2012 at 1:43 PM, Martin Spott wrote: > James Turner wrote: > >> Or to put it another way - the actual hard part is running the >> widgets in the main OpenGL window - which *is* a requirement for >> full-screen apps and multi-monitor setups. (Some people have claimed >> otherwise,

Re: [Flightgear-devel] Scenery

On Mon, Aug 6, 2012 at 10:00 AM, Martin Spott wrote: > Moin Yves, > > ys wrote: > >> [...], it's just in responsability of the core developers to show how >> "2nd-row" developers can help to improve apt.dat without being >> blocked by a deprecated. > > I tend to disagree. > > You're probably askin

Re: [Flightgear-devel] git help request

It sounds like your local tree has not been completely committed. See what "git status" says. Check out the man page for git-mv. I can't say more right at the moment, but I'll see if I can add more details later. Tim On Wed, Aug 8, 2012 at 5:45 PM, Curtis Olson wrote: > A quick update here. Rob

Re: [Flightgear-devel] git help request

On Thu, Aug 9, 2012 at 2:45 PM, Curtis Olson wrote: > It looks like every time you rebase you have to reapply the same set of > patches over top the target branch. So even if I figure out a way through > it once, I'll have to repeat the same conconction of craziness each time I > rebase. I think

Re: [Flightgear-devel] Memory issues

On Fri, Aug 10, 2012 at 12:50 PM, James Turner wrote: > > On 9 Aug 2012, at 21:49, Stuart Buchanan wrote: > Do we have any ideas addressing these issues? > > Random thought, hopefully someone with more OSG knowledge can confirm or deny: > > Can we create the geometry (and unload it) in the cu

Re: [Flightgear-devel] Memory issues

On Mon, Aug 13, 2012 at 7:40 PM, James Turner wrote: > > On 11 Aug 2012, at 18:21, Tim Moore wrote: > >> This is what osg::PagedLOD does, though we often forget that the >> paging of the higher LODs is triggered in the cull phase. >>> I can't recall wha

Re: [Flightgear-devel] Release 2.8.0 - closing release/2.8.0 branch

On Tue, Aug 14, 2012 at 3:40 PM, Curtis Olson wrote: > On Tue, Aug 14, 2012 at 3:30 AM, Torsten Dreyer wrote: >> >> Hi all, >> >> I have just suggested off-list to close the release/2.8.0 branches >> (FG+SG+FGDATA) on Thursday (16th) in the morning (UTC) to give those >> packing the binaries and

Re: [Flightgear-devel] license

On Mon, Sep 3, 2012 at 4:27 PM, Michael wrote: > Hi > saw this: > http://wiki.flightgear.org/File:Joystick_Configuration_Dialog.jpg > > which is Creative Commons Attribution-Share Alike 3.0 license. > Will that go into default 3.0? Hence I would use the same license to keep off > scammers. Sorry,

[Flightgear-devel] X-Plane sued for patent infringement

http://games.slashdot.org/story/12/09/14/2048240/patent-troll-sues-x-plane It turns out that the patent has nothing to do with flight simulation but with remote license checking, but still. The Slashdot article has the line ""X-plane is a cross-platform flight simulator app, notably the only serio

Re: [Flightgear-devel] fgdata trouble

On Fri, Sep 21, 2012 at 11:51 PM, ThorstenB wrote: > On 21 Sep 2012, at 13:03, Anders Gidenstam wrote: >> The master branch of fgdata has become messed up. A number of commits ... > It has happened again, fgdata history is messed up. It looks as if my > last commits (6d46fe7, f722671) were applied

Re: [Flightgear-devel] another git question

The short answer is to not have a bare repo on the thumb drive, so it is more practical to push from it, especially to your master repo. If you do that, you need to realize that the branch you have checked out into the working tree could be made out of date in odd ways by pushing into the repo. I

Re: [Flightgear-devel] Shader optimization

Thanks for writing this up. I have a couple of comments, nitpicks really. On Mon, Oct 15, 2012 at 9:43 AM, Renk Thorsten wrote: > > I thought it might be a good idea to write up a few things I've tried > recently and not seen in widespread use - so that either others know about > them as well o

Re: [Flightgear-devel] Shader optimization

On Tue, Oct 16, 2012 at 12:05 PM, Renk Thorsten wrote: >> One can assume that >> a vec4 varying is no more expensive than a vec3. > (...) >> I'm not sure it's useful to think of each component of a varying >> vector as a "varying" i.e., three vec3 varying values use up three >> varying "slots," an

Re: [Flightgear-devel] Shader optimization

On Tue, Oct 16, 2012 at 2:54 PM, James Turner wrote: > > On 16 Oct 2012, at 13:38, Tim Moore wrote: > >> The tile data on disk is actually stored in a >> coordinate system that is aligned with the earth-centric system, so Z >> points to the north pole. We rotate the

Re: [Flightgear-devel] Cloud layer performance

I haven't really been following this thread closely... are the "tracers" basically occludes? Are they completely opaque? One possible optimization for the cloud rendering would be to use polygons that closely follow the outline of the sprite instead of quads; this saves on fill costs. Also, I'm p

Re: [Flightgear-devel] Cloud layer performance

On Wed, Oct 24, 2012 at 10:40 AM, Renk Thorsten wrote: >> I haven't really been following this thread closely... are the >> "tracers" basically occludes? Are they completely opaque? > > Yes, they're completely opaque. That's tracer.frag - if it gets a white > gl_Color from the vertex shader, it's

Re: [Flightgear-devel] Cloud layer performance

On Wed, Oct 24, 2012 at 1:27 PM, Renk Thorsten wrote: >> I realize that I'm confused about whether you are working on Stuart's >> clouds in C++ or clouds in Nasal. >> How are you generating the tracer? I gather that it >> doesn't use any textures. > > If a flag is set in the cloud definition, aft

Re: [Flightgear-devel] Moonlight reloaded

On Sun, Nov 11, 2012 at 1:41 PM, Renk Thorsten wrote: > > I suspect the difference in light intensity > > (dynamic range) doesn't fit in an 8-bit 3-component color. > > It sure doesn't, but I think you're thinking way too complex. We don't > want to render physical light intensity, we want to ren

Re: [Flightgear-devel] Atmospheric Light Scattering

On Fri, Apr 26, 2013 at 8:39 AM, Renk Thorsten wrote: > > I've also taken a bit of a look at merging Rembrandt and ALS, and I think > > I understand the Rembrandt pipeline enough that I could add ALS to it. > > Just to provide some expectation management: > > Rembrandt (as deferred rendering) is v

Re: [Flightgear-devel] Upcoming Random Buildings changes

Cool stuff. Are those all individual models, or instanced geometry, or what? :) Tim On Fri, Oct 11, 2013 at 12:46 PM, Stuart Buchanan wrote: > On Wed, Sep 18, 2013 at 4:16 PM, Stuart Buchanan wrote: > > This is to give a heads up on some changes that I'm planning for > > Random Buildings for th

Re: [Flightgear-devel] More 3D cloud changes

Yon Uriarte wrote: > Hi, > > On Sun, Dec 14, 2008 at 6:12 PM, Heiko Schulz > wrote: > > > My last cloudset has fewer but larger sprites. I did this because I > noticed that it saves a lot of fps. On the forum Gijs noticed the > same with my cloudset. > >

Re: [Flightgear-devel] FlightGear-1.99.5-RC2

John Denker wrote: > On 12/12/2008 09:36 AM, Durk Talsma wrote: > >> If all goes well, I would like to prepare the final release version next >> Friday. > > Wow. > >> Until that time please hold back on committing anything risky, and >> give these prereleases a decent workout. Let's try to m

Re: [Flightgear-devel] FlightGear-1.99.5-RC2

James Turner wrote: > On 16 Dec 2008, at 13:45, Frederic Bouvier wrote: > >>> After 2.0 I'll start merging in my Effects framework code that will >>> make, among other things, local light sources practical. I'm not >>> sure if the best way to do cockpit lighting is to have a light >>> source in th

Re: [Flightgear-devel] tree rendering. was: More 3D cloud changes

Yon Uriarte wrote: > Hi, > > ok, last tree-rendering patch spam. Using attached patch (with no > attributes) and > "coverage /= 10.0" in obj.cxx: > Result: ufo, v=0, 160fps: > http://img266.imageshack.us/my.php?image=treessimpledlpatchbt7.jpg > click on the image to zoom it. > > RAM usage seem

Re: [Flightgear-devel] FlightGear-1.99.5-RC2

John Denker wrote: > On 12/16/2008 10:20 AM, James Turner wrote: > >> The problem is, what happened a couple of years is irrelevant, in the >> strictest sense of the word: it has zero relation to the present. > > Except that the problem continues into the present. Very > recently I submitted a

Re: [Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further

Tatsuhiro Nishioka wrote: > Hi there, > > I'm very happy that we finally released 1.9.0. > According to the discussions before the release, I believe that many of us > are willing to release FlightGear more often, like semiannually or quarterly > (or even more often). To release more than once a

Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/math SGGeodesy.cxx, 1.8, 1.9

James Turner wrote: > On 27 Dec 2008, at 08:16, Tim Moore wrote: > >> Modified Files: >> SGGeodesy.cxx >> Log Message: >> Fix include path > > > >> *** SGGeodesy.cxx26 Dec 2008 12:08:28 - 1.8 >> --- S

Re: [Flightgear-devel] Git advice (was Re: Refresh of the GIT mirror on 'mapserver.flightgear.org')

James Turner wrote: > I could benefit from some advice on using git to track (various) local > changes I'm working on. > Here's my workflow for using git with the FlightGear sources in CVS. Note that there are separate repositories for Fightgear, Simgear and the Flightgear data. This is incon

Re: [Flightgear-devel] Panel designers: feedback needed

James Turner wrote: > On 28 Dec 2008, at 15:54, Heiko Schulz wrote: > >> Currently there are two approaches: >> -making it all 3d. Means that signs, symbols lines are mostly done >> with 3d-objects. Good example the 787-display >> >> -using 2d-layers. Syd is using this approach on his 777 but it

Re: [Flightgear-devel] problems with z-buffer

Alex Romosan wrote: > the latest commit to src/Main/CameraGroup.cxx changed the value of > zNear from .1 to .4 and this causes strange artifacts to show up when > panning around (like holes in the cockpit, etc.). the following patch > changes it back: > > --- src/Main/CameraGroup.cxx27 Dec 200

Re: [Flightgear-devel] Grr... I am so angry

LeeE wrote: > Hello dev list, > > If you're in no mood to critically appraise a rant then read no > further. > > For quite a while now, since I stopped actively contributing to FG, > I've been sitting here watching the direction in which FG > development is heading and if ever there was a good

Re: [Flightgear-devel] Big black box

Frederic Bouvier wrote: > Hi, > > seeing reports that the big black box is often met with a FBO error, I began > to look at our way to render to texture. And I found this piece of code in > od_gauge.cxx, line 63 : > > camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT,

Re: [Flightgear-devel] Possible far camera problem in Custom Triple screen setup

Whoops! I've recreated your problem and I'll try to get a fix out soon. Tim Durk Talsma wrote: > Hi All, > > After today's CVS update (~8:00AM, CET), I'm only seeing approximately 10 > meters of scenery around me, using my customized camera setup (attached > below). The more distant scenery is

Re: [Flightgear-devel] Possible far camera problem in Custom Triple screen setup

Tim Moore wrote: > Whoops! I've recreated your problem and I'll try to get a fix out soon. > > Tim > > Durk Talsma wrote: >> Hi All, >> >> After today's CVS update (~8:00AM, CET), I'm only seeing approximately 10 >> meters of sc

Re: [Flightgear-devel] Possible far camera problem in Custom Triple screen setup

Tim Moore wrote: > Whoops! I've recreated your problem and I'll try to get a fix out soon. > > Tim > > Durk Talsma wrote: >> Hi All, >> >> After today's CVS update (~8:00AM, CET), I'm only seeing approximately 10 >> meters of sc

Re: [Flightgear-devel] SimGear SGMutex -> OpenThreads patch

James Turner wrote: > On 31 Dec 2008, at 19:32, Martin Spott wrote: > >> Do/merge/leave whatever/however you like, I just wanted to make sure >> Daniel's changes don't get lost. > > Right, thanks for clarifying. I'm happy to apply the still-relevant > parts of this, and Yon's SGReferenced patch

Re: [Flightgear-devel] SimGear SGMutex -> OpenThreads patch

Martin Spott wrote: > Tim, > > Tim Moore wrote: >> James Turner wrote: >>> On 31 Dec 2008, at 19:32, Martin Spott wrote: > >>>> Do/merge/leave whatever/however you like, I just wanted to make sure >>>> Daniel's changes don't get l

Re: [Flightgear-devel] Git advice

James Turner wrote: > On 27 Dec 2008, at 15:04, Tim Moore wrote: > >> Here's my workflow for using git with the FlightGear sources in CVS. >> Note that >> there are separate repositories for Fightgear, Simgear and the >> Flightgear data. >> This i

Re: [Flightgear-devel] Git advice

John Denker wrote: > On 01/07/2009 01:19 PM, James Turner wrote: >> On 7 Jan 2009, at 19:05, Tim Moore wrote: >> >>> I like to fetch and then rebase my local work without merging; it >>> makes >>> it much easier to get the commits into CVS via git-cvse

Re: [Flightgear-devel] Very bad surprise with last FG cvs

Frederic Bouvier wrote: > - "gerard robin" a écrit : > >> On vendredi 09 janvier 2009, Torsten Dreyer wrote: Hello, What happen now with the Cockpit view Getting now the cockpit cutted >>> That's the near clipping pane, >>> you might want to add >>> >>> >>> >

Re: [Flightgear-devel] FlightGear 1.9.1

Melchior FRANZ wrote: > * Durk Talsma -- Sunday 11 January 2009: >> As far as I'm concerned, we'll be doing a 1.9.1 bug fix release soon. > > Agreed. > > > >> I would indeed recommend that major updates to important system are >> held off until we have released 1.9.1. > I've established git re

Re: [Flightgear-devel] [BUG] FGEnvironment copy constructor bad

Csaba Halász wrote: > Hi! > > The copy constructor in question: > > 145 FGEnvironment::FGEnvironment (const FGEnvironment &env) > 146 { > 147 FGEnvironment(); > 148 copy(env); > 149 } > > I guess that wants to call the default constructor first. However, > that doesn'

Re: [Flightgear-devel] [BUG] FGEnvironment copy constructor bad

Tim Moore wrote: > Csaba Halász wrote: >> Hi! >> >> The copy constructor in question: >> >> 145 FGEnvironment::FGEnvironment (const FGEnvironment &env) >> 146 { >> 147 FGEnvironment(); >> 148 copy(env); >> 149

Re: [Flightgear-devel] [PATCH] using freed memory in src/Instrumentation/HUD/HUD_ladder.cxx

Csaba Halász wrote: > 540 // draw numbers > 541 std::ostringstream str; > 542 str << i; > 543 const char *num = str.str().c_str(); > > The str.str() is returning a temporary string, that gets immediately > freed, taking the returned c

Re: [Flightgear-devel] [PATCH] clouds_3d_enabled member not initialized in src/Environment/fgclouds.cxx

Csaba Halász wrote: > The clouds_3d_enabled member is not initialized in the constructor, > but the set_3dClouds function depends on it: > > void FGClouds::set_3dClouds(bool enable) > { > if (enable != clouds_3d_enabled) { > clouds_3d_enabled = enable; > buildCloudLayers(); >

[Flightgear-devel] proposed 1.9.1

gured, and an appropriate image jmt Fix test-program linkage now sgmath depends on sgstructure. fredb ignore generated files fredb fix end of file fredb Csaba/Jester : fix the material animation and display night textures Tim Moore SGPropertyNode must increment / decrement the reference counter

Re: [Flightgear-devel] [BUG] size of MP position message depends on architecture

Stuart Buchanan wrote: > Csaba Halász wrote: > >> On 32 bit system, sizeof(T_PositionMsg) = 196. On 64 bit system it is >> 200, due to extra 4 bytes padding at the end. >> >> To make matters worse, in the assembled MP packet this message is >> followed by property values. >> Assuming the padding b

Re: [Flightgear-devel] [BUG] size of MP position message depends on architecture

Tim Moore wrote: > Stuart Buchanan wrote: >> Csaba Halász wrote: >> >>> On 32 bit system, sizeof(T_PositionMsg) = 196. On 64 bit system it is >>> 200, due to extra 4 bytes padding at the end. >>> >>> To make matters worse, in the assembled MP pac

Re: [Flightgear-devel] proposed 1.9.1

Frederic Bouvier wrote: > - "Tim Moore" a écrit : > >> Reminder: >> git-clone git://repo.or.cz/simgear.git >> git-clone git://repo.or.cz/flightgear.git > > $ git-clone git://repo.or.cz/simgear.git > remote: Counting objects: 9905, done. > remot

Re: [Flightgear-devel] FG ocean water shader / water region issue.

Martin Spott wrote: > gerard robin wrote: > >> So, before to spend some time to try to develop any water shader, it would >> be >> better to invest time to try to get a consistent sea surface. > > Go ahead, > Martin. Some of the sea surface problems may be partially my fault. In August 2

Re: [Flightgear-devel] proposed 1.9.1

Csaba Halász wrote: > On Thu, Jan 15, 2009 at 12:56 AM, James Turner wrote: >> On 14 Jan 2009, at 23:40, Csaba Halász wrote: >> >>> There are some pending NaN problems I have reported, but have not >>> been fixed. >>> And users are complaining about IntersectionVisitor/CullVisitor >>> flooding con

Re: [Flightgear-devel] FG ocean water shader / water region issue.

Martin Spott wrote: > Hi Tim, > > Tim Moore wrote: > >> Some of the sea surface problems may be partially my fault. In August 2007 I >> added more polygons to the generic ocean tile to more closely match the >> curvature of the earth, in order to prevent

Re: [Flightgear-devel] proposed 1.9.1

Frederic Bouvier wrote: > - "Tim Moore" a écrit : > >> Frederic Bouvier wrote: >>> - "Tim Moore" a écrit : >>> >>>> Reminder: > >>> Initialized empty Git repository in I:/Devel/fg-maint/simgear/.git/ >>> In

Re: [Flightgear-devel] CVS: data/Aircraft/Boeing314 Boeing314A.xml,

Martin Spott wrote: > Erik Hofman wrote: >> Update of /var/cvs/FlightGear-0.9/data/Aircraft/Boeing314 >> In directory baron.flightgear.org:/tmp/cvs-serv11895 >> >> Modified Files: >> Boeing314A.xml >> Log Message: >> Add the license statement >> >> + This simulation model is not

Re: [Flightgear-devel] CVS: data/Aircraft/Boeing314 Boeing314A.xml,

Martin Spott wrote: > Tim Moore wrote: >> Martin Spott wrote: >>> Erik Hofman wrote: >>>> Update of /var/cvs/FlightGear-0.9/data/Aircraft/Boeing314 >>>> In directory baron.flightgear.org:/tmp/cvs-serv11895 >>>> >>>> Modified Files:

Re: [Flightgear-devel] Licensing and disclaimers for aircraft models

Jon S. Berndt wrote: > > I hope you agree with me that Boeing was very reasonable. I do hope we can > be equally reasonable and fair, and comply with the GPL at the same time. > This will require some creativity and thought. > I won't argue the fairness of their position, but it's simply not comp

Re: [Flightgear-devel] tree rendering. was: More 3D cloud changes

Yon Uriarte wrote: > Hi, > > ok, last tree-rendering patch spam. Using attached patch (with no > attributes) and > "coverage /= 10.0" in obj.cxx: > Result: ufo, v=0, 160fps: > http://img266.imageshack.us/my.php?image=treessimpledlpatchbt7.jpg > click on the image to zoom it. > > RAM usage seem

Re: [Flightgear-devel] FlightGear 1.9.1

Durk Talsma wrote: > Hi Tim, > > On Sunday 11 January 2009 21:07:25 Tim Moore wrote: >> I propose that the 1.9.1 release be made from these "maint" branches. This >> would let progress continue in CVS while hopefully achieving some stability >> in a maint

Re: [Flightgear-devel] FlightGear 1.9.1

pdates. From within the flightgear/simgear directories, > I > ran > > git fetch > > which did seem to do some updating, but then running git log gives me > > commit 5567eb1fff2e5335d77f495779da55f8bb9e09f9 > Author: Tim Moore > Date: Thu Jan 15 16:03:34 2009 +010

Re: [Flightgear-devel] FlightGear 1.9.1

Frederic Bouvier wrote: > Hi Tim, > > Would you mind adding this commit to the VC7.1 directory : > Fri Jan 16 07:31:01 2009 UTC : Update MSVC 7.1 project > > Otherwise I managed to get it with git and build it. I am just waiting > instructions ;-) > > -Fred > It's already there. Remember, "m

Re: [Flightgear-devel] proposed 1.9.1

Durk Talsma wrote: > On Friday 16 January 2009 17:50:04 Frederic Bouvier wrote: >>> Whoops. I've created a master branch in the repository, so you can >>> either redo >>> the clone, or you can type "git-checkout -b maint origin/maint" to >>> e.g. check out the maint branch directly. >> Both worked.

Re: [Flightgear-devel] FlightGear 1.9.1

into our main CVS repository, and which were kept in a > separate git repository set up by Tim Moore. > To recap, since the 1.9 release these commits are in maint: simgear: git log --date=short --pretty="format:%ad %ae %s" SIMGEAR_1_9_0..maint 2009-01-19 timo...@redhat.com

Re: [Flightgear-devel] engine reconfiguration?

John Denker wrote: > This morning I did a git-pull and make. > > I observe that the new version executes in 855 megabytes under > conditions where the previous version from a week or two ago > executed in only 450 megabytes. > > That seems kinda extravagant. > > Is everybody else seeing the sa

Re: [Flightgear-devel] weird memory bloat

John Denker wrote: > On 01/28/2009 09:55 AM, Stefan Seifert wrote: > >> "bloat" is a hard word for something, which you did not even measure yet. >> The >> VIRT column of top is basically useless for getting the memory usage. It's >> just the virtual address space allocated to that process. Tha

Re: [Flightgear-devel] weird memory bloat

27;t blame it on non-authoritative > sources. > > All this is with OSG 2.7.7. Debian etch. > > On 01/28/2009 01:18 AM, Tim Moore wrote: > >>> I'm seeing about 10% less virtual memory usage with the current next branch >>> compared to the 1.9 release. > > Puz

Re: [Flightgear-devel] The use of models from other formats

FGD ML wrote: > Hi All, > > Just got directed to your list today. Hope I'm posting this right as > that is a first for me too. Sorry if I goofed too. Welcome! > > I'm one of a bunch of content makers, I recently had a conversation with > Stuart, and felt it worth exploring this a bit further w

Re: [Flightgear-devel] some hopefully helpful gdb core debug output

FlightGear wrote: > hi, I am fg-torrents from the forums. I am trying to debug error in triangle > intersect problem. Original thread here: > http://www.flightgear.org/forums/viewtopic.php?f=2&t=2824 > > I keep running into what looks like other issues causing fg to crash before > triangle int

Re: [Flightgear-devel] some hopefully helpful gdb core debug output

Csaba Halász wrote: > On Fri, Feb 6, 2009 at 4:12 PM, Tim Moore wrote: >> This is a bit like whack-a-mole, but try again with the latest CVS or git >> version. >> >> When you send gdb output, it's helpful to know how you started the program >> and a

Re: [Flightgear-devel] The use of models from other formats

FGD ML wrote: > > > 2009/2/7 Melchior FRANZ mailto:mfr...@aon.at>> > > Not that this has much to do with this thread, or Ian's > FlightGear problems. > > > Oh I would not worry about it, this thread has been hijacked, dragged > off topic and otherwise generally killed already. > > Obv

Re: [Flightgear-devel] Tree shader - is it GLSL?

Christian Buchner wrote: > Hi, > > I was wondering whether FlightGear's vertex shader for trees was > implemented as ARB_vertex_program (ARBvp1.0) or as a GLSL fragment > shader. > > My point is that Intel 945 GM graphics cards do not currently support > GLSL shader programs, but run ARB vertex a

Re: [Flightgear-devel] Property System Overview?

LeeE wrote: > On Saturday 21 February 2009, Torsten Dreyer wrote: >>> Pretend Curt is in a meeting and he's given 30 seconds to >>> explain the property system to smart people who have never seen >>> this concept before. I've just burned my first 15 seconds with >>> "U, er, It's like ,

Re: [Flightgear-devel] Recent checkins and plans

Mathias Fröhlich wrote: > Hi all, > > ... some of you might remember me. > I might find some more time during the next weeks for work on flightgear. > > I am in the process of cleaning up some useful changes I have made during the > past year or so without committing anything. > I have in this m

Re: [Flightgear-devel] Parallel make does not work

Alfredo Tupone wrote: > I did a > make -j 20 > building flightgear. > It gave up while building it saying "no rules to make libMain.a" (more > or less) > > I have changed one line of the Makefile.am to avoid it. Thanks, but this change has already been in FlightGear CVS for almost a month. Tim >

Re: [Flightgear-devel] OpenStreetMap Open Database License

Martin Spott wrote: > Martin Spott wrote: > >> OSM are currently discussing a draft of their to be expected future >> license for their road database. If you're interesed in having OSM >> roads show up one day in some future releases of the FlightGear World >> Scenery, then feel free to reserve so

Re: [Flightgear-devel] [RFC] ac3d and materials

Mathias Fröhlich wrote: > Hi all, > > For ac models, we have currently a step in the scenery loading process that > modifies the material settings to match the material settings of the old plib > loader. > In fact this just overwrites the material settings and throws away useful > information t

Re: [Flightgear-devel] hypothetical gpl question

Curtis Olson wrote: > Here's a hypothetical question. > > Let's say some company "A" builds an internal product prototype that > incorporates FlightGear as part of a larger aggregate system. Let's say > they even make a few small changes to FlightGear. Now they give away a > demo system to a co

Re: [Flightgear-devel] [RFC] ac3d and materials

Mathias Fröhlich wrote: > Hi Tim, > > On Monday 16 March 2009 22:43:22 Tim Moore wrote: >> I'm working on something that might completely ignore the material settings >> in the .ac file, but I think that's OK. I'm adding support for effects >> files tha

  1   2   3   4   5   6   >