 Hello I am back again with my second .tech file update. I am going to cover a few interesting topics in this file. The first thing i want to talk about is: Detail In 3D Engines Today's modern engines can deliver a high triangle fillrate and are equipped with quite a big amount of memory for textures. Every engine i have ever seen had one little bug wich i dislike. When we get very close to a wall, we always end up by seeing huge pixels or a bilinear filtered image of a texture. We have all these cool features in today's engines (fog,shadows,etc...) but all of them suffer from the "bug" wich i have mentioned. So, what can we do about it? The approach that i considered is the following: We have to determine if we are close to a wall or object of somekind. In this case, our engine has a few triangles to process per frame, under 100 (correct me if i am wrong). At this amount of triangles, our engine has very less work to do, so we can flush out some textures from the video memory and upload some high detail textures onto the card (we have only a couple of triangles, so the number of textures is little) and use them to render a high detail texture. I asked at 3dfx if a 2 Mb transfer over the AGP will slow down my rendering. The answer was that I can transfer this amount of data without a big performance drop. When we go away from our "high detail object" we can flush out the big textures and load back the regular textures we use for rendering. Currently i don't have a 3D board, but if anyone has one and tries this out, I would be happy if i receive some feedback. I work in OpenGL using the implementation provided with Delphi (It's faster then the Micro$oft one). Another approach that i have considered is a pretty quite method of computing the texture coordinates once per every screen pixel and transfer it onto the screen.It is still much of a theory, but when i will implement it i will get back on it. This would limit my texture size to the limit of system memory. Modern 3D Hardware: What Is Good And What Is Wrong? You probably now what is good about 3D boards,so let me tell you what is wrong with them. They are not compatible with each other. A while ago I have read Carmack's debate on OpenGL versus Direct3D. At one point he said (Note: the words aren't exact. See www.directx.com for the whole debate): If there would be one 3D board covering almost all of the 3D board market, he would be writing straight to the metal, without using any API. So where is the point in writing low-level code when we can just use Direct3D,OpenGL or any high level Api? The answer is SPEED. Any piece of hardware runs faster when programmed low-level, instead of using some high-level abstract Api. Could we solve this compatibility problem somehow? Remember the god old Dos-days when we had Vesa and Univbe to take care of the video board incompatibility. Could we write something like that for 3D boards? Probably. But the amount of work is huge, since a 3D board is a lot more complicated then a simple Svga card. This kind of software will have to provide a very thin abstractization layer on top of the 3D hardware. I can't say more about this since i don't have many low-level 3D board specifications, but if someone has a few I would be glad if he mail's me a copy. That's all for this time. Next time i will come back with another interesting topic: Computing portals, how to have them computed automatically, so we don't have to define portals and cells by hand. Until next time: Keep coding, learning, and sometimes go out and have fun. 
|
