My game requires rendering of a relatively large snow-covered mountainous terrain. Most of the terrain, probably 80% of it, is pure snow with some detail texturing but there are areas of it, mostly near-vertical areas that have exposed rock under the snow.
My terrain system is fairly standard I think and allows me to render chunks with a lo-res texture combined with detailed textures. At a specified distance, the detail texture fades out leaving the lo-res texture at distance. Unfortunately, whilst the lo-res texture is great for things like giving some features to repeating textures (like grass or rock), it's too low to use for rock exposure at distance (and in fact up close as the highest resolution it gets is generally one pixel per metre).
My current idea is to use LODed geometry for the rocks. My material system allows me to add a second texture 'layer' to the material exposed by an alpha channel, so the base texture would be mountain rock with the relevant normal and specular maps, etc and the snow texture would be the second layer. To add some variety, I'd need to create several materials, each with the same textures but different alpha maps. I think I can probably achieve a fairly organic look with a handful of rotated and scaled rock meshes and a few of these double layered materials.
Before I embark on this, is it a good way of doing it? I don't use texture splatting for my terrain, I use multi-pass layers drawn using index buffer lookups. Because the layers use the same geometry as the terrain tiles (32x32 @ 1m resolution), this is not fine enough to use the sort of granular splatting you'd need (ie with a hi-res blend map).
I finally got one of the profilers working and to my utter astonishment, it didn't leak any memory. But in order to get my application working with the profiler, I had to fix the error it was giving me about the Microsoft Application Verifier. I tried virtually everything to remove/uninstall the Application Verifier, even manually removing references to it from the registry (backing up first of course) and deleting the exe from the Windows\System32 and SysWOW64 folders. That still didn't work.
I then, by pure chance, stumbled across a thread on a forum that mentioned there was an area in the registry which lists image file execution options for applications with which to start the Application Verifier, my editor was in there but my game was not. When I removed the entry for my editor from that list, the profiler started working and I'm back to running my app standalone with 8192x8192 terrain in under 800MB as expected. Quite an obscure one!!
As usual, thanks a lot to everyone for all your great help and advice
After a bit more tinkering, I think this might have something to do with running the engine from within Visual Studio. Built in Release mode and running the exe as a standalone app (in full screen mode), there are no spikes, everything is smooth. Running the same exe within Visual Studio causes the spikes.
I do a similar style terrain to what you're proposing. I stitch terrain patches with different lods together in the vertex shader by simply moving the edge-in-question vertices of the higher LOD patch to match those of the lower LOD patch. Performance is great.
I have made one or two posts on the subject on this forum a few years ago, I'll see if I can dig them out
This is essentially two 8192x8192 renders each frame (along with the rest of the scene of course). It works ok but does slow things down a bit.
Would it be straightforward to skip the copy operation, and just ping-pong between a pair of pre-allocated textures? Binding the second texture ought to be a lot cheaper than copying it first, seeing as you'd save half your fill-rate.
Took me a few seconds to work out what you meant there, but implemented that this morning and it worked perfectly, saving half my operation time. Brilliant idea, thank you Swiftcoder.
It only took 10 minutes to implement too, double whammy..!
I can see this 'confusion' from both sides. L.Spiro, with respect, you seem to get frustrated quite quickly - your posts are obviously useful and you are clearly a very experienced and talented developer, but ranting and being sarcastic/condescending and telling people they are wrong and you are right is no fun for anyone to read, especially, I expect, the OP.
OP, your method of fixed distance shadow map cascades does of course work, I've done it myself with good results, but I think as someone pointed out, you need to render your shadow map(s) to a render target to see why you're getting such low resolution. As someone mentioned, you'll probably find that your house appears, in the first shadow map, too small and so you need to more tightly encompass the light frustum around the object(s)/house for each cascade. When your close up objects appear small in the first cascade, you should be able to envisage that any reference to the shadow map texels used in the final image are going to be big, hence your 'jaggies'. Shadow map texels is the key here.
Before changing your method to use Hodgman's, which of course will also work, I would also suggest rendering your shadow maps out to check what you're seeing from the light's view and then adjust the light's frustum accordingly to encompass a smaller area on the first cascade, thence making the house render into the shadow map bigger, then the same for the other cascades. Doing this will no doubt, as L.Spiro and Hodgman point out, bring all 3 cascades into the picture regardless of how close you are to the house (unless you're super close like zooming in to one of the window ledges).
Also, I don't actually think your shadow maps look that bad for the method you're using - you will get finer resolution for the same viewpoint using Hodgman's method because in your image, your camera isn't that close to the house so a tighter frustum on your first cascade using a fixed distance will probably not even be used (nothing is close enough to the camera).
Most importantly, let's all get along and be nice to each other - that's half the reason this website is the best forum for game dev.
I did some profiling, switched over to using a pool of textures and I still had stuttering. Then I had a look at my surface locking code and realised I was not supplying any flags to LockRect. Passing D3DLOCK_DISCARD has fixed the issue.
I'm not entirely sure why this has fixed it but I'm back to smooth rendering.
Thanks again for all your thoughts and ideas, much appreciated.
I'm not 100% sure of why, but it appeared that my local shader objects were being somehow shared as both views were using the same underlying renderer. In theory this should have worked with one renderer but clearly it doesn't so I'll need to do some refactoring and give each view its own renderer instead of sharing it - but very happy to see two perfectly rendered views side by side!
I'm using newtons laws in my snowboarding game to move my character down the slopes. I've considered using a physics engine but I don't I need that just yet.
To compute acceleration and therefore velocity, I'm using the standard slope calc:
Acc = grav * sin(theta)
I then add or subtract the friction x force normal calc (mu * grav * cos(theta)) depending on whether the character is going down a slope or up. At the moment, the slope is calculated along the edge of the snowboard so it doesn't matter which way it is facing, it's either going down a slope with positive acceleration or up a slope with negative acceleration.
I've cancelled out mass here, theta is the angle of the slope with reference to the ground plane and mu is the coefficient for friction - I've currently got that at 0.2
This looks like it works quite nicely, when the character is moving down a slope, I increase the velocity by the acceleration by my delta time and it appears pretty natural. The only point it looks a little unnatural is when the character is travelling pretty fast down a slope that faces another opposite slope. He almost goes the same height as it came from on the upward slope and I wouldn't expect this. I would have thought that he would slow down a lot quicker.
So my question is am I calculating this correctly? Is it enough to apply negative acceleration and negative friction or should I be applying some further force when slowing the character going up an incline from kinetic energy?