Re: [Flightgear-devel] ident from phantom DME ... and some questions
In the real world, some VOR stations and even some localizers have a colocated DME station ... but there are plenty that don't. And there are standalone DME stations without a VOR. The DME has its own Morse ident, with a distinctive higher pitch. And IIRC the VOR ident repeats every 10 seconds, the DME ident repeats every 30 seconds. I hereby offer to write the code to fix this ... but only if somebody asks me to. May I kindly ask? On several occasions in the past I have sent in patches to solve specific problems, but in all cases such contributions have been ignored. Consider for example my patch to hsi.xml. Nobody said good patch, let's commit or bad patch, try again or even responded to my HSI bug report in any way. This is a well known feature on this list :-) I think the CVS admins are doing a very good job scanning this list for patches, checking them out and submitting them and I am sure this is sometimes not an easy job. It is also easy to overlook a submitted patch when the list is very busy. I would love to have a bugtracker (stop searching, there is none) but thats only a small part of the solution. We still need somebody who looks after the submitted bugs and patches. I have no solution for that. IMHO: -- What are people supposed to do when they find a bug? ask if it really is a bug, ask if someone else is up to it, if not: fix it and submit a patch. -- Is it considered rude to submit a patch? nope -- Is there a bug tracker somewhere? I wasn't able to find one. none -- Are we supposed to take seriously the list on the wiki site? http://wiki.flightgear.org/flightgear_wiki/index.php?title=Bugs It doesn't seem to be very complete. I wish these were the only bugs :-) quote It makes no claim to be a complete list, or even to be particularly accurate./quote Noticed the little [edit] in the upper right corner? You might go ahead and make this a perfect list of known bugs (and hopefully fixes). It's a wiki. -- Anything else that folks ought to know? Aviation is lifelong learning :-) - 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] ident from phantom DME ... and some questions
* John Denker -- Sunday 28 January 2007: [DME] I hereby offer to write the code to fix this ... but only if somebody asks me to. What I know about VOR and DME I learned from fgfs. So I can't say if there's something wrong, as long as there aren't blatant coding errors. But when Torsten agrees that there's a bug, then a patch would sure be a good idea. On several occasions in the past I have sent in patches to solve specific problems, but in all cases such contributions have been ignored. Same happened to me when I submitted my first patches. I think that's normal. (And yes, I was pissed, too! :-) BTW: on IRC you can often get instant feedback. Consider for example my patch to hsi.xml. Nobody said good patch, let's commit or bad patch, try again or even responded to my HSI bug report in any way. Not everbody with commit permissions knows all parts of fgfs equally well, or is an expert in aviation or all parts of it. In case of doubt, developers rather wait for someone else to comment/commit. And then a patch is easily lost, of course. Every developer has his areas for which he feels responsible, and for which the other developers deem him responsible. I would, for example, have felt responsible for your location-in-air dialog, as I had worked a lot on GUI matters. There were reasons why I didn't pick it up: (1) I wasn't at my computer at that time. (2) it wasn't submitted as a diff, so I couldn't see what it actually changed. (3) it was utterly overcommented. fgfs isn't a Literate Programming project. Place for literature is in the cvs logs, not the code. :-} -- What are people supposed to do when they find a bug? Report it, and if possible submit a fix in form of a unified diff. Only comment what the code self doesn't tell. Don't write *what* the code does, but why it does it, and only if it's not obvious anyway. If one patch has been ignored for longer, point to it again. -- Is there a bug tracker somewhere? I wasn't able to find one. Yes, but no developer looks into it. It's only there because every sf.net project has one. Don't use it. But for sake of completeness, here's a two links: fg: http://sourceforge.net/tracker/?group_id=583atid=100583 sg: http://sourceforge.net/tracker/?group_id=26352atid=387123 -- Are we supposed to take seriously the list on the wiki site? IMHO, no. While the wiki is official, and developers occasionally look into it, many TODO/bugs lists there seem to be mere user phantasies and aren't acknowledged by any developer. But I haven't read it for a while. m. - 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] ident from phantom DME ... and some questions
Hi, Melchior FRANZ wrote: -- Is there a bug tracker somewhere? I wasn't able to find one. Yes, but no developer looks into it. It's only there because every sf.net project has one. Don't use it. But for sake of completeness, here's a two links: fg: http://sourceforge.net/tracker/?group_id=583atid=100583 sg: http://sourceforge.net/tracker/?group_id=26352atid=387123 Is there a specific reason related to bug-tracking or sourceforge's implementation of it why developers ignore that bug tracker? Or is it just because users don't use the bug tracker? Or because developers don't like bugtracking? Just curious. Cheers, Rakf - 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] ident from phantom DME ... and some questions
Ralf Gerlich a écrit : Is there a specific reason related to bug-tracking or sourceforge's implementation of it why developers ignore that bug tracker? Or is it just because users don't use the bug tracker? Or because developers don't like bugtracking? Bugtracking needs: 1) People to know how to use it, particularly the bug repporters wich are often not developpers and fail to issue usefull reports, thus flooding the database. Thats a difficult point. 2) An administrator to qualify bugs, remove/classify redondant rapports, and manage the whole thing. It really costs a lot of time. IMHO, thats the main objections. Alexis - 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] location-in-air
On 01/28/2007 05:12 AM, Melchior FRANZ wrote: I would, for example, have felt responsible for your location-in-air dialog, as I had worked a lot on GUI matters. There were reasons why I didn't pick it up: (1) I wasn't at my computer at that time. Please check again the next time you are at the computer. http://www.av8n.com/fly/fgfs/location-in-air.xml.htm (2) it wasn't submitted as a diff, so I couldn't see what it actually changed. Actually it was submitted both ways. My makefile generates the diff automatically. There is a link to the diff from the aforementioned URL. Or just go directly here: http://www.av8n.com/fly/fgfs/location-in-air.xml.diff (3) it was utterly overcommented. fgfs isn't a Literate Programming project. Place for literature is in the cvs logs, not the code. :-} An even better type of literature is documentation in a place and in a form that users can use. I took the long comments out of location-in-air.xml and moved them to http://www.av8n.com/fly/fgfs/README.location-in-air - 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] picking the /nearest/ navaid or waypoint
On 01/28/2007 05:12 AM, Melchior FRANZ wrote: If one patch has been ignored for longer, point to it again. On 01/11/2007 03:55 AM, John Denker wrote: 1) Did you know that there are 8 different BRAVO intersections in the database? Until now there was no support in the code for this; all but one of the entries was thrown away at the lowest level. There was a comment in the code saying that fixing this was on the TODO list. Well, now it's fixed. The low-level database code keeps all the information around. This applies to named waypoints -- also called fixes in the code -- including intersections. 2) As for navaids (as opposed to waypoints) the low-level code already provided support for ambiguous IDs, but the information was not being used very wisely by the higher layers. 3) I patched a bunch of the .cxx and .hxx files so that they now provide the following feature: If you ask for a navaid or waypoint by ID, and the ID is ambiguous, you will get the one /nearest/ to your present position. This is part of my ongoing campaign to make the location-in-air popup work properly. BTW, on initial startup, when specifying your very first position, you will get the navaid or waypoint closest to KSFO. The diffs can be found at http://www.av8n.com/fly/fgfs/nearest-fix.diff http://www.av8n.com/fly/fgfs/strx.hxx (diffs against tonight's cvs version). Comments, anyone? - 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] location-in-air
* John Denker -- Sunday 28 January 2007: http://www.av8n.com/fly/fgfs/location-in-air.xml.diff +# We need our own private variables, to have and to hold, +# without worrying about whether the FDM will mess with +# them. A subset of these will be copied to FDM variables +# with similar names. Which subset depends on which radio +# button is pushed. Umm ... that's exactly the kind of comment that I absolutely detest. We all know what local variables are. And we can see what the code does. No need to repeat it in human language. Nasal/c++/xml *is* already human language, or we would all code in 1 and 0. And I will also not commit anything that uses baby-language. (myvar, mynode, ...). But I'll test the patch and see if agree with the code. :-) m. - 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 Book
Hi Nick, Nick Warne schrieb: On Friday 26 January 2007 23:46, Christian Mayer wrote: The quality of the text looks quite bad to me, it's about amateur writing level, I guess. The layout was done with OpenOffice which also fits in this picture. What on earth do you mean that statement? I tried to express that the book looks to me like the work of an amateur who tries to make some fast money by writing about an subject he doesn't know much more than the audience he targets. By using OpenOffice as the typesetting system he shows that there isn't an institution (e.g. the publisher) behind him that takes care of the little things that are the difference between an amateur work and an professional work (e.g. an editor, professional layout, perfect typesetting...) CU, Christian PS: OpenOffice is an great office suite - but it isn't a good publishing tool. For writing letters it's perfect, but the requirements for writing a book are quite different though. - 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 Book
Christian Mayer wrote: By using OpenOffice as the typesetting system he shows that there isn't an institution (e.g. the publisher) behind him that takes care of the little things that are the difference between an amateur work and an professional work (e.g. an editor, professional layout, perfect typesetting...) Apparently you know very little about OpenOffice. OpenOffice has much more in common with 'professional' typesetting software like FrameMaker than you'd probably expect - and certainly more than the competing M$-products BUT, this is not the point. You can do excellent typesetting with OpenOffice and doing very bad typesetting with FrameMaker is easy ;-) - it just depends on the skills of the respective user. Judging this book just by the software that was used to make it sounds really stupid. Indeed, this book was produced with a low buget, probably a budget that doesn't allow for an expensive 'toolchain', but on the other hand it has a pretty moderate price tag. So, what's wrong here ? A book that targets at FlightGear beginners doesn't necessarily have meet the level of O'Reilly sendmail 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
[Flightgear-devel] Patch to fix c182rg squat switch
Please apply this patch to the c182rg
controls.geartoggle won't allow gear handle to move to the down
position on the ground after it is moved to the up position.
Thanks,
Ron
Index: Nasal/squatswitch.nas
===
RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c182rg/Nasal/squatswitch.nas,v
retrieving revision 1.2
diff -u -w -r1.2 squatswitch.nas
--- Nasal/squatswitch.nas 21 Jan 2007 16:28:22 - 1.2
+++ Nasal/squatswitch.nas 28 Jan 2007 17:48:20 -
@@ -52,3 +52,6 @@
}
gearFncy();
}
+
+controls.gearToggle = func { controls.gearDown(getprop(/controls/gear/gear-handle-down) 0 ? -1 : 1); }
+
-
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] KT-70 3D Model for Instruments-3D
Hi all, I modelled a KT-70 transponder. It is at http://www.jentronics.com/fgfs/Instruments-3d.tgz Attached is a patch to install it in the c182rg. Also, I submitted a patch to enhance the test display on this instrument (but not vital to performance): http://sourceforge.net/mailarchive/forum.php?thread_id=31511054forum_id=1919 It would be great if all could go into CVS! Thanks, Ron Index: Models/c182rg-dpm.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c182rg/Models/c182rg-dpm.xml,v retrieving revision 1.2 diff -u -w -r1.2 c182rg-dpm.xml --- Models/c182rg-dpm.xml 21 Jan 2007 16:31:54 - 1.2 +++ Models/c182rg-dpm.xml 28 Jan 2007 17:48:20 - @@ -5,28 +5,37 @@ pathc182rg.ac/path !-- 3D Panel -- - panel namePanel/name pathAircraft/c182rg/Panels/c182rg-3d-panel.xml/path bottom-left - x-m-0.11/x-m + x-m-0.16/x-m y-m-0.55/y-m z-m-0.25/z-m /bottom-left bottom-right - x-m-0.11/x-m + x-m-0.16/x-m y-m 0.65/y-m z-m-0.25/z-m /bottom-right top-left - x-m-0.11/x-m + x-m-0.16/x-m y-m-0.55/y-m z-m 0.08/z-m /top-left /panel model +nameTransponder/name +pathAircraft/Instruments-3d/kt70/kt70.xml/path +offsets + x-m-0.155/x-m + y-m-0.015/y-m + z-m-0.225/z-m +/offsets + /model + + model nameMagCompass/name pathAircraft/Instruments-3d/mag-compass.xml/path offsets - 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] KT-70 3D Model for Instruments-3D
Ron Jensen wrote: I modelled a KT-70 transponder. It is at http://www.jentronics.com/fgfs/Instruments-3d.tgz Attached is a patch to install it in the c182rg. Did you check that this doesn't collide with the transponder that's already present ? http://sourceforge.net/mailarchive/forum.php?thread_id=31514314forum_id=47269 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] KT-70 3D Model for Instruments-3D
Ron Jensen wrote: I modelled a KT-70 transponder. It is at http://www.jentronics.com/fgfs/Instruments-3d.tgz Attached is a patch to install it in the c182rg. On 01/28/2007 01:28 PM, Martin Spott wrote: Did you check that this doesn't collide with the transponder that's already present ? http://sourceforge.net/mailarchive/forum.php?thread_id=31514314forum_id=47269 Don't worry, Ron Jensen has been communicating off-list with the guy who installed the other transponder (me). I'd say we were working together, except that he's done almost all of the work. He has a good collaborative spirit and good communication skills. I wish certain other people would follow his example. - 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] location-in-air
* John Denker -- Sunday 28 January 2007: I took the long comments out of location-in-air.xml and moved them to http://www.av8n.com/fly/fgfs/README.location-in-air Reviewed and rejected. This contains rather bad code and needs some serious reworking. It even replaces existing good code with bad code. Can't commit that in this form. * John Denker -- Sunday 28 January 2007: I wish certain other people would follow his example. Maybe you find certain other people who you can work with to fix the patch. Looks like I'm not the first address. m. :-} - 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] Rendered geometry/scenery graphics messed up on my Fedora 6 system with NVidia GeForce 600 graphics card
Hi, I just started working with FlightGear. I checked out the latest (head of trunk) distribution of FlightGear, data and SimGear from CVS. After finding that fgfs and js_demo core dumped with the existing rpm versions of the dependent libraries, I grabbed the latest CVS/SVN sources for OpenThreads, OpenProducer, OpenSceneGraph, plib, freeglut and recompiled. (The .9.10 release also core dumped with the released rpms of these libraries as well on my box.) So now the programs run without core dumping, but I'm having trouble with the rendering as shown in this picture: http://www.futuretek.com/flight/flight1.jpg I can hear the sound and see the heads up display, the cockpit instruments, the runway lights and the sun, but the airplane and scenery geometry isn't being rendered correctly. Any ideas why this would be occurring and how to fix it? Thanks, Rob p.s. Here's some information about my system in case that helps: [EMAIL PROTECTED] bin]$ gl-info GL_VENDOR = NVIDIA Corporation GL_RENDERER = GeForce Go 6800 Ultra/PCI/SSE2 GL_VERSION = 2.1.0 NVIDIA 97.46 GL_EXTENSIONS = GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_RED_BITS = 8 GL_GREEN_BITS = 8 GL_BLUE_BITS = 8 GL_ALPHA_BITS = 0 GL_DEPTH_BITS = 24 GL_INDEX_BITS = 0 GL_STENCIL_BITS = 0 GL_ACCUM_RED_BITS = 16 GL_ACCUM_GREEN_BITS = 16 GL_ACCUM_BLUE_BITS = 16 GL_ACCUM_ALPHA_BITS = 16 GL_AUX_BUFFERS = 4 GL_MAX_ATTRIB_STACK_DEPTH = 16 GL_MAX_NAME_STACK_DEPTH = 128 GL_MAX_TEXTURE_STACK_DEPTH = 10 GL_MAX_PROJECTION_STACK_DEPTH = 4 GL_MAX_MODELVIEW_STACK_DEPTH = 32 GL_MAX_CLIP_PLANES = 6 GL_MAX_EVAL_ORDER = 8 GL_MAX_LIGHTS = 8 GL_MAX_LIST_NESTING = 64 GL_MAX_TEXTURE_SIZE = 4096 GL_MAX_VIEWPORT_DIMS = 4096,4096 GL_POINT_SIZE_GRANULARITY = 0.125 GL_POINT_SIZE_RANGE = 1,63.375 Default values: GL_UNPACK_ALIGNMENT = 4 GL_UNPACK_ROW_LENGTH = 0 GL_UNPACK_SKIP_PIXELS = 0 GL_UNPACK_SKIP_ROWS = 0 GL_BLEND_SRC = 1 GL_BLEND_DST = 0 xwininfo: Window id: 0x123 Desktop Absolute upper-left X: 0 Absolute upper-left Y: 0 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1920 Height: 1200 Depth: 24 Visual Class: TrueColor
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Scripting NasalSys.cxx, 1.54, 1.55
Mathias,
Selon Mathias Froehlich :
--- 434,445
if(_purgeListeners) {
_purgeListeners = false;
! mapint, FGNasalListener *::iterator it;
! for(it = _listener.end(); it != _listener.end();) {
FGNasalListener *nl = it-second;
This line above is suspicious to me. How 'it' could be valid the first time when
initialized with end() ? The previous code was doing pre decrementation that I
don't see here.
if(nl-_dead) {
! _listener.erase(it--);
delete nl;
+ } else {
+ --it;
}
}
-Fred
--
Frédéric Bouvier
http://frfoto.free.fr Photo gallery - album photo
http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery
http://fgsd.sourceforge.net/ FlightGear Scenery Designer
-
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] KT-70 3D Model for Instruments-3D
On 01/28/2007 01:28 PM, Martin Spott wrote: Did you check that this doesn't collide with the transponder that's already present Ah, yes, very newly present. Here is the patch to remove my semblance of a transponder to make way for Ron Jensen's vastly nicer transponder. This is a patch against the CVS from a few minutes ago. This can be applied before or after the patch Ron submitted this morning. Index: c182rg-3d-panel.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c182rg/Panels/c182rg-3d-panel.xml,v retrieving revision 1.4 diff -u -b -r1.4 c182rg-3d-panel.xml --- c182rg-3d-panel.xml 22 Jan 2007 18:11:26 - 1.4 +++ c182rg-3d-panel.xml 28 Jan 2007 20:33:57 - @@ -235,11 +235,6 @@ h85/h /instrument - instrument include=../../Instruments/xpdr-kt76c.xml - nameKT76c Transponder/name - x775/x - y29/y - /instrument !-- end radio stack -- !-- center stack controls -- - 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] Patch: Re: Bug in property tree
Hi, sorry, the first sentence in the description was wrong. It should look like this: What the patch does: Every time a path is stored in a path-cache of a property node, the referenced node adds a link to this path-cache. Therefore a node knows all other nodes, which references him in their path-cache. Maik Justus schrieb am 28.01.2007 21:37: Hi, here is a patch, which adds remove functionality to the patch cache (hash-table) of the property tree. What the patch does: Every time a path is stored in a path-cache of a property node, the referenced hash table adds a link to this path-cache. Therefore a node knows all other nodes, which references him in their path-cache. If a node is removed, it and all children tell all patch-caches, which link to them, to delete this entries. Therefore it is save now, to address a node by its name, even if a node with the same name was deleted before (e.g. the AI/ tree is very dynamic). The property tree is a very central part of flightgear. Therefore I decided to comment out my debug outputs instead of deleting them (maybe it's easier to check the functionality of the patch). Even the _value member of SGPropertyNode::hash_table is only for the debug output. If noone complains, I will post a patch without the debug stuff to be committed to cvs soon. (With this patch and the multiplayer patch (in cvs) aerotow should work stable over the net). Maik Maik Justus schrieb am 22.01.2007 01:21: Hi just to clarify: if I wrote delete, I meant not delete as cpp defines delete. I thought of removing a node. Maik Maik Justus schrieb am 22.01.2007 01:11: Hi, the patch-cache of the property tree is not designed for node-deleting. But the multiplayer code deletes nodes deletes nodes very often. If you access such nodes by name, which is necessary to acces multiplayer-nodes (you can not store a pointer, tho node could be deleted meanwhile), you often get a pointer to a already deleted node. As a result, aerotowing often fails, if one player was removed from the multiplayer list for a short time. As an ugly fix, you can switch off the path cache and aerotow works as expected. As a solution I think of a vector of path caches at every node, which stores all path caches, if they are pointing to this node. If a node is removed, all linked path caches get this information and the link can be deleted. This must be done for all child-nodes, too. (one question: which member of SGPropertyNode is called if a node is removed from the tree?) Maik - 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] Rendered geometry/scenery graphics messed up on my Fedora 6 system with NVidia GeForce 600 graphics card
Rob Ratcliff wrote: Hi, I just started working with FlightGear. I checked out the latest (head of trunk) distribution of FlightGear, data and SimGear from CVS. After finding that fgfs and js_demo core dumped with the existing rpm versions of the dependent libraries, I grabbed the latest CVS/SVN sources for OpenThreads, OpenProducer, OpenSceneGraph, plib, freeglut and recompiled. (The .9.10 release also core dumped with the released rpms of these libraries as well on my box.) So now the programs run without core dumping, but I'm having trouble with the rendering as shown in this picture: http://www.futuretek.com/flight/flight1.jpg I can hear the sound and see the heads up display, the cockpit instruments, the runway lights and the sun, but the airplane and scenery geometry isn't being rendered correctly. Any ideas why this would be occurring and how to fix it? Thanks, Rob p.s. Here's some information about my system in case that helps: [EMAIL PROTECTED] bin]$ gl-info GL_VENDOR = NVIDIA Corporation GL_RENDERER = GeForce Go 6800 Ultra/PCI/SSE2 GL_VERSION = 2.1.0 NVIDIA 97.46 GL_EXTENSIONS = GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_RED_BITS = 8 GL_GREEN_BITS = 8 GL_BLUE_BITS = 8 GL_ALPHA_BITS = 0 GL_DEPTH_BITS = 24 GL_INDEX_BITS = 0 GL_STENCIL_BITS = 0 GL_ACCUM_RED_BITS = 16 GL_ACCUM_GREEN_BITS = 16 GL_ACCUM_BLUE_BITS = 16 GL_ACCUM_ALPHA_BITS = 16 GL_AUX_BUFFERS = 4 GL_MAX_ATTRIB_STACK_DEPTH = 16 GL_MAX_NAME_STACK_DEPTH = 128 GL_MAX_TEXTURE_STACK_DEPTH = 10 GL_MAX_PROJECTION_STACK_DEPTH = 4 GL_MAX_MODELVIEW_STACK_DEPTH = 32 GL_MAX_CLIP_PLANES = 6 GL_MAX_EVAL_ORDER = 8 GL_MAX_LIGHTS = 8 GL_MAX_LIST_NESTING = 64 GL_MAX_TEXTURE_SIZE = 4096 GL_MAX_VIEWPORT_DIMS = 4096,4096 GL_POINT_SIZE_GRANULARITY = 0.125 GL_POINT_SIZE_RANGE = 1,63.375 Default values: GL_UNPACK_ALIGNMENT = 4 GL_UNPACK_ROW_LENGTH = 0 GL_UNPACK_SKIP_PIXELS = 0 GL_UNPACK_SKIP_ROWS = 0 GL_BLEND_SRC = 1 GL_BLEND_DST = 0 xwininfo: Window id: 0x123 Desktop Absolute upper-left X: 0 Absolute upper-left Y: 0
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: FlightGear/src/Scripting NasalSys.cxx, 1.55, 1.56
Melchior,
Selon Melchior Franz :
--- 435,443
_purgeListeners = false;
mapint, FGNasalListener *::iterator it;
! for(it = _listener.end(); --it != _listener.end();) {
FGNasalListener *nl = it-second;
if(nl-_dead) {
! _listener.erase(it);
delete nl;
}
}
I am pretty sure it is illegal to use an iterator after it was used for erasing
an item. I think the code below is better and works on every systems :
_purgeListeners = false;
mapint, FGNasalListener *::iterator it;
for(it = _listener.end(); --it != _listener.end();) {
FGNasalListener *nl = it-second;
if(nl-_dead) {
mapint, FGNasalListener *::iterator it2 = it++; = use a copy
of the iterator
_listener.erase(it2); = to erase the item
delete nl;
}
}
But I thing the purpose of reverse iterators is exactly to do that and the use
of them should be more valid in the end.
-Fred
--
Frédéric Bouvier
http://frfoto.free.fr Photo gallery - album photo
http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery
http://fgsd.sourceforge.net/ FlightGear Scenery Designer
-
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: FlightGear/src/Scripting NasalSys.cxx, 1.55, 1.56
* Frederic Bouvier -- Sunday 28 January 2007: I am pretty sure it is illegal to use an iterator after it was used for erasing an item. I think the code below is better and works on every systems : [...] But I thing the purpose of reverse iterators is exactly to do that and the use of them should be more valid in the end. Sheesh. There's a reason why I usually just use good old foo.size() with random access. :-/ m. - 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] KT-70 3D Model for Instruments-3D
Ron Jensen wrote: Also, I submitted a patch to enhance the test display on this instrument (but not vital to performance): http://sourceforge.net/mailarchive/forum.php?thread_id=31511054forum_id=1919 I'm unable to handle this, please someone else do so, 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] FlightGear Book
Christian Mayer wrote: Hm, why do people think I'm trying to attack OpenOffice?!? I even use it myself... I'm only claiming that: Martin Spott schrieb: Apparently you know very little about OpenOffice. [...] Typesetting isn't only abut the placement of pictures - it's also about ligatures and kerning, to name a few. Tell me something new After diging a bit into this topic you'll realize that OpenOffice, certainly not being perfect, actually _does_ offer most of what you're looking for. As I said: - it just depends on the skills of the respective user. Sorry, this topic was _so_ tempting ;-) Regards, 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] apt.dat et al.
Hi! Joacim Persson wrote: I noticed that the versions of apt.dat, nav.dat etc we have in CVS are somewhat outdated (~12 months old). Time for an update perhaps? I understand we are using the 810 format for apt.dat -- are there work in progress for switching to version 850? (Not a trivial task: v850 includes improved drawing functions like Bezier curves.) AFAIK no data is yet publically available with apt version 850 (though the new X-Plane version seems to ship some airports with the new format, according to the APT 850 documentation). TaxiDraw is currently being renovated to allow migration to v850 (editing only), but we haven't even started the implementation yet. I hope that the renovation is done somewhen in February so that we can start with new features, but I can't guarantee that. Probably the trickiest part for a new genapts will be the marking stuff. Embedding that into the terrain without polygon offset, decals or similar will probably diminish the framerate heavily. The actual bezier polygons are probably not as tricky, as the current genapts essentially transforms the rectangles to single polygons and clips them to a big polygon. For implementing v850 one will probably have to approximate the beziers with polygons. There are methods out there which can be used to minimize the error (e.g. http://www.antigrain.com/research/adaptive_bezier/index.html) I have a set of different FlightGear-related projects I'd like to get done before end of May to have them presentable at LinuxTag 2007. This includes a v850-capable version of TaxiDraw, but there will be no time for implementing v850 in genapts. Volunteer, anyone? Cheers, Ralf - 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] [Simgear-cvslogs] CVS: SimGear/simgear/scene/model shadanim.cxx, 1.9, 1.10
On Friday 26 January 2007 21:30, Frederic Bouvier wrote:
Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/model
In directory baron:/tmp/cvs-serv5514
Modified Files:
shadanim.cxx
Log Message:
Ensure a reference on the cube map texture is always held
Fred, that code was correct (appart from not being deleted). I have that kind
of code at more places.
That technique called 'double checked locking'.
You don't bother locking a mutex if it is already there. But if the instance
must be created, you have to ensure that you are the only one. therefore you
need to ask if it is there a second time ...
That is not time critical here, so I don't bother locking, but in general this
kind of code should be left as is ...
Greetings
Mathias
Index: shadanim.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/model/shadanim.cxx,v
retrieving revision 1.9
retrieving revision 1.10
diff -C 2 -r1.9 -r1.10
*** shadanim.cxx 3 Dec 2006 16:57:21 - 1.9
--- shadanim.cxx 26 Jan 2007 20:30:02 - 1.10
***
*** 127,138
getOrCreateTextureCubeMap()
{
! static osg::TextureCubeMap* textureCubeMap = 0;
! if (textureCubeMap)
! return textureCubeMap;
static SGMutex mutex;
SGGuardSGMutex locker(mutex);
! if (textureCubeMap)
! return textureCubeMap;
// create and setup the texture object
--- 127,136
getOrCreateTextureCubeMap()
{
!static osg::ref_ptrosg::TextureCubeMap textureCubeMap;
static SGMutex mutex;
SGGuardSGMutex locker(mutex);
! if (textureCubeMap.get())
! return textureCubeMap.get();
// create and setup the texture object
***
*** 147,151
textureCubeMap-setUpdateCallback(new SGMapGenCallback);
! return textureCubeMap;
}
--- 145,149
textureCubeMap-setUpdateCallback(new SGMapGenCallback);
! return textureCubeMap.get();
}
___
Simgear-cvslogs mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/simgear-cvslogs
2f585eeea02e2c79d7b1d8c4963bae2d
-
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: source/src/Scripting NasalSys.cxx, 1.54, 1.55
On Sunday 28 January 2007 21:49, Melchior FRANZ wrote:
* Frederic Bouvier -- Sunday 28 January 2007:
! for(it = _listener.end(); it != _listener.end();) {
The previous code was doing pre decrementation that I don't see here.
No. The current code is wrong, just like the previous one.
I should have written for(it = _listener.end(); --it != _listener.end();)
though, and not compare against a pre-calculated end, after that
one does, of course, change.
Just a quick note, I did not try to think about that in detail, but I get the
impression that this totally overcomplicated code is still wrong.
If you postincrement-assign and then hand that assigned iterator
preincremented to the erase, the iterator to erase points to the same
location than it and this leads to an access to an already deleted region ...
It should just delete those map entries that are _dead ??
If so, restore what I checked in an replace the end() initialization with the
usual begin() one in the for statement ...
Because of the postincrement notation in the erease argument this code was
legal ...
Greetings
Mathias
-
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] Openscenegraph tarball
Hi, I need to have an other update to the openscenegraph tarball. For those ones not tracking cvs I have put together a tarball as usual. The key feature I need is the txf file font loader. That is with the time of packing that tarball included in osg's cvs and the tarball includes in fact a snapshot of the cvs tree. You can find that at ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/OpenSceneGraph-20070122 As far as I know, Olaf prepares the update to the win32 build these days. I am currently working with that tree, but I expect that current osg cvs will also work fine ... I will still wait checking in something that need the new tarball until we have an up to date win32 build environment ... greetings Mathias - 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] objects with transparent textures
On Thursday 25 January 2007 14:44, AJ MacLeod wrote: On Thursday 25 January 2007 10:21, Yurik V. Nikiforoff wrote: There are objects with transparent textures - part of visual model or 3d instruments. If two or more such objects overlaps, there is wrong appearance. I found, that appearance of transparent objects depend from sequense this objects in ac file. But there is no methods for control of object sequence in 3d editors (like ac3d). Actually, there are, (in AC3D, and ISTR in blender too) though they might not be very obvious in AC3D at least... I know someone else had to point them out to me. In AC3D, from the tools menu select heirarchy view. You are shown a view of the complete tree of objects and groups; if you right click on any object or group you can select move to head or move to tail and change the object ordering that way. There was also a simple ordering animation which could be done in the FG XML file using a none animation type, but simply listing the objects in object-name tags in the desired order. I'm not sure whether that still works with OSG or not (I've never used it myself anyway AFAIK). It's mentioned in the model-howto.html If you would like yet another way, Melchior has a python script called ac3d-scan which I think would also do what you want http://members.aon.at/mfranz/ac3d-scan That does not help here since osg has its own way to determine which osg::Drawbles are drawn at which time. So depending on your view the soring happens within osg. I am aware of that sorting problem, and thinking about that ... Anyway, osg has many stages it renders, and transparent stuff is sorted back to front anyway, but that sorting takes needless time if solid geometry is put into the transparent renderbin. To decide this the ac3d loader for example looks if we have either a alpha value not equal to 1 in the current material or if there is *any* pixel in the texture that has an alpha value not equal to 1. That way the c172 fuselage is something that is potentially transparent to osg and sorted back to front. Or in other words: we should not attach semitransparent textures to solid objects to avoid overhead in this area ... Greetings mathias - 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
