Re: [Flightgear-devel] SoundSystem continued

On 11/10/2009 09:36 AM, Alasdair Campbell wrote: > > On a totally different subject, I recall your kind offer of some patches > you have available on gitorious. I would be very grateful if you could > mail me the patches you have made to commlist.cxx. That patch was checked into CVS on November 8

Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)

erence frame for attitudes can be achieved via: >>> -- Heading = south. >>> -- Pitch = level flight. >>> -- Bank = level flight. >>> > > On 11/06/2009 02:48 PM, Tim Moore wrote: > >> You need to show your work :) > > The behavi

Re: [Flightgear-devel] Textures oddities in hi-rez scenery

On 11/03/2009 09:19 PM, Curtis Olson wrote: > On Tue, Nov 3, 2009 at 6:58 AM, cullam Bruce-Lockhart wrote: > > Hello all. I've encountered some very strange artifacts in the > hi-res scenery build I'm doing of Newfoundland. I've experimented a > bunch, but can't find one single thing t

Re: [Flightgear-devel] Crop Texture

On 11/03/2009 09:28 AM, Vadym Kukhtin wrote: > Very good!! > > > Is it possible to modify default shaders so they will look for normal map > file? > > In theory, it's possible to do this with effects. I believe that you can do it with shaders today; doing bump maps using only the fixed functio

Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)

On 11/01/2009 06:28 PM, Erik Hofman wrote: > > At this time I've tried about everything to get the listener orientation > aligned properly. What's needed it converting the ViewOrientation matrix > (quaternation) and/or ViewOrientationOffset matrix (quaternation) to > align with OpenGL and get t

Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)

On 11/01/2009 06:28 PM, Erik Hofman wrote: > > At this time I've tried about everything to get the listener orientation > aligned properly. What's needed it converting the ViewOrientation matrix > (quaternation) and/or ViewOrientationOffset matrix (quaternation) to > align with OpenGL and get t

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_os_osgviewer.cxx, 1.28, 1.29 renderer.cxx, 1.127, 1.128

On 11/01/2009 12:28 PM, James Turner wrote: > > On 31 Oct 2009, at 15:10, Ron Jensen wrote: > >> Starting with "fgfs --disable-real-weather-fetch --timeofday=noon " >> >> Also reported on IRC by stuart, MyName, pab... > > And me. I believe this is fixed now; let me know if not. Tim ---

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_os_osgviewer.cxx, 1.28, 1.29 renderer.cxx, 1.127, 1.128

On 10/31/2009 08:34 AM, Tim Moore wrote: > On 10/31/2009 04:58 AM, Ron Jensen wrote: >> On Fri, 2009-10-30 at 18:15 -0500, Tim Moore wrote: >>> Update of /var/cvs/FlightGear-0.9/source/src/Main >>> In directory baron.flightgear.org:/tmp/cvs-serv5452/src/

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_os_osgviewer.cxx, 1.28, 1.29 renderer.cxx, 1.127, 1.128

On 10/31/2009 04:58 AM, Ron Jensen wrote: > On Fri, 2009-10-30 at 18:15 -0500, Tim Moore wrote: >> Update of /var/cvs/FlightGear-0.9/source/src/Main >> In directory baron.flightgear.org:/tmp/cvs-serv5452/src/Main >> >> Modified Files: >> fg_os_osgviewer

Re: [Flightgear-devel] Altimeter setting does not produce correct field altitude

On 10/28/2009 05:53 PM, Ron Jensen wrote: > On Wed, 2009-10-28 at 09:56 -0600, dave perry wrote: >> Tim Moore wrote: >>> On 10/27/2009 01:49 PM, dave perry wrote: >>> >>>> Tim Moore wrote: >>>> >>>>> On 10/17/2009 07:42 PM,

Re: [Flightgear-devel] Altimeter setting does not produce correct field altitude

On 10/27/2009 01:49 PM, dave perry wrote: > Tim Moore wrote: >> On 10/17/2009 07:42 PM, Ron Jensen wrote: >> >>> On Sat, 2009-10-17 at 11:24 -0600, dave perry wrote: >>> >>>> With current cvs update on my notebook, I am not getting the correct

