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

Posts I've Made

In Topic: Drawing exposed rocks in a snowy mountain scene

03 December 2015 - 01:10 PM

Managed to get a really nice and natural effect using a bit of dot and normal trickery.  The good thing is that when you get further away from the rocks and the LOD changes, the material also changes to one without normals and at a distance it you can't distinguish it from it's close-up counterpart - just the effect I was looking for!



In Topic: Drawing exposed rocks in a snowy mountain scene

01 December 2015 - 07:16 AM

How much work are you willing to put in? Virtualized textures for terrain are fairly well documented at this point, but still not the easiest thing to do. Would give you all the resolution you could want though.


Rocks could be fine, depending on how many there are. If they're the same, or a few groups of the same mesh you could batch them to reduce draw calls. But if your view distance is high enough they'll start to overlap and drag performance down. Then again, is your game top down? If it generally is you might be able to get away with a bunch of rock meshes better.

Thanks.  I'm willing to put in as much as it takes to make it look convincing.  I hadn't thought of virtualized textures so that's an idea but I'm not sure that it would be worth its quality seeing as most of the mountain will be white.  It's a third person game.  Also, rocks at far away distances would use the low-resolution parts of the virtualized texture so unless I get it just right, I think it would perhaps suffer from the same granularity issue as using my lo-res surface textures.


On a side note, if you draw a rock mesh at a distance and it overlaps another mesh, does that cause an actual degradation in performance for another reason other than it just meaning you're drawing pixels two/three/multiple times?

In Topic: Aligning gizmo orientation with screen

12 November 2015 - 05:12 AM

Simply create the look at matrix like that (from, to, up) or hardcode directly the matrix to avoid to transpose :

CMatrix4 LookAtMatrix;
LookAtMatrix.LookAt( CVector3( 0.0f, 0.0f, 0.0f ), Camera->GetForwardVector(), Camera->GetUpVector() );

The transposed of this look at matrix is then the gizmo rotation, it's always face to the camera.

Then you simply compute the intersection of a plane using forward of the camera as normal, this will gives you the delta for the translation.

I don't have this mode in my editor, I only allow local space and world space, it's common in all game engine.

You can see a screenshot of my actual gizmo here : http://zupimages.net/up/15/46/r5q8.png

The center sphere is the screen space mode, in local space or world space.


Hi, thanks for the response


I did try that and whilst it does align the rotation with the screen when the object is in the centre of the screen, you still end up with perspective skewing when you move the camera:






The first image shows the object selected whilst in the centre, and the second shows the camera moved to the side.  Although the rotation of the gizmo is correct, the perspective of the camera is skewing the gizmo.  Should I be rendering the widgets using an ortho projection?

In Topic: Rendering to a region of a texture

09 November 2015 - 04:15 AM

Thanks everyone, after some testing I went with rendering a smaller quad against the large texture, works great.


Also, I didn't intentionally double-post, I initially posted it and gamedev reported an error twice.  After I checked to see if it had gone through despite the error [both times] and it hadn't, I tried again.  I'm a regular on this site with a lot of posts so I can't really understand why anyone would assume I had double-posted intentionally.


I also received a warning about it from a mod - not appreciated at all after contributing to the site financially and it being gamedev's fault.  *shakes head faster than finger*

In Topic: Rendering to a region of a texture

07 November 2015 - 05:32 AM

Yes, that's what the Viewport state does.


Thanks, I did some googling but couldn't find anything obvious - I was wrongly looking for locking