On Friday 04 February 2005 17:46, John Tsiombikas (Nuclear / the Lab) wrote: > > Decent engines do very little overdraw. Hidden geometry is removed > > before it ever gets to the card. In ID games, only movable objects > > are dumped into the Z buffer on top of the scenery, which is only > > one pixel deep. ID puts a huge load on the graphics card, but it's > > not overdraw, it's things multitexturing and more recently, > > shaders. I don't know too many details about the Unreal engine, > > but I'm fairly confident they don't just dump all their geometry > > onto the card either. > > Not everything is quake though (and it's derivatives). Techniques to > avoid overdraw in 1st person shooters and similar *static* *close > space* environments have been developed to a great extend, but there > are a lot of applications out there that do totally different things, > and most of the time avoiding overdraw is not feasible. Especially in > programs with highly dynamic 3D environments.
If you're talking about engineering and real time modelling, those are not twitch games and don't have to keep up a steady 30-60 frames per second. I don't belittle the importance of non-game 3D graphics applications, however I use games to measure performance because everybody else does. If it handles games well, it's going to handle a lot of things well. > Personally I don't care if it's going to be an ASIC (which I take it > means a fixed chip) or an FPGA since I'm not a hardware hacker, but I > do realize that a lot of people are looking forward to be able to > tinker with the thing, and I respect that. However let's not forget > that in order to be competitive and viable to the > non-hardware-hackers, speed is an issue of major importance. It is. The trick is to be good enough. If we can pull it off with a FPGA, it's really going to turn some heads, not to mention attract a lot more hackers to help make it better. This in no way lets out the possibility of following up with an ASIC, as Timothy has suggested in the past. It's just the idea of starting with an ASIC that I don't find particularly appealing. It would violate the "release early, release often" rule for one thing. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