Re: [Flightgear-devel] [GIT] various fixes including atcvoice, commlist and nans

On 10/26/2009 06:30 PM, Alan Teeder wrote: > With the current CVS and VC++ 2008 Express I now get this compilation error: > > "Compiling... > fg_init.cxx > ..\..\..\src\Main\fg_init.cxx(149) : error C3861: 'gethostname': identifier > not found" > > Also, as already discussed here, "#include " is

Re: [Flightgear-devel] Altimeter setting does not produce correct field altitude

On 10/17/2009 07:42 PM, Ron Jensen wrote: > On Sat, 2009-10-17 at 11:24 -0600, dave perry wrote: >> With current cvs update on my notebook, I am not getting the correct >> field elevation when I set the altimeter to match the real weather >> altimeter setting. It is off by 160 feet today at KLMO

Re: [Flightgear-devel] New Sound system committed

On 10/24/2009 09:29 PM, Nicolas Quijano wrote: > typo in ATCDCL/AIPlane.cxx : at line 198, sizte_t len; should be size_t len; > Cheers, > Nic > Fixed. Thanks, Tim -- Come build with us! The BlackBerry(R) Developer Confere

Re: [Flightgear-devel] Fwd: [Flightgear-cvslogs] CVS:

On 10/24/2009 05:30 PM, Curtis Olson wrote: > On Sat, Oct 24, 2009 at 10:11 AM, Heiko Schulz > wrote: > > Why has a such a serious project like FGFS no real support from > lawyer in such things like Flight Pro Sim? > > ... > Neither of these options has happe

Re: [Flightgear-devel] props.hxx - 4 modules not compiling with VC90

On 10/19/2009 03:34 PM, Alan Teeder wrote: > A heads up > > Simgear:- matmodel.cxx, model.cxx and Flightgear:- performancedb.cxx, > FGDeviceConfigurationMap.cxx are currently failing to compile here with > VC90. In each case the error is reported in props.hxx. > This is probably my "fault," thou

Re: [Flightgear-devel] Towards release 1.9.2

On 10/11/2009 08:56 PM, Durk Talsma wrote: > Hi Folks, > > Just wondering: Suppose we're aiming for another release by the end of the > year, would it be feasible to go ahead with our original plan and release a > 1.9.2-beta version just before FSWeekend? We've seen are few relatively major > c

Re: [Flightgear-devel] October $250 Flight Gear Developers

On 10/06/2009 03:14 PM, Curtis Olson wrote: > On Tue, Oct 6, 2009 at 7:57 AM, Tim Moore <mailto:timo...@redhat.com>> wrote: > > "3D panel" does not mean that you need a 3D view of the cockpit to > see the > instruments. > > > I guess I

Re: [Flightgear-devel] October $250 Flight Gear Developers

On 10/06/2009 02:41 PM, Thomas Betka wrote: > > > On Oct 6, 2009, at 3:19 AM, AJ MacLeod wrote: >>> >> >> We understood and understand perfectly what you were trying to >> achieve, and >> having plenty of experience in the task knew that it was not only >> possible to >> achieve it with "3D"

Re: [Flightgear-devel] October $250 Flight Gear Developers

On 10/06/2009 01:51 PM, Curtis Olson wrote: > On Tue, Oct 6, 2009 at 3:19 AM, AJ MacLeod wrote: > > On Monday 05 October 2009 22:34:01 Thomas Betka wrote: > >I really didn't hear many > > people even mention the IFR training opportunity that is being missed > > with FG; shoot, most

[Flightgear-devel] FlightGear arrivals October 2009 #1

If you've been following my git repositories on http://gitorious.org/fg/, you may have noticed that, while the tip of the next branch is identical to cvs, the history is rather complicated, with lots of merges. As people have been making commits to CVS, I've been assembling them in branches and

Re: [Flightgear-devel] bug tracking

On 10/01/2009 12:13 AM, Vivian Meazza wrote: > Curt wrote > > > > ‘git implementations under windows run fine’ Who claims that? Not here > they don’t. I get constant glitches with cloned repos hanging – not only > do they hang, but I can find no way out of the situation. I’m really > p*ssed off

