Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Oct 2007
Offline Last Active Dec 29 2015 02:24 AM

#5264346 Drawing exposed rocks in a snowy mountain scene

Posted by on 30 November 2015 - 08:00 PM

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).


#5260317 Who ate all the memory?

Posted by on 03 November 2015 - 08:27 AM

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

#5256222 Big frame time spike when moving camera

Posted by on 08 October 2015 - 09:42 AM

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.

#5248063 Terrain LOD

Posted by on 21 August 2015 - 10:01 AM

Thank you, i am very interested by the approach.


Here you go:




Happy to explain any of it if you get stuck, although it's been a while...

#5247952 Terrain LOD

Posted by on 20 August 2015 - 04:32 PM

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

#5227249 Smoothing large terrains

Posted by on 05 May 2015 - 01:28 AM

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.

Got it.
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..!

#5218111 Shadow maps flickering when light moves

Posted by on 21 March 2015 - 01:03 PM


#5212739 Is it time to upgrade to Dx11?

Posted by on 24 February 2015 - 11:49 AM

No apology necessary, but do play nice - it didn't feel like GF was trying to state facts, it felt like an opinion to me.

Either way, all's well that ends well - I'm holding off for a bit but writing it with future changes in mind - it shouldn't be too difficult.

#5210526 Heightfield Normals

Posted by on 13 February 2015 - 01:02 PM

If you're talking about the slight diamond-shaped anomalies, that's normal for that type of terrain tile - you can hide it pretty well when you start texturing the terrain.

I've never been able to get rid of that effect.

#5209586 Cascaded Shadow Maps Look Bad

Posted by on 09 February 2015 - 07:57 AM

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.

#5208473 Render To Texture without depth

Posted by on 03 February 2015 - 03:59 PM

Think I've fixed this by setting the depth stencil surface to NULL and then setting it back again afterwards - seems to work

#5208018 Terrain sculpting

Posted by on 01 February 2015 - 05:08 AM

I am, of course, assuming you can use a vertex texture (floating point texture) as a render target...

#5203757 Streaming causing render glitches

Posted by on 12 January 2015 - 02:51 PM

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.

#5200545 Swap chain rendering to multiple views

Posted by on 29 December 2014 - 08:19 AM

I've just fixed this.

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!

Thanks again

#5196443 Slope physics

Posted by on 05 December 2014 - 09:11 AM

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?