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