Re: [Flightgear-devel] Source code control systems

On 09/29/2009 08:54 AM, Stefan Seifert wrote: > On Tuesday, 29. September 2009, Olaf Flebbe wrote: > >> Let me talk from the Windows perspective: >> >> git seems to work best with msysgit. Entrance barrier: You need to know >> UNIX shell. (After trying out I would recommend the msysgit rather the

Re: [Flightgear-devel] Allow use of external shaders in 3d clouds and trees

On 09/29/2009 09:50 AM, James Turner wrote: > > On 28 Sep 2009, at 08:49, Stuart Buchanan wrote: > >> Thanks for the patch. >> >> I'm currently working on improvements to the 3D clouds, including some >> changes/bug-fixes to the shaders. >> >> Are you planning some enhancements to the shaders you

Re: [Flightgear-devel] Source code control systems

On 09/26/2009 10:50 PM, Olaf Flebbe wrote: > Hi, > > I do not have write permissions to any of the hg or git reprositories... > > So I can only check repositories out, which works flawless with git and > hg, no surprise. > I see that you've cloned the gitorious repo; if you still need write acc

Re: [Flightgear-devel] Source code control systems

On 09/24/2009 10:56 PM, Olaf Flebbe wrote: > > 2) From the homepage: > "So you do not want to help? Then there is nothing to see here, please > move along." this is not friendly for the casual user of some kind of > middleware when I have other options. This is in the section "How Not to Parti

Re: [Flightgear-devel] Another FlightGear Package for Sale: Illegal?

On 09/26/2009 02:55 AM, syd adams wrote: > Wish I had know I'd be working for Mr Charlie Taylor for free ! > Makes me hesitate to continue maintaining my aircraft as GPL. Whatever Charlie Taylor has done in terms of copyright violations and outright lying, I don't think we can know that there is a

[Flightgear-devel] gitorious repositories for FlightGear and SimGear

By way of experimentation, and to move the discussion about source control forward, I've put git repositories for FlightGear and SimGear up at http://gitorious.org/fg. These are somewhat special in that they include all the history of the project back to 1997, as reconstructed from the historica

[Flightgear-devel] Atmosphere patch from John Denker

On 09/10/2009 01:00 AM, Tim Moore wrote: > so I'm not touching that. Instead, it looks like "Two-parameter physics-based > model of atmosphere up to 262,467 ft i.e. the top of the mesosphere. Correctly > exhibits the HALT phenomenon." would be awesome to have and is rel

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

On 09/09/2009 07:06 PM, John Denker wrote: > On 09/09/09 06:16, Tim Moore wrote: > >>>> Yes, the 2009 code is different from the 2007 code. >>>> The 2009 features and bugfixes are a superset of the >>>> 2007 features and bugfixes. Also the 2009 comm

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

On 09/09/2009 02:57 PM, John Denker wrote: > On 09/08/09 23:10, Tim Moore wrote: > >> Is this different from this commit in sportmodel?: >> commit 77a6f88082a74e3187268c9fde4cee49539cae43 >> Author: John Denker >> Date: Sun Jun 24 19:11:34 2007 -0400 >> &g

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

On 09/09/2009 01:37 AM, John Denker wrote: > 4) Back in January I wrote the code to implement correct > ICAO localizer behavior. This includes the important > service volume issues that Atadjanov Daniyar reminded us > about recently, i.e. 09/08/09 09:30. This also includes > false localize

Re: [Flightgear-devel] Source code control systems

On 09/03/2009 06:07 PM, Curtis Olson wrote: > On Thu, Sep 3, 2009 at 4:10 AM, Tim Moore <mailto:timo...@redhat.com>> wrote: > > It would be a pity to move from CVS and end up with SVN, even > temporarily. > First, let's be clear that "some othe

Re: [Flightgear-devel] 1.9.2 release for FSWeekend?

On 09/06/2009 08:13 AM, Durk Talsma wrote: > Hi James, > > I'm certainly open to the idea, but I don't think I'm able to manage that, > since I'm both primarily responsible for organizing FSWeekend, and have been > coordinating the releases in the last few years as well. Having two deadlines >

