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

Topics I've Started

Drawing exposed rocks in a snowy mountain scene

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


Aligning gizmo orientation with screen

11 November 2015 - 12:44 PM

I have a 'gizmo' in my level editor which I use to rotate, translate and scale objects.  The gizmo is just a mesh which has 3 arrows pointing along each axis, you can hover over and click on the arrows to move, translate etc - standard stuff.  The gizmo is drawn at the same position as the object it is targeting but is a set distance away from the camera so however near or far the object is, the gizmo stays the same size.  This all works fine.

What I'm trying to do now is offer local, world and screen coordinate systems for rotating, translating, etc.  local was simple.  I basically borrow the world matrix from the targeted object (the thing we're rotating) - removing the scale.  For world, even simpler as there's no rotation at all so it's just an identity matrix set to the position of the targeted object (again set at a certain distance away from the camera).


Screen space is causing me lots of headaches.  My train of thought was that I would use the inverse view projection matrix of the camera which will effectively remove what will be added at the rendering stage leaving the object oriented in alignment with the screen.  This does work to a certain extent, the orientation of the gizmo stays in the right position inside the object and in an orientation aligned with the screen no matter where my camera is situated.  The problem is, the view projection matrix intrinsically contains scale (for perspective) which causes my gizmo to get smaller the further away from the object I am - even though the position of the gizmo is still that set distance away from the camera.


I've tried lots of different methods of removing scale but it always messes up the rendering of the gizmo.  Is there a better way or a step I'm missing?

Rendering to a region of a texture

07 November 2015 - 04:59 AM

Is it possible to do this in direct X 9? I'm rendering to a very large texture but I only want to update a relatively small region of it. Seems wasteful to render the whole thing?

Rendering to a region of a texture

07 November 2015 - 04:58 AM

Is it possible to do this in direct X 9? I'm rendering to a very large texture but I only want to update a relatively small region of it. Seems wasteful to render the whole thing?

Who ate all the memory?

02 November 2015 - 11:45 AM

Does anyone know if there are any caveats or gotchas when allocating lots of heap memory in a native c++ dll from c# via C++/CLI?  Running my game editor (in release mode outside the debugger) seems to chew up close to 5GB for my 8192x8192 terrain.  When running the game, which is an all-native exe loading the native engine as a dll the same terrain uses around 500MB which is as I'd expect.


The 8192x8192 at the lowest quadtree level creates 65536 patch objects which are (currently) around 272 bytes each (approximately 18MB in total).  At the moment I'm not reserving this upfront so I'm wondering whether c# is forcing the native library to align the allocations to a much bigger order.  I'm a bit unclear as to why that would happen but it's the only thing I can think of at the moment.  Seems odd that it only uses 500MB when run in full native mode.