Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Oct 2007
Offline Last Active Oct 10 2015 02:35 PM

Topics I've Started

Big frame time spike when moving camera

08 October 2015 - 08:29 AM

I've previously been accused of early optimisation in the game development cycle.  It might feel like I'm doing something like that here, but this is really confusing me and perhaps I'm missing something obvious...


As a test, my engine is running with no visible objects, just a keyboard-controller controlling a camera entity.  My camera system update code essentially checks if buttons are down (using KeyDown() at the moment) and moves the camera accordingly, it's all a bit basic at the moment - just so I can move around the world using a keyboard.


When the engine starts, my frame time eventually (after a few seconds) settles on around 0.39-0.41ms.  This is fine, it's not rendering anything, it's just clearing and presenting.  However, when I move the camera position, the frame time shoots up to over 2ms sometimes even higher and stays there until I stop moving.  I'm doing some matrix manipulation to move the camera in the current direction and all that stuff, but that takes a negligible amount of time.  After going through my method commenting out chunks of code until the frame rate stays steady, it turns out that the issue is on one line.


LVec3 position = entity->GetPosition();


// ... matrix manipulation code





I don't want to flood this post with code because I think most of it is irrelevant, but it's the SetPosition line that appears to be causing the frame time spikes.  Take it out and the frame time stays steady, whether moving the camera or not.


I usually use the Control key with AWSD to move, but I removed the Control check so this update method gets called every update cycle (every physics step) and when I'm not moving the camera (i.e. changing the original value passed to SetPosition), the frame rate stays steady even though all the rest of the code is still being called.  It's only when the position value actually changes that the spikes occur.  The position vector is used again after the SetPosition call to determine the lookAt position, so the compiler is not optimising it out.


There is nothing in my entity code to do anything when the position changes:


void SetPosition(LVec3 vec3) { position = vec3; }



Any thoughts on where I can go next with my investigation?  I can't understand why removing that SetPosition line stops the spikes (even though, of course, the camera doesn't physically move with it not there - but the view does change slightly as I'm changing the LookAt).


(Originally, my GetPosition() entity method returned a reference to the position vector to save a copy, but I removed that to simplify.)


Frustratingly, this error is sporadic, after a good 20 seconds or so, I can move around with no spikes but the spikes come back randomly.  It sounds like they might not be linked to the moving code, but after dozens of tests, they definitely are.



WIN32 or WIN64

02 October 2015 - 05:16 AM

I decided to upgrade my game engine (C++, DirectX9.0c) to 64 bit.  I'm not actually even sure which platforms I'm targeting yet, PC to start with and, if it gets anywhere, Xbox one and PS4 - I'm aware of how tricky it can be to get onto these latter platforms.


Is there any reason I shouldn't upgrade to 64bit?

Smoothing terrain heights

29 September 2015 - 10:46 AM

My terrain uses a vertex texture for heights. Because my world texture needs to be 8192x8192, I stream the terrain during normal play which works nicely. At design time, my terrain editing tools allow the user to make very large changes (like raising/lowering) across the entire terrain which means the whole full 8192 x 8192 vertex texture needs to be in the GPU's memory. For raising/lowering, I use a shader which just does an additive vlend to the existing vertex texture but for smoothing, I need to average the surrounding heights which means I need to pass a copy of the vertex texture in when editing in order to access the heights.

Is there a way I can do height smoothing without supplying another 8192x8192x4bytes texture? I'm getting to the limits of GPU memory in my game editor as I also have other 8192 textures loaded like the global normal map (I can't stream this because I'd like to see far away detail - it's a mountain scape). I'm using a geomipmapped terrain so I can't create the normals in the shader as the detail far away would be very lo-res. having lo-res triangles coupled with a hi-res normal map actually makes it look very smooth at distances.

PBR specular BRDF

14 August 2015 - 07:40 AM

I've been doing research on PBR and, not wanting to piggy back the other recent PBR thread, I was wondering if there's a reason why we still need a specular BRDF. If all light comes from what surrounds an object that needs lighting, can we not just include the light that would provide the specular highlight(s) into the environment map? And then in order to achieve roughness we simply have blurred versions of the environment map in the mipmap levels? I don't see why we need the specular computation, it would come for free with the reflection of the light would it?

I know this approach isn't new or anything but I don't understand why we still need to compute a specular highlight.

For metallic materials we use a linear interpolation of the environment map mip levels based on a roughness value and for dielectric materials, we simply blend in the albedo, still using the environment map for reflections albeit just the brighter parts of it.

I may have misunderstood PBR...?

Centered terrain?

11 August 2015 - 10:48 AM

I currently have my terrain positioned at 0,0 extending out to 1024,1024 or bigger - from a floating point accuracy point of view, would it be better to have it centered around 0,0 rather than starting there? My terrain size can be 8192x8192