Re: [Flightgear-devel] Source code control systems

On 09/02/2009 09:19 PM, Curtis Olson wrote: > On Wed, Sep 2, 2009 at 2:02 PM, Tom P > wrote: > > Hi Curt > > My only concern with SVN is that it stores every file twice in the > local file system, so it's not ideal for the 'data' portion of > FlightGear.

Re: [Flightgear-devel] Source code control systems

On 09/02/2009 05:55 PM, Curtis Olson wrote: > Source code control systems are close to religious topics for many > people so I want to avoid potential panic here. I understand that due > to the diversity of opinions within our developer community, it will be > impossible to reach any kind of conse

[Flightgear-devel] CVS permissions

Hi Curtis, Can you fix the permissions on the flightgear/source/projects/VC90 subdirectory? Also, I suspect that the permissions are wrong on data/Shaders and data/Effects. Perhaps there's a way to configure CVS so that new directories are writable by all? Thanks, Tim ---

Re: [Flightgear-devel] Chasing warnings...

Torsten Dreyer wrote: > While iterating through the source files, trying to eliminate the warnings, I > just found this precious line of code (some more of them in the same file) > > *((float*)&buf[length]) = sg_bswap_32(*(uint32_t*)&val); > > The beauty of pointers - poor Java, C# et al develo

Re: [Flightgear-devel] Till Busch's terrain shaders

Erik Hofman wrote: > Tim Moore wrote: >> I've committed a version of Till Busch's terrain effects, as seen at >> LinuxTag. >> I know that he hasn't finished tuning them, and I've changed his landmass >> effect >> to use the base terra

Re: [Flightgear-devel] Compiling CVS FlightGear first time-files not found: svn_autth.h, osgd.lib, fltkd.lib

Victhor Foster wrote: > Just a note: current CVS FG won't compile with a version of OSG lower > than 2.9.4. You will need code from OSG's SVN repository. As far as I know CVS FG compiles with OSG 2.8.2; at least, it did a couple of weeks ago on my 2.8.2 machine, and I didn't set out to break it.

Re: [Flightgear-devel] fgviewer

Mathias Fröhlich wrote: > Hi, > > On Tuesday 11 August 2009 12:08:05 Martin Spott wrote: ... >> I understand the idea behind the 'fgviewer' tool as creating a distinct >> viewer component (yet still in the early stage of development) which, >> while still remaining compilant with the FlightGear en

Re: [Flightgear-devel] fgviewer

Ron Jensen wrote: > On Mon, 2009-08-10 at 22:28 +, Martin Spott wrote: >> Tim, >> >> Tim Moore wrote: >>> Ron Jensen wrote: >>>> For some reason scenery textures are no longer being loaded by fgviewer? >>>> >>> This is the

Re: [Flightgear-devel] fgviewer

Ron Jensen wrote: > Mathias, > > For some reason scenery textures are no longer being loaded by fgviewer? > This is the "fault" of the new effects code. Effects rely on the FlightGear property tree and on some custom OSG handling. I started pulling what was needed into fgviewer. After a bunch of

[Flightgear-devel] Till Busch's terrain shaders

I've committed a version of Till Busch's terrain effects, as seen at LinuxTag. I know that he hasn't finished tuning them, and I've changed his landmass effect to use the base terrain texture, which he's not entirely in agreement with :) Nevertheless, they are great examples of using the new effect

Re: [Flightgear-devel] geodesic, geocentric, and OSG

Patrice Poly wrote: > I will go further than my previous post. > In fact I am totally lost in coordinates systems. > > Say I have a SGGeod, or a lon,lat,elev triplet. > I want to place a lamp here, so I need to > > light->setPosition(osg::Vec4d(x,y,z, 1.0)); > > What is the relation between lo

Re: [Flightgear-devel] osg devel and Tims changes

dave perry wrote: > I am getting segmentation fault after updating osg trunk from svn, > SimGear from cvs, and fgfs source from cvs. I also tried compiling > against osg-2.8.2-rc4. I still get a segmentation fault right after > "loading aircraft" completes. Can you send me a backtrace? Than

Re: [Flightgear-devel] heads up - effects

stefan riemens wrote: > The current simgear cvs version doesn't compile for me either. I'm on > fedora 11, with gcc 4.4.0. I've tried with both osg 2.8.0 (system > version) and osg trunk. See the builderror here: > http://briemens.com/fs/simgear-build-error > > Thanks, > Stefan > That problem sho

Re: [Flightgear-devel] osg devel and Tims changes

Mathias Fröhlich wrote: > Hi, > > With yesterdays checkin from Tim we need a more or less recent osg version to > build flightgear. Tim promised to provide come conditional code to work > around > that. > > But I would suggest to just have a somehow recent osg version as a > requirement > fo

Re: [Flightgear-devel] heads up - effects

Martin Spott wrote: > Hi Tim, > > Tim Moore wrote: > >> I've checked in the initial work on my effects framework. > > Quite interesting operations gaining ground here. Just a little side > note as I just tried to compile the current state on FreeBSD. Should &g

[Flightgear-devel] heads up - effects

I've checked in the initial work on my effects framework. This allows one specify OpenGL attributes, including shaders, in .eff files. For the moment these are only associated with terrain materials. The default effect for terrain has a shader that does per-pixel lighting, with a fallback to th

Re: [Flightgear-devel] property system extensions redux

Mathias Fröhlich wrote: > Hi Tim, > > On Sunday 05 July 2009 22:51:32 Tim Moore wrote: >> We can now rely on std::tr1:shared_ptr and its cousins, through Boost if >> need be, so perhaps we could come up with some nice templates to paper over >> the differences betw

Re: [Flightgear-devel] property system extensions redux

Mathias Fröhlich wrote: > Hi Tim, > > On Thursday 25 June 2009 23:58:42 Tim Moore wrote: >> Mathias Fröhlich wrote: >>> Hi Tim, > >> Seriously, I didn't realize that reducing dependencies on OSG in simgear is >> a design goal. That's fine, but I

Re: [Flightgear-devel] property system extensions redux

Mathias Fröhlich wrote: > Hi Tim, > > On Thursday 25 June 2009 10:22:54 Tim Moore wrote: >> OK, but in case you hadn't noticed, libsgmath depends on OSG. > Yes I have noticed that change in the quaternion/matrix. If you mean the methods in SGGeod that return osg::Matrix

Re: [Flightgear-devel] property system extensions redux

Curtis Olson wrote: > 2009/6/23 Mathias Fröhlich > > Well, from my point of view. I would prefer to have these. > The reason is to have something self contained here. > Sure we already rely on osg at many places. But if I build an > aplication on > simgear, I hope to have simge

Re: [Flightgear-devel] License of simgear/screen/texture.cxx

Frederic Bouvier wrote: > Hi ? > > o...@arcticnet.no a écrit : >> It seems that the license header of simgear/screen/texture.{cxx,hxx} >> does not have the same LGPL header as the rest of the sources. In fact, >> it says that the code is "freely distributable", but not freely >> modifiable. Is thi

Re: [Flightgear-devel] property system extensions redux

Mathias Fröhlich wrote: > On Friday 12 June 2009 20:10:17 Curtis Olson wrote: >> So as you speak of adding Vec3 and Vec4 types to the property system, I >> immediately have orthogonality concerns. We seems to be adding a >> specialized core type that is only good for one purpose along with the >

Re: [Flightgear-devel] compile error ...

Brisa Francesco wrote: > syd adams ha scritto: >> After a fresh checkout of Flighgear yeterdat , I get this error : >> >> gui_funcs.cxx: In function ‘void guiErrorMessage(const char*, const >> sg_throwable&)’: >> gui_funcs.cxx:144: error: cannot convert ‘const >> std::basic_string, std::allocator >

Re: [Flightgear-devel] X-Plane 850 file format support committed

Jon Stockill wrote: > Curtis Olson wrote: > >> I wonder what tricks and approaches the gaming community uses for >> drawing clear and realistic roads? The problem with cutting the lines >> into the surface as polygons is that (1) you explode the polygon count >> and (2) you have hard aliased e

Re: [Flightgear-devel] property system extensions redux

