Re: [Flightgear-devel] Urban building model efficiency
Jim Wilson wrote: Just a thought: Wouldn't we improve the rendering efficiency by building downtown urban areas as a scene...e.g. single model with one ac file for all the buildings? A few things I can think of: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. I really think we should switch over to .ssg files for scenery objects. The problem with .ac files is that we need to recalculate the normal vectors (for each object?). I've tested them with some other file formats and they all load way faster. 2) Use a single texture file containing all the textures mapped to the various buildings in the model. Rendering efficiency. That's a good idea, but after playing with ac3d a bit I still don't know how to use a section of the texture for a particular object. So it's making things a bit harder for model designers. Is this true that the textures get reloaded, and is there some way to share textures between objects and not just save disk space? Probably yes. I had the same issue with audio files. I've managed to overcome this problem by implementing a 'cache' which holds the complete location of the file, and a pointer to the buffer containing the file. Maybe we can do this for textures also (before passing them to plib)? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Erik Hofman [EMAIL PROTECTED] said: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. I really think we should switch over to .ssg files for scenery objects. The problem with .ac files is that we need to recalculate the normal vectors (for each object?). I've tested them with some other file formats and they all load way faster. So long as we have a good converter, it should be fine to do that. One possibility would be to cache .ac files as .ssg files on the disk. From the modeler's perspective it is probably going to be easier to have .ac files in the base package. 2) Use a single texture file containing all the textures mapped to the various buildings in the model. Rendering efficiency. That's a good idea, but after playing with ac3d a bit I still don't know how to use a section of the texture for a particular object. So it's making things a bit harder for model designers. Recent release(s) (this year) have a texture coordinet editor. It's on the menu. There was actually a way to do it before, but it was very time consuming. Is this true that the textures get reloaded, and is there some way to share textures between objects and not just save disk space? Probably yes. I had the same issue with audio files. I've managed to overcome this problem by implementing a 'cache' which holds the complete location of the file, and a pointer to the buffer containing the file. Maybe we can do this for textures also (before passing them to plib)? There have been a few other reasons that I've been thinking that we should implement our own loader for 'ac' files. Two big ones are overriding texture file names in the xml wrapper, and having more control over the building of the scene graph (plib's optimization problems). This could be another one. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. I really think we should switch over to .ssg files for scenery objects. The problem with .ac files is that we need to recalculate the normal vectors (for each object?). I've tested them with some other file formats and they all load way faster. So long as we have a good converter, it should be fine to do that. One possibility would be to cache .ac files as .ssg files on the disk. From the modeler's perspective it is probably going to be easier to have .ac files in the base package. I tested this one a bit today and even a LOD of 1 meters will give good results on the SFO skyscrapers for normal (non clear sky conditions), it has just one drawback: after conversion FlightGear doesn't seem to find the textures anymore: http://sourceforge.net/mailarchive/forum.php?thread_id=2748130forum_id=4479 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. We will have problems with non-flat terrains. Actually, I use fgsd to position buildings and the elevation is computed automatically from the scenery. I bought an image of the Financial District at TerraServer and with the metadata provided, I was able to position this image exactly in the scenery. Then positionning buildings is quite easy. I really think we should switch over to .ssg files for scenery objects. The problem with .ac files is that we need to recalculate the normal vectors (for each object?). I've tested them with some other file formats and they all load way faster. So long as we have a good converter, it should be fine to do that. One possibility would be to cache .ac files as .ssg files on the disk. From the modeler's perspective it is probably going to be easier to have .ac files in the base package. A Blender loader would be cool too. 2) Use a single texture file containing all the textures mapped to the various buildings in the model. Rendering efficiency. That's a good idea, but after playing with ac3d a bit I still don't know how to use a section of the texture for a particular object. So it's making things a bit harder for model designers. Recent release(s) (this year) have a texture coordinet editor. It's on the menu. There was actually a way to do it before, but it was very time consuming. Is this true that the textures get reloaded, and is there some way to share textures between objects and not just save disk space? Probably yes. I had the same issue with audio files. I've managed to overcome this problem by implementing a 'cache' which holds the complete location of the file, and a pointer to the buffer containing the file. Maybe we can do this for textures also (before passing them to plib)? Do you mean dynamic object textures are also duplicated ? There have been a few other reasons that I've been thinking that we should implement our own loader for 'ac' files. Two big ones are overriding texture file names in the xml wrapper, and having more control over the building of the scene graph (plib's optimization problems). This could be another one. I vote for to remove this sharp edge smoothing artefact. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
As a blender user I'd like to see blender supporting some of these formats natively... I'm getting the urge to do something about that, at the moment it falls about 20th on my TODO list. Above that is closer integration of blender and the gimp for UV textures through the python interface. On Sun, 2003-07-13 at 10:15, Erik Hofman wrote: Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. I really think we should switch over to .ssg files for scenery objects. The problem with .ac files is that we need to recalculate the normal vectors (for each object?). I've tested them with some other file formats and they all load way faster. So long as we have a good converter, it should be fine to do that. One possibility would be to cache .ac files as .ssg files on the disk. From the modeler's perspective it is probably going to be easier to have .ac files in the base package. I tested this one a bit today and even a LOD of 1 meters will give good results on the SFO skyscrapers for normal (non clear sky conditions), it has just one drawback: after conversion FlightGear doesn't seem to find the textures anymore: http://sourceforge.net/mailarchive/forum.php?thread_id=2748130forum_id=4479 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Christopher S Horler [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Urban building model efficiency
Jim Wilson writes: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. Static scenery should be positioned only once, when the tile is loaded, so there's no on-going overhead. 2) Use a single texture file containing all the textures mapped to the various buildings in the model. Rendering efficiency. I think all that matters is the total amount of texture memory used. 3) Savings for buildings that use the exact same texture. More efficiency. How often do different geometries use the same texture? In any case, we can accomplish the same thing with separate models, simply by making sure that no texture is loaded more than once. The 2D panel already does that, but we'd have to find a way to hook into the plib AC3D loaded. Is this true that the textures get reloaded, and is there some way to share textures between objects and not just save disk space? Any comment, plib types? We should also set up static model support in the scenery loader so that each static model is loaded only once and reference counted. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Frederic Bouvier writes: I vote for to remove this sharp edge smoothing artefact. All of our airplanes will start looking a lot worse. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Erik Hofman writes: I tested this one a bit today and even a LOD of 1 meters will give good results on the SFO skyscrapers for normal (non clear sky conditions), it has just one drawback: after conversion FlightGear doesn't seem to find the textures anymore: http://sourceforge.net/mailarchive/forum.php?thread_id=2748130forum_id=4479 I think that skyscrapers need a visual range of much more than 5 nm. As far as I understand, we are already cropping out anything beyond the current visual range, but when visibility is OK, we need to see skyscrapers from at least 20 nm (~40,000m) away. They are *extremely* visible from the air (try flying anywhere near Manhattan, Montreal, or Toronto, and you'll see what I mean). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Urban building model efficiency
Jim Wilson writes: Erik Hofman [EMAIL PROTECTED] said: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. I really think we should switch over to .ssg files for scenery objects. The problem with .ac files is that we need to recalculate the normal vectors (for each object?). I've tested them with some other file formats and they all load way faster. .ssg files are *much* faster loading then anything else. So long as we have a good converter, it should be fine to do that. One possibility would be to cache .ac files as .ssg files on the disk. From the modeler's perspective it is probably going to be easier to have .ac files in the base package. we could keep the .ac .3ds .whatever files as they are in the base package and require that you run a 'scenery' compiler before you actually run FGFS after a scenery update. AFAICT it would even be faster to keep the .ac name in the xml files and do the extension manipulation in our code and do a fstat() on filetimes and compile the .ac to .ssg if necessary Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Urban building model efficiency
David Megginson writes: Jim Wilson writes: Is this true that the textures get reloaded, and is there some way to share textures between objects and not just save disk space? Any comment, plib types? SSG models should already be sharing textures based on 'Texture Name' see ssgTexture* ssgLoaderOptions::createTexture(..) and ssgTexture* ssgTextureArray::findByFilename ( .. ) for the mechanism used. Note that this can be changed see class ssgLoaderOptions and ssgSetCurrentOptions(). We should also set up static model support in the scenery loader so that each static model is loaded only once and reference counted. This should be easy enough todo SSG will 'just do' the correct thing wrt to memory as long as the refcnt mechanism is respected Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Erik Hofman wrote: I tested this one a bit today and even a LOD of 1 meters will give good results on the SFO skyscrapers for normal (non clear sky conditions), it has just one drawback: after conversion FlightGear doesn't seem to find the textures anymore: That's odd. After tweaking the utility a bit so it can support models without LOD, the textures reappeared after converting them with infinitive LOD ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
On Sunday 13 July 2003 10:39, Frederic Bouvier wrote: I vote for to remove this sharp edge smoothing artefact. -Fred That would save me a lot of time:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
On Sunday 13 July 2003 11:14, Norman Vine wrote: Jim Wilson writes: we could keep the .ac .3ds .whatever files as they are in the base package and require that you run a 'scenery' compiler before you actually run FGFS after a scenery update. While it's great that we _can_ use .3ds models, until we can texture them I think we should consider them only temporary (I haven't forgotten the TSR2 or A10 - they've got to be re-done) LeeE AFAICT it would even be faster to keep the .ac name in the xml files and do the extension manipulation in our code and do a fstat() on filetimes and compile the .ac to .ssg if necessary Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
On Sunday 13 July 2003 11:07, David Megginson wrote: Frederic Bouvier writes: I vote for to remove this sharp edge smoothing artefact. All of our airplanes will start looking a lot worse. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ Is there any way to set a constriant on it? It's fine when it's smoothing angles 90deg 270 but it would be better if it didn't try to do sharper angles. This seems to be the cause of the artifacts often seen on models, for example at the wing traiing edges. I get around this by splitting area into separate surfaces, which apart from extra work, increases the object and vertex count (though I dunno how much of a problem that might be). LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Lee Elliott writes: Is there any way to set a constriant on it? It's fine when it's smoothing angles 90deg 270 but it would be better if it didn't try to do sharper angles. This seems to be the cause of the artifacts often seen on models, for example at the wing traiing edges. It's a bit of a mess, really. The problem is that AC3D is (or was, until recently) the only general format that worked fully with plib, but AC3D files do not contain information on normals. If there's a better semi-standard format that we can use -- one that we can easily get From AC3D and Blender and import into plib with object names, normals, and texture information intact -- I'll be happy to switch to it. All the best, david -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
I wonder if it's possible to write a plib loader for blender files? On Sun, 2003-07-13 at 16:00, David Megginson wrote: Lee Elliott writes: Is there any way to set a constriant on it? It's fine when it's smoothing angles 90deg 270 but it would be better if it didn't try to do sharper angles. This seems to be the cause of the artifacts often seen on models, for example at the wing traiing edges. It's a bit of a mess, really. The problem is that AC3D is (or was, until recently) the only general format that worked fully with plib, but AC3D files do not contain information on normals. If there's a better semi-standard format that we can use -- one that we can easily get From AC3D and Blender and import into plib with object names, normals, and texture information intact -- I'll be happy to switch to it. All the best, david -- Christopher S Horler [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Christopher S Horler writes: I wonder if it's possible to write a plib loader for blender files? Very much so. An easier solution, though, would be to fix plib's VRML1 loader so that it works with *.wrl files exported by Blender. Nobody likes VRML1, but everybody can import and export it, and I think that it can include explicit normals. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
David Megginson [EMAIL PROTECTED] said: Lee Elliott writes: Is there any way to set a constriant on it? It's fine when it's smoothing angles 90deg 270 but it would be better if it didn't try to do sharper angles. This seems to be the cause of the artifacts often seen on models, for example at the wing traiing edges. It's a bit of a mess, really. The problem is that AC3D is (or was, until recently) the only general format that worked fully with plib, but AC3D files do not contain information on normals. If there's a better semi-standard format that we can use -- one that we can easily get From AC3D and Blender and import into plib with object names, normals, and texture information intact -- I'll be happy to switch to it. A lot (but not all) of the mess we've seen has to do with bad modeling work. I know because I've done the worse of it. With the normals being generated on the fly the right way to construct the model is with surfaces assigned to separate objects if they are sharpy edged, like the ailerons. While there are certain advantages to other methods (with greater control over the normals), this ac3d method really isn't difficult to do at all. If we further developed the ac3d loader for our purposes we might solve most of the problems. Much of the annoying issues with ac3d loading has to do with the optimization step. I feel that if we copied this loader code into SimGear and interact with plib at a lower level on this, we could eliminate some of the things that don't help us, and add to it some features that would help us. It'd be nice to have the ability to substitute textures for example. Plus we might be able to track our own table of loaded textures so that their use can be optimized. We may also be able to implement some of our own extensions and certainly could probably look at implementing some of the ac3d features that aren't currently supported in the plib loader (like selected flat shading for things that really are square edged!). Having a VRML1 loader would be useful. It would be great to move to something so widely supported, but I think we should still develop our own laoder and have it oriented toward loading and supporting simulation models without worrying about fitting in with the plib development goals. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
