I have done some more work on my virtual texturing project in the last couple months, which has been pretty fun. I had some issues along the way while (re-)developing some of the base concepts for it. For example, one significant issue was when I was experimenting with the way that texture lookups would be done. At first, I thought it would be feasible to have every texture page be stored in a large texture in a non-continuous manner, and in the pixel shader use an indirection texture to specify what blocks of a texture should be looked up at a certain texture coordinate. Not unlike page lookup tables on a virtual memory system, really. However, I ran into an extremely objectionable artifact, shown below:
(click for enlarged version)
At first, I, like just about everyone else I asked on the issue, thought it was related to texture bleeding, however as I investigated it carefully, this was not the case at all. Basically, it was due to the hardware doing anisotropic filtering in a manner that it is not at all used to, or designed for (if anyone wants a more detail explanation, I'll make a subsequent entry on it). I was quite taken aback that I managed to make any kind of artifact that was so close to the hardware, and one that basically no one I knew had seen before and could accurately guess as to what the problem was. I've since "solved" that issue, so I moved onto another one that I had to w*ork out: evaluating the visibility of individual pages on textures.
If you look through my journal posts from early in the year, you'll notice that I was initially going to try for a software rasterizer to figure out what texture blocks are necessary for a given frame. Since that time, I've decided to forget it partially due to the undesirably high CPU usage, and more importantly, because there would have likely been objectionable artifacts as the contents of the scene moved around due to the mismatched resolutions of the GPU rendering and the softrast. I did some pondering and have come up with a new, good, solution that I think will work really well. It's also fairly odd too I think, for example, the evaluation requires that all of the objects in the scene have to be rendered using a specific shader, and in the vertex shader, the position of the vertex is determined entirely using the inputted texture coordinates. Like above, if anyone wants more information on how I'm planning/doing this part, I'll be more than willing to make an entry about it.
I do hope that I get this done and working to a reasonable extent fairly soon, as I've been itching to get some other graphics programming done. I haven't been working on other stuff primarily because I have a fairly one-track mind, and I didn't want to get distracted. But once this is done, I really want to do a high end shadow map-based renderer, partially because there's been some work recently that I think is not that great and I want to be able to say "Come on guys, THIS is how shadow maps are done". Of course, idNext is probably going to be shown off at QuakeCon this year, and I certainly hope that that does it instead. I'm getting really tired at game devs, both formal and informal, who seem to so easily tolerate issues like shadow mapping's aliasing, and I hope something is done about it soon.
So, that's basically an update of what I've been doing this last little while. Like I said earlier, I'll probably let my GDNet+ account slide a bit once I get a bit more prolific in my work and have more stuff to show off.