Ray Intersect Distance
issueid=120 03-11-2008 05:21
Member
Number of reported issues by ISAWHIM: 11
Ray Intersect Distance
To keep things slightly short and simple... (Two things I am good at. ::) )

In the "Entity World" of TBGL, as opposed to the RAW GL-View. For the "Informational" or as part of the "Collision Detection" area...

I would like to request what I believe is the most basic, (Not simple, just basic.), collision detection item which we would need to process our own collision detection code. (Well, our own code based on the rendered output of the view or the entire "Entity" world.)

{Ray Intersect Distance}, which would be used to check if there is something in the world/view that this "Ray" intersects with.

For example, we would input...
- {XYZ Start} (And)...
- [{XYZ Point} Or {XZ Angle, Y Angle}] (And)...
- {Unit Distance}

That would be used to find anything in the entity-world, along that "Ray", which intersects the ray within that distance. The return value, to be of any use to us, would have to include the distance of the intersection along the ray, or the XYZ location of the intersection, and also the entity/item which the point intersects.

Repeated empty calls would recycle the same values, but ignore the prior entity/item detections.

EG...

If I am a boat, floating on a fixed-horizon, and I want to check collision/intersection with a "Ray" dropped from the front of the boat...

TBGL_RayHit(MyNoseXYZ, DownOnAxisY, BoatDepth, %IntersectDistance)
Returns (IntersectDistance, EntityID)
I see that the distance is not -1, so there is an object present, the object is the WATER, so I call again...

TBGL_RayHit()
Returns (IntersectDistance, EntityID)
I see that this is not -1, but this is a decoration fish, ignore it, and call again (Or kill the fish)

TBGL_RayHit()
Returns (IntersectDistance, EntityID)
I see that this is not -1, and this is a rock... (Stop the boat, a collision is about to happen.)

However... If...
TBGL_RayHit()
Returns (IntersectDistance, EntityID)
If this returns -1, the distance that was set to cast the ray has not produced any more collisions.

These things can not be done by our code, because we don't know the "Space" in which the entity is being drawn, and this would require the GL items to be duplicated in arrays, being calculated side-by-side to match the output/translations of the entity world, for us to calculate. This would also require us to all use the M15 format exactly as you use it, and track which entities are on and off in the world. (Without the speed gains of the GL matrix translations.)

But, if that single item can be translated for us, from the GL world... We can respond to the scenery without duplicating the world through a view-port/rendering that adds undesired overhead, and can provide false and limited information, as undesired elements pass between the camera and the desired target.

Point Inside does not help unless you know where the surface is. It can only help do entity/entity detection of small bodies. (Thinking about the race-track ground surface, and rooms, which we will always be inside.)

For reference, though not the best code for collision... (It is better than a lot of the half-code I see all over.)
http://nehe.gamedev.net/data/lessons....asp?lesson=30
Issue Details
Issue Number 120
Issue Type Feature
Project TBGL
Category Unknown
Status Suggested
Priority Unknown
Suggested Version Unknown
Implemented Version (none)
Votes for this feature 0
Votes against this feature 0
Attachments 0
Assigned Users (none)
Tags (none)




03-11-2008 07:30
Super Moderator
Thank you Jason,

seems reasonable to me ( but I will not add feature of killing fishes :D ).
Sure thing is there will be need to define somehow bounding geometry for entities ( maybe not for primitives like box, sphere ... but definitely for display lists for example ).

I have currently the ray-mesh working and ray-box is work in progress in my test code.
Keep your fingers crossed.


Petr
Reply Reply  

03-11-2008 07:37
Member
The other problem I was having with the camera/viewport technique... Besides overlapped items, and walls/surfaces not rendering due to "Glitches" in the graphics card...

