[Flightgear-devel] spinning animation in osgViewer version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This patch fixes the (lack of) spin animation in the osgViewer version. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGV+cFeDhWHdXrDRURArn+AKCpfvYnUmolduqrcLROaXZ4hfInjgCfc8t8 wd3k56qrKgAvVv4pvzEFyXQ= =Oj9W -END PGP SIGNATURE- Index: src/Main/renderer.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v retrieving revision 1.85 diff -d -u -r1.85 renderer.cxx --- src/Main/renderer.cxx 21 May 2007 17:50:03 - 1.85 +++ src/Main/renderer.cxx 26 May 2007 07:46:41 - @@ -381,7 +381,7 @@ mRealRoot = dynamic_castosg::Group*(viewer-getSceneData()); mRealRoot-addChild(fgCreateSplashNode()); osgViewer::Scene* scene = viewer-getScene(); - scene-setFrameStamp(mFrameStamp.get()); + mFrameStamp = viewer-getFrameStamp(); // Scene doesn't seem to pass the frame stamp to the update // visitor automatically. mUpdateVisitor-setFrameStamp(mFrameStamp.get()); - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] patch to dump entire scene graph
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
These patches implement a command to dump the entire OSG scene graph as
a .osg text file. While large, this allows debuggers to really see
what's happening in the scene graph.
Tim
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGV+4PeDhWHdXrDRURAjsyAJ43j2FxyonHypcWzehgDFrvvXR/ywCg24jI
5y2nbs0MY1fGYYYJRbU2vpE=
=iDW+
-END PGP SIGNATURE-
Index: src/GUI/gui.h
===
RCS file: /var/cvs/FlightGear-0.9/source/src/GUI/gui.h,v
retrieving revision 1.17
diff -d -u -r1.17 gui.h
--- src/GUI/gui.h 7 Jan 2007 15:51:29 - 1.17
+++ src/GUI/gui.h 26 May 2007 08:17:05 -
@@ -47,6 +47,7 @@
extern void guiErrorMessage(const char *txt, const sg_throwable throwable);
extern void fgDumpSnapShot();
+extern void fgDumpSceneGraph();
extern puFont guiFnt;
extern fntTexFont *guiFntHandle;
Index: src/GUI/gui_funcs.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/GUI/gui_funcs.cxx,v
retrieving revision 1.51
diff -d -u -r1.51 gui_funcs.cxx
--- src/GUI/gui_funcs.cxx 7 Jan 2007 15:51:29 - 1.51
+++ src/GUI/gui_funcs.cxx 26 May 2007 08:17:06 -
@@ -571,3 +571,49 @@
}
}
+// do a screen snap shot
+void fgDumpSceneGraph()
+{
+char *filename = new char [24];
+string message;
+static int count = 1;
+
+FGRenderer *renderer = globals-get_renderer();
+
+static const SGPropertyNode *master_freeze
+ = fgGetNode(/sim/freeze/master);
+
+bool freeze = master_freeze-getBoolValue();
+if ( !freeze ) {
+fgSetBool(/sim/freeze/master, true);
+}
+
+while (count 1000) {
+FILE *fp;
+snprintf(filename, 24, fgfs-graph-%03d.osg, count++);
+if ( (fp = fopen(filename, r)) == NULL )
+break;
+fclose(fp);
+}
+
+if ( fgDumpSceneGraphToFile(filename)) {
+ message = Scene graphe saved to \;
+ message += filename;
+ message += \.;
+} else {
+message = Failed to save to \;
+ message += filename;
+ message += \.;
+}
+
+mkDialog (message.c_str());
+
+delete [] filename;
+
+if ( !freeze ) {
+fgSetBool(/sim/freeze/master, false);
+}
+}
+
+
+
Index: src/Main/fg_commands.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_commands.cxx,v
retrieving revision 1.87
diff -d -u -r1.87 fg_commands.cxx
--- src/Main/fg_commands.cxx15 May 2007 14:39:56 - 1.87
+++ src/Main/fg_commands.cxx26 May 2007 08:17:06 -
@@ -487,6 +487,12 @@
return true;
}
+static bool
+do_dump_scene_graph (const SGPropertyNode*)
+{
+fgDumpSceneGraph();
+return true;
+}
/**
* Built-in command: hires capture screen.
@@ -1481,6 +1487,7 @@
{ savexml, do_save_xml_from_proptree },
{ press-cockpit-button, do_press_cockpit_button },
{ release-cockpit-button, do_release_cockpit_button },
+{ dump-scenegraph, do_dump_scene_graph },
{ 0, 0 } // zero-terminated
};
Index: src/Main/renderer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v
retrieving revision 1.85
diff -d -u -r1.85 renderer.cxx
--- src/Main/renderer.cxx 21 May 2007 17:50:03 - 1.85
+++ src/Main/renderer.cxx 26 May 2007 08:17:07 -
@@ -1109,5 +1109,10 @@
return !pickList.empty();
}
+bool fgDumpSceneGraphToFile(const char* filename)
+{
+return osgDB::writeNodeFile(*mRealRoot.get(), filename);
+}
+
// end of renderer.cxx
Index: src/Main/renderer.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.hxx,v
retrieving revision 1.13
diff -d -u -r1.13 renderer.hxx
--- src/Main/renderer.hxx 21 May 2007 17:50:03 - 1.13
+++ src/Main/renderer.hxx 26 May 2007 08:17:07 -
@@ -74,4 +74,6 @@
osg::ref_ptrFGManipulator manipulator;
};
+bool fgDumpSceneGraphToFile(const char* filename);
+
#endif
Index: gui/menubar.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/gui/menubar.xml,v
retrieving revision 1.62
diff -d -u -r1.62 menubar.xml
--- gui/menubar.xml 24 Mar 2007 20:56:40 - 1.62
+++ gui/menubar.xml 26 May 2007 08:18:43 -
@@ -445,6 +445,12 @@
/binding
/item
+item
+ labelDump Scene Graph/label
+ binding
+commanddump-scenegraph/command
+ /binding
+ /item
/menu
menu
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits.
Re: [Flightgear-devel] small thread safe patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathias Fröhlich wrote: Hi, On Thursday 24 May 2007, Tim Moore wrote: OSG reference counting doesn't need to be thread safe, even in the multi-threaded OSG modes, unless you're doing something very tricky. In any event, it shouldn't be turned on in the model reader initialization. Please don't! It is there by intention. OK, but maybe this call shouldn't be buried in the initialization of the model loader. osgViewer::Viewer changes this mode for threading models that need it, and maybe your new viewer should do the same. I have a multithreaded viewer in the works and for that it is still useful to have thread safe reference counting in place. Also Having the database pager set up once we have the osgviewer code settled we will do model loading in a thread that runs in parallel to the rest of the application. And remember that we share some data across models. That model cloning will need thread safe reference counting. It does not cost much OTOH. Here's a somewhat unscientific test : src/Main/fgfs --fg-root=/home/moore/graphics/FlightGear/data/ - --aircraft=bo105 --disable-ai-models --geometry=1024x768 time of day: noon. Without thread safe reference counting (time in milliseconds): event 5.75 update 3.3 cull 1.75 draw 3.6 Total: 14.4 event 5.75 update 3.83 cull 1.83 draw 3.75 Total: 15.16 So, .76ms, or a 5% difference... I think this is fairly significant. The real cost will come when we start doing database paging: that's when a lot of Referenced objects will have their reference counts changed. In normal operation database paging doesn't need threadsafe reference counting. You have a good point about copying models. The thread safe mode can be set per Referenced object, which may be a better way of dealing with shared objects. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGV/TDeDhWHdXrDRURAprLAJsHVi/Pb96Bx6vFfLzFNuUIkoiouwCgmqAr BEDvR4SEE4jEHdoIkZIrW0I= =0MLv -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] small thread safe patch
On Saturday 26 May 2007, Tim Moore wrote: OK, but maybe this call shouldn't be buried in the initialization of the model loader. osgViewer::Viewer changes this mode for threading models that need it, and maybe your new viewer should do the same. That is probably too late. Some of our shared osg::Referenced are assigned on static initialization. That is may be even before that osgDB::Registry is loaded. I do even thing about some ugly hacks to ensure that ew have really every object safe. The other way to do so is to use what we currently have in simgear to do atomic reference counts by compiler intrinsics. That is really fast. I have a mostly patched version of osg on local disk. But did not manage to finish that and send it to Robert ... This way we could be sure that we do not loose any references at least on any relevant architecture. The others (AIX, HP-UX ...) would need to set the OSG_THREAD_SAFE_REFERENCE counting environment variable if they want to make use of any multithreaded features ... I have a multithreaded viewer in the works and for that it is still useful to have thread safe reference counting in place. Also Having the database pager set up once we have the osgviewer code settled we will do model loading in a thread that runs in parallel to the rest of the application. And remember that we share some data across models. That model cloning will need thread safe reference counting. It does not cost much OTOH. Here's a somewhat unscientific test : src/Main/fgfs --fg-root=/home/moore/graphics/FlightGear/data/ --aircraft=bo105 --disable-ai-models --geometry=1024x768 time of day: noon. Without thread safe reference counting (time in milliseconds): event 5.75 update 3.3 cull 1.75 draw 3.6 Total: 14.4 event 5.75 update 3.83 cull 1.83 draw 3.75 Total: 15.16 So, .76ms, or a 5% difference... I think this is fairly significant. The real cost will come when we start doing database paging: that's when a lot of Referenced objects will have their reference counts changed. In normal operation database paging doesn't need threadsafe reference counting. You have a good point about copying models. The thread safe mode can be set per Referenced object, which may be a better way of dealing with shared objects. Vote against. Even that stuff that is currently not managed by osgDB will be handled by osgDB in the future. I intent to make model and tile loading as well a osgDB reader. At least an internal reader that registers itself at osgDB. This way we will not have any frame drop any more in the feature. Everything io bound operation is done in an offline thread and osgDB make sure that display lists are already compiled when the model/tile whatever is plugged into the scenegraph. ... no hangs anymore when an AIModel comes in sight ... Greetings Mathias - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flightgear building thread.
Hi All, I decided to start a new clean thread here, so people can find what they need to build FG to perform. As we know, using the CMAKE command: cmake -i . produces a question/answer type script so you can build as a 'Release' and configure any optimisations to suit. Using: ./configure CXXFLAGS= -O3 ... will build Simgear/FG with similar optimisations. Today I tested again OSG, and there are two options that made me wonder - so I turned ON to use a float matrix rather than double: //Set to ON to build OpenSceneGraph with float matrix instead of // double. OSG_USE_FLOAT_MATRIX:BOOL=ON //Set to ON to build OpenSceneGraph with float matrix instead of // double. OSG_USE_FLOAT_PLANE:BOOL=ON Oh my!!! Again a huge increase in performance on my lowly 1.2GHz machine. For the first time ever I saw 60fps+ today... three weeks ago I was lucky to see 35fps. This gets better and better... Nick - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
Hi, Hi, On Saturday 26 May 2007, Nick Warne wrote: I decided to start a new clean thread here, so people can find what they need to build FG to perform. As we know, using the CMAKE command: cmake -i . produces a question/answer type script so you can build as a 'Release' and configure any optimisations to suit. Using: ./configure CXXFLAGS= -O3 ... will build Simgear/FG with similar optimisations. Today I tested again OSG, and there are two options that made me wonder - so I turned ON to use a float matrix rather than double: //Set to ON to build OpenSceneGraph with float matrix instead of // double. OSG_USE_FLOAT_MATRIX:BOOL=ON //Set to ON to build OpenSceneGraph with float matrix instead of // double. OSG_USE_FLOAT_PLANE:BOOL=ON That is bad idea. That clamps the available precision of the transform matrices to floats which is no longer enough. Are you on win32? Greetings Mathias - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AN-225 patch
On Friday 25 May 2007 10:36, Joacim Persson wrote: On Fri, 25 May 2007, leee wrote: http://www.air-and-space.com/Antonov%20An-225%20Mriya.htm it's the rear four sets. This site also has some nice pics of the main gear, which show that the front three and rear four units are different, if anyone would like to make more detailed and accurate main gear units:) (I can barely make a cube in Blender -- so don't look at me ;) I suspect it can also kneel like the An-124. Looks like that on some of the pictures too. But the 124 has a different setup with the main gear steering, with the two forward axels steerable instead. Yeah - it can kneel to lower the nose for loading/unloading but I never modelled the opening nose or kneeling:) And rumor has it they are working on finishing the second 225 down in Kiev now. The one they have in operation is booked up most of the time. Yeah (again) - I saw some reports saying that the sole AN-225 is in such demand that they are going to complete a second airframe, due for completion in 2008. The AN-225 also has a max taxiing weight but I couldn't find the doc which stated what it was:( Basically, it means that the AN-225 cannot make ground turns above this weight and so for mtow takeoffs it has to be lined up on the runway and then loaded. Unlike the AN-124, from which it was developed, it was never intended for short-field operation. That information ought to be in the 2001 civil type certificate. (which may have been published in Ukranian only though) I found the type certificate number for it: (in latin-faked kyrillic) CTOK200-AH-225, but not the document itself. (well, I can't google in non-latin alphabets) We should add some more hard points to it. One can easily dip a wingtip or engine in the ground now by turning too hard at too high taxi speed. Max taxi speed is probably also specified in the type cert. And CG limits, and other goodies... The contact points should be ok as the aircraft geometry is fundamental to YASim and is taken from the 3d model. YASim does recognise ground contact with wings etc - heh - I've hit the ground with a wing tip in a turn when at very low level and realistically spun in and crashed as a result and I've also clipped a few buildings and structures and got a yaw to the appropriate side:) Perhaps the problem is that these collisions don't cause any damage. This isn't the fault of YASim because FG only really recognises a total crash and doesn't have any provision for partial airframe damage. Personally, I wouldn't do anything to pervent the wing tips or outer engines grounding when taxiing at too high a speed because I suspect this would be realistic. It's just the lack of resultant damage that's unrealistic. Of course, there's certainly scope for further tuning of the undercarriage springing and displacements - atm it's just tuned so that the a/c sits level on the ground at various weights and doesn't collapse on landing, which was a serious factor when I was developing it. It was certainly possible to collapse the nose gear by breaking too hard on the ground at high weights, which also seemed realistic to me:) I don't think I put any brakes on the nose gear, just the mains. LeeE - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
Hi Mathias, On Saturday 26 May 2007 14:18:14 Mathias Fröhlich wrote: //Set to ON to build OpenSceneGraph with float matrix instead of // double. OSG_USE_FLOAT_MATRIX:BOOL=ON //Set to ON to build OpenSceneGraph with float matrix instead of // double. OSG_USE_FLOAT_PLANE:BOOL=ON That is bad idea. That clamps the available precision of the transform matrices to floats which is no longer enough. Are you on win32? I hope not ;-) ... I understand/stood what these options did, and hence why I tried it. I do not see any difference at all, other than a 100% 'responsiveness' to FG and super FPS. It what respect does applying a float matrix rather than a double matrix do? I cannot see any visible difference - in fact I do, in that it is 'cleaner'. Nick - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
hi, On Saturday 26 May 2007, Nick Warne wrote: I hope not ;-) ... What compiler do you use? What distro? I understand/stood what these options did, and hence why I tried it. I do not see any difference at all, other than a 100% 'responsiveness' to FG and super FPS. It what respect does applying a float matrix rather than a double matrix do? I cannot see any visible difference - in fact I do, in that it is 'cleaner'. ??? Greetings Mathias - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 737-300 FDM patch for gear location
On Friday 25 May 2007 15:13, Reagan Thomas wrote: Martin Spott wrote: Berndt, Jon S wrote: Reagan Thomas wrote: Short version: Here is the link to an updated patch which (a) corrects the VRP precisely as Anders did with the F80C while removing the somewhat incorrect Z offset in /Models and (b) adds several contact points. It does not change any other pre-existing gear, etc coordinates: The VRP is supposed to be a way for the 3D modeler and the FDM modeler to agree on a way to make sure that the 3D model is placed exactly where it is supposed to be placed. Did you get to an agreement wether the patch is correct or not ? Martin. To the best of my newbie ability, I think I've gotten it correct. However, I've moved the patch to a different link :( New URL: http://139.78.95.188/flightgear/VRP/737-300/ FYI I've identified about 30 aircraft that look like they might have similar issues. Most of them I have only tagged because I found that the origin in the 3D model was not at the nose and didn't find complementary offsets in loading the model or VRP. I've been right about all but one that I've checked into further so far, but that doesn't mean much. If anyone else would like to peruse this (probably flawed) list: http://139.78.95.188/flightgear/AircraftAlign.txt The VRP isn't really an issue with YASim aircraft because the geometry is fundamental to the solver and as long as everything is consistant, that is the fdm, animations and visual origin, it should look and work correctly regardless of where the model and fdm origin is actually located. You'll find that the early aircraft were done before the VRP concept was established and for YASim aircraft, at least, making them VRP compliant would have had a low priority because it would have had no effect on the behaviour or appearance of the aircraft but would have required a lot of work to re-align all of the animations. Well, that was my excuse:) LeeE - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
Mathias Fröhlich wrote: Hi, Hi, On Saturday 26 May 2007, Nick Warne wrote: I decided to start a new clean thread here, so people can find what they need to build FG to perform. As we know, using the CMAKE command: cmake -i . produces a question/answer type script so you can build as a 'Release' and configure any optimisations to suit. Using: ./configure CXXFLAGS= -O3 ... will build Simgear/FG with similar optimisations. Today I tested again OSG, and there are two options that made me wonder - so I turned ON to use a float matrix rather than double: //Set to ON to build OpenSceneGraph with float matrix instead of // double. OSG_USE_FLOAT_MATRIX:BOOL=ON //Set to ON to build OpenSceneGraph with float matrix instead of // double. OSG_USE_FLOAT_PLANE:BOOL=ON That is bad idea. That clamps the available precision of the transform matrices to floats which is no longer enough. Are you on win32? Greetings Mathias Are we talking about the matrices used for the culling and the rendering ? If that's the case then we don't need precision for culling and the gpu does nothing with doubles, they have allready some trouble to use floats efficiently. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
Hi, On Saturday 26 May 2007, Harald JOHNSEN wrote: Are we talking about the matrices used for the culling and the rendering ? If that's the case then we don't need precision for culling and the gpu does nothing with doubles, they have allready some trouble to use floats efficiently. These are also the matrices that control the transform from and back to the view. You will get jitter if these are floats. Remember the jittering aircraft models in earlier days ... The workaround was a complex logic to carry that scenery center with you. Having doubles in the transform matrices is a much simpler and cleaner solution - without scenery center ... What double precision problems do you have? Greetings Mathias - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
On Saturday 26 May 2007 14:34:44 Mathias Fröhlich wrote: hi, On Saturday 26 May 2007, Nick Warne wrote: I hope not ;-) ... What compiler do you use? What distro? gcc version 3.4.6 Slack 10 (but heavily updated from source all bar glibc [too scared to update that]). I understand/stood what these options did, and hence why I tried it. I do not see any difference at all, other than a 100% 'responsiveness' to FG and super FPS. It what respect does applying a float matrix rather than a double matrix do? I cannot see any visible difference - in fact I do, in that it is 'cleaner'. ??? OK, what I mean by 'cleaner' is more responsive, less 'stutters', and just generally faster all round. I do not see any issues graphically - in fact, cloud layer etc. is better as it all works faster. But, having said all this, I am on a 6 year old Athlon1.2GHz via aBit MoBo - so perhaps to a newer, modern machine this all doesn't matter as it is all rendered faster anyway. Nick - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathias Fröhlich wrote: Hi, On Saturday 26 May 2007, Harald JOHNSEN wrote: Are we talking about the matrices used for the culling and the rendering ? If that's the case then we don't need precision for culling and the gpu does nothing with doubles, they have allready some trouble to use floats efficiently. These are also the matrices that control the transform from and back to the view. You will get jitter if these are floats. Remember the jittering aircraft models in earlier days ... The workaround was a complex logic to carry that scenery center with you. Having doubles in the transform matrices is a much simpler and cleaner solution - without scenery center ... What double precision problems do you have? Harald, You might not realize that OSG doesn't push / pop the matrix in each transform node to OpenGL. Instead, it accumulates the effective ModelView matrix for each drawable and and loads that when the drawable is rendered. This allows you to keep the coordinates of geometry as small values that comfortably fit in floats, relative to a transform that can have a very large (wgs84) translation. If the eyepoint is in wgs84 too, then the effective translation calculated by OSG won't be very large -- it's effectively limited by the visual range -- and will also fit nicely in a float. As Mathias says, this is much more convenient than a scheme where you translate all the tiles each frame relative to an eyepoint at 0. I doubt you can measure any difference between glLoadMatrixf and glLoadMatrixd. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGWF4PeDhWHdXrDRURAnq1AKC2f7Cy70xwAwFeMFgha3PDO+NpuQCeKc7v IMwzirJnZR9C2rmxWvp7/Xs= =dW9G -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
On 5/26/07, Tim Moore wrote: You might not realize that OSG doesn't push / pop the matrix in each transform node to OpenGL. Instead, it accumulates the effective ModelView matrix for each drawable and and loads that when the drawable is rendered. This allows you to keep the coordinates of geometry as small values that comfortably fit in floats, relative to a transform that can have a very large (wgs84) translation. If the eyepoint is in wgs84 too, then the effective translation calculated by OSG won't be very large -- it's effectively limited by the visual range -- and will also fit nicely in a float. As Mathias says, this is much more convenient than a scheme where you translate all the tiles each frame relative to an eyepoint at 0. I doubt you can measure any difference between glLoadMatrixf and glLoadMatrixd. If this works as well as advertised (and it appears to) then this is a really nice feature of OSG. Dealing with whole earth scales using floating point numbers requires a few non-obvious tricks. For those not familiar with the issue, a floating point number can represent about 7(-8?) significant digits. The est-epsilon program in the tests directory of the FlightGear source estimates the smallest floating point number that can be represented. In practical terms, this means you run out of floating point precision trying to accurately place yourself or objects on the surface of the world. You could easily a several meter shift in the position of objects (or the view point) depending on whether or not the results of your placement math gets rounded up or rounded down. You can just use doubles because *everything* that opengl does uses floating point math. This leads to scenery that will jitter back and forth by this amount as you move. It's a huge problem for flight simulators, unless you are studying alchohol effects on pilots or something. :-) OSG appears to have come up with a nice workaround/solution to the problem. Cool ... Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] patch to use DrawElements primitive sets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
This patch combines all the triangles, triangle strips and triangle fans
with the same material in a tile into one DrawElements primitive set.
This also reduces by a factor of 100 the number of Geodes that needs to
be processed by the cull phase.
On my machine I see a 1.5 ms decrease in cull and draw times and a .5ms
increase in event time, probably due to increased time in intersection
testing. I'll take a 1ms decrease in total frame time (9%) :)
Tim
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGWG02eDhWHdXrDRURAlP4AKCEermb3De1Nt04N0uBTpzPKMRAkACgzu2/
wyxVgdDpZgrSmWO9OePmaAU=
=9NxH
-END PGP SIGNATURE-
Index: simgear/scene/tgdb/leaf.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/tgdb/leaf.cxx,v
retrieving revision 1.10
diff -d -u -r1.10 leaf.cxx
--- simgear/scene/tgdb/leaf.cxx 8 May 2007 06:11:15 - 1.10
+++ simgear/scene/tgdb/leaf.cxx 26 May 2007 16:55:18 -
@@ -97,7 +97,7 @@
}
};
-static void SGGenRandomSurfacePoints( osg::Geometry *leaf, double factor,
+void SGGenRandomSurfacePoints( osg::Geometry *leaf, double factor,
osg::Vec3Array *lights )
{
osg::TriangleFunctorSGRandomSurfacePointsFill triangleFunctor;
@@ -227,3 +227,160 @@
return geometry;
}
+// Specialization of triangle index production and DrawElements type.
+namespace {
+// Trick to turn integers (e.g., GL_TRIANGLES) into types
+template int v
+struct Int2Type
+{
+enum { value = v };
+};
+
+// Triangles use the vertices in order.
+template class DEType
+void addIndices(int baseIndex, int numIndices, DEType* de,
+ Int2TypeGL_TRIANGLES)
+{
+typedef typename DEType::value_type ValueType;
+for (int i = 0; i numIndices; ++i) {
+ de-push_back((ValueType)(baseIndex + i));
+}
+}
+
+// Duplicate the vertex swapping of triangle strips using the
+// indicies of the vertex data.
+template class DEType
+void addIndices(int baseIndex, int numIndices, DEType* de,
+ Int2TypeGL_TRIANGLE_STRIP)
+{
+typedef typename DEType::value_type ValueType;
+int index = baseIndex;
+
+for (int i = 2; i numIndices; ++i, ++index) {
+ de-push_back((ValueType)(index));
+ if (i % 2) {
+ de-push_back((ValueType)(index + 2));
+ de-push_back((ValueType)(index + 1));
+ } else {
+ de-push_back((ValueType)(index + 1));
+ de-push_back((ValueType)(index + 2));
+ }
+}
+}
+
+// And again for triangle fans.
+template class DEType
+void addIndices(int baseIndex, int numIndices, DEType* de,
+ Int2TypeGL_TRIANGLE_FAN)
+{
+typedef typename DEType::value_type ValueType;
+int index = baseIndex + 1;
+for (int i = 2; i numIndices; ++i, ++index) {
+ de-push_back((ValueType)(baseIndex));
+ de-push_back((ValueType)(index));
+ de-push_back((ValueType)(index + 1));
+}
+}
+
+template class GeomType
+void addIndicesToGeometry(int baseIndex, int numIndices,
+ osg::Geometry *geometry, GeomType)
+{
+osg::PrimitiveSet* pset = geometry-getPrimitiveSet(0);
+osg::DrawElementsUByte* db = dynamic_castosg::DrawElementsUByte*(pset);
+osg::DrawElementsUShort* ds = dynamic_castosg::DrawElementsUShort*(pset);
+osg::DrawElementsUInt* di = dynamic_castosg::DrawElementsUInt*(pset);
+if (db)
+ addIndices(baseIndex, numIndices, db, GeomType());
+else if (ds)
+ addIndices(baseIndex, numIndices, ds, GeomType());
+else
+ addIndices(baseIndex, numIndices, di, GeomType());
+}
+
+} // namespace
+
+// Add leaf geometry to an existing osg::Geometry which has a
+// DrawElements primitive set. The caller must guarantee that the
+// DrawElements type (UByte, UShort or Uint) is big enough to contain
+// the indices for the new triangles.
+void SGAddLeafToDrawable(osg::Geometry* geometry, const GLenum ty,
+SGMaterial *mat,
+const point_list nodes, const point_list normals,
+const point_list texcoords,
+const int_list node_index,
+const int_list normal_index,
+const int_list tex_index)
+{
+double tex_width = 1000.0, tex_height = 1000.0;
+
+if (mat) {
+// set the texture width and height values for this
+// material
+tex_width = mat-get_xsize();
+tex_height = mat-get_ysize();
+}
+osg::Vec3Array* vl
+ = static_castosg::Vec3Array*(geometry-getVertexArray());
+osg::Vec3Array* nl
+ = static_castosg::Vec3Array*(geometry-getNormalArray());
+osg::Vec2Array* tl
+ = static_castosg::Vec2Array*(geometry-getTexCoordArray(0));
+int baseIndex = vl-size();
+int i;
+
+// vertices
+
Re: [Flightgear-devel] patch to use DrawElements primitive sets
Hi Tim, On Saturday 26 May 2007, Tim Moore wrote: Hi, This patch combines all the triangles, triangle strips and triangle fans with the same material in a tile into one DrawElements primitive set. This also reduces by a factor of 100 the number of Geodes that needs to be processed by the cull phase. On my machine I see a 1.5 ms decrease in cull and draw times and a .5ms increase in event time, probably due to increased time in intersection testing. I'll take a 1ms decrease in total frame time (9%) :) Tim Sorry, I won't apply that. I have something very similar on my disk. I believe we should talk about such stuff before you start hacking ... And yes, if this is done right I see not only better cull and draw times but also an overall frame rate improvement. Greetings Mathias - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
Hi Curt, On Saturday 26 May 2007, Curtis Olson wrote: If this works as well as advertised (and it appears to) then this is a really nice feature of OSG. Dealing with whole earth scales using floating point numbers requires a few non-obvious tricks. For those not familiar with the issue, a floating point number can represent about 7(-8?) significant digits. The est-epsilon program in the tests directory of the FlightGear source estimates the smallest floating point number that can be represented. In practical terms, this means you run out of floating point precision trying to accurately place yourself or objects on the surface of the world. You could easily a several meter shift in the position of objects (or the view point) depending on whether or not the results of your placement math gets rounded up or rounded down. You can just use doubles because *everything* that opengl does uses floating point math. This leads to scenery that will jitter back and forth by this amount as you move. It's a huge problem for flight simulators, unless you are studying alchohol effects on pilots or something. :-) OSG appears to have come up with a nice workaround/solution to the problem. Cool ... Yes, this works in that way. You can already see that in fg HEAD. Robert's library is heavily used in the Viz-Sim industry and thus exactly written for our needs :) Greetings Mathias - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
Hi Mathias, On Saturday 26 May 2007 19:52:17 Mathias Fröhlich wrote: Well, not that I do not care for older hardware. But I think that we should better rely on double here. It eases life very much and reduces complexity in the code ... Remember this is OSG build - not FG. OK. But what restriction implies that a 'user' has to build OSG with float matrix or double matrix then? Surely any implementation of a product that uses OSG will want it's own way to do it? What happens if another application works better with OSG build with float matrix? BTW, I am not debating/arguing here, you coders are the key - I know naff all about the way FG/OSG integration works - I am only relaying my observations when using FG. Nick - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: SimGear
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-25_10:49:26 (andy) /var/cvs/SimGear-0.3/source/simgear/nasal/naref.h Sync with trunk 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear source
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-21_12:50:02 (frohlich) /var/cvs/FlightGear-0.9/source/src/Main/FGManipulator.cxx /var/cvs/FlightGear-0.9/source/src/Main/FGManipulator.hxx /var/cvs/FlightGear-0.9/source/src/Main/fg_os_osgviewer.cxx Modified Files: configure.ac src/Main/Makefile.am src/Main/fg_os.cxx src/Main/fg_os.hxx src/Main/fg_os_sdl.cxx src/Main/main.cxx src/Main/renderer.cxx src/Main/renderer.hxx src/Network/jpg-httpd.cxx Added Files: src/Main/FGManipulator.cxx src/Main/FGManipulator.hxx src/Main/fg_os_osgviewer.cxx: Tim Moore: Make use of osgViewer. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-25_02:20:13 (durk) /var/cvs/FlightGear-0.9/source/src/Traffic/TrafficMgr.cxx Don't fix what ain't broke. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-25_16:16:14 (andy) /var/cvs/FlightGear-0.9/source/src/FDM/YASim/FGFDM.cpp /var/cvs/FlightGear-0.9/source/src/FDM/YASim/Rotor.cpp Maik: add unbalance and testing of rotor ground contact =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-25_16:16:15 (andy) /var/cvs/FlightGear-0.9/source/src/FDM/YASim/Rotor.hpp /var/cvs/FlightGear-0.9/source/src/FDM/YASim/Rotorpart.cpp /var/cvs/FlightGear-0.9/source/src/FDM/YASim/Rotorpart.hpp Maik: add unbalance and testing of rotor ground contact =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-25_17:58:12 (andy) /var/cvs/FlightGear-0.9/source/src/FDM/YASim/Rotor.cpp Maik: place the contact points at the rotor blade tips (center+radius), not at center+diameter =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-26_08:53:46 (frohlich) /var/cvs/FlightGear-0.9/source/src/Main/fg_os_osgviewer.cxx Modified Files: src/Input/input.cxx src/Input/input.hxx src/Main/FGManipulator.cxx src/Main/fg_os.cxx src/Main/fg_os.hxx src/Main/fg_os_osgviewer.cxx src/Main/fg_os_sdl.cxx src/Main/renderer.cxx src/Main/renderer.hxx: First cut of osg multi view configurations. 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear data
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-20_11:25:48 (vmmeazza) /var/cvs/FlightGear-0.9/data/AI/foch_demo.xml Gérard Robin Updates =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-20_11:27:45 (vmmeazza) /var/cvs/FlightGear-0.9/data/Models/Geometry/Foch/fochv3-10v1.ac Gérard Robin Updates =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-23_00:15:11 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/b1900d/b1900d-quickstart-set.xml re-add the b1900d and changes ... Added beginning of startup tutorial Added a b1900d-set --- engines and power off Added a b1900d-quickstart-set --- power on , ready to fly Moved instruments to separate folder ...more to do still And more I dont remember ... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-23_00:15:25 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/b1900d/Nasal/Electrical.nas re-add the b1900d and changes ... Added beginning of startup tutorial Added a b1900d-set --- engines and power off Added a b1900d-quickstart-set --- power on , ready to fly Moved instruments to separate folder ...more to do still And more I dont remember ... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-24_15:29:39 (martin) /var/cvs/FlightGear-0.9/data/Aircraft/an2/Docs/an2.html /var/cvs/FlightGear-0.9/data/Aircraft/an2/Docs/engine_start.jpg Yurik V. Nikiforoff: Details to the Engine start procedure of the help file. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-05-24_15:41:58 (martin) /var/cvs/FlightGear-0.9/data/Aircraft/an2/an2-set.xml /var/cvs/FlightGear-0.9/data/Aircraft/an2/an2.xml /var/cvs/FlightGear-0.9/data/Aircraft/an2/Model/an2-model.xml Yurik V. Nikiforoff: - This tutorial teaches the An-2 engine start procedure. - and there is small fdm patch for tune gear appearance. So, tires has pumped :) 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
