RE: [Flightgear-devel] Scenery engine features.
Curtis L. Olson writes: Paul Surgeon writes: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. Norman Vine writes: - Ability to cut in polygon models of airports. Any cut in polygons respect tile boundaries i.e a polygon can only be in one tile It's easy to chop up polygons on tile boundaries, but you are probably referring to airport areas. :-) I am referring to any polygon whether or not they are part of an airport area is immaterial :-) This has been discussed before and I do appreciate the 'pain' factor on the construction side of things but having to special case airports to cross tile boundaries is a killer when it comes to subdivision and or indexing schemes. - Ability to page terrain / textures so continuous flights around the world are still possible. :-) I only say this because I've seen a lot of ROAM type demos that look cool for a small area, but I get the sense that it's a bit trickier to build an entire seamless earth. It's probably been done in commercial games (?) but I haven't seen this done in the open souce world. Hence my smiley, also I am not convinced that FGFS should adbandon using pretesselated scenery in favor of a ROAM approach. This doesn't necessarily mean that we can't have scenery LOD though Modeling the entire world is a good way to keep yourself honest. :-) You are preaching to the choir here :-) I think we could make the current scheme work as the only thing changing will be the local 'Z' and height calculations would be *much* simpler We have to be careful though of objects floating up and down noticable as the underlying terrain LOD changes. Yes and the Local Z simplification really only applies to ROAM like tesselations not TINs We still need polygons to shape the terrain for roads, rivers etc. during scenery creation and then there are the airports. My understanding is that roads, rivers, lakes, cities, etc. (all that stuff we handle with 2d polygons right now) could be embedded in the aerial photos / textures that we are draping over the terrain, so there would be no need to cut them in as polygons. I am not necessarily suggesting a ROAM approach as the data requirements are humongous both for the textures and the elevations. What I think would be most beneficial is to write an abstract interface for terrain first so that the actual mechanism used is not exposed to the rest of the SIM. What we have is a good start on this. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery engine features.
I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. I want to keep this to features only - lets forget about the implementation for the moment so we can at least get everyone's ideas down without having 50 emails of it can't be done like this or must be done like that. Let's make a comprehensive list first and then discuss the HOWTO's afterwards. Maybe we can even come up with a roadmap!!! :-P My list : 1. LOD algorithm/system (with adjustable radius for high and low end users) The current irregular grid mesh works but it's not very efficient and we could get much better framerates with a nice LOD system. Alternatively much higher elevation resolution with similar framerates. 2. Texture overlays - FG scenery engine does the chopping and texture co-ord generation. (I won't go into details but this would greatly simplify LOD algorithms) Your list : Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery engine features.
Paul Surgeon writes: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. I want to keep this to features only - lets forget about the implementation for the moment so we can at least get everyone's ideas down without having 50 emails of it can't be done like this or must be done like that. Let's make a comprehensive list first and then discuss the HOWTO's afterwards. Maybe we can even come up with a roadmap!!! :-P My list : 1. LOD algorithm/system (with adjustable radius for high and low end users) The current irregular grid mesh works but it's not very efficient and we could get much better framerates with a nice LOD system. Alternatively much higher elevation resolution with similar framerates. 2. Texture overlays - FG scenery engine does the chopping and texture co-ord generation. (I won't go into details but this would greatly simplify LOD algorithms) Your list : I'll add in a few things: - Ability to cut in polygon models of airports. - Ability to page terrain / textures so continuous flights around the world are still possible. - Ability to populate the world with arbitrary additional 3d objects. Note that our current ability to populate the world with random objects would not work with the new scheme. We'd need to completely overhaul that functionality to work in a photo texture drapped, LOD terrain world. - Care should be taken with object vertical placement so the terrain LOD doesn't move the 3d objects up and down noticable. And also so it doesn't noticably bury objects or float objects when the terrain LOD changes. - I assume all the current 2d polygon data would go away since this would be better represented by the photo texture overlay anyway. I bet we'll run into other things, but if you are serious about making a stab at this, then I will propose that we a) find a way to do it in parallel to the current system and b) just jump in and start going. I don't think it's realistic to have your first pass encapsulate *all* current functionality of the scenery subsystem. And there will most likely be things we don't consider until we get hit over the head with it. I can think of different situations where each approach would be more optimal than the other, so it probably wouldn't hurt to have more than one way to do things. Best regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Scenery engine features.
Curtis L. Olson writes: Paul Surgeon writes: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. I'll add in a few things: me too - Ability to cut in polygon models of airports. Any cut in polygons respect tile boundaries i.e a polygon can only be in one tile - Ability to page terrain / textures so continuous flights around the world are still possible. :-) - Ability to populate the world with arbitrary additional 3d objects. Note that our current ability to populate the world with random objects would not work with the new scheme. We'd need to completely overhaul that functionality to work in a photo texture drapped, LOD terrain world. I think we could make the current scheme work as the only thing changing will be the local 'Z' and height calculations would be *much* simpler - Care should be taken with object vertical placement so the terrain LOD doesn't move the 3d objects up and down noticable. And also so it doesn't noticably bury objects or float objects when the terrain LOD changes. - I assume all the current 2d polygon data would go away since this would be better represented by the photo texture overlay anyway. We still need polygons to shape the terrain for roads, rivers etc. during scenery creation and then there are the airports. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery engine features.
On 11/14/03 at 12:17 AM Paul Surgeon wrote: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. I want to keep this to features only - lets forget about the implementation for the moment so we can at least get everyone's ideas down without having 50 emails of it can't be done like this or must be done like that. Let's make a comprehensive list first and then discuss the HOWTO's afterwards. Maybe we can even come up with a roadmap!!! :-P My list : 1. LOD algorithm/system (with adjustable radius for high and low end users) The current irregular grid mesh works but it's not very efficient and we could get much better framerates with a nice LOD system. Alternatively much higher elevation resolution with similar framerates. 2. Texture overlays - FG scenery engine does the chopping and texture co-ord generation. (I won't go into details but this would greatly simplify LOD algorithms) Your list : The ability to drape the textures at differing resolutions at different locations in the scenery. (ie. higher res data immediately adjacent to airports where the pilot is generally closer to the ground and to give good definition on final approach). Some sort of fix or workaround for the stretched-textures-on-cliff faces problem that draped textures suffer from in mountainous regions - possibly the ability to cut in textured polygons on steep faces. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Scenery engine features.
Paul Surgeon writes: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. Norman Vine writes: - Ability to cut in polygon models of airports. Any cut in polygons respect tile boundaries i.e a polygon can only be in one tile It's easy to chop up polygons on tile boundaries, but you are probably referring to airport areas. :-) - Ability to page terrain / textures so continuous flights around the world are still possible. :-) I only say this because I've seen a lot of ROAM type demos that look cool for a small area, but I get the sense that it's a bit trickier to build an entire seamless earth. It's probably been done in commercial games (?) but I haven't seen this done in the open souce world. Just a word of advice ... if you are building a scheme and run across some oversite and are tempted to think, what are the chances of seeing this case in real life. Believe me, when you throw all the data of the world at your scheme, you'll see it a lot more than you expected. :-) Modeling the entire world is a good way to keep yourself honest. :-) I think we could make the current scheme work as the only thing changing will be the local 'Z' and height calculations would be *much* simpler We have to be careful though of objects floating up and down noticable as the underlying terrain LOD changes. We still need polygons to shape the terrain for roads, rivers etc. during scenery creation and then there are the airports. My understanding is that roads, rivers, lakes, cities, etc. (all that stuff we handle with 2d polygons right now) could be embedded in the aerial photos / textures that we are draping over the terrain, so there would be no need to cut them in as polygons. Airports are a bit different though ... unless we have *really* high res data as in less than 1 foot per pixel, we'll want to still model this polygonally. The San Jose demo was interesting, but it still needed better resolution. Just one airport area could easily consume a Gb of texture ram if we wanted to use a nice resolution. But that still wouldn't address all the squashed buildings, and all the nice aircraft painted on the runways in various stages of taxiing, landing, and taking off. Also, you get everything shaded from one particular time of day. There are tradeoff's to every approach. :-) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
