Re: [Flightgear-devel] Playing with textures
On Tuesday 02 December 2003 02:31, Curtis L. Olson wrote: My understanding of systems that impliment these basic ideas is that step 1) is to give up the idea of seamless, non-blurry textures in the distance. Every system I have seen blurs the textures excessively as you go further in the distance ... that also yields a corresponding texture blurry-sharp popping effect as you get closer to a new area. And because the system typically has to do this stuff in a low priority thread to keep up rendering rates, you can see by the popping that the detail texture loading often lags and doesn't pop into full detail until you are right over it. Just for fun, sit down and assume 1 meter texture resolution, assume you are flying at 500 kts, and assume something like 20 mile visible radius. Now crunch the math on how much data you have to flow in from your HD per second or per frame, and you will see that it is a *lot* of work. Couldn't we load the whole data into RAM before? 1 GB Ram are cheap today. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
[EMAIL PROTECTED] writes: On Tuesday 02 December 2003 02:31, Curtis L. Olson wrote: My understanding of systems that impliment these basic ideas is that step 1) is to give up the idea of seamless, non-blurry textures in the distance. Every system I have seen blurs the textures excessively as you go further in the distance ... that also yields a corresponding texture blurry-sharp popping effect as you get closer to a new area. And because the system typically has to do this stuff in a low priority thread to keep up rendering rates, you can see by the popping that the detail texture loading often lags and doesn't pop into full detail until you are right over it. Just for fun, sit down and assume 1 meter texture resolution, assume you are flying at 500 kts, and assume something like 20 mile visible radius. Now crunch the math on how much data you have to flow in from your HD per second or per frame, and you will see that it is a *lot* of work. Couldn't we load the whole data into RAM before? 1 GB Ram are cheap today. 1. Threre is a big difference between having texture data loaded into main RAM vs. having the texture data loaded into your cards video RAM. (There are probably a few exceptions, the only one I can think of at the moment is the sgi O2 which has a unified main/video ram structure.) 2. If my math is working this early, 1GB of ram = 1073741824 bytes. Now, we need to store 3 bytes per pixel, so 1GB of ram actually lets us store 1GB/3 = 357913941 pixels of data. We would need to store a 2d array of RGB values. So sqrt(357913941) = 18918 x 18918 array of pixels we can store in 1Gb of RAM. Assuming 1m texture resolution, this gives you a 18.9 x 18.9 km area you can shove into 1Gb of RAM (assuming all your other software is taking zero bytes of main RAM.) That's not much. Assuming even 10km visibility (6.2 miles) means you could always see off the edge from any place in this area. 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] Playing with textures
Paul Surgeon wrote: Yeah that's because the scenery is pre-rendered. Who said we have to pre-render the scenery? :) Rendering in real time would only require a library of geodata which would be similar in size to the current FG scenery. In that case, it wouldn't look like TerraScene scenery -- TerraScene used much more detailed inputs than we use (i.e. every city street in the U.S.). Furthermore, you have to consider the land area we'd have to be rendering in real time. Average visibility on the U.S. east coast is about 7 statute miles, or about 11 km. That means that we'd have to render 380 km^2 of scenery in real time. In the Western plains and mountains, visibility of 50 statue miles (80 km) is not unusual, requiring rendering over 20,000 km^2 of scenery in real time. Yip but the results still looked better than default scenery outside of the US. One can always add more data as it becomes available. Actually, our scenery looks better than TerraScene did for Canada (I tried it), but TerraScene could have been tweaked to use non-U.S. scenery more effectively. Well it was only 7.5 meters/pixel - I was thinking of at least 4 meters/pixel and possible down to 1 meter/pixel. Also we can have extra high res textures around airports. I think that what you're talking about probably will happen, but I'd guess that it will take at least four more generations of Moore's law before the highest-end personal computers can do this at a reasonable framerate even with the lower visibility. If you generate the scenery at run time you will know the terrain type. Alternatively you could use the geodata to find that out. Quite right, but the geodata would have to match the textures, including any fudging or adjusting done to smooth out curves and make things look better -- otherwise, you'll get trees in the middle of rivers, etc. It would be neat if FG could properly support large ortho photos to start with. That sounds like a reasonable project -- do you want to take a run at it? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Playing with textures
Curtis L. Olson writes: Andy Ross writes: That was my thinking when I started, too. But your math is a little off. Getting to a worst case resolution of 1 texel per screen-space pixel with unique texturing requires *vast* amounts of memory. Yup, I doubt if we get to the 1 texel - screen pixel level very soon :-) My understanding of systems that impliment these basic ideas is that step 1) is to give up the idea of seamless, non-blurry textures in the distance. Every system I have seen blurs the textures excessively as you go further in the distance ... that also yields a corresponding texture blurry-sharp popping effect as you get closer to a new area. And because the system typically has to do this stuff in a low priority thread to keep up rendering rates, you can see by the popping that the detail texture loading often lags and doesn't pop into full detail until you are right over it. Some schemes use a continuously 'improving' progressive refinement i.e *all* texture and corresponing mesh is initialy loaded at lowest LOD and it is progressively refined prioritized by 'current' distance. The amount of blurry-sharp 'popping' you get is pretty much dependent on your paging speed. i.e. if you can load sharp enough LOD quickly enough popping is minimal. Since LOD requirements vary according to distance this is not much of a problem at high enough altitudes i.e. where the earth appears 'smooth' but is an area of 'active research' once the 'dimpling' of the surface becomes significant It's easy for us to sit here and say it can't work (at least not very well), but the hard headed ones will forge ahead anyway, attack the problems and issues head on, and a few of those people will find successful solutions and a place in the geek hall of fame. :-) :-) FWIW I am currently looking into a scheme based on ideas incorporated in this project http://globe.sintef.no/. The Aasgaard projection is quite interesting esp as it relates to data storage schemes, but I have *lots* of experimentation and learning todo yet Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
On Tuesday 02 December 2003 13:57, Curtis L. Olson wrote: [EMAIL PROTECTED] writes: Couldn't we load the whole data into RAM before? 1 GB Ram are cheap today. 1. Threre is a big difference between having texture data loaded into main RAM vs. having the texture data loaded into your cards video RAM. (There are probably a few exceptions, the only one I can think of at the moment is the sgi O2 which has a unified main/video ram structure.) But when the data is allready in the RAM we wouldn't need to load the data from the slow hard drive. 2. If my math is working this early, 1GB of ram = 1073741824 bytes. Now, we need to store 3 bytes per pixel, so 1GB of ram actually lets us store 1GB/3 = 357913941 pixels of data. We would need to store a 2d array of RGB values. So sqrt(357913941) = 18918 x 18918 array of pixels we can store in 1Gb of RAM. Assuming 1m texture resolution, this gives you a 18.9 x 18.9 km area you can shove into 1Gb of RAM (assuming all your other software is taking zero bytes of main RAM.) That's not much. Assuming even 10km visibility (6.2 miles) means you could always see off the edge from any place in this area. But we could use at a visibility of 5 km a 4 m texture resolution, at 10 km a 8 m texture resolution and at 19 km or more nothing of that, there we can use normal textures like it is today in flightgear. distance 5 km = 1m texture resolution = 10.0 x 10.0 km = 1 pixels of data distance 5 km and 10 km = 4 m texture resolution = (20.0 * 20.0 km) - (10.0 x 10.0 km) = 3/4 = 7500 pixels of data. Now we we have 357913941-1-7500 = 182913941 for the rest: distance 10 km and 19 km = 8 m texture resolution = (39.0 x 39.0) - (20.0 * 20.0 km) =112100 /8 = 140125000 pixels of data And 182913941-140125000 = 42788941 pixel of data . (42788941*3)/(1024*1024) = 122.42 MB So we still have about 122 MB Ram for other things. Now the only problem that still exists is the data transfer from the RAM to the video ram. A new Atlhon 64 FX has a bandwidth of about 6.4 GB/s. When we need to load the data from the local ram for every frame instead from the video ram and our framerate should be about 25 fps we have only 6.4GB/s / 25= 245 MB/frame that's IMHO not enough especilly when we need also to load the polygon data. We maybe need to adjust the values above a little bit. ;) Like 2km distance = 1m texture resoluton pixel 2-5km distance = 4 m texture resolution/pixel 5-10 km distance = 8 m texture resolution/pixel 10 km distance = old rendering solution or something like that. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Oliver C. wrote: Couldn't we load the whole data into RAM before? 1 GB Ram are cheap today. It's not nearly that simple. If you want to draw something on the screen, it has to get into the video card's memory at some point during the frame. Even 256MB Übercards are going to thrash* with a 1GB texture set. You end up being limited by the DMA bandwidth over the AGP bus, which is much lower than the memory bandwidth of the DDR SDRAM on the card (for lots of reasons, including the need to transfer higher mipmaps that wouldn't be sampled by the actual texturing operation). Andy * In this context, thrash means having to swap textures many times each frame. It's a performance condition exactly analagous to virtual memory thrashing via disk swap. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
[EMAIL PROTECTED] writes: 1. Threre is a big difference between having texture data loaded into main RAM vs. having the texture data loaded into your cards video RAM. (There are probably a few exceptions, the only one I can think of at the moment is the sgi O2 which has a unified main/video ram structure.) But when the data is allready in the RAM we wouldn't need to load the data from the slow hard drive. Right, but sending that much data across the AGP bus isn't fast either, especially when you want/need to draw at 60hz. Sure, everything else being equal, I'd rather fetch the data from RAM rather than a HD, but the AGP bus can be a real bottle neck if you need to shove too much info across it every frame. 2. If my math is working this early, 1GB of ram = 1073741824 bytes. Now, we need to store 3 bytes per pixel, so 1GB of ram actually lets us store 1GB/3 = 357913941 pixels of data. We would need to store a 2d array of RGB values. So sqrt(357913941) = 18918 x 18918 array of pixels we can store in 1Gb of RAM. Assuming 1m texture resolution, this gives you a 18.9 x 18.9 km area you can shove into 1Gb of RAM (assuming all your other software is taking zero bytes of main RAM.) That's not much. Assuming even 10km visibility (6.2 miles) means you could always see off the edge from any place in this area. But we could use at a visibility of 5 km a 4 m texture resolution, at 10 km a 8 m texture resolution and at 19 km or more nothing of that, there we can use normal textures like it is today in flightgear. Well, exactly, but that's where you get into complex texture management schemes and threaded loaders and all sorts of non-trivial stuff ... especially if you want to fly over a couple hundred miles worth of terrain and do it seamlessly and with no frame rate interruptions. Now the only problem that still exists is the data transfer from the RAM to the video ram. A new Atlhon 64 FX has a bandwidth of about 6.4 GB/s. When we need to load the data from the local ram for every frame instead from the video ram and our framerate should be about 25 fps we have only 6.4GB/s / 25= 245 MB/frame that's IMHO not enough especilly when we need also to load the polygon data. We maybe need to adjust the values above a little bit. ;) Like 2km distance = 1m texture resoluton pixel 2-5km distance = 4 m texture resolution/pixel 5-10 km distance = 8 m texture resolution/pixel 10 km distance = old rendering solution or something like that. Yes, this is exactly what you need to do with such schemes. You need to start making trade offs right and left. I'm not saying it's impossible to come up with something reasonable, I'm just saying it's non-trivial when we are doing it from scratch. There are a lot of issues that need to be considered and problems that need to be overcome. Anyone that launches into something like this will need to approach it with that in mind. The way I see it is that when I sit down to solve a problem, there is almost always going to be someone out there who has already thought of a better solution than what I manage to come up with. However, it's usually published in a paper some place with some minimal proof of concept implimentation. And there is often a big gap to cross to make the idea work in a real life application such as FlightGear. So, for the most part, it's not about coming up with some new amazing idea or observation, but rather taking a survey of existing ideas, picking the one approach (or hybrid of approaches) that you think will work best for the given situation, figuring out how to apply the theory to a real life application, figuring out how to extend the approach to the vast world that an application like FlightGear covers, and then doing what it takes to all that together and write well working, well optimized code. It can be a lot of *hard* work to grind it out and see it to completion. But that's really what it's all about: patience, persistance, and a lot of hard work. If someone wants to rework the scenery engine, that is exactly what it will take. And there's no reason we can't have several competing scenery engines in FlightGear. As long as we think a little bit about the API, and make sure they all support a common set of features, there's no reason why we can't make it work. We do this already with the flight dynamics modeling and the weather modeling. 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] Playing with textures
Unfortunately, plib (our scene graph engine) doesn't support multitexturing at this point in life. :-( From what I've read, this isn't the only thing it doesn't support that would make life easier for you guys. Why not just dump it for a scene graph library that does the job you need it to instead of working around the holes in plib? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Gene Buckle writes: Unfortunately, plib (our scene graph engine) doesn't support multitexturing at this point in life. :-( From what I've read, this isn't the only thing it doesn't support that would make life easier for you guys. Why not just dump it for a scene graph library that does the job you need it to instead of working around the holes in plib? This is something that has been considered, but it will be a massive amount of work to do this and preserve all the existing functionality. Massive might be slightly overstated, but it probably means tearing everything down and rebuilding it piece by piece. That's a big job, and it is made more complicated if we want to keep the current cvs head runnable. 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] Playing with textures
On Tuesday 02 December 2003 16:56, Curtis L. Olson wrote: Gene Buckle writes: Unfortunately, plib (our scene graph engine) doesn't support multitexturing at this point in life. :-( From what I've read, this isn't the only thing it doesn't support that would make life easier for you guys. Why not just dump it for a scene graph library that does the job you need it to instead of working around the holes in plib? This is something that has been considered, but it will be a massive amount of work to do this and preserve all the existing functionality. Does dumping plib mean that we can choose something like the SDL library for the OpenGL initialization? Massive might be slightly overstated, but it probably means tearing everything down and rebuilding it piece by piece. That's a big job, and it is made more complicated if we want to keep the current cvs head runnable. We could create a second branch in the CVS and merge them back together when the new one is working. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Gene Buckle writes: Unfortunately, plib (our scene graph engine) doesn't support multitexturing at this point in life. :-( From what I've read, this isn't the only thing it doesn't support that would make life easier for you guys. Why not just dump it for a scene graph library that does the job you need it to instead of working around the holes in plib? This is something that has been considered, but it will be a massive amount of work to do this and preserve all the existing functionality. Massive might be slightly overstated, but it probably means tearing everything down and rebuilding it piece by piece. That's a big job, and it is made more complicated if we want to keep the current cvs head runnable. I can imagine this would be a complex undertaking, but wouldn't it be the best solution in the long run? If it would be easier, why not just fork plib and add the features needed without having to wait for patches to be (maybe) accepted and merged in? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Oliver C. wrote: Does dumping plib mean that we can choose something like the SDL library for the OpenGL initialization? No, that means dumping glut. Earlier plib versions had a glut dependency, but I believe that has been removed from current versions. We can keep the plib parts that we use and still move to SDL. I promised Curt long ago that I'd look into that issue. But then I went AWOL for a while. Basically, we need to change the glut callbacks in the existing fgfs code into an SDL event loop. That part is easy. The harder bit is the mouse cursor: glut hooks the window system to give you an easy choice of multiple cursor types with a simple glutSetCursor() API. SDL does nothing of the sort -- you need to come up with your own cursor bitmaps for the SDL API, or actually draw your own cursor icon using OpenGL. Most games take the second route, since you can do nifty color and blending tricks which the underlying window system APIs don't support (in a portable way; I think most OS's have color cursors now...). Moving to SDL has a bunch of advantages though. It's more portable than glut, and unlike glut is under active development. Glut has bugs that won't ever be fixed, like the linkage problem with Red Hat 9 and the NVidia drivers. [regarding work on a multitexturing terrain implementation:] We could create a second branch in the CVS and merge them back together when the new one is working. It's not about development methodology. It's about someone sitting down, dissecting the existing code, coming up with a prototype for a new implementation and then working their butt off to make it happen. Buzzing on mailing lists just leads to flame wars, not code. Code is all that matters. I'll say it again: this is a *hard* problem. And I'm someone who really likes hard problems. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
On 09:56 Tue 02 Dec , Curtis L. Olson wrote: This is something that has been considered, but it will be a massive amount of work to do this and preserve all the existing functionality. Massive might be slightly overstated, but it probably means tearing everything down and rebuilding it piece by piece. That's a big job, and it is made more complicated if we want to keep the current cvs head runnable. ...and maybe move to SDL too ?! All the best, Matt ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Gene Buckle writes: I can imagine this would be a complex undertaking, but wouldn't it be the best solution in the long run? Sure, and it's on the todo list (or to investigate list) somewhere. However, there is always a significant time shortage. If it would be easier, why not just fork plib and add the features needed without having to wait for patches to be (maybe) accepted and merged in? Forking plib would create a support nightmare since this is a standard package on many distributions. insert long list of potential gotcha's -here- that increase exponentially as the level of computer experience of the end user decreases. 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] Playing with textures
On Tuesday 02 December 2003 16:21, Curtis L. Olson wrote: But when the data is allready in the RAM we wouldn't need to load the data from the slow hard drive. Right, but sending that much data across the AGP bus isn't fast either, especially when you want/need to draw at 60hz. Sure, everything else being equal, I'd rather fetch the data from RAM rather than a HD, but the AGP bus can be a real bottle neck if you need to shove too much info across it every frame. How long could it take until we see the first videocards with 1024 MB RAM in the computer stores for an acceptable price (100-300 )? Are 2 years in the possible range? But we could use at a visibility of 5 km a 4 m texture resolution, at 10 km a 8 m texture resolution and at 19 km or more nothing of that, there we can use normal textures like it is today in flightgear. Well, exactly, but that's where you get into complex texture management schemes and threaded loaders and all sorts of non-trivial stuff ... especially if you want to fly over a couple hundred miles worth of terrain and do it seamlessly and with no frame rate interruptions. Ok, do you know any good documentation and information about this particular real time rendering topic. That doesn't mean that i will write such an engine, but i just want to read the basic stuff so that i know what i am talking about. ;) Yes, this is exactly what you need to do with such schemes. You need to start making trade offs right and left. I'm not saying it's impossible to come up with something reasonable, I'm just saying it's non-trivial when we are doing it from scratch. There are a lot of issues that need to be considered and problems that need to be overcome. Anyone that launches into something like this will need to approach it with that in mind. The way I see it is that when I sit down to solve a problem, there is almost always going to be someone out there who has already thought of a better solution than what I manage to come up with. However, it's usually published in a paper some place with some minimal proof of concept implimentation. And there is often a big gap to cross to make the idea work in a real life application such as FlightGear. So, for the most part, it's not about coming up with some new amazing idea or observation, but rather taking a survey of existing ideas, picking the one approach (or hybrid of approaches) that you think will work best for the given situation, figuring out how to apply the theory to a real life application, figuring out how to extend the approach to the vast world that an application like FlightGear covers, and then doing what it takes to all that together and write well working, well optimized code. It can be a lot of *hard* work to grind it out and see it to completion. But that's really what it's all about: patience, persistance, and a lot of hard work. What alternative ways do we have to make the visual quality especially of the ground scenery in flightgear better? And did someone read those LOD (level of detail) planet rendering documentations i mentioned last week? What do you think about that, is that possible with the flightgear scenery? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
[EMAIL PROTECTED] writes: On Tuesday 02 December 2003 16:56, Curtis L. Olson wrote: Gene Buckle writes: Unfortunately, plib (our scene graph engine) doesn't support multitexturing at this point in life. :-( From what I've read, this isn't the only thing it doesn't support that would make life easier for you guys. Why not just dump it for a scene graph library that does the job you need it to instead of working around the holes in plib? This is something that has been considered, but it will be a massive amount of work to do this and preserve all the existing functionality. Does dumping plib mean that we can choose something like the SDL library for the OpenGL initialization? This is a completely (well almost completely) unrelated issue. 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] Playing with textures
[EMAIL PROTECTED] writes: On Tuesday 02 December 2003 16:21, Curtis L. Olson wrote: But when the data is allready in the RAM we wouldn't need to load the data from the slow hard drive. Right, but sending that much data across the AGP bus isn't fast either, especially when you want/need to draw at 60hz. Sure, everything else being equal, I'd rather fetch the data from RAM rather than a HD, but the AGP bus can be a real bottle neck if you need to shove too much info across it every frame. How long could it take until we see the first videocards with 1024 MB RAM in the computer stores for an acceptable price (100-300 $,1tL(B)? Are 2 years in the possible range? If a person is working on some feature that won't be finished for 2 years, then I think it is reasonable to try to predict card performance that far out and write to future hardware. In large part, that is what we did when we started the current FlightGear scenery system. Ok, do you know any good documentation and information about this particular real time rendering topic. That doesn't mean that i will write such an engine, but i just want to read the basic stuff so that i know what i am talking about. ;) I would recommend doing a net search for CLOD (continuous level of detail) and ROAM (I forget what that stands for.) There are a lot of spiffy demos out there. However, there are some non-trivial issues in taking a chunk of demo code and making it work for the entire world. Most demos just handle a small fixed area. You need to consider paging terrain data in/out, paging textures in/out, and making your chunks of data fit seamlessly together in the context of your CLOD algorithm. You could always start out by doing a small fixed area in FlightGear and work on some of the more complex issues later. These things never get developed all at once, and the issues are large enough that a patient, step by step approach will probably be needed. What alternative ways do we have to make the visual quality especially of the ground scenery in flightgear better? The FlightGear scenery engine renders an arbitrary set of triangles, painted with arbitrary textures. It is actually quite flexible. Currently FlightGear scenery is autogenerated via the TerraGear tool set. A person could conceivably develop there own set of tools to produce FlightGear scenery, or extend the TerraGear tools, or use some commercial package like Multigen Creator (with it's associated add ons.) FlightGear can also load quite a variety of 3d formats, so it's not unreasonable to consider building a terrain area by hand. That is what many high end simulators do. And did someone read those LOD (level of detail) planet rendering documentations i mentioned last week? What do you think about that, is that possible with the flightgear scenery? I personally haven't had a chance to look at these. But this is outside my personal focus and priority right now. 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] Playing with textures
On Tuesday 02 December 2003 18:15, Curtis L. Olson wrote: Ok, do you know any good documentation and information about this particular real time rendering topic. That doesn't mean that i will write such an engine, but i just want to read the basic stuff so that i know what i am talking about. ;) I would recommend doing a net search for CLOD (continuous level of detail) and ROAM (I forget what that stands for.) There are a lot of spiffy demos out there. However, there are some non-trivial issues in taking a chunk of demo code and making it work for the entire world. Most demos just handle a small fixed area. You need to consider paging terrain data in/out, paging textures in/out, and making your chunks of data fit seamlessly together in the context of your CLOD algorithm. You could always start out by doing a small fixed area in FlightGear and work on some of the more complex issues later. These things never get developed all at once, and the issues are large enough that a patient, step by step approach will probably be needed. OK, I will take a closer look at these CLOD and ROAM documents. Thank you. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
On Tuesday, 2 December 2003 19:15, Curtis L. Olson wrote: If a person is working on some feature that won't be finished for 2 years, then I think it is reasonable to try to predict card performance that far out and write to future hardware. In large part, that is what we did when we started the current FlightGear scenery system. Good point. 512 MB cards are probably less than a year away. 3-4 years from now 1 GB video cards will probably be the norm. I think the current practical limit for aerial/satelite scenery is about 4 meters/pixel and then only for small pre-rendered areas. One could add a detail map to enhance the textures at close range. Another option I thought of is to pre-render a corridor of scenery between arrival and departure points and if you fly outside of the corridor fall back to the default scenery. A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km) would require about 311 GB of storage space using S3TC compression with a texture resolution of 1 meter/pixel. That translates to 13.88 MB of texture data flowing across the AGP bus every second if one was traveling at 1000km/h. That's possible with current hardware but it's out of most people's budgets. - 500MB disk with larger than 14 MB/sec transfer rates - 256 or 512 MB video card - PC with decent bus transfer rates The other side of the coin is to forget about the raster approach and use the polygon approach but that is less practical. i.e. Add lots of polygons to get more detail. I doubt that the polygon processing of GPUs is going to increase as fast as the amount of video RAM and besides that it takes space to store all those polygons. Ideas, ideas ... one can always dreaming I guess. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Curtis L. Olson wrote: I would recommend doing a net search for CLOD (continuous level of detail) and ROAM (I forget what that stands for.) Real-time Optimally Adapting Meshes. -- Russ Conway's Law: The structure of a system tends to mirror the structure of the group producing it. -- Mel Conway Datamation (1968) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
[Heh, this turned out longer than I expected when I started writing...] Curtis L. Olson wrote: I would recommend doing a net search for CLOD (continuous level of detail) and ROAM (I forget what that stands for.) There are a lot of spiffy demos out there. However, there are some non-trivial issues in taking a chunk of demo code and making it work for the entire world. Amen, brother. :) I got as far as making a whole-world ROAMish* tesselator work. It works on mipmap-style tiles, with many generations. The largest generation was 1024m per sample with my test data, down to 8m for the smallest. Tiles would be paged in and out based on screen-space priority with a threaded loader. This part worked really well, actually. * For the LOD geeks: Split only, with a modified screen error metric and square/diamond-based (instead of per-triangle) error terms. The spherical world geometry is handled via a trapezoidal deformation of the square grids and a distance-dependent push-down of elevation data, with an internal transition to a separate data set near the poles. But the texturing is a huge mess. The first problem is that you want to generate your textures automatically out of archetypes to avoid having to store the whole world at 1m per pixel. I was using a terrain type gridding, with 1 terrain type for each 256mx256m area. But of course you don't just draw them next to each other, because that's ugly. So I came up with a set of noise-based blending textures (four of them, which sum to an alpha of 1.0) that smoothly (but not too smoothly) blend the type textures into each other. This was working pretty well, too. I have some samples that saved somewhere; I'll try to dig them up and post them. Then the problem was getting S3TC working to acheive a useful level of coverage. As I mentioned before, this just didn't work well at all on current ATI drivers. I was looking either at writing my own S3TC compressor (about which there are confusing patent issues, sigh) or settling for a rather poor level of on-screen texture detail. And the final problem was the mapping of generational terrain textures to the geometry polygons. Remember that the terrain geometry is paged in according to screen-space error (so that distant mountains might get loaded before nearby plains). But the terrain textures don't care about vertical error -- they want a plain, flat generation structure. Handling the mapping between these two spaces, and keeping it consistent as geometry tiles came in and out and terrain textures were generated and deallocated turned into a huge bookeeping mess. Add that to the fact that due to the compression issue it wasn't going to look very good anyway, and I just gave up. If I was going to revisit the project, I think a better idea would be to reduce the required number of textures by compositing the terrain types and noise modulators right on the polygons as they are drawn. That's an 8x (!) multitexture algorithm (i.e. at least two passes on current hardware), but that should be doable. It is, however, and even greater bookeeping nightmare. It also needs to be pointed out that this kind of mechanism has no built-in support for custom terrain geometry features like roads or airports (this wasn't a problem for the game I had in mind, but it's kind of a showstopper for FlightGear). Those would require lots more work. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Andy Ross [EMAIL PROTECTED] wrote: Oliver C. wrote: Does dumping plib mean that we can choose something like the SDL library for the OpenGL initialization? No, that means dumping glut. Earlier plib versions had a glut dependency, but I believe that has been removed from current versions. [...] Moving to SDL has a bunch of advantages though. It's more portable than glut, and unlike glut is under active development. I have a strong impression that the PLIB and FreeGLUT projects share quite a few developers. I'm not shure about new features in FreeGLUT-2 but I definitely know that it works as a drop-in-replacement for GLUT on Linux when you look at FlightGear, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Paul Surgeon wrote: A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km) would require about 311 GB of storage space using S3TC compression with a texture resolution of 1 meter/pixel. Probably half, that, actually, since a lot of the trip is over ocean. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km) would require about 311 GB of storage space using S3TC compression with a texture resolution of 1 meter/pixel. You can buy 320MB of hard disk space for a mere USD 275 (GBP 160) if you shop around. What sounds OTT today will soon become the norm, so maybe it's best to have an eye a little into the future with all these calculations. Mally --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.545 / Virus Database: 339 - Release Date: 27/11/03 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Playing with textures
David Megginson writes: Paul Surgeon wrote: A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km) would require about 311 GB of storage space using S3TC compression with a texture resolution of 1 meter/pixel. Probably half, that, actually, since a lot of the trip is over ocean. Actually, I will be *very* surprised if you will be able to find anything better then 30 meter per pixel for anyplace not in the USA so you will probably only need a couple of gigabytes for this corridor Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Playing with textures
I made a tilable grass texture today. If anyone likes it and wants to use for some part of FG then let me know and I'll e-mail it to you. 1024x1024 RGB - 3MB I made it quite light to reflect the type of grass in my part of the world so if someone wants darker greens let me know and I'll tweak it before sending it. I tested it in FG by adding it to the high res terrain texture folder. I was surprised to see it load and that the scaling seems to be correct as well. I was expecting some sort of scaling or clipping problem. http://www.geocities.com/surgptr/images/grass1.jpg http://www.geocities.com/surgptr/images/grass2.jpg Now if I can just figure out how to change the mip mapping to not be so aggressive. It kills the texture detail far too close to the viewer and makes the screenshots look bad. Regards Paul Surgeon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Paul Surgeon writes: Now if I can just figure out how to change the mip mapping to not be so aggressive. It kills the texture detail far too close to the viewer and makes the screenshots look bad. The best thing I've seen for this is to enable anisotropic texture filtering for your card. On Linux this is an environment (shell) variable setting. Perhaps on windows it would be settable in the display properties 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] Playing with textures
Paul Surgeon schrieb: I made a tilable grass texture today. It looks great If anyone likes it and wants to use for some part of FG then let me know and I'll e-mail it to you. 1024x1024 RGB - 3MB 1024x1024 is *extremly* big for such a texture! We should try to render our terrain with multitextures. So we can have a small hi-res noisy texture for the details and a big low-res texture for the general appearance. Then we'd only need a fraction of that texture size! CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
If you could define N multiple textures overtextures, you would get N^2 possible textures, which would really break up the patterns for a small memory cost. And while you're on the subject of We should try, I've always wondered about using multitextures with the top one off the ground. You could put stuff like bushes, forrest canopies and maybe rooftops in them and really improve your sense of altitude for VFR. You could even define different altitudes based on the terrain type. It would be really helpful to see the treetops on either side of the runway go by as you approach a touchdown. Of course, they would disappear at eye level on flat ground but it's a start. I also wonder what the effect of bump-mapping the ground would be. Josh Christian Mayer wrote: Paul Surgeon schrieb: I made a tilable grass texture today. It looks great If anyone likes it and wants to use for some part of FG then let me know and I'll e-mail it to you. 1024x1024 RGB - 3MB 1024x1024 is *extremly* big for such a texture! We should try to render our terrain with multitextures. So we can have a small hi-res noisy texture for the details and a big low-res texture for the general appearance. Then we'd only need a fraction of that texture size! CU, Christian ___ 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] Playing with textures
Josh Babcock writes: If you could define N multiple textures overtextures, you would get N^2 possible textures, which would really break up the patterns for a small memory cost. And while you're on the subject of We should try, I've always wondered about using multitextures with the top one off the ground. You could put stuff like bushes, forrest canopies and maybe rooftops in them and really improve your sense of altitude for VFR. You could even define different altitudes based on the terrain type. It would be really helpful to see the treetops on either side of the runway go by as you approach a touchdown. Of course, they would disappear at eye level on flat ground but it's a start. I also wonder what the effect of bump-mapping the ground would be. Unfortunately, plib (our scene graph engine) doesn't support multitexturing at this point in life. :-( 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] Playing with textures
Paul Surgeon wrote: I'm sure there will be protesters but this polygonal looking scenery is not very nice in my opinion. Yes it works but it doesn't even begin to resemble real life scenery. Out of curiosity has anyone ever used TerraScene? (synthetic scenery generation app for Fly! and Fly!2) Yes, I did use it -- it was a very well-thought out little program, but it had some pretty disasterous problems: 1. The generated scenery was enormous: we couldn't dream of making worldwide scenery available online (TerraScene scenery was never available for more than tiny areas). 2. The GIS data TerraScene used was mostly U.S.-only. 3. It looked great at altitude, but absolutely horrendous when you got close to the ground, as it blurred out into giant pixels. That made it very unsuitable for low-flying vehicles like helicopters, ultralights, or balloons (or even the Piper Cub for that matter). 4. There was no (easy) way to determine the terrain type at runtime, so it wouldn't be possible to place 3D objects like trees or buildings, much less generate appropriate ground reactions (when we get around to that). That said, it would be neat if we could support TerraScene-generated textures for special applications. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Paul Surgeon wrote: Detail textures help but I they are not the answer. What is needed is new terrain rendering engine. :D I'm sure there will be protesters but this polygonal looking scenery is not very nice in my opinion. Yes it works but it doesn't even begin to resemble real life scenery. But the answer can't possibly be to blow 4MB of card memory per texture. There are dozens of terrain types. Even a 256MB megacard is going to run short when you spend your VRAM like that that. A new terrain renderer would be great. But it's *not* easy. On my game project last year, I got a lot of decidedly non-trivial things (like Nasal) to work well. Guess what I was working on when I lost interest? :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
On Tuesday, 2 December 2003 00:12, David Megginson wrote: Yes, I did use it -- it was a very well-thought out little program, but it had some pretty disasterous problems: 1. The generated scenery was enormous: we couldn't dream of making worldwide scenery available online (TerraScene scenery was never available for more than tiny areas). Yeah that's because the scenery is pre-rendered. Who said we have to pre-render the scenery? :) Rendering in real time would only require a library of geodata which would be similar in size to the current FG scenery. 2. The GIS data TerraScene used was mostly U.S.-only. Yip but the results still looked better than default scenery outside of the US. One can always add more data as it becomes available. 3. It looked great at altitude, but absolutely horrendous when you got close to the ground, as it blurred out into giant pixels. That made it very unsuitable for low-flying vehicles like helicopters, ultralights, or balloons (or even the Piper Cub for that matter). Well it was only 7.5 meters/pixel - I was thinking of at least 4 meters/pixel and possible down to 1 meter/pixel. Also we can have extra high res textures around airports. 4. There was no (easy) way to determine the terrain type at runtime, so it wouldn't be possible to place 3D objects like trees or buildings, much less generate appropriate ground reactions (when we get around to that). If you generate the scenery at run time you will know the terrain type. Alternatively you could use the geodata to find that out. That said, it would be neat if we could support TerraScene-generated textures for special applications. It would be neat if FG could properly support large ortho photos to start with. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
On Tuesday, 2 December 2003 00:16, Andy Ross wrote: But the answer can't possibly be to blow 4MB of card memory per texture. There are dozens of terrain types. Even a 256MB megacard is going to run short when you spend your VRAM like that that. It would not work for the way the current scenery engine works but it would work for aerial/satelite scenery. In the case of aerial/satelite scenery the scenery engine only has to cache the textures it needs. That would only be the textures in visible range. Then also factor mip mapping in and your memory consumption drops drastically. Think along the lines of about 57MB for 400 km2 with the terrain directly under the aircraft at 1 meter/pixel resolution and then gradually tappering off to 8 meters/pixel in 5 steps to a distance of 10 km in all directions from the aircraft. Then we haven't even started to discuss stuff like S3TC texture compression which can drop the texture size down to about 10MB. :) A new terrain renderer would be great. But it's *not* easy. No kidding! That's why I'm doing all my proof of concept development outside of FG. No point in trying to implement something that I'm not sure will work properly/fast enough. On my game project last year, I got a lot of decidedly non-trivial things (like Nasal) to work well. Guess what I was working on when I lost interest? :) Hehe! Hopefully I'll see this one through. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Paul Surgeon wrote: Think along the lines of about 57MB for 400 km2 with the terrain directly under the aircraft at 1 meter/pixel resolution and then gradually tappering off to 8 meters/pixel in 5 steps to a distance of 10 km in all directions from the aircraft. That was my thinking when I started, too. But your math is a little off. Getting to a worst case resolution of 1 texel per screen-space pixel with unique texturing requires *vast* amounts of memory. The anisotropy kills you; far-away texels might typically be rendered at an aspect ratio of 10:1, forcing you to waste most of your card memory on useless information. The newer anisotropy controls might help with that, but coding the management intelligence for that is very non-trivial. Think of a texture that is viewed diagonally: anisotropy won't help; you need to rotate it to match the texel grain to get anything better than a factor of two benefit. Then we haven't even started to discuss stuff like S3TC texture compression which can drop the texture size down to about 10MB. :) This part I actually got working, sort of. Dynamically generated 256x256 textures take about 1/30 second to generate on my GeForce3 (the limiting factor is the DMA to and from the card; the compression itself is done on the CPU). Using ATI's drivers, it was 1/3 of a second or worse. That just isn't useful for realtime stuff; the driver would spend all of its time compressing textures and have no time left for rendering. Like I said; it ain't easy. I tried, and failed. I'm not saying it won't work, mind you; I might pick up the problem again if I'm feeling adventurous. Ideas are free, and designs are cheap. Code is all that matters. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Playing with textures
Could it be possible to create a rendering engine that allows us to fly from the ground up into space seamlessly? Many flight simulators have their limits at around 5 feet altitude so it would be great if we are able to fly higher in flightgear. This would be desirable for something like the X-15. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Andy Ross writes: That was my thinking when I started, too. But your math is a little off. Getting to a worst case resolution of 1 texel per screen-space pixel with unique texturing requires *vast* amounts of memory. The anisotropy kills you; far-away texels might typically be rendered at an aspect ratio of 10:1, forcing you to waste most of your card memory on useless information. The newer anisotropy controls might help with that, but coding the management intelligence for that is very non-trivial. Think of a texture that is viewed diagonally: anisotropy won't help; you need to rotate it to match the texel grain to get anything better than a factor of two benefit. My understanding of systems that impliment these basic ideas is that step 1) is to give up the idea of seamless, non-blurry textures in the distance. Every system I have seen blurs the textures excessively as you go further in the distance ... that also yields a corresponding texture blurry-sharp popping effect as you get closer to a new area. And because the system typically has to do this stuff in a low priority thread to keep up rendering rates, you can see by the popping that the detail texture loading often lags and doesn't pop into full detail until you are right over it. Just for fun, sit down and assume 1 meter texture resolution, assume you are flying at 500 kts, and assume something like 20 mile visible radius. Now crunch the math on how much data you have to flow in from your HD per second or per frame, and you will see that it is a *lot* of work. There is a reason that high end graphics computers often have 4 or more cpus, multiple scsi busses, and all sorts of other fancy, high bandwidth gizmos (and cost upward into the millions.) PC's just can't compete in this arena (yet) which is why sgi hasn't completely tanked (yet). :-) Then we haven't even started to discuss stuff like S3TC texture compression which can drop the texture size down to about 10MB. :) This part I actually got working, sort of. Dynamically generated 256x256 textures take about 1/30 second to generate on my GeForce3 (the limiting factor is the DMA to and from the card; the compression itself is done on the CPU). Using ATI's drivers, it was 1/3 of a second or worse. That just isn't useful for realtime stuff; the driver would spend all of its time compressing textures and have no time left for rendering. Like I said; it ain't easy. I tried, and failed. I'm not saying it won't work, mind you; I might pick up the problem again if I'm feeling adventurous. Ideas are free, and designs are cheap. Code is all that matters. Yes, good luck on doing the rendering in real time with a single CPU. :-) If you worked up a well functioning demo, I bet it would be quite popular and get you large quantities of geek points. Everything's possible, and one of the goals of FlightGear is to provide a forum and a structure where people can develop and plug in new ideas to see how they work, without needed to also develop the entire application. It's easy for us to sit here and say it can't work (at least not very well), but the hard headed ones will forge ahead anyway, attack the problems and issues head on, and a few of those people will find successful solutions and a place in the geek hall of fame. :-) 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
