Re: [Flightgear-devel] OSG point lights
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathias Fröhlich wrote: On Thursday 30 November 2006 01:36, Tim Moore wrote: Try http://www.bricoworks.com/moore/lightpt3.diff instead. A last-minute typo disabled point sprites. This is still faster with point sprites reenabled? I'm not sure about faster but, as far as I can tell, equivalent. By the way, it would be very nice to have some more timing information available than just the frame rate. I don't know if the easiest way to get there is to move to Producer so we can get its nice rendering stage statistics, wait for Robert to duplicate that in his new osgViewer stuff, do it ourselves, or what. I do not want to remove the old implementation that was happening completely on the GPU in favour to an CPU based one if we end up slower. Anyway, can we keep the old implementation instead of just a plain OpenGL point based one. That means the old one that used triangles that are backface culled and draw points for the front side where two of them are transparent? I don't mind adding the old implementation back in as an option, except for the VASI lights, where it really would have no advantage over the OSG lights. One would lose some features, such as point size scaled by intensity, fading alpha with distance, and blink sequence animations for the approach lights. Like I stated before in some private mails I would like to have the osg version only as an alternative to the old implementation if it is faster than the GPU/triangle based one. May be not exactly the old implementation but an implementation that does nothing on the CPU but does all lightging decisions on the GPU. I would like to see some comparisons between the two approaches on a low-end machine. You may be overestimating the cost of the CPU based approach and underestimating the costs of triangle approach. As I said in private email, the old approach uses a fairly exotic rendering path - -- polygons rendered in point mode with a texture environment -- which very well may be done on the CPU on a low-end machine. And as also told before I would like to have an other alternative for the main usage where we still do that light intensity decision - together with more advanced light texturing dependent on fog density, distance and other neat parameters - on the *GPU*. Just use a vertex shader for the view direction dependence of the light and fragment shaders for more advanced halos. That will require a newer OpenGL implementation and for that I believe we need to keep a lighting version for older boards. Also this all happens in the *GPU*. That has the advantage that it is probably way faster and even if it is about at fast as on the CPU, it does not block CPU cycles that can equally well be spent for more advanced physical models or better AI traffic or whatever we need to do on the CPU. So on the longer term I will favour that shader based approach as default as long as the GPU supports it. Yes, I think that is a great project, but more work than I have time for right at the moment. It would be good for people to learn about OSG's support for shading programs *hint*hint* :) For that we still need some factory methods that will provide now the old implementation or the osg::LightPoint based one and later when I have the time to merge my tests into simgear the shader based one. So we need to he able to decide between implementations based on capabilities of the GPU and settings from the user anyway. Can we set up together such an infrastructure and put the old triangle based approach as other alternative below? We? :) Seriously, I would be happy to look at getting the OpenGL extensions available from OSG and making that available to fg in an elegant way, but goes way beyond to scope of light points, so for now exposing the choice to the user is probably the best way. Automatically benchmarking the user's machine and putting it into slow /fast categories would be an interesting project too. In the long term I believe that we will reduce that back to two alternatives again. The shader based and one of the low end card capable ones - whichever of the low end card implementation is faster. For that decision we need *both* up again and optimized well ... I'll add back the old one and do the obvious optimizations. I will look at the current patch that weekend. Cool. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFbp5ReDhWHdXrDRURAl5xAKCqJsKXQ0IL84SwMINO+k822eAnyQCdHjQ0 sDNDGgKV0U9b1rEltT7Pixo= =bmNW -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash
Re: [Flightgear-devel] Forums integration thought
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill wrote: Alex Perry wrote: I know our development culture is built around mailing lists. I'm sure the FlightGear community will be decisively split between forums versus mailing lists if I ask people's preferences ... so I'm not expecting a consensus here. Is this anything that is worth exploring? I'd also hate to look in two places. On the other hand, changing how we present the mailing list archives so they look like a forum _and_ allow replying if you have logged in ... would be really useful. Logging in implies an account whose email address has been verified in the same way that mailman does. So it can't be used for spamming unless you could easily have spammed with the mailman list system. Mailman has the facility to gate mailing lists to usenet groups. There's also a PHP based news client, which presents it all just like a forum. gmane.org is already doing doing that for the flightgear lists. Is what they provide forum-like enough? Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFbqSkeDhWHdXrDRURAmdTAJ9Ru4LLenB/r7RFvG85I6SpeiYHcgCgr7Wp 5g9+7uh3MPWbEBe53i2Pxhw= =FTkQ -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/Sikorsky-76C S76c.xml, 1.1, 1.2
Hi, The following data is taken from Janes (S76c): Powerplant: 2 turbomeca Arriel 2S1 turboshafts with FADEC - each rated at 638 kW (856 shp) for take-off, - 731 kW (980 shp) OEI for 30 seconds, - 592 kW (794 shp) max continuous Standard fuel capacity: - 1083 litres of which 1064 litres are usable, - optional auxiliary tank capacity 405 litres Dimensions: - MR diameter: 13.41 m - MR blade chord: 0.39m - TR diameter: 2.44 m - TR blade chord: 0.16 m - MR tip speed (prouty) : 205.74 m/s - rpm = 292.8 Performance: - Vnever exceed and max level speed: 155 kt (287 km/h) - Max range cruising speed: 140 kt (259 km/h) - rate of climb at S/L: 495 m (1625 ft)/ min - service ceiling: 3871 m - service ceiling, OEI: 975 m - hovering ceiling IGE: 1722 m - hovering ceiling OGE: 549 m - range at 140 kt at FL40, standard fuel: - no reserves: 439 n miles (813 km) I hope this is of any use. Greetings, Wim On 11/29/06, Maik Justus [EMAIL PROTECTED] wrote: Hi Syd, I have tried to adjust the rotor parameters to fit the real heli. Unfortunately I have only very few data for the s76c, therefore I have changed only some geometric data an changed the rpm to get the same tip-speed as the bo. The geometric data is from a poor scaled drawing of the s76c, maybe you have a better drawing and could correct the values for the width of the blade (chord) and the position of the flapping hinge (rellenflaphinge). I found the airfoil sikorsky is using for the s76, but I did not found drag/lift curves for this airfoil. But I think, that the flight behavior with this parameter set is more realistic than with the parameters in cvs (not as easy to fly as the bo). The sound configuration need some adjustment to the changed rpm (I think, we need other samples). Maik Index: S76c.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/S76c.xml,v retrieving revision 1.2 diff -u -p -r1.2 S76c.xml --- S76c.xml28 Nov 2006 08:20:26 - 1.2 +++ S76c.xml29 Nov 2006 19:47:48 - @@ -22,12 +22,12 @@ Single Blade : 6.089 m /cruise -rotor name=main x=0.0 y=0.0 z=0 nx=0.05 ny=0 nz=1. fx=1 fy=0 fz=0 ccw=0 +rotor name=main x=0.0 y=0.0 z=0 nx=0.10 ny=0 nz=1. fx=1 fy=0 fz=0 ccw=0 maxcollective=15.8 mincollective=0.2 mincyclicele=-4.7 maxcyclicele=10.5 mincyclicail=-4.23 maxcyclicail=5.65 - diameter=13.41 numblades=4 weightperblade=95 relbladecenter=0.5 - dynamic=1 rpm=442 rellenflaphinge=0.18 delta3=0 + diameter=13.41 numblades=4 weightperblade=97 relbladecenter=0.5 + dynamic=1 rpm=330 rellenflaphinge=0.07 delta3=1 delta=.25 pitch-a=10 pitch-b=15 @@ -42,7 +42,7 @@ Single Blade : 6.089 m ground-effect-constant=0.1 twist=-8.5 taper=1 - chord=0.27 + chord=0.32 number-of-segments=8 number-of-parts=8 rel-len-where-incidence-is-measured=0.7 @@ -57,7 +57,7 @@ Single Blade : 6.089 m stall-change-over=5.5 drag-factor-stall=2.0 cyclic-factor=0.8 - rotor-correction-factor=0.7 + rotor-correction-factor=0.85 control-input axis=/controls/flight/aileron-trim control=CYCLICAIL split=true/ control-input axis=/controls/flight/aileron control=CYCLICAIL @@ -76,7 +76,7 @@ Single Blade : 6.089 m rotor name=tail x=-8.12 y=0.4 z=0.424 nx=0.0 ny=1 nz=0.0 fx=1 fy=0 fz=0 ccw=0 maxcollective=20 mincollective=-10 diameter=2.44 numblades=4 weightperblade=2 relbladecenter=0.7 - dynamic=1 rpm=2219 rellenflaphinge=0.0 delta3=1 translift=0 delta=0.5 + dynamic=1 rpm=1750 rellenflaphinge=0.07 delta3=1 translift=0 delta=0.5 pitch-a=10 pitch-b=15 airfoil-lift-coefficient=6.4 @@ -84,7 +84,7 @@ Single Blade : 6.089 m airfoil-drag-coefficient1=0.10 notorque=0 taper=1 - chord=0.205 + chord=0.23 number-of-segments=5 number-of-parts=4 rel-len-blade-start=0.33 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Avoid hangovers - stay drunk! - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list
[Flightgear-devel] Linux - Solaris AMD64-SPARC64 interfacing
Hi All I have an AMD64 machine that runs a 64-bit flavor of GNU/Linux. I have a Sun SPARC64 machine that runs Solaris 7 with a gnu compiler toolset. Now if I want to use both these machines to run FlightGear, will it work. Say I run Flightgear on the AMD64 and the panel display of FG on SPARC64. 1) Will it work ? 2) Is data transfer between two flight gear apps done only via XML ? 3) Isn't XML very slow ? Remember that the endianness of the AMD64 and SPARC64 are different. As of today I do not have a good Gfx card for the SPARC64, so I have not tried running/compiling FG on it, but if this scenario works, I will spend some cash/time/effort getting one. 4) If it does not work, and if I install Linux on the SPARC64, will the endianness make a difference. Will it work then ? Hoping for an answer. Thanks and regards, Vikas -- http://www.vikaskumar.org/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linux - Solaris AMD64-SPARC64 interfacing
Hi Vikas, Vikas N Kumar wrote: Hi All I have an AMD64 machine that runs a 64-bit flavor of GNU/Linux. I have a Sun SPARC64 machine that runs Solaris 7 with a gnu compiler toolset. Now if I want to use both these machines to run FlightGear, will it work. Say I run Flightgear on the AMD64 and the panel display of FG on SPARC64. 1) Will it work ? Yes, it will work. You'll be able to direct the $DISPLAY to the Sun, but don't expect tremendous frame rates. The performance will be comparable to that when running FG locallly on the Sun. As of today I do not have a good Gfx card for the SPARC64, so I have not tried running/compiling FG on it, but if this scenario works, I will spend some cash/time/effort getting one. I guess this requires a significant amount of cash bacause you might need at last a graphics card of the XVR-4000 class or better to run FlightGear decently. 4) If it does not work, and if I install Linux on the SPARC64, will the endianness make a difference. Will it work then ? No idea, but you could help porting the current state of FlightGear to Solaris :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Forums?
From: Curtis Olson Now that I am hosting the FlightGear web site with a commercial hosting service, it becomes quite easy to setup online forums using phpBB2. I know our development culture is built around mailing lists. I'm sure the FlightGear community will be decisively split between forums versus mailing lists if I ask people's preferences ... so I'm not expecting a consensus here. Is this anything that is worth exploring? Is it worth having both options available? Would end user support benefit from forums? Would forums be useful for those that have trouble with sourceforge's spam blockers? A backup communication mechanism for when the sourceforge email lists experience their inevitable down time? Thoughts? Curt. Ummm...this email makes it sound like we are doing forums just because we can. I think it's already been said, why this isn't such a great idea. My vote would be to just ditch the three development categories. To be honest, I'd sort of expect to see the forum format with third party groups and not the core project. Keeping track of all these channels of dialog is just something I won't be able to do. That said... I do have a fairly complete archive of mail in unix format going back 5 or 6 years (only for the -devel, -model, and -cvs lists). This data could be used to build an archive on flightgear.org. Is this idea of interest to anyone? Best, Jim -- Jim Wilson Kelco Industries PO Box 160 Milbridge, ME 04658 207-546-7989 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Scenery development in Magdeburg (Germany)
If you speak german, and are interested in scenery development, take a look at what City Magdeburg have done with vritual reality. Frauhofer Institut (remember MP3) is providing the technology. Start the video at min 07:27 Roberto - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Forums?
I don't really care about which form is used for user support. If passers-by prefer a web-based forum, then this *may* be the better choice. (But also consider that someone has to do the support. These are to a certain degree developers, so even here it's not unimportant what those prefer. Unless we expect users to help themselves, of course.) But for development the answer is IMHO very clear. Mailing lists are absolutely preferable, and forums are a big annoyance. 1. mail clients are made and optimized for message exchange, while web browsers are made for mere *display* of information. As a consequence, mail clients have decent editors, elaborated search functions, tagging, spell-checking, address books, address completion, filters and personal message categories (rather than cheesy sub-forums). One can easily CC messages to people who are not subscribed etc. In a web browser you get a small box where you have to write with often limited editing capabilities. It's easy to lose all one has written, too. 2. web forums often mangle messages: they have to convert all html-critical stuff (such as to lt; etc.), and they often replace or even remove(!) tabs. As a consequence, one can't take such a forum message and pipe it into the patch program, whereas it's quite normal to save a whole email and pipe it into patch with no problems whatsoever. 3. one can easily edit and reply to several emails while being offline. This is a pain with forums if you don't have DSL/ISDN, but an expensive dial-up connection. 4. this may not mean much to some people, but *I* prefer to see the sender's email address, the date header (with time zone information) etc. On forums all you get is a cheesy nick behind which people hide (I do :-). Sure, the admin has the mail address. But I'm not the admin. 5. it might be easier to explain POP3 scanning of the local provider's mail server to one's employer, than it might be to explain scanning the same game server in the U.S. all day long (yes, I'm speaking of www.flightgear.org ;-) I'm sure if I thought about it longer I would find some more arguments. Why is it that none of the *many* development projects that I know uses a forum for development communication? Those are always only used for users, if at all. We have already had the same discussion in the past, and the mailing list clearly won. Please don't bring the same thing up in regular intervals, in the hope that people eventually give up their resistance. The only effect would be that developers continued on an inofficial list, basically ignoring the official development forum. :-P m. PS: yes, I created an account on the users forum ... :-} - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Forums?
Melchior FRANZ wrote: I'm sure if I thought about it longer I would find some more arguments. I have one to add: You need a graphical desktop in order to deal with the web forum because 'browsing' this forum with Lynx is a PITA (this is one of the rare occasions that I use this acronym ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Forums?
+1 for users forum -1000 for developers forum just my 0.01 cents. On 11/30/06, Martin Spott [EMAIL PROTECTED] wrote: Melchior FRANZ wrote: I'm sure if I thought about it longer I would find some more arguments. I have one to add: You need a graphical desktop in order to deal with the web forum because 'browsing' this forum with Lynx is a PITA (this is one of the rare occasions that I use this acronym ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
