Re: [Flightgear-devel] OSG caching
On Sun, Apr 17, 2011 at 6:10 PM, ThorstenB bre...@gmail.com wrote: On 16.04.2011 21:16, Anders Gidenstam wrote: If I'm not mistaken the particles issue has been around since we got particles, so it is apparently not that bad (leak and race condition) in practice. Ok, thanks! I've create a bug issue as a reminder, in case someone else noticed the issue some day. http://code.google.com/p/flightgear-bugs/issues/detail?id=305 Not sure, but I guess the issues with Effect objects is probably worse than with particles. There's a larger number of Effect objects - and each is connected to a texture (.rgb/.png images) - which may occupy a lot of memory. Just by starting at KSFO, loads of KSFO terminal textures - and textures of 15 different MP aircraft immediately stick in memory... Yes, the big textures will eat memory fast. Particle systems usually use small textures (the effect of the accumulation of particle system updaters is noticeable with wildfire, though - but you'd need a lot of MP aircraft passing through to generate anywhere near those numbers of particle systems). The effect/texture mystery is also solved - alas - explained. There is a global cache in simgear/makeEffect.cxx (effectMap), and it has no condition to ever drop anything. So, created effects always stay in memory until shutdown - hence also their textures. If that's used for scenery/MP aircraft a lot, it _might_ accumulate a lot of memory. Tim might know more about this :). It seemed like a good idea at the time :) The Effect cache could be changed to use osg::observer_ptr, which is a weak pointer. Also, there may be some places where effects are not being found in the cache and are being recreated. Tim cheers, Thorsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Csaba Halász wrote: It is certainly good advice to optimize for the correct processor, but using unsupported instructions typically result in a SIGILL not a SIGSEGV. It would help to see the actual disassembly around the fault and machine register contents. It smells like alignment problem. Hi Jester, I can get that for you, if you want. But what do you need? info registers? The whole coredump file? Cheers, Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Mon, Apr 18, 2011 at 12:16 PM, Christian Schmitt ch...@ilovelinux.de wrote: I can get that for you, if you want. But what do you need? info registers? The whole coredump file? Info registers, and something like x/10i $eip (or $rip on 64 bit) -- Csaba/Jester -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Csaba Halász wrote: Info registers, and something like x/10i $eip (or $rip on 64 bit) Here you go (still on Atom), Phenom this evening. (gdb) info registers eax0x0 0 ecx0xb7e67380 -1209633920 edx0x814aab0135572144 ebx0xb7fbfff4 -1208221708 esp0xbfffc4d8 0xbfffc4d8 ebp0xbfffc4e8 0xbfffc4e8 esi0x3 3 edi0xbfffc72c -1073756372 eip0xb7fb8fdd 0xb7fb8fdd merge_left+9 eflags 0x210286 [ PF SF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) x/10i $eip = 0xb7fb8fdd merge_left+9: mov0x14(%eax),%eax 0xb7fb8fe0 merge_left+12: movl $0x1,0x4(%eax) 0xb7fb8fe7 merge_left+19: mov0x8(%ebp),%eax 0xb7fb8fea merge_left+22: mov0x14(%eax),%edx 0xb7fb8fed merge_left+25: mov0xc(%ebp),%eax 0xb7fb8ff0 merge_left+28: mov0x14(%eax),%eax 0xb7fb8ff3 merge_left+31: cmp%eax,%edx 0xb7fb8ff5 merge_left+33: je 0xb7fb9058 merge_left+132 0xb7fb8ff7 merge_left+35: mov0x8(%ebp),%eax 0xb7fb8ffa merge_left+38: mov0x14(%eax),%eax Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Vostok-1
On Sun, 17 Apr 2011 00:39:52 +0200 Torsten Dreyer wrote: 156MB!? Isn't that a bit - huge? Maybe... but it looks like a fantastic model. If only I had the time to actually work out how to fly it :-) Really impressive work though. -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Vostok-1
Take a look at the J246 model in the JSBSim distribution or in our CVS browser. That's a hypothetical heavy launch vehicle flight model that is under (slow) development. Jon -Original Message- From: AJ MacLeod [mailto:aj-li...@adeptopensource.co.uk] Sent: Monday, April 18, 2011 6:24 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Vostok-1 On Sun, 17 Apr 2011 00:39:52 +0200 Torsten Dreyer wrote: 156MB!? Isn't that a bit - huge? Maybe... but it looks like a fantastic model. If only I had the time to actually work out how to fly it :-) Really impressive work though. -- --- --- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware- sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim issues
On Monday, April 18, 2011 01:09:56 Heiko Schulz wrote: I had a fix locally but with the patch fixing the YASim issue I have now to begin again. I see the problem in the airfoil, but a change to this means that I have to change a lot of other parameters as well to keep the behavior 100% correct. Means a lot of tuning Hi, I took a quick look inside the FDM file. Unless your version is significantly different than mine, this patch should not affect the behaviour. There is no mention of cruise glide angle or approach and cruise fuel levels inside the file. The defaults provided inside FGFDM.cpp are the same as those that were previously hardcoded in Airplane.cpp. Maybe the problem is not at all related to this change? Adrian -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Vostok-1
On Mon, 18 Apr 2011, AJ MacLeod wrote: On Sun, 17 Apr 2011 00:39:52 +0200 Torsten Dreyer wrote: 156MB!? Isn't that a bit - huge? Maybe... but it looks like a fantastic model. If only I had the time to actually work out how to fly it :-) Really impressive work though. Fly it? I thought you just lit a match and then did your best to hang on until the big noisy thing at the other end runs out of gas. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Mon, Apr 18, 2011 at 1:38 PM, Christian Schmitt ch...@ilovelinux.de wrote: Csaba Halász wrote: Info registers, and something like x/10i $eip (or $rip on 64 bit) Here you go (still on Atom), Phenom this evening. (gdb) info registers eax 0x0 0 (gdb) x/10i $eip = 0xb7fb8fdd merge_left+9: mov 0x14(%eax),%eax Hm, ok, that doesn't seem to be SSE related, it's just your everyday NULL pointer. Have to check source code to see how that can happen. -- Csaba/Jester -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Vostok-1
On Mon, 18 Apr 2011 06:31:09 -0700 (PDT), Gene wrote in message alpine.lfd.2.00.1104180630330.13...@grumble.deltasoft.com: On Mon, 18 Apr 2011, AJ MacLeod wrote: On Sun, 17 Apr 2011 00:39:52 +0200 Torsten Dreyer wrote: 156MB!? Isn't that a bit - huge? Maybe... but it looks like a fantastic model. If only I had the time to actually work out how to fly it :-) Really impressive work though. Fly it? I thought you just lit a match and then did your best to hang on until the big noisy thing at the other end runs out of gas. :) g. ..fly it, means control it well enough to do e.g. touch-n-go's at will, not by accident. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Vostok-1
I've never looked into it, but I've always wondered how (or how much) control they have over those giant rockets. I know the space shuttle flies a very precise profile and rolls over at a particular point, so they must have some good control. But I have never thought about how that control is implemented. Do they have secondary thrusters? Can they vector or deflect their thrust? Can they throttle? I know that some smaller rockets will spin along their longitudinal axis to help average out any built in imbalances and keep a stable course (probably the same idea as a rifle bullet.) Curt. On Mon, Apr 18, 2011 at 9:29 AM, Arnt Karlsen a...@c2i.net wrote: On Mon, 18 Apr 2011 06:31:09 -0700 (PDT), Gene wrote in message alpine.lfd.2.00.1104180630330.13...@grumble.deltasoft.com: On Mon, 18 Apr 2011, AJ MacLeod wrote: On Sun, 17 Apr 2011 00:39:52 +0200 Torsten Dreyer wrote: 156MB!? Isn't that a bit - huge? Maybe... but it looks like a fantastic model. If only I had the time to actually work out how to fly it :-) Really impressive work though. Fly it? I thought you just lit a match and then did your best to hang on until the big noisy thing at the other end runs out of gas. :) g. ..fly it, means control it well enough to do e.g. touch-n-go's at will, not by accident. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Vostok-1
Hi Curt, As far as I know, some of the early rocket models either had secondary attitude thrusters or deflector plates placed inside the main rocket exhaust. Modern types (i.e. anything from the 1950s onward) have used gimbaling main engines. If you watch prelaunch space shuttle footage, you can usually see the 3 SSMEs do a full motion cycle just before ignition. Additionally, some rockets, including the Saturn 5 first stage, used airfoils for improved stability. Also, the more sophisticated engines can throttle. IIRC, the Space Shuttle can throttle between approx 65% and 104% of its rated thrust. Typically it throttles back to 65 during a period of max dynamic pressure, just around the time of solid booster separation. At this time, it's already picked up quite a bit of velocity, but is still going through a relatively thick atmosphere. Interestingly, another challenge is to restart a rocket engine in orbit, because the liquid fuels are just floating around. The Saturn 5 third stage, needing to reignite for lunar trajectory insertion, had a separate set of solid fuel engines, which only served the purpose of pushing the fuels down in order to enable a restart. Rather fascinating if you think about what kind of extraordinary challenges space poses for things we take for granted Cheers, Durk On 18 Apr 2011, at 16:41, Curtis Olson wrote: I've never looked into it, but I've always wondered how (or how much) control they have over those giant rockets. I know the space shuttle flies a very precise profile and rolls over at a particular point, so they must have some good control. But I have never thought about how that control is implemented. Do they have secondary thrusters? Can they vector or deflect their thrust? Can they throttle? I know that some smaller rockets will spin along their longitudinal axis to help average out any built in imbalances and keep a stable course (probably the same idea as a rifle bullet.) Curt. On Mon, Apr 18, 2011 at 9:29 AM, Arnt Karlsen a...@c2i.net wrote: On Mon, 18 Apr 2011 06:31:09 -0700 (PDT), Gene wrote in message alpine.lfd.2.00.1104180630330.13...@grumble.deltasoft.com: On Mon, 18 Apr 2011, AJ MacLeod wrote: On Sun, 17 Apr 2011 00:39:52 +0200 Torsten Dreyer wrote: 156MB!? Isn't that a bit - huge? Maybe... but it looks like a fantastic model. If only I had the time to actually work out how to fly it :-) Really impressive work though. Fly it? I thought you just lit a match and then did your best to hang on until the big noisy thing at the other end runs out of gas. :) g. ..fly it, means control it well enough to do e.g. touch-n-go's at will, not by accident. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Christian Schmitt wrote: Here you go (still on Atom), Phenom this evening. Phenom: (gdb) bt #0 0x77bd4504 in merge_left (p=0x7c4f00, q=0x0, list=0x7c4f30) at gpc.c:785 #1 0x77bd6861 in gpc_polygon_clip (op=GPC_UNION, subj=0x747fb0, clip=0x770120, result=0x74edc0) at gpc.c:1383 #2 0x0045a3cb in polygon_clip (poly_op=POLY_UNION, subject=..., clip=...) at polygon.cxx:385 #3 0x0045a613 in tgPolygonUnion (subject=..., clip=...) at polygon.cxx:441 #4 0x0045337c in gen_taxiway (rwy_info=..., alt_m=25.29840087890625, material=..., rwy_polys=0x7fffb0b0, texparams=0x7fffb090, accum=0x7fffa180) at taxiway.cxx:103 #5 0x0040d61d in build_runway (rwy_info=..., alt_m=25.29840087890625, rwy_polys=0x7fffb0b0, texparams=0x7fffb090, accum=0x7fffa180, apt_base=0x7fffa220, apt_clearing=0x7fffa1d0) at build.cxx:300 #6 0x0040fbde in build_airport (airport_id=..., alt_m=25.2984009, runways_raw=..., beacons_raw=..., towers_raw=..., windsocks_raw=..., root=..., elev_src=...) at build.cxx:614 #7 0x00444623 in main (argc=4, argv=0x7fffda68) at main.cxx:340 (gdb) info registers rax0x0 0 rbx0x3 3 rcx0x0 0 rdx0x7c4f30 8146736 rsi0x0 0 rdi0x7c4f00 8146688 rbp0x7fff8430 0x7fff8430 rsp0x7fff8430 0x7fff8430 r8 0x7506b0 7669424 r9 0x3 3 r100x7720def0 140737339514608 r110x206518 ---Type return to continue, or q return to quit--- r120x405540 4216128 r130x7fffda60 140737488345696 r140x0 0 r150x0 0 rip0x77bd4504 0x77bd4504 merge_left+20 eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) x/10i $rip = 0x77bd4504 merge_left+20: mov0x20(%rax),%rax 0x77bd4508 merge_left+24: movl $0x1,0x4(%rax) 0x77bd450f merge_left+31: mov-0x18(%rbp),%rax 0x77bd4513 merge_left+35: mov0x20(%rax),%rdx 0x77bd4517 merge_left+39: mov-0x20(%rbp),%rax 0x77bd451b merge_left+43: mov0x20(%rax),%rax 0x77bd451f merge_left+47: cmp%rax,%rdx 0x77bd4522 merge_left+50: je 0x77bd45a1 merge_left+177 0x77bd4524 merge_left+52: mov-0x18(%rbp),%rax 0x77bd4528 merge_left+56: mov0x20(%rax),%rax -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Right, as said before, you crashed inside the gpc code. Have you tried regenerating this airport using the --nudge option (increasing the value in small increments until you find a value that allows the airport to be successfully built.) Regards, Curt. On Mon, Apr 18, 2011 at 11:59 AM, Christian Schmitt ch...@ilovelinux.dewrote: Christian Schmitt wrote: Here you go (still on Atom), Phenom this evening. Phenom: (gdb) bt #0 0x77bd4504 in merge_left (p=0x7c4f00, q=0x0, list=0x7c4f30) at gpc.c:785 #1 0x77bd6861 in gpc_polygon_clip (op=GPC_UNION, subj=0x747fb0, clip=0x770120, result=0x74edc0) at gpc.c:1383 #2 0x0045a3cb in polygon_clip (poly_op=POLY_UNION, subject=..., clip=...) at polygon.cxx:385 #3 0x0045a613 in tgPolygonUnion (subject=..., clip=...) at polygon.cxx:441 #4 0x0045337c in gen_taxiway (rwy_info=..., alt_m=25.29840087890625, material=..., rwy_polys=0x7fffb0b0, texparams=0x7fffb090, accum=0x7fffa180) at taxiway.cxx:103 #5 0x0040d61d in build_runway (rwy_info=..., alt_m=25.29840087890625, rwy_polys=0x7fffb0b0, texparams=0x7fffb090, accum=0x7fffa180, apt_base=0x7fffa220, apt_clearing=0x7fffa1d0) at build.cxx:300 #6 0x0040fbde in build_airport (airport_id=..., alt_m=25.2984009, runways_raw=..., beacons_raw=..., towers_raw=..., windsocks_raw=..., root=..., elev_src=...) at build.cxx:614 #7 0x00444623 in main (argc=4, argv=0x7fffda68) at main.cxx:340 (gdb) info registers rax0x0 0 rbx0x3 3 rcx0x0 0 rdx0x7c4f30 8146736 rsi0x0 0 rdi0x7c4f00 8146688 rbp0x7fff8430 0x7fff8430 rsp0x7fff8430 0x7fff8430 r8 0x7506b0 7669424 r9 0x3 3 r100x7720def0 140737339514608 r110x206518 ---Type return to continue, or q return to quit--- r120x405540 4216128 r130x7fffda60 140737488345696 r140x0 0 r150x0 0 rip0x77bd4504 0x77bd4504 merge_left+20 eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) x/10i $rip = 0x77bd4504 merge_left+20: mov0x20(%rax),%rax 0x77bd4508 merge_left+24: movl $0x1,0x4(%rax) 0x77bd450f merge_left+31: mov-0x18(%rbp),%rax 0x77bd4513 merge_left+35: mov0x20(%rax),%rdx 0x77bd4517 merge_left+39: mov-0x20(%rbp),%rax 0x77bd451b merge_left+43: mov0x20(%rax),%rax 0x77bd451f merge_left+47: cmp%rax,%rdx 0x77bd4522 merge_left+50: je 0x77bd45a1 merge_left+177 0x77bd4524 merge_left+52: mov-0x18(%rbp),%rax 0x77bd4528 merge_left+56: mov0x20(%rax),%rax -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Curtis Olson wrote: Right, as said before, you crashed inside the gpc code. Have you tried regenerating this airport using the --nudge option (increasing the value in small increments until you find a value that allows the airport to be successfully built.) Regards, Curt. Curt, it's not a question of finishing this build, it's a fact that something is broken and I'd like to do my best to help get it fixed. FYI: I found another, different segfault with EGKK: Starting program: /usr/bin/genapts --input=./EGKK.dat --work=./test Input file = ./EGKK.dat Terrain sources = ./test/SRTM2-Africa-3 ./test/SRTM2-Australia-3 ./test/SRTM2-Eurasia-3 ./test/SRTM2-Islands-3 ./test/SRTM2-North_America-3 ./test/SRTM2-South_America-3 ./test/DEM-USGS-3 ./test/SRTM-1 ./test/SRTM-3 ./test/SRTM-30 Work directory = ./test Nudge = 10 Longitude = -180:180 Latitude = -90:90 Data version = 810 Next airport = EGKK 196 End of file reached last_apt_id.length() = 4 Building EGKK Runway count = 0 Taxiway count = 1 w010n50/w001n51/2941771 Program received signal SIGSEGV, Segmentation fault. 0x0040fc55 in build_airport (airport_id=..., alt_m=0, runways_raw=..., beacons_raw=..., towers_raw=..., windsocks_raw=..., root=..., elev_src=...) at build.cxx:621 621 taxiways[i].generated = true; (gdb) bt #0 0x0040fc55 in build_airport (airport_id=..., alt_m=0, runways_raw=..., beacons_raw=..., towers_raw=..., windsocks_raw=..., root=..., elev_src=...) at build.cxx:621 #1 0x00444e15 in main (argc=3, argv=0x7fffda68) at main.cxx:442 Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim issues
On 18.04.2011 14:51, Adrian Musceac wrote: On Monday, April 18, 2011 01:09:56 Heiko Schulz wrote: I had a fix locally but with the patch fixing the YASim issue I have now to begin again. I see the problem in the airfoil, but a change to this means that I have to change a lot of other parameters as well to keep the behavior 100% correct. Means a lot of tuning I took a quick look inside the FDM file. Unless your version is significantly different than mine, this patch should not affect the behaviour. There is no mention of cruise glide angle or approach and cruise fuel levels inside the file. The defaults provided inside FGFDM.cpp are the same as those that were previously hardcoded in Airplane.cpp. Maybe the problem is not at all related to this change? And you also checked that approach glide angle isn't used? Otherwise, the new default cruise angle (0.0) might not match the original approach angle setting... Anyway, we've committed the patch since it was assumed to not cause major differences. These bugs have been there since the beginning of YASim - so for 10+ years. If it's confirmed that the patch actually caused major differences, then we should improve the patch. We could restore the old buggy behaviour by default and only use the new correct FDM configuration behaviour for new FDMs, e.g. add a switch, such as a new FDM parameter or YASim FDM version number in the xml file to enable the bugfix. Heiko, and anyone else: if you think there is a major change, then directly compare the FDM behaviour with and without the patch - and let us know if there was trouble. And that's the relevant patch: http://www.gitorious.org/fg/flightgear/commit/7f5a0e35184677c21f1eafdfbe6438eb644cdbff cheers, Thorsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shaders flicker
Hi developers, I have a new computer, installed FG on it and have a problem with the graphics. The problem (beside missing runway lights) is that surfaces generated by a shader will flicker. This applies to terrain and aircraft instruments, trees and the Crop texture however do not flicker. The flicker disapears when I switch off Material shaders in the Rendering menu. It seems not to appear everywhere, but only if custom scenery is near. When I tested today, it didn't happen at airports which do not have any buildings. You find screenshots here: http://www.flightgear.org/forums/viewtopic.php?f=37t=11686. I would appreciate any help. Cheers David -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
The first fault is inside the gpc code. As I said before, by my best estimation, gpc is algorithmically correct, but when we throw arbitrary real world numerical data at it, we can encounter some numerical degeneracies and that can blow up the gpc routines. I have no complaints if someone wants to dive into gpc and make it more numerically stable, but that's beyond what I've ever wanted to tackle myself. I'm sure there are a few dumb bugs in the code, but at least for this particular issue, if you are hoping that the fix is a one or two line patch that fixes a dumb programming typo, I afraid that's not the case. You have to dive deep into the underworld of polygon clipping and numerical representation. You need to get down to the level where flipping one trailing bit in a floating point number is the difference between the algorithm being numerically stable, or things going degenerate. Because of the way things work with computer floating point numbers, after clipping one region against another, you can end up with artifacts like a zero area triangle or a boundary that goes out to a point, returns to the previous point, and then continues on. Things happen that you can't see with the naked eye until you zoom in with an electron microscope. The basic process is that terragear/genapts is creating a jigsaw puzzle out of a collection of almost arbitrary polygon data. The source data could overlap in any variety of ways (even by just a very very very tiny bit.) There could be cracks and gaps in the input data. We have to resolve questions like: what if a road, airport runway, and ocean area all want to occupy the same physical space (due to different data sets assembled with different standards of precision.) The end result can't have any slivers that are too small, and can't have any gaps or cracks. It needs to be topologically consistent. However, given the nature of the input data and the nature of ieee floating point numbers, this is not always possible to do. And as the input data gets more detailed, these problems are magnified. So my suggestion is to focus on how to maintain a topologically consistent numerical representation of arbitrary polygon data while performing arbitrary clipping and union functions to the pieces. That is where the problems will get cured. Hunting for a stray null pointer that some programmer inadvertently screwed up, or digging into gcc optimization routines might all be interesting, and you may just find some real problems that have been lurking, but you won't have addressed the core underlying issues that cause most of the problems with terragear. One possible solution would be to create a fine grid and map all the input data to our grid --- but there are some challenges with properly mapping an arbitrary polygon (out of some gis database) to our underlying grid. That can't be done perfectly so all kinds of special cases will need to be discovered the hard way and dealt with. Maybe we could create really fine mesh, and then paint each grid section based on the highest ranking polygon type that covers that grid. Maybe this could even be done in the form of a raster image? There are probably ways this could be done to avoid the polygon clipper problems, but none of these approaches would be trivial to implement and would bring their own unique challenges and problems that we'd have to discover the hard way through trial and error. And with all of this, I'd love for anyone to advance the discussion by jumping in with code that fixes the problems or new ways to do things that are better than the way we were doing things before ... or even evidence that proves me entirely wrong. I'm stating the way I understand things and the observations and evidence I have ... and my hope is that it lights a fire under someone to advance the discussion by proving me wrong or coming up with something better ... while simultaneously saving people from hunting for problems in fruitless areas. Best regards, Curt. On Mon, Apr 18, 2011 at 12:20 PM, Christian Schmitt wrote: Curtis Olson wrote: Right, as said before, you crashed inside the gpc code. Have you tried regenerating this airport using the --nudge option (increasing the value in small increments until you find a value that allows the airport to be successfully built.) Regards, Curt. Curt, it's not a question of finishing this build, it's a fact that something is broken and I'd like to do my best to help get it fixed. FYI: I found another, different segfault with EGKK: Starting program: /usr/bin/genapts --input=./EGKK.dat --work=./test Input file = ./EGKK.dat Terrain sources = ./test/SRTM2-Africa-3 ./test/SRTM2-Australia-3 ./test/SRTM2-Eurasia-3 ./test/SRTM2-Islands-3 ./test/SRTM2-North_America-3 ./test/SRTM2-South_America-3 ./test/DEM-USGS-3 ./test/SRTM-1 ./test/SRTM-3 ./test/SRTM-30 Work directory = ./test Nudge = 10 Longitude = -180:180 Latitude = -90:90 Data
Re: [Flightgear-devel] Shaders flicker
David Glowsky wrote: Hi developers, I have a new computer, installed FG on it and have a problem with the graphics. The problem (beside missing runway lights) is that surfaces generated by a shader will flicker. This applies to terrain and aircraft Moin David, while I have no solution for the main problem, the following patch (kudos to Jester) helps here on my ATI to let runway lights shine as expected: http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=blob;f=dev- games/simgear/files/simgear-radeon-fix-runway- lights.patch;h=a48c4bf62cd52ffe7f1c2c71dbb8f95ac41fbb09;hb=HEAD Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders flicker
On Mon, 18 Apr 2011 19:56:38 +0200, David wrote in message banlktimbxl03ofww5qsvqoygszwybhs...@mail.gmail.com: Hi developers, I have a new computer, installed FG on it and have a problem with the graphics. The problem (beside missing runway lights) is that surfaces generated by a shader will flicker. This applies to terrain and aircraft instruments, trees and the Crop texture however do not flicker. The flicker disapears when I switch off Material shaders in the Rendering menu. It seems not to appear everywhere, but only if custom scenery is near. When I tested today, it didn't happen at airports which do not have any buildings. You find screenshots here: http://www.flightgear.org/forums/viewtopic.php?f=37t=11686. ..first, try take the same screenshots with today's fg-git, the shaders _may_ have been fixed since you shot your shots. I would appreciate any help. ..I suspect FG shader bugs not properly supporting ATI hardware, most if not all FG developers have Nvidea graphics on closed source nvidea drivers and noton GPL nouveau, a quick test can be done with Knoppix: http://nouveau.freedesktop.org/wiki/ http://knopper.net/knoppix/knoppix64-en.html ..I'd like to see what happen when you do exactly the same things in FG as you did here, but running your box on Knoppix and installing the same FG in your Knoppix session. http://knopper.net/knoppix/index-en.html http://knopper.net/knoppix/knoppix64-en.html ..if you don't wanna touch your disks, run Knoppix in ramdisk and install the same version FG into your ramdisk session and then try take the same screenshots as you did on Wintendo and ATI's drivers. (Usb sticks and SD etc flash cards are other possible options.) ..boot it with 'knoppix toram ' and see what happens, if that fails to do what we want, try e.g. 'knoppix toram xmodule=ati ', more ideas to try append to the boot command: ftp://ftp.uni-kl.de/pub/linux/knoppix/knoppix-cheatcodes.txt ..xmodule's I'd like to see compared, is radeon, radeonhd, and ATI's own fglrx, and on Nvidea's, nvidea and nouveau. ..note that you _may_ have to use knoppix64 to boot a 64bit kernel on a 64bit cpu, and knoppix32 or somesuch to boot a 32bit kernel on 32bit cpus, I'm not up to date on current knoppix boot cheatcodes. _Play_around_. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Mon, 18 Apr 2011 19:20:59 +0200, Christian wrote in message 20110418172059.cd1fe1318...@mail.sigmos.de: Curtis Olson wrote: Right, as said before, you crashed inside the gpc code. Have you tried regenerating this airport using the --nudge option (increasing the value in small increments until you find a value that allows the airport to be successfully built.) Regards, Curt. Curt, it's not a question of finishing this build, it's a fact that something is broken and I'd like to do my best to help get it fixed. ..heeding Curt's hint on ' --nudge ', helps find a new way to crash it, which again means we get a little closer to a viable diagnosis on gpc. Without that, expect no fix. FYI: I found another, different segfault with EGKK: ..this will help, once we understand the bug, we can fix it. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim issues
On Monday, April 18, 2011 20:51:17 ThorstenB wrote: And you also checked that approach glide angle isn't used? Otherwise, the new default cruise angle (0.0) might not match the original approach angle setting... No mention of approach glide angle either. I have no idea how this applies to rotorcraft since I only dug into the traditional winged code. A quick search through fgdata/Aircraft revealed the following aircraft to have different glide angles specified for approach and cruise: - ASK13 - ASK21 - ASK21-MI - IAR80 (fixed by Emilian I believe) - PaperAirplane ASK13 and PaperAirplane have the biggest difference between the two numbers (23 vs 2). The fuel is a different matter, a very large number of aircraft have numbers other than default. As far as the solver is concerned, the glide angle has a very large influence on the coefficients, while the fuel has a relatively small relevance in the final numbers. Adding a tag which would be used on the new models could retain compatibility for older aircraft which are no longer developed. On the other hand, it would be a pity to have the very clean code of YASim cluttered by special cases for bugs. It's a tough choice, your call I guess. Adrian Anyway, we've committed the patch since it was assumed to not cause major differences. These bugs have been there since the beginning of YASim - so for 10+ years. If it's confirmed that the patch actually caused major differences, then we should improve the patch. We could restore the old buggy behaviour by default and only use the new correct FDM configuration behaviour for new FDMs, e.g. add a switch, such as a new FDM parameter or YASim FDM version number in the xml file to enable the bugfix. Heiko, and anyone else: if you think there is a major change, then directly compare the FDM behaviour with and without the patch - and let us know if there was trouble. And that's the relevant patch: http://www.gitorious.org/fg/flightgear/commit/7f5a0e35184677c21f1eafdfbe643 8eb644cdbff cheers, Thorsten --- --- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim issues
Hello Heiko, does your local FDM still uses default approach fuel etc? But even if not, there should be no difference in the flight behavior. The only effect of the approach fuel level is (for a rotorcraft) within the gear solver. By the way: I would prefer to use the old default values for the gear solver. The spring constants of a gear should not be a function of the approach fuel settings. Maybe some gears would need some tuning with the patch otherwise. The _approachWeight = _emptyWeight + totalFuel*_approachFuel; should be moved behind the gear solver call. Maik Am 17.04.2011 22:37 schrieb Heiko Schulz: Hi, Well, I'm glad it helps. The patch should not affect the solution too much in most cases, I've checked this myself. I have tested it, and well, at least for helicopters there seems a difference. No idea how long we have this bug now- but I guess a very long time. I was working on the bo105 to get to a more realistic climb rate by keeping the flight behavior matching to the known detailed datas. The bo105 doesn't have a realistic climbrate, but while reaction time, rate and control sensibility matches exactly the real one. I can now see a difference between before and after this patch, and now it seems the climb rate is even less than before. Heiko -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders flicker
I also have the flickering issue with shaders on. (ATI/AMD, Debian, fglrx) On my system the problem occurs at low framerates (30-35 fps) caused by the scenery. On lighter airports I get 60-75 fps and the problem seems to be gone. David, maybe someone of us should file a bug report here: http://code.google.com/p/flightgear-bugs/issues/list -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim issues
Hi, Hello Heiko, does your local FDM still uses default approach fuel etc? But even if not, there should be no difference in the flight behavior. The only effect of the approach fuel level is (for a rotorcraft) within the gear solver. Heiko, and anyone else: if you think there is a major change, then directly compare the FDM behaviour with and without the patch - and let us know if there was trouble. I was already aware of that, and used the approach settings to improve the behaviour of the gear on the EC130 B4. I wanted compare before and aft patch-version anyway to see if I'm wrong here and mixed something up, but unfortunately real life came with night shift working and having a damaged car by an arson attack the last night before one. A lot of things to manage, so I'll have to wait for the easter-weekend for some free time. I hope I'm not doing too much noise here, especially when I'm wrong. Kind Regards Heiko -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
