Ray test mouse picking step size

[SilverWarior]

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.

[Thyandyr]

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

[Chebmaster]

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.

[User137]

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.