[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 Cities curt '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