Using the "GetPixelInfo"... one pixel may be composed of many triangles. It may also be composed of a surface that does not exist at the pixels center-ray. (Caught between triangles, right on the border. When you get close enough, the triangles don't actually form a solid joint. That 0.000000000000001 gap allows a ray to pass through it.)

You have a similar issue with small triangles, which GL will not draw, if they are smaller than a pixel. The surrounding triangles that pass through the pixel, determine the pixels color. There is no actual surface under the center of the pixel which we requested the "GetPixelInfo" for. (This is what commonly makes characters "Stuck" in the geometry, at the joints, or on micro-detailed structures.)

This is where "Ray Intersect" would have the advantage. It gives us the ability to check two or more points, three being ideal. The tripod-intersection is what we would use to align objects to the ground-angles. We can also use it raise or lower on a significant slope, without knowing the actual normals of the surfaces we are above. (That normals formula fails when you stand over something shaped like a diamond pattern on a floor. Surface normals can also lead to funny sticking and odd angles or spastic surface following. Like when traveling over stairs or an abrupt incline change.)

It is nearly impossible to get "Stuck" in geometry, because you can simply ignore out-of-range values in a tripod. (If we were bound to GL single line only intersection, and GL control, there would be no resolution for "Sticking", until you code for every possible sticky situation. There are too many to code for, and checking them would destroy the function of GL being fast.)

Going hand in hand with the existing GL functions you have... Follow, GetPointXYZ, Turn, Push, RotateXYZ, SetTarget, Get Closest, etc... we have all we need to give that formula the required entity data. We also have almost all we need, for the more detailed sub-checking, into "Which Vertex", once we get back the distance and object, and possibly the XYZ of the actual intersect (Which we can calculate easy enough, with the data we sent for the "Ray".)

NOTE: Since objects have multiple surfaces... and only the closest surface intersect of each object along the path is important... The function would not return (100,fish) (101,fish) (120,fish) (185,rock) It would only return the next object, first intersect. The XYZ would technically start from the last intersect detection, but without the last object detected in the scene. (100,fish) next call (185,rock). {Fish removed or just ignored}
Reply Reply  

03-11-2008 16:32
Super Moderator
Hi Jason,

I know graphic way is not very precise :)
The functions provided will be based on exact math.


Petr
Reply Reply  

03-11-2008 22:51
Member
I think I may have found a generic way to use that camera/viewport method to do something similar. (Since this requires the entity translations, it has a similar use to your multi-probe car you created for the AI part of the game.)

For now, I am trying to isolate specific "Collision groups", which only uses the desire collision items in the "Special" view, and removes them once found in the view. (Not for actual use in a game, but to show you what might be a possible solution method.)

Right now, it knows "your location", collects any items within 101 units (Using the game-tile size in my sandbox.), places them into a new scene, with the same angles as the game, but without any graphics. When detecting from one entity to another, the entity which the viewport is detecting for, is not drawn, since the polygons don't use faces correctly. Moving the camera inside the object draws the inside of the object. (They render the non-normal face of the polygon, and those should not be rendered.)

As the game-scene changes, the collision scene changes. New found items get created in the scene, and old ones get removed. Existing ones are skipped over, since they already exist in the scene. (The whole point of that is to reduce the number of things to detect in this mini-scene. Mostly those which are not important to the collision group. Fog, emitter particles, 3d missiles, mines... Those last two would use their own detection. Purely math based.)

I am using it to find the "Ground" of the track, but also using it to collide only with solid racers which I may have jumped over, and landed on top of. Only the ray directly below my nose, and the two at my heels are important, forming a tri-pod foot and detection.

My trouble is still the field of view... It sends too many polygons to the screen that are not needed. (Also the inability to set isometric view.) Since I am attempting to make this a "Ray" actually a line, since it stops at the draw-distance... processing anything too far to the left-right-top-bottom is just wasted thinking. But the cool thing about it is... I can actually do an area sweep of angles.

I think I will just wait until your code comes around.
Reply Reply  

04-11-2008 09:20
Super Moderator
Scene system camera FOV setup will come very soon, stay tuned please :)


Petr
Reply Reply  

+ Reply