[Flightgear-devel] FlightGear OSG
Hi, Now that I've installed the CVS version of FlightGear I noticed a few things; * I don't have 3d clouds and shrub/tree cover anymore. Is this based on shaders these days? * Rain/Snow is rendered like dots on my system (not like the screenshots I've seen) and doesn't originate at the proper location, sometimes it is even 90 degrees off. * I can't get the transparency fixed for the F-16. Is the drawing order changed for the OSG version or is there anything else I could do? 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear OSG
Erik Hofman wrote: Hi, Now that I've installed the CVS version of FlightGear I noticed a few things; * I don't have 3d clouds and shrub/tree cover anymore. Is this based on shaders these days? * Rain/Snow is rendered like dots on my system (not like the screenshots I've seen) and doesn't originate at the proper location, sometimes it is even 90 degrees off. * I can't get the transparency fixed for the F-16. Is the drawing order changed for the OSG version or is there anything else I could do? 3d clouds have not been ported to osg. At the current rate of progress - sometime in the next decade :-). Rain/snow should work nicely: has your osg version got all the plugins included, and are they in the path? Ordering transparencies is handled automatically, which can lead to unexpected problems - I had to break the Seahawk canopy into many separate objects to ensure that objects inside were visible, but otherwise it usually works well. HTH Vivian - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear OSG
Vivian Meazza wrote: 3d clouds have not been ported to osg. At the current rate of progress - sometime in the next decade :-). Well, things would probably perform much better if not a little crowd of only very few people - including yourself - would have been so efficient in scaring most of the primary developers away. It's always a nice try to blame other people after you've messed it up, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear OSG
On Wed, 23 Jul 2008, Erik Hofman wrote: Ordering transparencies is handled automatically, which can lead to unexpected problems - I had to break the Seahawk canopy into many separate objects to ensure that objects inside were visible, but otherwise it usually works well. Odd, I keep getting that the non-transparent sections of the texture get transparent within FlightGear (creating a hole in the fuselage). Hi, If I have understood the transparency issues correctly, semi-transparent objects are one source of ordering problems. You could consider/try separating the transparent and the opaque parts into separate objects. The work on FG/OSG has lead to major architectural improvements behind the scenes, e.g. having all model loading moved off the main thread. The use of the OSG data base pager has also considerably reduced the memory footprint of FlightGear on my box. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear OSG
On Wednesday 23 July 2008 10:48:23 Erik Hofman wrote: * I don't have 3d clouds and shrub/tree cover anymore. Is this based on shaders these days? I've completely forgotten how they work, but we do have (much improved, IMO) tree coverage. As Vivian mentioned, no 3d clouds or shadows at the moment, but I understand they are being worked on to some extent. * I can't get the transparency fixed for the F-16. The F-16 looks good here - the only transparency problem I can find is with the star and bars markings (bottom right of f16.rgb) and that could easily be worked round by removing the transparency in that part of the texture. It sounds like you're seeing something much more significant... maybe a screenshot would help? What hardware are you using? In general I've found OSG to be vastly nicer to make models for - transparency in particular tends to be exactly as intended where PLIB often required manual fiddling to get the desired effect. Cheers, AJ - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] continuing flight in the middle of a recording
Hello all, so we are working on an industrial application that among other things, deals with recording and playing back flights. We set this up using the native-fdm and native-ctrls protocols, and it all works pretty well. However, now it turns out that it will be a requirement to play back a flight up to a certain point, then give controls to the user, who should be able to continue to fly from there. The problem is that receiving native-fdm with having an active fdm instead of the external/dummy one doesn't work so well - instead of updating the entire fdm state, it sort of oscillates (as if the entire state was reset after receiving updates). We considered just updating the position, which kind of works (just setting the /position/altitude-ft etc. properties, with --notrim enabled); but this doesn't handle the rest of the fdm state, like engines (so the plane will drop off the air instead of flying along normally). Has anyone else done something like this? Is there a simple solution, or should we try to set up as much of the state as possible by setting idividual properties from Nasal or something? With thanks, Mate - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear OSG
AJ MacLeod wrote: The F-16 looks good here - the only transparency problem I can find is with the star and bars markings (bottom right of f16.rgb) and that could easily be worked round by removing the transparency in that part of the texture. It sounds like you're seeing something much more significant... maybe a screenshot would help? What hardware are you using? Screenshot, good idea: http://home.telfort.nl/sp004798/emh/f16cockpit.jpg http://home.telfort.nl/sp004798/emh/f16-transparent.jpg I'm using a Gainward GeForce 4 (Ultra/750) In general I've found OSG to be vastly nicer to make models for - transparency in particular tends to be exactly as intended where PLIB often required manual fiddling to get the desired effect. Ok, as you suggested it might be a local problem then. 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear OSG
Am Mittwoch, den 23.07.2008, 14:21 +0200 schrieb Erik Hofman: AJ MacLeod wrote: The F-16 looks good here - the only transparency problem I can find is with the star and bars markings (bottom right of f16.rgb) and that could easily be worked round by removing the transparency in that part of the texture. It sounds like you're seeing something much more significant... maybe a screenshot would help? What hardware are you using? Screenshot, good idea: http://home.telfort.nl/sp004798/emh/f16cockpit.jpg http://home.telfort.nl/sp004798/emh/f16-transparent.jpg This is most likely sorting order. I usually fix this by putting the transparent parts in a seperate xml file and load it at the very end of my model.xml file. This works with plib too. Avoid transparent parts in textures. Weird things can happen. I'm using a Gainward GeForce 4 (Ultra/750) In general I've found OSG to be vastly nicer to make models for - transparency in particular tends to be exactly as intended where PLIB often required manual fiddling to get the desired effect. Ok, as you suggested it might be a local problem then. 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Detlef Faber http://www.sol2500.net/flightgear - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Antwoord bij afwezigheid
Ik ben momenteel op vakantie. Woensdag 13 augustus ben ik weer terug. -- I'm on holiday at the moment. I return home at wednesday 13 August. - 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=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear OSG
Detlef Faber wrote: This is most likely sorting order. I usually fix this by putting the transparent parts in a seperate xml file and load it at the very end of my model.xml file. This works with plib too. Avoid transparent parts in textures. Weird things can happen. Ok, thanks for the hint. I agree transparency in textures isn't all that great (I've been fighting problems caused by them from day one) but it allows me to add different markings to the same aircraft and they can be of a higher resolution that the skin that way. If you have any suggestions on how to do this without transparent textures I would be pleased to know. 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Including a camera API in Cygwin
Hi there. I've been working on adding a live video functionality into Flightgear, using a Lumenera Camera. Just to be sure it works, I've created a standalone C++ program that interacts with the Cameras API, just to be sure that I know how to use all the functionalities that I'm going for. I'm now working on adding this into Flightgear. The only thing I've done so far is include the camera's api.h file, and my class .h file and .cpp file. (those aren't the actual file names, but that didn't seem like useful info). When I try to compile flightgear, it complains about all the camera's API functions. When it gives these complaints, it adds extra junk to the names. For example: ../../src/Main/libMain.a(renderer.o): In Function '_ZN6Camera12countCamerasEv': /home/RAVEN/FlightGear-1.0.0/src/Main/camera.cpp:32: undefined reference to '[EMAIL PROTECTED]' I presume it's something to do with my unfamiliarity with Cygwin and Linux, but my function is actually called Camera::countCameras, and the function it can't find is LucamNumCameras. I have no idea where the extra text comes from. The essential issue is that many of my Camera functions call some sort of LucamBlahBlahBlah function. And the compiler isn't finding any of these Lucam functions, even though the .h file where they are defined has been included, apparently successfully. Any idea what I'm missing? Thanks so much! -cullam - 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=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear OSG
Am Mittwoch, den 23.07.2008, 15:22 +0200 schrieb Erik Hofman: Detlef Faber wrote: This is most likely sorting order. I usually fix this by putting the transparent parts in a seperate xml file and load it at the very end of my model.xml file. This works with plib too. Avoid transparent parts in textures. Weird things can happen. Ok, thanks for the hint. I agree transparency in textures isn't all that great (I've been fighting problems caused by them from day one) but it allows me to add different markings to the same aircraft and they can be of a higher resolution that the skin that way. If you have any suggestions on how to do this without transparent textures I would be pleased to know. In the eurofighter I copied only the faces which will contain the Markings to a seperate object, remapped it and put a transparent texture containing the markings on it. The Drawback is, the decal faces need to be above the fuselage wing surface to be seen. 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Detlef Faber http://www.sol2500.net/flightgear - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 2d panel question
My brain cells are running out of steam this afternoon so I thought I'd post this to the list to see if anyone has a quick answer or suggestion. Here's the situation. I am working on setting up a flight simulator with a cockpit enclosure and physical cockpit controls. The display consists of one computer with a single video card driving a single 3840x1024 resolution window. The monitor is a matrox triplehead 2 go box which feeds takes the 3840x1024 display in and feeds 3 1280x1024 displays out. This particular cockpit hardware does not have a physical wet compass, so I would like to use 2d instrument to simulate this. I have done this before on a 1280x1024 display and it worked well. What is throwing me off here is the extra wide 3840x1024 display. Let's say I want the instrument to be in the center of the middle screen ... this means I want to position it at x = 1920. However, if I move the instrument past x = 1024 it gets clipped and not drawn. In fact if I put it at 1024, I see the left half of the instrument and not the right. I've tried to specify that my panel width is 3840 w3840/w and height is 1024, but that seems to have no affect on the problem. Can anyone out there throw me a hint or a suggestion to try or a place to look in the code? I haven't spotted any 1024 width restrictions on the 2d panels, but it's been so long since I've looked at this particular code that I could easily be missing something somewhere. I hate to say I'm desperate, but I'm getting close to it! :-) Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - 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=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2d panel question
The README.xmlpanel file shows what I already seemed to remember: Regarding Window Geometry: - For the sake of simplicity the FGFS window is always considered to be 1024x768 so all x/y values for instrument placement should relative to these dimensions. Since FG uses OpenGL 0,0 represents the lower left hand corner of the screen. Panels may have a virtual size larger than 1024x768. Vertical scrolling is accomplished with Shift+F5/F6. Horizontal scrolling is via Shift+F7/F8. An offset should be supplied to set the default visible area. It is possible to place items to overlap the 3D viewport. 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2d panel question
On Wed, 2008-07-23 at 23:27 +0200, Erik Hofman wrote: The README.xmlpanel file shows what I already seemed to remember: Regarding Window Geometry: - For the sake of simplicity the FGFS window is always considered to be 1024x768 so all x/y values for instrument placement should relative to these dimensions. Since FG uses OpenGL 0,0 represents the lower left hand corner of the screen. Panels may have a virtual size larger than 1024x768. Vertical scrolling is accomplished with Shift+F5/F6. Horizontal scrolling is via Shift+F7/F8. An offset should be supplied to set the default visible area. It is possible to place items to overlap the 3D viewport. Erik Which means Curt wants to use x=512. And possibly divide the width of the compass by 3... or multiply the height by 3... 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
