[Flightgear-devel] multitex investigation
Guys Have some troubles with multitex maybe you gime me how-tos Ok I can use second texture and second texture coordinates but we load tiles using genleaf function in obj.cxx ok it's done at startup but if we want to have landing lights moves we have generate second texture coordinates in realtime please give me hint where in flightgear it can be done? in tileentry? but we have to regenerate our tiles (second texture coordinates in realtime and genleaf function don't work at all) Thanx in advance Roman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Jim Wilson writes: Ok, yes as long as the origin is in sync, and the fdm rotates correctly. Just the same if the FDM origin was at the c.g. (geometry or gravity?) instead of the cockpit there would be a better chance of actually having the thing on the runway. The CG moves around quite a bit -- that's why aircraft have a fixed reference point for calculating weight and balance. Use the reference point, Luke. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] model.h usable for multiplayer
ace project writes: Is the class FGModelPlacement a good class to inherit to be used for drawing other multiplyer planes ? You probably don't need all of that -- just place it like any other 3D model using FGModelMgr. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multitex investigation
Roman Grigoriev wrote: ok it's done at startup but if we want to have landing lights moves we have generate second texture coordinates in realtime please give me hint where in flightgear it can be done? in tileentry? I'm not the right person to answer questions about the scenery tile subsystem, but you are aware of OpenGL's texgen features for doing realtime texture coordinates, right? If you set things up right, texgen will generate the texture coordinates for you dynamically from the vertex coordinates on the GPU, with no significant loss of performance. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Tony Peden wrote: BTW, you will rarely see the c.g. used as a reference point for dimensions on aircraft. First of all, it moves in flight. Second of all, it's very difficult to actually point to its location. That's my intuition too. David is correct, though, that most lightplane POH's use a nominal center of gravity as the origin for their weight balance tables. The front seat is N meters in front, the fuel tank is M meters behind, etc... But still, the goal here is to make communication between 3D artists and aero modellers easy, not necessarily to adhere to pre-existing conventions. An artist using Blender is much more likely to be working from a 3-view or a photograph; the c.g. isn't marked on these. Picking an easily recognized spot on the airframe seems like the best convention. Whether that be the nose or not, I don't much care. Other good choices would be the nose gear base, wing root, tail, top of the vertical stabilizer, etc... The nose seemed straightforward to me. In this case, the simplest solution is to bring up the 747 model in a (registered) copy of AC3D, drag it around so the nose tip lies exactly on the origin, and save it. I can do all but the last step. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
--- Andy Ross [EMAIL PROTECTED] wrote: Tony Peden wrote: BTW, you will rarely see the c.g. used as a reference point for dimensions on aircraft. First of all, it moves in flight. Second of all, it's very difficult to actually point to its location. That's my intuition too. David is correct, though, that most lightplane POH's use a nominal center of gravity as the origin for their weight balance tables. The front seat is N meters in front, the fuel tank is M meters behind, etc... Hmm, I thought he said just the opposite. At any rate, Cessna does not use a nominal CG for weight and balance in the POH. They use the lower forward face of the firewall. But still, the goal here is to make communication between 3D artists and aero modellers easy, not necessarily to adhere to pre-existing conventions. An artist using Blender is much more likely to be working from a 3-view or a photograph; the c.g. isn't marked on these. Picking an easily recognized spot on the airframe seems like the best convention. Whether that be the nose or not, I don't much care. Other good choices would be the nose gear base, wing root, tail, top of the vertical stabilizer, etc... The nose seemed straightforward to me. In this case, the simplest solution is to bring up the 747 model in a (registered) copy of AC3D, drag it around so the nose tip lies exactly on the origin, and save it. I can do all but the last step. :) But all the FDM's (AFAIK) are still pumping out position info for the CG, so if the model uses this point to rotate about, then the model won't look right (without doing some additional math). Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
In this case, the simplest solution is to bring up the 747 model in a (registered) copy of AC3D, drag it around so the nose tip lies exactly on the origin, and save it. I can do all but the last step. :) I could do nthing - but the last step. AC3D on SGI IRIX is free and unsupported - it has the necessary 'save' option in the 'file' menu and it appears to work. Unfortunately I never had the time to get to know AC3D Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
On Tuesday 05 November 2002 3:14 pm, Jim Wilson wrote: When the 3D model origin is set at the nose or cockpit, the aircraft is too far back on the runway at startup. So far back that the main gear is not on the pavement. It looks stupid. Even as it is currently, it sits too far back. If we can agree how to fix that problem, then I can make the adjustments to the 3D model. That's really because the startup position is based on a smaller aircraft though, isn't it? Is the code taking into consideration the size of the plane? Is that even reported in a consistent manner? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Jim Wilson wrote: When the 3D model origin is set at the nose or cockpit, the aircraft is too far back on the runway at startup. So far back that the main gear is not on the pavement. It looks stupid. Ah, now I think I understand what you mean. I agree, the model placement looks dumb. But it's correctly dumb. If we were modeling off-runway ground handling, the aircraft would be bouncing (or sinking!) because YASim really *does* think the aircraft is off the runway. Moving the model origin only fixes the problem on the screen. The bug you are trying to fix is in the runway placement initialization code, not the model geometry. Right now it puts the origin just barely past the threshold, which is fine for light planes but not for jumbo jets. Even if you were going to try to do the Right Thing, you would have to deal with aircraft geometry. Real aircraft pull onto the runway with their nosegear on the taxi lines, and have to pull forward by different amounts depending on their gear geometry. Just moving the aircraft origin will never be sufficient. I agree, we need a per-aircraft runway startup offset (which would basically be the length of the fuselage). Alternatively, we could pick the *tail* of the aircraft as the coordinate origin. That would behave correctly under these conditions. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
I have been flying with the 747-yasim for short while now, and I also have a few questions. Is fuel consumption modeled in yasim, or will it ever be? Lots of fuel in the tanks could also cause problems with landing right? I have tried landing several times but always bounce off the runway. Also, sometimes setting the flaps around 20-30 degs can cause the plane to shoot thousands of feet into the air. Has anyone else noticed this? Is there any documentation on the 3d cockpits, or any information I can have about them? I was originally interested in creating a 2d panel but of course a 3d cockpit would work a lot better for the 747 cockpit. Thanks alot! Jack ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Burrito Jack wrote: Is fuel consumption modeled in yasim, or will it ever be? Someday. :) Right now, you can use --prop:/sim/fuel-fraction=0.2 to get an appropriate landing weight. Really, this would be very simple. Like I've said, I'm lazy. To be honest, I don't usually fly cross country in FlightGear. I'll set up the aircraft for whatever I want to practice (vertical landings in the Harrier are my most recent addiction) and just do the interesting parts. Fuel consumption ends up being superfluous under those circumstances. Lots of fuel in the tanks could also cause problems with landing right? I have tried landing several times but always bounce off the runway. Lots of fuel will cause fast approach speeds, which are more difficult and could result in bounced landings. But there's an honest bug with ground effect that is probably causing your real problem. I (literally) just checked a fix for this into CVS. Can you try that and see if it fixes things for you? Also, sometimes setting the flaps around 20-30 degs can cause the plane to shoot thousands of feet into the air. Has anyone else noticed this? Which version are you using? There were sporadic reports of this sort of behavior about six months ago, and I thought it was due to a flap drag bug that has since been fixed (maybe in 0.7.8 or 0.7.9). The way to exercise it was to (1) be going very fast (300+ kts); (2) be at a significant negative AoA; and (3) pop the flaps. The flap drag could end up pointing in the wrong direction and producing thrust proportional to speed; the aircraft would then speed up and produce more thrust, and the airspeed would diverge. Like I said, I think this has been fixed. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
I wrote:
Jim Wilson wrote:
How hard would it be to have a property that toggles hotspot
visibility? It'd be nice to be able to turn it on and have yellow
rectangles show up on the hotspots...
That's not a bad idea.
It's actually an astoundingly good idea, and implementable over lunch
to boot. :)
Try the attached patch, which predicates the boxes on the
/sim/panel-hotspots property. I mapped a toggle event on this to a
spare joystick button, and had fun. :)
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
Men go crazy in conflagrations. They only get better one by one.
- Sting (misquoted)
Index: panel.hxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/panel.hxx,v
retrieving revision 1.2
diff -u -r1.2 panel.hxx
--- panel.hxx 29 Oct 2002 19:44:03 - 1.2
+++ panel.hxx 5 Nov 2002 21:38:59 -
@@ -370,6 +370,7 @@
virtual ~FGPanelInstrument ();
virtual void draw () = 0;
+ virtual void drawHotspots();
virtual void setPosition(int x, int y);
virtual void setSize(int w, int h);
Index: panel.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/panel.cxx,v
retrieving revision 1.3
diff -u -r1.3 panel.cxx
--- panel.cxx 29 Oct 2002 19:44:03 - 1.3
+++ panel.cxx 5 Nov 2002 21:38:59 -
@@ -436,6 +436,21 @@
glPopMatrix();
}
+ // Draw yellow hotspots if directed to. This is a panel authoring
+ // feature; not intended to be high performance or to look good.
+ if(fgGetBool(/sim/panel-hotspots)) {
+glPushAttrib(GL_ALL_ATTRIB_BITS);
+glDisable(GL_DEPTH_TEST);
+glDisable(GL_TEXTURE_2D);
+glColor3f(1, 1, 0);
+
+for(int i=0; i_instruments.size(); i++)
+ _instruments[i]-drawHotspots();
+
+glPopAttrib();
+ }
+
+
// restore some original state
glPopAttrib();
glPolygonOffset(0, 0);
@@ -647,6 +662,25 @@
it++) {
delete *it;
*it = 0;
+ }
+}
+
+void
+FGPanelInstrument::drawHotspots()
+{
+ for(int i=0; i_actions.size(); i++) {
+FGPanelAction* a = _actions[i];
+float x1 = getXPos() + a-getX();
+float x2 = x1 + a-getWidth();
+float y1 = getYPos() + a-getY();
+float y2 = y1 + a-getHeight();
+
+glBegin(GL_LINE_LOOP);
+glVertex2f(x1, y1);
+glVertex2f(x1, y2);
+glVertex2f(x2, y2);
+glVertex2f(x2, y1);
+glEnd();
}
}
RE: [Flightgear-devel] Clickable 3D panel
Andy, Try the attached patch, which predicates the boxes on the /sim/panel-hotspots property. I mapped a toggle event on this to a spare joystick button, and had fun. :) Up until we'll have that pretty menu system soon ;-) would it be hard to bind a spare key to this by default? Sincerely, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Michael Basler wrote: Andy Ross wrote: Try the attached patch, which predicates the boxes on the /sim/panel-hotspots property. I mapped a toggle event on this to a spare joystick button, and had fun. :) Up until we'll have that pretty menu system soon ;-) would it be hard to bind a spare key to this by default? The toggling bit was mostly a joke. :) This is really only useful to people designing and debugging panels, and they're not likely to decide to do that in the middle of a long flight. They'll start up fgfs with a --prop:/sim/panel-hotspots=1 on the command line, edit their panels, and do a reset to see their changes. Unless there are applications for this feature that I don't see, they'll never want to turn the feature on and off interactively. There are a limited number of keys available. IMHO, panel hotspots aren't important enough to a general user to justify getting a key assigned to them by default. As you said, a menu option would make a lot more sense. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
burrito [EMAIL PROTECTED] said: Is fuel consumption modeled in yasim, or will it ever be? Lots of fuel in the tanks could also cause problems with landing right? I have tried landing several times but always bounce off the runway. It should be possible to land even with ack! full tanks. I've done it several times. It seems that it isn't possible to dump fuel. You can bring up the property browser on the menu and look at the fuel/ path. Also, sometimes setting the flaps around 20-30 degs can cause the plane to shoot thousands of feet into the air. Has anyone else noticed this? What version are you running (the proper flap modeling has been completed for several months now)? Keep in mind you have to be flying reasonably slow and adjust your nose down when deploying flaps. Is there any documentation on the 3d cockpits, or any information I can have about them? So far they've all been done in ac3d or blender and converted to ac3d as part of the external model. If you are talking about the instrument panels, those are 2D panels, with the exception of the j3cub instruments which were all done in ac3d file format. Take a look at README.xmlpanel in docs-mini directory of the distribution for info on the 2D panel. Take a look at http://www.flightgear.org/Docs/fgfs-model-howto.html for information on animating 3D instruments. I was originally interested in creating a 2d panel but of course a 3d cockpit would work a lot better for the 747 cockpit. I started one last summer and have quite a bit of info. Basically I put it aside until this winter because it became apparent that I need to get better at modeling and it is going to take a lot of time. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Andy Ross [EMAIL PROTECTED] said: I agree, we need a per-aircraft runway startup offset (which would basically be the length of the fuselage). Alternatively, we could pick the *tail* of the aircraft as the coordinate origin. That would behave correctly under these conditions. One advantage of switching to the tail would be that just about any aircraft would position reasonably on the runway without special configuration. Don't know if there are any disadvantages. I do have a licensed AC3D here, so once a decision is made the 747 and A-4 models will be fixed. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Jim Wilson writes: One advantage of switching to the tail would be that just about any aircraft would position reasonably on the runway without special configuration. Don't know if there are any disadvantages. I think that's the wrong reason to make the choice -- it's a permanent kludge to solve a temporary problem. We need to configure per-aircraft anyway, so that the 747 doesn't start on the 1500ft grass runway instead of the 12000ft concrete one. I do have a licensed AC3D here, so once a decision is made the 747 and A-4 models will be fixed. For these two, it's easy -- use the same origin that Andy used. For models used by both JSBSim and YASim, we'll have to coordinate. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] screen-shot
Hi all: I have been working (a little) on trying to make the hsi look like a real one, here is a link to a screen shot of it. I still need to add the index marks on the bezel. http://members.verizon.net/~vze3b42n/fgfs-screen-001.jpeg Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
On Mon, Nov 04, 2002 at 09:24:43AM -0800, Andy Ross wrote: Cool, someone's playing with the 747. This model hasn't had a lot of tweaking yet beyond the engine thrust bugs that Jim Wilson dealt with a few months back. Hey, the 747 is the queen of the sky :-) Does it model the thrust reversers ? What about Speedbrakes/Spoilers ? No, no, yes. The spoilers control is mapped to the /controls/spoilers property, which doesn't have a default input binding. I have it wired to one of the thumbwheels on my Saitek throttle. ok, thats cool. I'll just add a key mapping for the spoilers. I didn't even think of snooping around to see wether there is any 'functionality' that I could use and map it to a key. Thrust reversers and speedbrakes wouldn't be hard to support, I've just been lazy. The Boeing obviously doesn't have a speedbrake, but the A-4 and Harrier should. There are still some (much harder) issues with drag scaling that I'd like to get fixed first. None of the planes need a brake right now, since they all sit way behind the power curve during approach and dump speed really fast. BTW: What is the difference between Speedbrakes and Spoilers? Some stuff i was reading about the 747 made it seem to me that the speedbrake lever in the cockpit controls the spoiler surfaces. ... Actually on the cockpit photos I found on the web (eg www.airliners.net) there is a lever that is labeled 'speed brake'. Its the one right next to the #1 Throttle, on the pilots side. Bouncing: Part of this is due to a blindingly stupid bug with ground effect that I discovered this weekend. It should interpolate the effect from zero Is there a way I could apply this to 0.8.0 which I currently have? Another factor is the lack of automatic wing spoiler deployment, which helps a lot to keep the airplane from getting airborne again after a hard landing. This would require just a tiny amount of C++ code right now: watch the /gear[n]/wow properties and set the /controls/spoilers to 1.0 when they transition from false to true. This would be a great application for interactive scripting from the aircraft definition; a feature that has been long talked about but not yet moved on. I played around with the telnet interface and also with fgfsscript.pl I tried to use fgfsscript.pl to get the radio altimeter announcements during approach... but its hard to make this work right, since the polling nature of fgfsscript.pl and since the feet values change rather quickly. So I must allow for a certain 'window' of feet values around those I want announced. Tuning this just right is a lot of work. And finally, I agree. The default gear damping is a little too light. YASim computes a default damping coefficient automatically, based on the weight of the plane and the placement of the gear. But it's not going to work perfectly for all aircraft. There needs to be a per-gear tunable for spring and damping coefficients, but there isn't yet. This is like the reversers/speedbrakes issue -- something unimplemented only due to my laziness. Well, laziness is actually a good character 'flaw' for programmers. :-) Thats the same with me ;-) ... But, back on the topic... so ... when are you gonna implement these 'due to laziness' features Grin ;-) Well, pumping the brakes during the takeoff is hardly standard procedure; I'm not sure what the real aircraft would do. :) The Well, I was trying to 'emulate' the parking brakes by keeping 'b' pressed, advancing the throttle and wait a little for the thrust to develop. joystick trigger is mapped to the wheel brakes, by the way. You can Yeah, I know, but I don't use a joystick to fly. Mouse and keyboard work well (actually: better) for me. I like the mouse yoke. And esp. the mapping of the elev. trim to the mousewheel :-) The wheel bounce issue is real, though. In my copy, I got better results by changing the compression distance of the nose wheel strut from 2m to 1m in the Aircraft-yasim/747.xml file. This has the effect I'm gonna try this. thanks. (BTW: the parking brake doesn't seem to work w/ the 747) Uh, true. This is trivial to fix, just add a mapping from the parking brake property in the 747.xml file. Everywhere you see: I should have thought about this ... that was an easy one :-) I suppose I could wire up an eye candy starter, which spooled the engine up and down from zero while diddling the temperature and fuel flow variables in a vaguely plausible way. But features like realistic engine start aren't possible for this code; they'll need to wait for someone with the patience and dedication to model one specific engine (and electrical system, and APU, and...). :) From what I read on the list, Curt started adding support for electrical systems, and people talked also about pneumatic and hydraulic systems... This will hopefully provide a more 'realistic' way of starting procedures in the future. But a fake eye candy
Re: [Flightgear-devel] 747-yasim Questions
Manuel Bessler wrote: BTW: What is the difference between Speedbrakes and Spoilers? Typically spoilers refer only to flaps on the top of a wing. They spoil the lift generated and allow the plane to fly at a higher angle of attack for the same lift, and thus descend more steeply (or remain on the ground after landing). They also create a little drag of their own, but that is not their primary purpose. A speedbrake, on the other hand, is a pure drag device. Most of them are just flat plates that pop up when deployed. The A-4 has one on either side of the tail, and the Harrier has one on its underbelly. These things don't do anything but create drag. In the context of jetliners, I've seen the terms used interchangably to mean what I'm calling spoilers. Part of this is due to a blindingly stupid bug with ground effect that I discovered this weekend. Is there a way I could apply this to 0.8.0 which I currently have? Only by bugging Curt to make a new release. :) To be fair, building FlightGear from CVS really is no harder than building the source tarballs. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multitex investigation
- Original Message - From: Andy Ross [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 05, 2002 9:07 PM Subject: Re: [Flightgear-devel] multitex investigation Roman Grigoriev wrote: ok it's done at startup but if we want to have landing lights moves we have generate second texture coordinates in realtime please give me hint where in flightgear it can be done? in tileentry? I'm not the right person to answer questions about the scenery tile subsystem, but you are aware of OpenGL's texgen features for doing realtime texture coordinates, right? If you set things up right, texgen will generate the texture coordinates for you dynamically from the vertex coordinates on the GPU, with no significant loss of performance. Andy texgen don't work here because we need dinamically calculate lightmap texture coordinates using some formulas I'm working now on light lobes of aircraft. Think that it will be really nice But I can't understand why Steve refuse add multitex support code from Marten Stromberg to PLIB It took us ages to wait OpenGL2.0 and shaders. PSL is not suitable for that. Roman Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re : Opengl
Title: Message Hey guys, I so desperately want to help you guys, but it's one of those time issues. One of the projects I help with, is a site full of Opengl tutorials. Go to www.sulaco.co.za . If you guys ever need any help with any Opengl issues, feel free to contact me directly Regards Danie Heath Software Integrator RisC Com cc +27 12 654 5100 083 412 6904 [EMAIL PROTECTED] www.risccom.co.za
[Flightgear-devel] rmi
Hi Pretty much done messing with the hsi, but also moved the rmi to the adf position on the c310 2d panel. Makes the adf approaches much easier and is what the original hsi designer probably had in mind. The c172 instrument panel is perfect the way it is for ifr work, but for ifr in the c310 I think this set-up will work better than the previous panel if any one interested. Screenshot is on approach into anchorage, and if you look at adf/rmi you see the heading matches up with the hsi heading , and the adf needle is pointing back at the outer marker. http://members.verizon.net/~vze3b42n/fgfs-screen-002.jpeg Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