Curtis Olson wrote: > Hi Tim, > > I have one concern that I may not have voiced clearly before. > > I tend to think about these design choices in terms of what is often > called "orthogonality". The idea stems from the world of vectors. > ... > > So if you translate that concept over to comput

[Flightgear-devel] property system extensions redux

For various reasons I've let the discussion on my proposed property system extensions drop for a couple of months. You may recall that the proposal was to add two vector types, Vec3D and Vec4D, as primitive types in the property system. My rationale is that this improves readability of (the soon

Re: [Flightgear-devel] Progress report on the infamous "error in TriangleIntersect" NAN Problem

Tim Moore wrote: > Durk Talsma wrote: >> On Friday 15 May 2009 20:31:17 Durk Talsma wrote: >> >> While trying to trap bad data in this the popMatrix function, I just >> noticed that a bad transformation matrix is already set up relatively >> early in the proce

Re: [Flightgear-devel] Progress report on the infamous "error in TriangleIntersect" NAN Problem

Durk Talsma wrote: > On Friday 15 May 2009 20:31:17 Durk Talsma wrote: > >> I'm not sure about this, but my estimate is that the trouble doesnt arise > >> when the mag-compass is part of the user aircraft, but only when it's part > >> of the exterior world, i.e. when part of an AI aircraft. Also

Re: [Flightgear-devel] RFC: graphics effects files

LeeE wrote: > > I've been following this but I don't remember anyone, in either > camp, pointing out where it brings a significant performance > increase, or where the failure to adopt it will result in a > significant performance drop. I specifically asked about this in > one of my earlier

Re: [Flightgear-devel] RFC: graphics effects files

Melchior FRANZ wrote: > Nobody wants to see fgfs stagnate. But that doesn't justify every > approach, no matter which bad side effects. There is an alternative > solution with *no* bad side effects, but all the same possibilities. > None of the vector-property supporters even bothered to explain wh

Re: [Flightgear-devel] RFC: graphics effects files

Melchior FRANZ wrote: > * Tim Moore -- Tuesday 07 April 2009: >> How / where do you document that a parent node requires this explicit >> listener activation? > > How/where do we document that the heading is in degree, not radian? > > How/where do we document that

Re: [Flightgear-devel] RFC: graphics effects files

Melchior FRANZ wrote: > * Anders Gidenstam -- Tuesday 07 April 2009: >> Some additional thoughts on atomicity: we have several levels of "setting >> a bunch of values in one go" in FlightGear: > > The whole discussion is still much too detached from any actual use case. > What aggregate data bloc

Re: [Flightgear-devel] RFC: graphics effects files

Anders Gidenstam wrote: > On Tue, 7 Apr 2009, Anders Gidenstam wrote: > >> Can we find a better/more general solution to that problem (i.e. setting >> the value of a subtree or a set of properties), >> because someone might need to set a 3 doubles in one go at some point, or >> 7 doubles or why no

Re: [Flightgear-devel] RFC: graphics effects files

Melchior FRANZ wrote: > * Tatsuhiro Nishioka -- Tuesday 07 April 2009: >> I hope many people understands what Melchior said on the property >> system. > > They don't. They are already drooling over the awaited shader > changes. They fell for the argument that this change is in any > way required

Re: [Flightgear-devel] RFC: graphics effects files

Tatsuhiro Nishioka wrote: > Hi, > > I agree with those who are against the proposed new vector format even > though I like Tim's basic idea that improves vector calculation > performance. > > As Melchior alrwady said, the new format has nothing to do with what > Tim really wants (performanc

Re: [Flightgear-devel] RFC: graphics effects files

Melchior FRANZ wrote: > * Vivian Meazza -- Tuesday 07 April 2009: >> There is no doubt that the introduction of arrays in the Property >> Tree has both advantages and disadvantages. Not least we should >> ask ourselves, if they are such a good idea, why aren't they in >> it already? > > We've had

Re: [Flightgear-devel] RFC: graphics effects files

Erik Hofman wrote: > > Mathias Fröhlich wrote: >> Catching up with an already heated up discussion. >> >> IMO: >> Tim should go on and include arrays into the property system. >> I even believe that aggregates and more sophisticated types will be >> something >> good to have. > > There is still

