Re: [Flightgear-devel] osg material animaton
Tim, On Tuesday 08 May 2007, Tim Moore wrote: > >> There is also a second assumption in the animation system: The textures > >> for the liveries are expected not to be in the osg::Drawables. That is > >> not always true and is especially no longer true with the ac loader > >> update in osg svn since a few days. > > I don't think the material animation makes that assumption. It overrides > the texture attribute, so any textures in nodes below, even in > Drawables, are ignored. Not with the material animation, but the animations system model loading system ... That assumption is made with the liveries. We take an already loaded model that is cloned except the drawables and textures to share the display lists and textures. Then there is a visitor that walks the texture attributes and checks if the loaded image is the same than the one in the current livery load path. If that does not match it replaces the texture attribute with the one with the correct livery texture. Then osgDB walks again over the tree and collapses the textures again to a single one that is also shared with other models if it is the same. If this happens on any StateSet attached to a cloned Node this works well. But if this happens on a StateSet attached to a shared drawable, it will change all models except only the single one the livery is meant for ... > >> The problem that is fixed here, which is also in the past and current > >> material animation to some degree, is that render bin numbers in osg > >> build hierarchical render bins. That means we should only put render bin > >> numbers at drawables or on nodes that have well known leafs. > >> With that change the transparencies are handled way better with osg. > > You're a lot more familiar with the problem than I. Do you get the > undesirable hierarchical behavior if the states sets in the drawables > inherit their render bins? No, if they inherit this is ok. But if they inherit, you cannot set anything new to them ... That is also a powerful tool, but that is the one I struggled at most with. It became clear at the time Robert visited us in Tübingen and told that ... > When you load a model, you get a prototype that you will copy, if > necessary, for its instances. Ideally you should only copy > Transformation nodes for animated parts; if materials are animated, the > nodes that hold the animated material should be copied too. Ideally you > share entire state sets, not just the texture. That would be nice. I am not sure if it is worth it. What do you gain here? The osg::State can collapse the state sets a little more efficient since it is already finished if the pointers to the state sets are compared and match. It does not need to look into the StateSets' attributes and modes. I have played with that at some stage and did not see any improvement. There is not much more than the dlists and the textures that can be shared efficiently in the GPU in the StateSet (well, the shaders, but leave them away for now). But I think it complicates current and future animation work. >From the animations system I think it is best that you can assume to work an an already private tree. You have to think much about the side effects of first applying that animations, leading to some partial private tree and than applying the other one, leading to whatever. Group, Transforms and all that stuff is not that memory intensive in main memory that it is worth the effort. Also in the GPU these cannot be shared. To ease the job for animation programmers I think of some normalization of the scenegraph. Proposal: Lift and StateSet's in Drawables into the Geodes introducing new geodes if necessary. That means Drawables do not have textures attached to it and can be shared over more models. Then still clone everything in a model except that StateAttributes and Drawables (dlists) that are shared in the GPU for efficiency. I believe that we gain most flexibility with private trees without loosing efficiency. BTW: my last patch to the ac3d loader delivers that type of trees. But loaders cannot be assumed to work like that ... > There's no reason not to share the geode too. > Also, you really want to share StateSets if possible, because OSG will > order all the drawables by StateSet to avoid state changes, but it > doesn't look inside StateSets to minimize state changes. No, it does not order by state. You can configure that in the render bin, but the sort function does nothing. Look into the code. Robert told me that he has played with that for some time, but state sorting does not gain more in state changes than you loose with the sorting step ... So, sharing the StateSet's does not gain too much. If you want to manage the complexity of partial tree sharing feel free to do so. But my feeling (and experience) is that you do not gain anything from that. We have other cpu hogs where we can gain much more ... > Yes, though this sharing can either be a literal sharing of
Re: [Flightgear-devel] osg material animaton
On Tuesday 08 May 2007, Harald JOHNSEN wrote: > Yes by states I was thinking of statesets. Anyway I looked again the > geode and drawable definitions and now > I'm confused, I thought the states were tied to the geodes but they are > tied to the drawable. I really don't > understand how we can have one drawable with several states. That is a strong tool in osg. StateAttributes and state modes deeper in the tree (my wording for closer at the leafs) replace the StateAttributes and state modes closer at the root. There are override and protected flags for them, but leave them away for the first cut. Those overrides must also be handled with care. IMO these should be used with extreme care because the might interfere with some effects like shadows where we need to do multi pass rendering of the same scenegraph with different override attributes. I guess that even if there is currently no effect that brakes with using overrides or protected state attributes, this has the potential to brake something like that. Tim, the material animation stuff should IMO try so work without the overrides. 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] osg material animaton
Hi Harald, On Tuesday 08 May 2007, Harald JOHNSEN wrote: > To recap we have (or should have in the future) : > - one drawable per model / part of model Not sure what this means, the Drawable's are the leaf nodes in osg. They can have StateSet's attached to it. With one Drawable there is one display list. That means if we want to share the geometry te drawables must be shared. When you get models from the loaders there might be textures attached to the drawables which is not that good in presence of liveries and material animations. When a new model is loaded osgDB provides you a cached model that is already loaded. This one is cloned except the Texture StateAttributes and the drawables. This way you will share the display lists and the textures. > - one texture per texture loaded Yes. osgDB hands you over a cached Image. Comparing two texture state attributes with the same parameters and the same texture are identical and the osgDB step during model loading to share duplicate state will collapse them together. > - one state per static / animation material ?? > - adding a 'model' will add a geode with a new state pointing to a > cached texture and to a cached drawable Not only a geode, but a whole tree. You get a cached complete tree. That is cloned except the drawables and textures. These are shared. Note that the StateSet's are not shared anymore, just the Texture StateAttributes. > - animation material can be shared by several geodes > (by animation material I mean any animation that can alter the state, > not the one we have atm). Yes. But that fine grained rewriting of materials that we have done in plib is a kind of a problem. IMO, we should change the material animation to require a whole material set. One remaining thing we cannot really get around is when we have colors attached to the drawables. Also a side note: We have currently a post processing step that cripples down the material information in the loaded models to match the plib behavior (the color material is changed hard from ambient(?) to ambient and diffuse). But the ac3d loader loads the models with the material information that is in the ac3d file. In the longer term we should rework the models so that they do not need to be changed. That will leave the modeler more room for working with the materials. 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] patch for osgViewer and statistics
Hi, On Friday 18 May 2007, Tim Moore wrote: > renderer.cxx already contains a lot of OSG specific code; in fact it > would be fair to say that is all OSG specific code. I did add some > osgViewer specific code to renderer.cxx because the details of accessing > the scene root, controlling the camera, and running the rendering loop > are different when using a Viewer; those are concepts that fg_os doesn't > handle at all. That needs to be restructured! > It's possible that the osgViewer changes to renderer.cxx could be > refactored a bit to be less intrusive, but I'm hoping the need for the > non-osgViewer case will disappear :) In the mean time the differences > between the two approaches are made obvious, which I think is good for > people looking at this code. Yes, SDL and glut will go away. 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 gearlocat ionand contactpoints
On Friday 18 May 2007 23:47, Jon S. Berndt wrote: > 737 drawing: > > http://hawker.smugmug.com/gallery/92076/1/3226720#3226720-O-LB > > JB http://boeing.com/commercial/airports/3_view.html More accurate. :) Also: http://boeing.com/commercial/airports/737.htm Ampere - 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] Missing-Generic tile over the sea
On Tuesday 15 May 2007, gh.robin wrote: > Hello, > The generic tiles over the sea is/are missing. > > Tested with last cvs SG/FG built with last svn OSG > and with last cvs SG/FG built with older svn OSG (10-April 2007) > > here snapshot > > http://perso.orange.fr/GRTux/FG_OSG_Generic-Tile.jpg Hmm, noted. Sunday is next fg day :) 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] patch for osgViewer and statistics
On Tuesday 15 May 2007, Tim Moore wrote: > Howdy, > This patch implements the option of using OpenSceneGraph's osgViewer > instead of SDL or glut. The major user visible difference is the > availability of OSG statistics, as seen in > http://www.bricoworks.com/moore/osgstats.png, which show the time spent > in each major part of the update and rendering process and which can > help track down performance problems (hit the '*' key). The osgViewer > framework also allows very flexible view / camera / window configuration > and multithreading options which will be useful in the future. The one > loss of functionality with this patch is that the cursor can't be > changed; I'm looking into that. This is great! I am a bit short in time. I will probably look into that at sunday! Thanks! 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 gearlocationand contactpoints
> > I'm not in a position at this time to check whether Z pos'n in the > > FDM/configuration file was wrong or the Z offset in the Model file > > was wrong; > > Unless the one that's in the FlightGear distribution is different from the > one that's been in JSBSim CVS for years, it isn't the FDM that's wrong. > > Jon 737 drawing: http://hawker.smugmug.com/gallery/92076/1/3226720#3226720-O-LB JB - 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 locationand contactpoints
> I'm not in a position at this time to check whether Z pos'n in the > FDM/configuration file was wrong or the Z offset in the Model file > was wrong; Unless the one that's in the FlightGear distribution is different from the one that's been in JSBSim CVS for years, it isn't the FDM that's wrong. Jon -- Jon S. Berndt Development Coordinator JSBSim Project www.JSBSim.org - 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 and contactpoints
Berndt, Jon S wrote: > That should not be necessary. The aircraft configuration file only needs > to be consistent within itself. The structural frame is used for the > location of engines, landing gear, empty-weight CG, etc. There is also > a point called the visial reference point (typically the nose of the > aircraft) that is defined as a known reference point for the 3D modeler. > The 3D model need not have any particular coordinate frame origin, to > the best of my recollection, though there is an offset that is specified > in another file (the -set file?). My [possibly mis-]understanding is that the offset should be specified in Aircraft/737-300/Models/737-300.xml in this case, which is where I added the single offset 9.04. > > The point is, do NOT change the aircraft configuration file in order to > place the aircraft in the scene properly. > > Jon > After posting this patch and seeing your response, I belatedly recalled that I had started by changing the Z position of the landing gear in the "configuration" file instead of adjusting the previously existing Z offset in the Model file. I'm not in a position at this time to check whether Z pos'n in the FDM/configuration file was wrong or the Z offset in the Model file was wrong; I'll post notice here when I have done so... the prior posted link will reflect any changes. > > >>I noticed the 737's wheels were "floating" above the ground >>and decided to tweak it. In the process, I discovered that >>the gear, engines, CG, etc were all defined to be about 9 >>meters behind the 3D model. >> >>The linked patch adds a 9.04 meter offset on X in >>Models/737-300.xml and adds contact points at the tail, >>belly, nose, engines and wingtips in 737.xml. >> >>This model is in the base distribution package so please >>check my work :) >> >>Patch courtesy of fg_submit: >>http://139.78.95.188/flightgear/737-300/ >> >> >>-- >>Reagan Thomas > -- Reagan Thomas - 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] RFD: New Airports;
Martin Spott wrote: > Hi Jon, > > Jon Stockill wrote: > >> Any plans to update nav.dat too? If so I'll update the navaid models in >> the scenery database. > > Please see the respective changelog notice. I've been updating all four > files that FlightGear picks from Robin's package. These include > Airports/apt.dat.gz as well as Navaids/[awy,fix,nav].dat.gz Ah, sorry - I only spotted the commit message for apt.dat - missed the one for the rest. Jon - 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 and contactpoints
That should not be necessary. The aircraft configuration file only needs to be consistent within itself. The structural frame is used for the location of engines, landing gear, empty-weight CG, etc. There is also a point called the visial reference point (typically the nose of the aircraft) that is defined as a known reference point for the 3D modeler. The 3D model need not have any particular coordinate frame origin, to the best of my recollection, though there is an offset that is specified in another file (the -set file?). The point is, do NOT change the aircraft configuration file in order to place the aircraft in the scene properly. Jon > I noticed the 737's wheels were "floating" above the ground > and decided to tweak it. In the process, I discovered that > the gear, engines, CG, etc were all defined to be about 9 > meters behind the 3D model. > > The linked patch adds a 9.04 meter offset on X in > Models/737-300.xml and adds contact points at the tail, > belly, nose, engines and wingtips in 737.xml. > > This model is in the base distribution package so please > check my work :) > > Patch courtesy of fg_submit: > http://139.78.95.188/flightgear/737-300/ > > > -- > Reagan Thomas - 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] 737-300 FDM patch for gear location and contact points
I noticed the 737's wheels were "floating" above the ground and decided to tweak it. In the process, I discovered that the gear, engines, CG, etc were all defined to be about 9 meters behind the 3D model. The linked patch adds a 9.04 meter offset on X in Models/737-300.xml and adds contact points at the tail, belly, nose, engines and wingtips in 737.xml. This model is in the base distribution package so please check my work :) Patch courtesy of fg_submit: http://139.78.95.188/flightgear/737-300/ -- Reagan Thomas - 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] RFD: New Airports;
Hi Jon, Jon Stockill wrote: > Any plans to update nav.dat too? If so I'll update the navaid models in > the scenery database. Please see the respective changelog notice. I've been updating all four files that FlightGear picks from Robin's package. These include Airports/apt.dat.gz as well as Navaids/[awy,fix,nav].dat.gz Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - 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] RFD: New Airports;
Martin Spott wrote: > "Curtis Olson" wrote: > >> Double check there isn't any x-plane 8.50 bezier stuff in the version we use >> since we really aren't setup to use the new file format features yet. > > Done, no v8.50 style runway definitions in the new file. > Well, Robin currently does not have a v8.50 file for download at all, > so this is not surprising :-) Any plans to update nav.dat too? If so I'll update the navaid models in the scenery database. Jon - 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-0.9.11-pre1-------Carriers are Flying
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Bytheway wrote: >> Martin Spott wrote: >>> "gh.robin" wrote: >>> With FlightGear-0.9.11-pre1 it is something strange we have Flying Carriers. >>> The carrier is correct - sea level is wrong :-)) >> Wait for the tide to come in. >> >> Jon >> > I presume this is to do with the fact that the sea is modelled as a few > huge flat polys whose surfaces have a significant "altitude" change > between the centres and the vertices. Try one quad per tile :P > > AFAIK this has not changed since the very early days of FG, but since we > now all have graphics cards that are 2-3 orders of magnitude faster than > when FG started, is now the time to increase the number of polys in the > ocean? A reduction in the edge length of a factor of 3 would reduce the > surface height variation by a factor of ~3, and increase the poly count > in the ocean by a factor of 9, which I believe should be acceptable. > > Unfortunately, I have no idea where so start poking around in the > codebase to do this though. In the OSG tree, SGGenTile() in simgear/scene/tgb/obj.cxx. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGTc+MeDhWHdXrDRURAslLAJ47BB4gzLo2H9guFYKdPLzGWbbv3gCeMhjp /ZPZdNExOucU1JK2LkzZyoQ= =HCmY -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] patch for osgViewer and statistics
On Thu 17 May 2007 22:28, Tim Moore wrote: SNIP > > > The "Cull" is basically very high compared to the other values but when > > i fly over the sea (without tiles as i said in an other topic). > > What is exactly the meaning of the "Cull" value ? > > It's hard to assign a meaning to these times in isolation, except to > note that 16 milliseconds total is the magic number that gives you a > frame rate of 60hz. The large cull time indicates poor scene graph > layout; possibly there's a problem with transparent objects in your > beautiful cockpit :) The large draw time vs. gpu time shows that the > scene and model geometry could be grouped in larger batches. > > > I get ThreadingModel : SingleThreaded , is it right ? > > Yes; I've forced all the OSG operations into one thread to start with. > There is a lot of flexibility in that area, and we'll try multithreading > things on multiprocessor machines. > > > Here a snapshot of the Stats http://perso.orange.fr/GRTux/OSG-Stat.jpg > > > > Regards > > Thanks! I'd love to know the details of that (aircraft, location, ...) > > Tim > Hello Tim, May be that new test could be useful, and help to understand. Every parameter are the same than these one used for the previous test, only one diff i did built SG/FG with an older OSG 1.9.4 10-april With that one do get a very good FPS with that one ( as said on a previous topic). the snapshot is there http://perso.orange.fr/GRTux/OSG_older-Stat.jpg You can notice : => your patch gives that ugly sky (blue sky has vanished, grey takes place) It is not a problem because working nice without patch. => the cull was with the previous test 35 more or less it is now 6.5 more or less. DRAW and GPU have decreased dramatically (same Nvidia parameters, High Quality, Anti aliasing setting 4x 9tap G, Anisotropic Filtering x4, Texture sharpening ON) Regards -- Gérard - 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] patch for osgViewer and statistics
On Thu 17 May 2007 22:28, Tim Moore wrote: SNIP > It's hard to assign a meaning to these times in isolation, except to > note that 16 milliseconds total is the magic number that gives you a > frame rate of 60hz. The large cull time indicates poor scene graph > layout; possibly there's a problem with transparent objects in your > beautiful cockpit :) The large draw time vs. gpu time shows that the > scene and model geometry could be grouped in larger batches. > > > I get ThreadingModel : SingleThreaded , is it right ? > > Yes; I've forced all the OSG operations into one thread to start with. > There is a lot of flexibility in that area, and we'll try multithreading > things on multiprocessor machines. > > > Here a snapshot of the Stats http://perso.orange.fr/GRTux/OSG-Stat.jpg > > > > Regards > > Thanks! I'd love to know the details of that (aircraft, location, ...) > > Tim > > That Aircraft is an old (achieved) model Crusader F-8E from my French Air Navy Models collection (which suit to to French Carrier Foch). the Low FPS performance and that large cull (you point the finger on it) represent, to me, the average performances i get compared to every others aircraft which are there into FG, more or less according the model. So it is, for me, a measurement tool. Regards -- Gérard - 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-0.9.11-pre1-------Carriers areFlying
On Thu 17 May 2007 18:19, Vivian Meazza wrote: > It's not a bug it's a feature! The carrier operates in the same frame of > reference as aircraft - it has to otherwise you couldn't catch wires > correctly. Unfortunately, the sea surface does not - elsewhere on the sea > surface you will see the carrier up to the sponsons in water. If you don't > crash into the sea near the carrier you won't see this bug (er ... > feature). I have a partial fix moving the wake to compensate, which also > uses submodels to provide a nice curved wake following the carrier as it > manoeuvres. But since it uses the scale animation to work, and that's > broken for submodels in plib, I haven't uploaded it to cvs. > > Hope this explains it. You will also see the same effect when moving around > KSFO with an aircraft, although much less, and you will have to look very > closely to see it. BTW - this isn't a new problem it's been around a while. > > Vivian > Hello Vivian, Sorry for the noise, I was reminding , a very old talk , we had on IRC, regaring that topic, i did not understood it was a feature. That answer, means that i must review the French Foch Carrier position in order to give her a better eye Candy, that AImodel being included into FlightGear-0.9.11-pre1. Regards -- Gérard - 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] Flash2a Patch
Hi Stuart, Stuart Buchanan wrote: > --- Martin Spott wrote: > > Stuart Buchanan wrote: > > > I have a patch available for the flash2a, so it works on the plib > > branch. > > > > > > Available here: > > > > > > http://www.nanjika.co.uk/flightgear/flash2a.diff.bz2 > > > > Is the patch meant for PLIB only or for OSG as well ? > The fix is plib-only, and removes some OSG-only features (pick animation). > However, I'm happy for it to go into both branches to keep things > consistent. Well, I'm uncertain if we really should kick a working feature out of the CVS HEAD base package in order to make things compatible for just one single release. Therefore I'd prefer _not_ to put that into HEAD. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - 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] Flash2a Patch
--- Martin Spott wrote: > Stuart Buchanan wrote: > > > I have a patch available for the flash2a, so it works on the plib > branch. > > > > Available here: > > > > http://www.nanjika.co.uk/flightgear/flash2a.diff.bz2 > > Is the patch meant for PLIB only or for OSG as well ? The fix is plib-only, and removes some OSG-only features (pick animation). However, I'm happy for it to go into both branches to keep things consistent. Thanks -Stuart Send instant messages to your online friends http://uk.messenger.yahoo.com - 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-0.9.11-pre1-------Carriers are Flying
> Martin Spott wrote: > > "gh.robin" wrote: > > > >> With FlightGear-0.9.11-pre1 it is something strange > >> we have Flying Carriers. > > > > The carrier is correct - sea level is wrong :-)) > > Wait for the tide to come in. > > Jon > I presume this is to do with the fact that the sea is modelled as a few huge flat polys whose surfaces have a significant "altitude" change between the centres and the vertices. AFAIK this has not changed since the very early days of FG, but since we now all have graphics cards that are 2-3 orders of magnitude faster than when FG started, is now the time to increase the number of polys in the ocean? A reduction in the edge length of a factor of 3 would reduce the surface height variation by a factor of ~3, and increase the poly count in the ocean by a factor of 9, which I believe should be acceptable. Unfortunately, I have no idea where so start poking around in the codebase to do this though. Richard - 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] patch for osgViewer and statistics
* Tim Moore -- 5/18/2007 9:20 AM: > renderer.cxx already contains a lot of OSG specific code; in fact it > would be fair to say that is all OSG specific code. I agree. Main/fg_os*.cxx are there to handle the operating system dependent interfaces for window management/keyboard/mouse: glut and later sdl. But if the osg counterparts can fully replace those two on all platforms (maybe they are even better?), then we should probably delegate that job to osg and drop glut/sdl support altogether. I doubt we would ever have introduced the fg_os* files if plib had offered all we need. glut is a dying species, just like plib ... m. - 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] patch for osgViewer and statistics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: > Hi Tim, > > I took a peek at the diffs and had a couple questions. Originally the > idea of the fg_os files was to have a single interface within the > flightgear code so that the details could be hidden in fg_os.[ch]xx, but > I see with your changes that you have a lot of OSG specific code now > that has filtered up into the renderer.cxx. Is that needed or could > these new changes be hidden better behind fg_os like the code originally > intended? > > Thanks, > Hi Curt, renderer.cxx already contains a lot of OSG specific code; in fact it would be fair to say that is all OSG specific code. I did add some osgViewer specific code to renderer.cxx because the details of accessing the scene root, controlling the camera, and running the rendering loop are different when using a Viewer; those are concepts that fg_os doesn't handle at all. It's possible that the osgViewer changes to renderer.cxx could be refactored a bit to be less intrusive, but I'm hoping the need for the non-osgViewer case will disappear :) In the mean time the differences between the two approaches are made obvious, which I think is good for people looking at this code. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGTVPGeDhWHdXrDRURAoZaAJ462o0jI0I5HdbXXaPLd59ZSZsYjwCgjVAM KyG6cixedS/pNH9+eptsOxU= =aGBK -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
