Re: [Flightgear-devel] 3D instruments vanished with today's cvs
Tim Moore wrote: > You're seeing it in the pa24-250. The depth sort can go awry with > nearly-coplanar polygons. Furthermore, it's too expensive to sort every > polygon, > so the sort is based on sets of polygons which just make the sorting > ambiguity > worse. The plib version doesn't sort at all, AFAIK, but draws polygons in the > order in which they appear in the .ac files. This doesn't work in general but > does work well for views from a fixed position, like the cockpit, so aircraft > designers carefully arranged their transparent polys with this in mind. The > OSG > version does sort, causing rendering artifacts with some models. > Is it possible with osg to disable sorting for a model using an animation type? Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D instruments vanished with today's cvs
James Turner wrote: > On 16 Sep 2008, at 07:05, Erik Hofman wrote: > >>> ALPHA_TEST is slow on modern hardware, which is why I was hoping to >>> not have it >>> be on by default in the scene graph. Oh well. I'll leave this >>> reverted for now >>> and think about turning it on only for states with transparent >>> textures. >>> >>> >> I had no problems like this with my f-16 probably because I decided >> not >> to add transparent glasses to the instruments. >> One way I could think of is to change the alpha-test animation to turn >> in on for that particular model. It has been used for the plib branch >> for quite some time and is unused for the osg version as far as I >> know. > > As I understand it, alpha-testing is slow(er, than it was on say SGI > hardware) because the (vastly) preferred solution is collect the > transparent geometry and render it back-to-front after the opaque > geometry - usually with Z-tests enabled but Z-writes disabled. This Alpha testing is slow because it disables the "early z" optimization in modern cards, which can avoid processing a fragment altogether if it's known that the fragment won't pass the depth test. In our case this is probably a micro-optimization and I should get over it :) > assumes transparent materials (StatesSets) can be pulled out and re- > ordered, but I'd sort of guessed OSG could do this already using a > RenderBin. OSG (and FlightGear) does do this, of course, but with Z writes enabled. When alpha testing is enabled, the Z buffer won't be written if the test fails (i.e., the fragment is transparent), whereas if it is disabled the blended fragment will be written with the new depth. This is the cause of the pa24-250 problems. > > Or is there some fundamental / awkward reason why FG can't use this > approach? You're seeing it in the pa24-250. The depth sort can go awry with nearly-coplanar polygons. Furthermore, it's too expensive to sort every polygon, so the sort is based on sets of polygons which just make the sorting ambiguity worse. The plib version doesn't sort at all, AFAIK, but draws polygons in the order in which they appear in the .ac files. This doesn't work in general but does work well for views from a fixed position, like the cockpit, so aircraft designers carefully arranged their transparent polys with this in mind. The OSG version does sort, causing rendering artifacts with some models. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D instruments vanished with today's cvs
Erik Hofman wrote: > dave perry wrote: > >> After updating SimGear and fgfs source from cvs this morning, the 3D >> instruments in the pa24-250 and pa28-161 disappear and reappear >> depending on the the viewing angle. This was not the case with cvs from >> a week ago. After seeing this anomaly, I updated OpenSceneGraph from >> today's svn and recompiled all three. The 3D instruments were still not >> visible. >> > > This should be fixed, I've committed a one liner patch to renderer.cxx > > Erik > > > Thanks Erik, fixed indeed. - Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D instruments vanished with today's cvs
dave perry wrote: > After updating SimGear and fgfs source from cvs this morning, the 3D > instruments in the pa24-250 and pa28-161 disappear and reappear > depending on the the viewing angle. This was not the case with cvs from > a week ago. After seeing this anomaly, I updated OpenSceneGraph from > today's svn and recompiled all three. The 3D instruments were still not > visible. This should be fixed, I've committed a one liner patch to renderer.cxx Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D instruments vanished with today's cvs
On Sat, 2008-09-13 at 15:48 -0600, Ron Jensen wrote: > On Sat, 2008-09-13 at 14:18 -0600, dave perry wrote: > > After updating SimGear and fgfs source from cvs this morning, the 3D > > instruments in the pa24-250 and pa28-161 disappear and reappear > > depending on the the viewing angle. This was not the case with cvs from > > a week ago. After seeing this anomaly, I updated OpenSceneGraph from > > today's svn and recompiled all three. The 3D instruments were still not > > visible. > > > > - Dave Perry > > Just as a quick data point my fgfs built around 05:00 GMT 13 Sep works > for me. > > Ron Whoops, sorry for the noise. The pa28-161 is broken as Dave describes. The instruments are behind a transparent panel and they don't always show through. Ron - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D instruments vanished with today's cvs
On Sat, 2008-09-13 at 14:18 -0600, dave perry wrote: > After updating SimGear and fgfs source from cvs this morning, the 3D > instruments in the pa24-250 and pa28-161 disappear and reappear > depending on the the viewing angle. This was not the case with cvs from > a week ago. After seeing this anomaly, I updated OpenSceneGraph from > today's svn and recompiled all three. The 3D instruments were still not > visible. > > - Dave Perry Just as a quick data point my fgfs built around 05:00 GMT 13 Sep works for me. Ron - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 3D instruments vanished with today's cvs
After updating SimGear and fgfs source from cvs this morning, the 3D instruments in the pa24-250 and pa28-161 disappear and reappear depending on the the viewing angle. This was not the case with cvs from a week ago. After seeing this anomaly, I updated OpenSceneGraph from today's svn and recompiled all three. The 3D instruments were still not visible. - Dave Perry - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d instruments
Hi, Thanks Curt, You wrote half of what I really want to say. As I only wrote one extreme aspect of my thought, Many objections can be expected, but that's OK. Actually I do agree with sharing files because of productivity, ease in fixing bugs, availability of latest functions, etc. however, the different versions of shared files may lead some aircraft to unexpected result. As Curt said, it is a dilemma in sharing vs holding all needed files in each independent package. Both have pros and cons. So here is my real question. How can we take the pros of shared files as well as keeping the robustness currently given only by separating shared files in each aircraft? What I'm doing in developing some Japanese aircraft is storing shared files in one place in a repository, and put these shared files into each package when I release aircraft package. This way, I can release one aircraft as fast as I can. then, I'm going to test another aircraft using the updated shared file after the release. These files can be stored in a shared folder as Melchior said. but now I'm not doing it. that's maybe simply because I don't have a CVS account and don't want to bother you guys for updating my aircraft. But I also want to find some better ways to have both robustness and productivity. I have some broad idea, but it's still kinda hard to realize. A shared file has its own version number in cvs, if each aircraft package has such version number in it, then an aircraft download program can check a compatibility of shared files. If the shared files are not suitable for the aircraft, then it automatically installs some proper files for the aircraft package, probably by exporting one from cvs with version number? Tagging the repository for each aircraft for compatibility is much easier but we have too many tags in cvs. no good. By the way, Melchior's last post also has a point since copied shared files do not tend to be maintained. If all the aircraft are equally well maintained, then all shared files can be safely stored in shared folder, even the base package goes a bit fat. Maybe I'm thinking too much since I want too much? I'm making my jwarbirds work on 0.9.10/0.9.11/CVS-head but it is a time consuming work. I want to make it easier. Best, Tat - Original Message - > From: Melchior FRANZ <[EMAIL PROTECTED]> > > * Curtis Olson -- Sunday 09 December 2007: > > a change to a common object breaks your aircraft. Newer aircraft > > may not work with older versions of FlightGear that don't have the > > shared pieces you expect. > > Newer aircraft usually don't work with older releases, anyway. There's > too much changing. Aircraft developers who don't want to have their work > in CVS have to live with making their aircraft for a particular release. > Maintained aircraft in CVS don't have the problem at all. > > This copying of generic files is more likely to cause problems. We > still have aircraft around with old copies of fuel.nas and aar.nas. > The generic files are maintained and work, the copies don't. > > m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d instruments
* Curtis Olson -- Sunday 09 December 2007: > a change to a common object breaks your aircraft. Newer aircraft > may not work with older versions of FlightGear that don't have the > shared pieces you expect. Newer aircraft usually don't work with older releases, anyway. There's too much changing. Aircraft developers who don't want to have their work in CVS have to live with making their aircraft for a particular release. Maintained aircraft in CVS don't have the problem at all. This copying of generic files is more likely to cause problems. We still have aircraft around with old copies of fuel.nas and aar.nas. The generic files are maintained and work, the copies don't. m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d instruments
On Dec 9, 2007 9:21 AM, Melchior FRANZ <> wrote:
> * Tatsuhiro Nishioka -- Sunday 09 December 2007:
> > For downloadable add-on aircraft, 3D instruments should be stored
> > inside each downloadable aircraft package even these can be duplicated.
>
> NO! $FG_ROOT/Aircraft/{Generic,Instruments,Instruments-3d} are to
> be shipped with the release. They are meant to contain shared files
> and these files *must* *not* be copied to every single aircraft.
> (Of course, you are free to copy whatever pleases you in aircraft
> that you distribute on your own.)
Yes! :-) I think both of you make good points.
There is a dilema here and probably not one right or perfect answer.
If you are an aircraft designer and depending on things in the shared
directories, understand that these may be subject to change. That could be
good: you get the newer version of the object automatically, or it could be
bad: a change to a common object breaks your aircraft. Newer aircraft may
not work with older versions of FlightGear that don't have the shared pieces
you expect. If you make a local copy of a shared item for your aircraft,
just flip all those things around. Your aircraft won't be broke when
something outside of your control changes, but you also won't automatically
get the updates and improvements to these objects. And we never have
complete aircraft independence because aircraft are dependent on all the
supporting code in FlightGear to run.
I think it boils down to the preferences of the aircraft designer. If you
depend on shared items, the burden is on you to check and test once in a
while and make sure no changes in the common files break your design. If
you make local copies of shared items, then you also have a burden to track
the changes in the common files and update your local copies in order to get
improvements or bug fixes.
For aircraft that are distributed with flightgear and put in CVS, I think it
makes more sense to depend on the common objects. Developers that change
those shared objects and scripts have an opportunity (obligation?) to test
your aircraft and make sure their changes don't break anything. For
aircraft that are developed and distributed outside the
flightgear.orgrealm, then it probably makes more sense to keep your
own local copies of
shared objects and just update and test them as needed.
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d instruments
* Tatsuhiro Nishioka -- Sunday 09 December 2007:
> For downloadable add-on aircraft, 3D instruments should be stored
> inside each downloadable aircraft package even these can be duplicated.
NO! $FG_ROOT/Aircraft/{Generic,Instruments,Instruments-3d} are to
be shipped with the release. They are meant to contain shared files
and these files *must* *not* be copied to every single aircraft.
(Of course, you are free to copy whatever pleases you in aircraft
that you distribute on your own.)
m.
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d instruments
Tatsuhiro Nishioka wrote: > Hi Syd, > > For downloadable add-on aircraft, 3D instruments should be stored > inside each downloadable aircraft package even these can be duplicated. > I also think that each downloadable aircraft should be independent from > both base package and other aircraft even these share the same panel, > sound, etc. The reasons are as follows: > > > 1. To make FlightGear user friendly > Independent downloadable package has less problem in downloading > a new aircraft since users don't have to download some other aircraft > that > the downloaded one relies on. Plus, aircraft itself can be work on > several > different version of FlightGear. we, at this moment, have three > different > versions, 0.9.10, 0.9.11-pre, and CVS/head. So having 3D instruments > inside a package provides with users more chance to use a new aircraft. > > Of course this redundancy might give developers a bit annoying situation > since they need to maintain duplicated parts for every aircraft that > shares > the same ones. As you know, I made some nas files and instruments > shared with three different japanese warbirds, but I didn't put any of > these > to the shared folder in a base package, this is because I want to make > these packages independent from the base package of a certain version > so users can use these on both 0.9.10 and CVS version. even though > I have to maintain these shared parts considering the differences among > active fgfs versions, I use local repository and some helper scripts > to save > my time. > > Having a nice downloading GUI program can solve such problem if > it can automatically downloads the parts that an aircraft depends on. > It may check the dependencies and conflicts semi-automatically to avoid > messing around other aircraft. > > > 2. To make base package travel light > To put many shared parts into the base package can make a fat base > package. This may lead long downloading time for possibly unwanted > shared objects. Lightweight base package is always a good answer > unless these shared ones are needed by the base package itself. > > > 3. To avoid unexpected impact on changing an shared instrument > Especially in an early development phase of a certain aircraft, the > developers want to change its instruments, sound, etc often. > In this case changes can affect some other (older?) aircraft and users > might experience unexpected changes on other aircraft. > In this case users need to update every aircraft that shares the changed > instrument, otherwise the older ones might not work properly. > That what we should avoid, I believe. > > I think such thing can be always a troublesome issue since we need to > take care of many perspectives. But it is always a good to think about > such things for maintaining entire FlightGear package wholesome > for both developers and users side. > > Talking about wholesome, I'm changing some nas files in japanese > warbirds due to Melchior's advise about "var." I love his thought > since he always want to maintain FlightGear wholesome and consistent. > I'll give you these files when completed. > > > Best, > > Tat > > On Dec 9, 2007, at 5:31 PM, Durk Talsma wrote: > > >> On Sunday 09 December 2007 07:22, Syd&Sandy wrote: >> >>> Hi everyone , >>> I ran into another issue , just wondering what everyone else's >>> opinion is >>> on the matter. I,ve been updating the Bravo , and the Primus 1000 >>> instruments and controllers are in the Aircraft/Instruments-3d >>> folder. I >>> assumed that this is the place all 3d instruments should go ... >>> preventing >>> unneccesary duplication , but if the aircraft is a separate >>> download , this >>> could be a problem . Unless of course , those instruments are added >>> to the >>> download package . I guess my question is , should the 3d >>> instruments stay >>> in each Aircraft folder , or the Instruments_3d folder. I have done >>> it both >>> ways , but I think if we get enough accurate 3d instruments in the >>> Instruments_3d folder , assembling a 3d panel should become easier >>> as time >>> goes by ... Cheers >>> >> As it stands right now, the Instruments-3D directory will be part of >> the base >> package, so downloaded aircraft should still work. >> >> cheers, >> Durk >> >> Hi All, Instruments-3d is not the only folder in Aircraft with common shared files. The Generic folder has shared autopilot Nasal files. There are many other examples such as common wave files. I believe I disagree with Tatsuhiro for the following reasons: 1. As concerns the pa24-250, since all but one of the shared files is shared with aircraft in the base package, moving all of these into the individual aircraft folders would increase the base package size. 2. Also, who would have the awesome task of removing files from the base package that should now be in the individual AC folders? Would that be the maintainer of each non-base package AC. They mig
Re: [Flightgear-devel] 3d instruments
Hi Syd, For downloadable add-on aircraft, 3D instruments should be stored inside each downloadable aircraft package even these can be duplicated. I also think that each downloadable aircraft should be independent from both base package and other aircraft even these share the same panel, sound, etc. The reasons are as follows: 1. To make FlightGear user friendly Independent downloadable package has less problem in downloading a new aircraft since users don't have to download some other aircraft that the downloaded one relies on. Plus, aircraft itself can be work on several different version of FlightGear. we, at this moment, have three different versions, 0.9.10, 0.9.11-pre, and CVS/head. So having 3D instruments inside a package provides with users more chance to use a new aircraft. Of course this redundancy might give developers a bit annoying situation since they need to maintain duplicated parts for every aircraft that shares the same ones. As you know, I made some nas files and instruments shared with three different japanese warbirds, but I didn't put any of these to the shared folder in a base package, this is because I want to make these packages independent from the base package of a certain version so users can use these on both 0.9.10 and CVS version. even though I have to maintain these shared parts considering the differences among active fgfs versions, I use local repository and some helper scripts to save my time. Having a nice downloading GUI program can solve such problem if it can automatically downloads the parts that an aircraft depends on. It may check the dependencies and conflicts semi-automatically to avoid messing around other aircraft. 2. To make base package travel light To put many shared parts into the base package can make a fat base package. This may lead long downloading time for possibly unwanted shared objects. Lightweight base package is always a good answer unless these shared ones are needed by the base package itself. 3. To avoid unexpected impact on changing an shared instrument Especially in an early development phase of a certain aircraft, the developers want to change its instruments, sound, etc often. In this case changes can affect some other (older?) aircraft and users might experience unexpected changes on other aircraft. In this case users need to update every aircraft that shares the changed instrument, otherwise the older ones might not work properly. That what we should avoid, I believe. I think such thing can be always a troublesome issue since we need to take care of many perspectives. But it is always a good to think about such things for maintaining entire FlightGear package wholesome for both developers and users side. Talking about wholesome, I'm changing some nas files in japanese warbirds due to Melchior's advise about "var." I love his thought since he always want to maintain FlightGear wholesome and consistent. I'll give you these files when completed. Best, Tat On Dec 9, 2007, at 5:31 PM, Durk Talsma wrote: > On Sunday 09 December 2007 07:22, Syd&Sandy wrote: >> Hi everyone , >> I ran into another issue , just wondering what everyone else's >> opinion is >> on the matter. I,ve been updating the Bravo , and the Primus 1000 >> instruments and controllers are in the Aircraft/Instruments-3d >> folder. I >> assumed that this is the place all 3d instruments should go ... >> preventing >> unneccesary duplication , but if the aircraft is a separate >> download , this >> could be a problem . Unless of course , those instruments are added >> to the >> download package . I guess my question is , should the 3d >> instruments stay >> in each Aircraft folder , or the Instruments_3d folder. I have done >> it both >> ways , but I think if we get enough accurate 3d instruments in the >> Instruments_3d folder , assembling a 3d panel should become easier >> as time >> goes by ... Cheers > > As it stands right now, the Instruments-3D directory will be part of > the base > package, so downloaded aircraft should still work. > > cheers, > Durk > > - > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.s
Re: [Flightgear-devel] 3d instruments
On Sunday 09 December 2007 07:22, Syd&Sandy wrote: > Hi everyone , > I ran into another issue , just wondering what everyone else's opinion > is > on the matter. I,ve been updating the Bravo , and the Primus 1000 > instruments and controllers are in the Aircraft/Instruments-3d folder. I > assumed that this is the place all 3d instruments should go ... preventing > unneccesary duplication , but if the aircraft is a separate download , this > could be a problem . Unless of course , those instruments are added to the > download package . I guess my question is , should the 3d instruments stay > in each Aircraft folder , or the Instruments_3d folder. I have done it both > ways , but I think if we get enough accurate 3d instruments in the > Instruments_3d folder , assembling a 3d panel should become easier as time > goes by ... Cheers As it stands right now, the Instruments-3D directory will be part of the base package, so downloaded aircraft should still work. cheers, Durk - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 3d instruments
Hi everyone , I ran into another issue , just wondering what everyone else's opinion is on the matter. I,ve been updating the Bravo , and the Primus 1000 instruments and controllers are in the Aircraft/Instruments-3d folder. I assumed that this is the place all 3d instruments should go ... preventing unneccesary duplication , but if the aircraft is a separate download , this could be a problem . Unless of course , those instruments are added to the download package . I guess my question is , should the 3d instruments stay in each Aircraft folder , or the Instruments_3d folder. I have done it both ways , but I think if we get enough accurate 3d instruments in the Instruments_3d folder , assembling a 3d panel should become easier as time goes by ... Cheers -- Syd&Sandy <[EMAIL PROTECTED]> - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d instruments
> > was it 10 or 12 engines??? oups - was 12... --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d instruments
On 2/19/06, Torsten Dreyer <[EMAIL PROTECTED]> wrote: > > Hi Torsten you dont have to create 2 separate 3d RPM gauges. > > The xml file loads the .ac model , so create two separate RPM xml files, > > one file driven by engine 1 , the other by engine 2 , but both files > > using the same 3d model > Yep - that's what I will do. > I hope I will never model the Do-X - Amphibian with 10 engines ;-) was it 10 or 12 engines??? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d instruments
> Hi Torsten you dont have to create 2 separate 3d RPM gauges. > The xml file loads the .ac model , so create two separate RPM xml files, > one file driven by engine 1 , the other by engine 2 , but both files > using the same 3d model Yep - that's what I will do. I hope I will never model the Do-X - Amphibian with 10 engines ;-) Torsten --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 3d instruments
Hi Torsten you dont have to create 2 separate 3d RPM gauges. The xml file loads the .ac model , so create two separate RPM xml files, one file driven by engine 1 , the other by engine 2 , but both files using the same 3d model Syd --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d instruments
On Tuesday 14 February 2006 06:28, Mathias Fröhlich wrote: > Since we now have that feature, I would like to introduce mouse click > actions for 3D instruments without panel using that code. I believe that > this will give the 3D instruments a big push ... Hi Matthias, This is very good news I think. Having just about "finished" a model myself, I know that the current "hotspot" setup is a completely non-intuitive and cumbersome hack. It does work, eventually (after literally weeks of infuriating trial and error and also help from others), but really it's completely unsatisfactory and by far the worst part of trying to build a 3d cockpit. I for one would be delighted to see a well-designed replacement take over... Cheers, AJ --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
