Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Feb 2009
Offline Last Active Jun 25 2013 09:35 AM

Posts I've Made

In Topic: Shadow Mapping: Understanding Orthographic Projection

04 June 2013 - 05:13 PM

The lookat is exactly as it says...the position that a light/camera/object is looking at. It is used to create the forward vector of the objectss orthonormal basis. this, combined with an up vector, can give a compete rotation matrix that defines how the object is oriented. Coupled with the objects position position, you can give a transform that equates to that objects world matrix. The ortho projection should not change from frame to frame, only when the parameters of that projection change. This is the whole point of separate view and projection transfoms. The light "view matrix" is used to get what the light "sees" and the projection describes how it is to be projected onto the shadow map.

Yeah after some trial and error got it working, basically i provide the player position as the camera position and the player position + light direction as the lookat vector so the shadow maps follows the player, i have a bug related with the moment each thing is update making the shadow jitter a bit but is something i have to investigate.


Thanks anyway 

In Topic: Shadow Mapping: Understanding Orthographic Projection

22 May 2013 - 04:11 PM

Take a point whose view space coordinates are (x, y, z).
If you create an orthographic projection matrix with the parameters buildProjectionMatrixOrthoLH(200, 100, 0, 50), the point will only be visible if its coordinates in view space are within the following ranges:
-100 <= x <= 100
-50 <= y <= 50
0 <= z <= 50
(I'm not sure if the comparisons should be < or <= but its isn't important).
Basically, the parameters are used to build a box centered in front of the camera, it the vertices (in view position) are only visible if they're inside the box.
And yes you need a light view matrix.
If some geometry is not casting shadows increase the width, height and zfar of the projection matrix.
Since directional lights don't have a position. You should create the light view matrix (used to created the shadow map) every frame based on the camera position:
//Calculate a position used in the view matrix for this frame
//Tweak backupDist for your game
lightPosition = cameraPosition - (lightDirection*backupDist) 
lightViewMatrix = createViewMatrix(lightPosition, lightDirection, ...)
This way geometry around the camera will always cast shadows.
There's an error in your math:
M[14] should be:
M[14] = (T)(-zNear/(zFar-zNear));


(As you can see at the bottom of this page)




Thank you for the answer, this helped me to clear out the projection part, i guess i would have to construct the ortho projection every frame based on the user camera frustum so the ortho camera always "gets" the area visible by the player.


I still dont know how the view matrix on this case works, do i need to set te position of the camera in the "center" of the frustum bbox? what about the LookAt vector? Honestly i never got the idea of what exactly does the view matrix and how the LookAt vector works (its an absolute position? can it be a normalized direction vector?)


About the bug, well i didnt wrote the library as it was taken from the Irrlicht engine, i will report the bug to them



In Topic: Octrees: Precomputed visibility and rendering approach

19 April 2013 - 11:58 AM

I suggest splitting your static data on node boundaries after you have your visibility graph, since this allows you to associate data with nodes of your tree partition. Then you just draw the static geometry associated with that node if the node is visible. If you have instanced geometry in a node, you can just conservatively make the whole object visible - just be sure to do a scoreboard/mailbox check so that you don't draw it once for each visible node it intersects. You may want to do the same for non-instanced geometry if your subdivision is very fine and results in a lot of splits (since this will result in more draw calls).

For dynamic objects, you can easily (via a hierarchical test) figure out which nodes it intersects, and if it intersects a visible node, then it is treated as visible.

BTW, How do you intend to compute the PVS for the nodes? (which approach/algorithm - it's a difficult problem)

For best results, I suggest a general axially aligned BSP tree, since you ideally want to keep your leaf nodes cubic.


Thank you for the answer, the AA BSP Tree might be a good idea.


I already thought about how to filter dynamic objects just in the same way you said, basically each entity would know in which cell its located so the entity knows what's visible (useful for IA), same as player basically.


My idea to compute the PVS was to go raycast from each cube corner to all the other cubes, main problem with this is that it will be really expensive based on the fact that each cube have 8 childs, i was thinking to just raycast to the "bigger" cubes (either by area or polygon count) this way i would be able to still skip rendering of hidden geometry and not take ages to compute the visibility.