Re: [Flightgear-devel] Second Class Properties (was: Re: RFC: graphics effects files)

hf...@inmail24.com wrote: >> Except for a few inconsistencies in xml style that already have been >> mentioned I think it's worth adding it then. > > Maybe I am misunderstanding this issue, but I have been involved in > using FlightGear at work for a number of simulation related projects > during

Re: [Flightgear-devel] Second Class Properties (was: Re: RFC: graphics effects files)

Curtis Olson wrote: > I agree that the property system is for generic data ... so adding > color_vectors or position_vectors is really out of the scope of what it > should be intended for. This is too specific and I agree that it > creates a mess and there's then no good place to draw the line whe

Re: [Flightgear-devel] Second Class Properties (was: Re: RFC: graphics effects files)

Curtis Olson wrote: > I agree that the property system is for generic data ... so adding > color_vectors or position_vectors is really out of the scope of what it > should be intended for. This is too specific and I agree that it > creates a mess and there's then no good place to draw the line whe

Re: [Flightgear-devel] RFC: graphics effects files

Melchior FRANZ wrote: > * Heiko Schulz -- Saturday 04 April 2009: >> How would it be better, and would all what Tim wants to do, >> be still possible? > > The features that Tim is talking about (effects and stuff), and > the XML and property tree representation do IMHO not have much > to do with

Re: [Flightgear-devel] RFC: graphics effects files

Melchior FRANZ wrote: > * Vivian Meazza -- Saturday 04 April 2009: >> ? >> , . ? >> material/ambient ? > > I did't even look at that. The vector properties (that have already > been rejected before) were enough for me to reject the whole second > attempt to get this in. But I agree with all your p

Re: [Flightgear-devel] RFC: graphics effects files

Anders Gidenstam wrote: > On Sat, 4 Apr 2009, Tim Moore wrote: > >> 1) Write the full vector every time a component is changed. This means >> potentially 4 times the memory traffic to change a color, and leaves the >> values stored in OSG in an inconsistent stat

Re: [Flightgear-devel] RFC: graphics effects files

Vivian Meazza wrote: > Wow! Complicated or what? I can live with the colour stuff - just. But I > think there's stuff there which will for ever catch me out: I think it has about the same complexity as Ogre material scripts, with a couple of exceptions: * The OpenGL features is more complicated.

Re: [Flightgear-devel] RFC: graphics effects files

Erik Hofman wrote: > > Heiko Schulz wrote: >> Hi, >> Well, for someone who don't have any ideas or knowledge about shaders, it >> looks really complicated at the first sight. On the other site, it looks a >> bit like the .osg-files, and with a bit diggin in, it would be >> understandable for me

Re: [Flightgear-devel] RFC: graphics effects files

Heiko Schulz wrote: > Hi, > Well, for someone who don't have any ideas or knowledge about shaders, it > looks really complicated at the first sight. On the other site, it looks a > bit like the .osg-files, and with a bit diggin in, it would be understandable > for me at least. > I'm sorry tha

[Flightgear-devel] RFC: graphics effects files

Hello, A couple of weeks ago I was asked for a sample of an effects file that uses my proposed changes to the property system; here it is. The syntax differs from current property system syntax in two ways: it uses vector types for some properties, and some properties can have a variance="dynamic"

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Frederic Bouvier wrote: > Erik Hofman a écrit : >> Frederic Bouvier wrote: >> >>> Tim, perhaps if you could show us a real effect file, with the syntax >>> you propose, we ( at least I ) could see what we are talking about, and >>> the pros and cons of the new syntax. >>> That's a great ide

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Curtis Olson wrote: > On Sat, Mar 21, 2009 at 12:06 PM, Tim Moore wrote: > > Melchior FRANZ wrote: > > > Doesn't sound like a valid reason to me: > > > > SGVec3 vec = n->getVec3Value("/some/vector"); > > >

Re: [Flightgear-devel] RFC: vector types in the property system

