Results 1 to 7 of 7

Thread: Ray test mouse picking step size

  1. #1

    Ray test mouse picking step size

    To pick what is behind mouse pointer in 3D you get the vector from near plane to far plane and iterate through it in world coordinates and check from world data if anything is supposed to be in those coordinates.

    Assumed we operate in world that has coordinate significance/resolution of full integers.

    In order not to miss any coordinates the vector intercepts (but minimize the amount of iterations), how to determine the step size?

    Is a safe step size 0.5*0.4*0.3? Intuitively it feels that when close to a intersection of different coordinate volumes the significant step size should get infinitely small, or you jump over some corners of slightly intersecting coordinates.

    Inverse of draw canvas pixel size could be a good threshold. One cannot pick more accurately than how many pixels you have available for the mouse pointer to rest on.
    Last edited by Thyandyr; 11-10-2017 at 11:34 AM.

  2. #2
    I don't understand what you mean by steps even, using mouse-ray is not iteration. Usually you would use line-to-triangle intersect, line-to-sphere intersect and so on functions. It's normally not at all about pixels. For that you may be able to do something different, like glReadPixels at cursor's screen coordinates? I don't know, very much depends on what the app needs to do.

  3. #3
    Quote Originally Posted by User137 View Post
    I don't understand what you mean by steps even, using mouse-ray is not iteration. Usually you would use line-to-triangle intersect, line-to-sphere intersect and so on functions. It's normally not at all about pixels. For that you may be able to do something different, like glReadPixels at cursor's screen coordinates? I don't know, very much depends on what the app needs to do.
    A ray from camera that goes through the world coordinate that match the mouse pointer. The vector is normalized for Z.

    How to know which world coordinates this ray traverses through? I iterate the ray from camera towards -Z (openGL), and check if anything is supposed to be in the world coordinate (cube based world), and pick the first match, or end up too far without any match. In practice it works great with steps like 0.5 and 0.3. (Z)

    The question is more of a theoretical nature. If you have a ray (for example close to diagonal) to the world axes, how do you know that you do not skip the narrow corner of a world coordinate. Say the mouse is middle of screen on the right, at 1,0 normalized. The vector could be something like (0.95, 0, -1). The vector crosses world space (0,0,0), (1,0,-1), (2,0,-2) and so forth. But it could/would cut through the corner of space (0,0,-1) before going to (1,0,-1). Iterating with arbitrary step will occasionally miss and hit these corners in unpredictable fashion. No big deal in practice, but it is unwanted behaviour. I'm sure there is some math to do this properly but I don't know of it.
    Last edited by Thyandyr; 16-10-2017 at 09:23 AM.

  4. #4
    Let me see if I understand what you are doing correctly.
    Instead of checking if your ray is intersecting each world cube you have divided your world into multiple planes based on Z axis position and now you are simply checking ray collision with each individual Z plane.
    But you encountered problems when ray can pas through two nearby Z planes without triggering collision and you want to know what distance (steps) you should have between these Z panes in order to prevent that. This could happens because angle of your ray relative to the Z axis is smaller than the angle between two opposite corners of the same cube face which in case of step 1 (distance between two nearby Z planes is same as the size of the cube) would be any angle that is smaller than 45 degrees. In case of step 0.5 it could happen for any angle lower than 22.5. In case of step 0.25 it could happen for any angle lower than 11.25 and so on.

    But this is not how ray-tracing is being done. When doing ray-tracing you are always checking the collision between your ray and every possible collidable object in your world.
    Now since you are working with cube based world you can avoid the need for checking ray collision with every cube in the world by grouping multiple cubes into one larger cube so you first check to see if your ray has collided to this larger cube and only then further check to see if it also collided with any smaller cubes. This approach would be called heuristic collision detection and the data structure that you would use for storing information about your cubes would probably be Octree.

  5. #5
    Quote Originally Posted by SilverWarior View Post
    Instead of checking if your ray is intersecting each world cube you have divided your world into multiple planes based on Z axis position and now you are simply checking ray collision with each individual Z plane.
    I want to check intersection of a vector with world cubes.

    If I was to test every world cube for intersection, it would be more steps than just starting from the camera and traveling along the vector until the first intersection is found. But, it is possible to miss a cube if the ray only intersects with tiny slice of a corner of that cube if the step is too high.

    Anyway don't worry about it. I'll google it.



    Update:

    All the stuff I find is for testing if ray and AABB intersect. That is counter intuitive to me since we do not know which AABB to test for and looping all of them, or even fraction of them would be way too many. I want rather to travel along the ray and see what AABBs are getting intersected, something like Bresenham's line generation but in 3D. But it does take input parameter 'Resolution' so I'm not nuts. In fact:

    For the mathematically challenged (meaning me, until I looked it up), Bresenham's algorithm is a neato and efficient way to enumerate all of (actually "most of") the points between two endpoints.
    So there it is. I want to know how it would return all the points and not just "most of".

    Also, don't worry about it. I'll google it. It's just that keeping a journal helps
    Last edited by Thyandyr; 16-10-2017 at 11:32 PM.

  6. #6
    That is counter intuitive to me since we do not know which AABB to test for and looping all of them, or even fraction of them would be way too many.
    That's why you need a system to organize your bounding boxes into manageable chunks. Octree? Fixed chunks like in Minecraft? Fixed chunks with small octrees inside them? It's up to you.

  7. #7
    You need to ask questions right way. This topic, now if i re-understand it reads: "ray intersection with voxel-terrain". With these terms Google will start giving better results.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •