mast4as

Members
  • Content count

    7
  • Joined

  • Last visited

Community Reputation

124 Neutral

About mast4as

  • Rank
    Newbie
  1. I think this is the information you are looking for: http://scratchapixel.com/lessons/3d-advanced-lessons/perspective-and-orthographic-projection-matrix/ and http://scratchapixel.com/lessons/3d-basic-lessons/lesson-6-rays-cameras-and-images/standard-coordinate-systems/
  2. mesh versus entity in frustum

    However when I was saying "breaking it up into chances" you can do this in the engine at render time. You can insert the polygons in the cells of your mesh (insert polygon only once) and then display the content of the cell in the cell boundaries (min and max) are contained in the frustum. This way, you don't need to go back to modeling and you can just use a simple grid as a start to do that. It might use a bit of memory and it will take some time to construct the grid (and find optimal settings for the size of the grid, etc.) but it might be simple and fun implementing the technique and see what you gain out of it.
  3. Kevin by talking to the guys today I realised I made a mistake in my explanation. I amended the post above. Sorry about that. Please, if you find the time go through it again. You say you use column-major rather than row-major. The explanation I gave works for row-major so technically you will need to transpose the matrix. If other words for column major your matrix should be written with the basis vectors vertically:    |Rx Ux Fx| M =|Ry Uy Fy| if you use column-major    |Rz Uz Fz| Them matrix mult should be written as         |Rx Ux Fx|   |Vx| M * V = |Ry Uy Fy| * |Vy|         |Rz Uz Fz|   |Vz| For the right- left-hand naming convention I would also have a look at this page: http://scratchapixel.com/lessons/3d-basic-lessons/lesson-4-geometry/math-operations-on-points-and-vectors/ Now from my understanding, there's a lot of people out there using different names for the same thing which is very confusing. That's why I like to refer to this page and try to stick to their convention which seems to be following some of the industry standards. Hopefully what's in their website is accurate and reliable ;-)
  4. mesh versus entity in frustum

    If you mesh is only one big chunk you can break it using some of sort of spatial subdivision scheme a little bit like what the REYES algorithm does (it's not exactly the same but you can get inspire by the concept).
  5. mesh versus entity in frustum

    Are you talking about whether drawing your mesh if it's contained in the frustum (or straddling it). Generally checking if the object's bounding box is completely outside the frustum is already a good start and will certainly provide some level of optimisation. You might gain little from implementing a more complex intersection routine than that. However it all depends of the complexity of the geometry contained in the bbox. For instance if you render a terrain, a large part of the terrain might be outside the frustum but if it's part of a single mesh then you don't have a choice to discard the invisible bits. You need to be sure for large meshes that they are split into smaller bits (of reasonable size) organised eventually as a hierarchy, and then you can easily discard the individual pieces which are outside the frustum. If you choose this strategy, a lot of the objects will be culled and the drawing objects straddling on the frustrum's boundaries is probably okay...
  6. Ray-AABB collision detection

    You can find some information about the ray-box algorithm at this location:   http://scratchapixel.com/lessons/3d-basic-lessons/lesson-7-intersecting-simple-shapes/ray-box-intersection/   As mentioned by other people, don't print stuff out from your program. It will significantly slow things down (printf, std::cout <<, etc.).   To accelerate your code if you really need speed up you can use SSE instructions.
  7. Hi Kevin, I hope I am not too late to help you with your problem/question. You did right to watch on scratchapixel but you should look at this page in particular: http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-4-geometry/conventions-again-row-major-vs-column-major-vector/ Basically knowing whether you use a right or left hand coordinate system is indeed important but in fact, in that particular case, it has little to do with whether you matrix is correct or not. What is important for constructing your matrix from the 3 vectors (up, right, forward) is whether you renderer uses row- or column-major notation for matrices. As mentioned in the page above if you use the row-major notation, your 3 vectors should be written vertically in the matrix and if you use column-major they should be written horizontally. In other words, assuming you have the vectors A B C (representing the right, top and forward vector from your camera coordinate system) you should write: Ax Bx Cx Ay By Cy Az Bz Cz If you use row-major notation. Now I will explain you why (there's a way an easy of checking how you should write the matrix if you can't remember it by heart). Remember that if you use row-major vector then the vector-matrix multiplication needs to be written as:            |Ax Ay Az| V[x y z] M |Bx By Bz| [EDITED: changed from original post]            |Cx Cy Cz| Where A is Right Vector, B is Up Vector and C is Forward Vector Computing the multiplication can be done like that: V'x = Vx * Ax + Vy * Bx + Vz * Cx V'y = Vx * Ay + Vy * By + Vz * Cy [EDITED: changed from original post] V'z = Vx * Az + Vy * Bz + Vz * Cz EDITED FROM HERE: I guess I was a bit too quick yesterday when I replied and my demonstration was actually wrong. Talking to the guys from work, they showed me a better way of checking that this is the right way of writing the matrix if you use a row-major notation for matrices. The default cartesian coordinate system should be like that:    Y (up 0, 1, 0)    ^    |    |----> X (right 1, 0, 0)   /  / Z (forward 1, 0, 0) If you have a camera you would be looking down the z-axis. Now you can imagine that your camera is looking down the x-axis. Therefore the right vector for this camera becomes (0, 0, -1), the Up vector is still (0, 1, 0) and the Forward vector becomes the x-axis (1, 0, 0): Up Right  ^  /      \  | /        \  |/----> Fwd > camera             /            / Now if you right these vectors as a matrix you get:     |Rx Ry Rz|   |0 0 -1| M = |Ux Uy Yz| = |0 1 0|     |Fx Fy Fz|   |1 0 0| This matrix is called the camera-to-world matrix. The demonstration to check that this is correct is a bit complicated so I thought I would first quickly correct my original post to avoid leading you and other people on the wrong track. I will post the demonstration later today. Sorry for having (probably) confused you (even more). Anyway, bottom line is that if you use row-major notation for your vectors and matrices (and assuming a right-hand coordinate system) as you mentioned, then this is the "proper" way of writing the camera-to-world matrix from the right, up and fwd vector. One tip though. I am always (and I proved it) myself very confused about these things. I found scratchapixel very useful but I am also often using Maya to check the accuracy of my code. For instance in that case, you can create a default camera, rotate it around the y-axis by 90 degrees CCW, and check the resulting world matrix with the following mel code: getAttr camera.worldMatrix; Because Maya uses row-major and uses the right hand coordinate system, if you use the same standard, then the result you get should mach your code and what you use.