![\"\"](\"http:\/\/www.anguishgames.com\/download\/images\/GoodGraphics28.png\")
<\/a>GoodGraphics28.png, Terrains.<\/p><\/div>\n
So, again, I’m still very early into my implementation. \u00a0That image represents approximately 3 days worth of work. \u00a0I still have a lot of work to do in spatial partitioning, LOD, and blending different detail maps to get something that looks and performs as well as I need it to. \u00a0I also found an Nvidia sample<\/a> that utilizes the tessellation hardware to great effect that I want to try to incorporate. \u00a0However, right now I’m able to generate 10 square kilometers worth of game world terrain and maintain over 60fps so I’m not unhappy with how things are going right now. \u00a0To get a sense of the scale, here are some images:<\/p>\n And that brings me to the other issue I wanted to talk about; errors in the framework. \u00a0Some of them are caused by subtle problems but are still obvious. \u00a0For example, setting the depth function to D3D11_COMPARISON_EQUAL can be a great way to re-use depth information and eliminate pixel overdraw on subsequent material passes. \u00a0However, if one pass multiplies the viewprojection matrix against the world matrix on the cpu, and another does this on the gpu, you will not get the result you want because of differing precision. \u00a0It seems obvious as I type it, but it took me about 30 minutes to realize what was going on. \u00a0But at least it was incredibly obvious that something WAS wrong because the output was broken.<\/p>\n Things get tougher when you get a continuous output from your error and you don’t realize anything is wrong, and this can happen a lot in graphics. \u00a0A good example is depth data usage in my lighting and postprocessing. \u00a0The image in my last post was actually completely incorrect, but I didn’t realize it when it was initially taken. \u00a0Tweaking some data lead me to realize that moving the camera far enough away caused illumination to zero out, which makes no sense. \u00a0But for a large range of distances it seemed correct, so it took me a while to even realize there was a problem. \u00a0A good way to simulate this (but wasn’t my actual problem) is to bind the active depth buffer as the shader resource view my lighting is sampling, ensuring I get an all black texture. \u00a0That’s obviously wrong, but the output you get can seem right within the right data set. \u00a0This problem also manifested itself in my depth of field effect. \u00a0When I first implemented it, I happened upon values that worked against my incorrect depth data. \u00a0It wasn’t until I started tweaking focal distance and width that I realized something was very wrong.<\/p>\n Those problems might be specific to me, but I think the real takeaway here is that when you implement something new in graphics, you really need to test a wide range of data to ensure your effect is really doing what you want, and not doing it by circumstance. \u00a0If you don’t, a fundamental error can persist in your code base for a long, long time without anyone realizing, and it makes it much harder to add new features when basic code additions don’t do what you should reasonably expect them to.<\/p>\n So, that’s it for this time. \u00a0I wish I’d taken some screenshots of output of the errors I talked about, but I think the information is still pretty worthwhile without pretty pictures. \u00a0Next time (hopefully soon), I’ll talk about the start of my move to a physically based rendering model, beginning with replacing the specular reflection model.<\/p>\n","protected":false},"excerpt":{"rendered":" Last time I said I would be talking about my work on terrain and some errors I ran into over the course of developing my framework for this year. \u00a0So, surprisingly, that’s what’s about to happen. I’ll talk about terrain first because it’s visually more appealing (and I actually remembered \u2026 Continue reading <\/a><\/p>\n<\/a>Now, unfortunately these screenshots have different terrains in them and it kind of ruins the effect of what I was trying to illustrate. \u00a0But, the movement of the terrain is minuscule as the car moves out of view into the far distance. \u00a0I would have retaken them to fix this inconsistency, except I’ve made dramatic changes to the lighting model that I want to save for my next post. \u00a0Sorry!<\/p>\n