LeeE wrote: > On Friday 20 March 2009, Tim Moore wrote: > >> RFC: Vector Types in the Property System >> >> Proposal: Allow vector types as properties in property list XML >> files and as properties in the runtime property system. > > [snip...] > >

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Melchior FRANZ wrote: > * Curtis Olson -- Saturday 21 March 2009: >> To me the idea of giving nasal efficient access to vec3 and vec4 types for >> manipulating things like material properties, texture coordinates, lighting, >> and positions seems like the strongest argument "for" this proposal. >

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Erik Hofman wrote: > > Tim Moore wrote: >> property node aggregates and aggregate C++ types is not a real problem >> coding-wise. I just don't like the current XML syntax. > > If this is you main motivation I'm just plain against this. > But I have the

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Erik Hofman wrote: > Tim Moore wrote: >> Erik Hofman wrote: >>> Allright but how would you acces /model/skin/color/red in the new case then? >> What do you mean by "access?" In C++ or Nasal within fg, or in the XML parse >> within >> another app? Why

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Melchior FRANZ wrote: > * Tim Moore -- Saturday 21 March 2009: >> Gene Buckle wrote: >>> What benefit does the compound property offer? > >> More concise syntax for aggregate values like colors, rotations, etc. > > Doesn't sound like a valid reason to m

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Curtis Olson wrote: > On Fri, Mar 20, 2009 at 6:51 PM, Tim Moore <mailto:timo...@redhat.com>> wrote: > > Gene Buckle wrote: > > What benefit does the compound property offer? > > > > g. > > > More concise syntax for

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Jon S. Berndt wrote: >> I have the feeling this will become a developers nightmare, give the >> number of possibilities to access the property tree.. >> But if anyone feels brave enough, be my guest. >> >> Erik > > > I've thought, from time to time, about a units extension to the property > syste

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Curtis Olson wrote: > 2009/3/20 Mathias Fröhlich wrote: > > Ok. > But from my point of view the property tree is also used as a reflection > framework to reflect objects state into the > models/scripting/whatever. From my > point of view, the serialization of the objects into x

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Erik Hofman wrote: > > Mathias Fröhlich wrote: >> But from my point of view the property tree is also used as a reflection >> framework to reflect objects state into the models/scripting/whatever. From >> my >> point of view, the serialization of the objects into xml is just a special >> case

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Curtis Olson wrote: > On Fri, Mar 20, 2009 at 10:22 AM, Stuart Buchanan wrote: > > > Melchior FRANZ wrote: > > > This will probably become a flame-war, but I see no way to avoid > > it. > > > I think you laid out your position in a very well thought out and fair > manner, backed up

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Stuart Buchanan wrote: > I think it would be good for Tim to explain why more complex types are > required, as I'm sure he will do shortly :) > > My immediate thought is that one could write some fairly straightforward > code to interpret a given property node with 3 child values as a Vec3. Could

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Melchior FRANZ wrote: > * Buganini -- Friday 20 March 2009: >> IMO, if these compound types are unavoidable, [...] > > They are very much avoidable. We've had colors and coordinates since > *ages*. And what next? If we have VEC3, then what about POSITION, > which contains latitude/longitude/altitu

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Erik Hofman wrote: > Melchior FRANZ wrote: >> How will a VEC3 property be written in an XML file? As >> 123;341;123? Will then every application >> which reads such a file have to have its own (sub)parser for >> certain fields, in addition to using an XML parser? > > This is my strongest point to

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Gene Buckle wrote: >> >> In my opinion this planned change would be an incredibly bad >> move, and would almost have to be seen as the destruction of >> the property system. So let me repeat: I strongly object. >> > > I guess it boils down to whether or not the benefit gained outweighs the > down

Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types

Melchior FRANZ wrote: > This will probably become a flame-war, but I see no way to avoid > it. Tim plans to extend the property system with compound data > types, such as VEC3, VEC4, or COLOR. We've discussed this three times > in IRC, and I've always pointed out why this is IMHO a *BAD* thing, > a

[Flightgear-devel] RFC: vector types in the property system

RFC: Vector Types in the Property System Proposal: Allow vector types as properties in property list XML files and as properties in the runtime property system. The syntax in an XML file would look like: .2 .4 .6 1.0 .4 .5 .7 1.0

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   >