Idea for new module to support game

[Petr Schreiber]

Hi,

as you know, I work on collision detection right now too, I would like to consult it with you before I will make further steps.
TBGL module is graphic library, I do not want to end with 2 MB DLL doing "everything".

So my idea is to create separate ThinBasic Collision Detection Library to help us with this project, and with those coming in future :)
Unlike TBGL, TBCDL would be kept with open sources available to registered thinBasic users, like Mike's TBEM is.
I would prefer to use PowerBASIC for development.

I attached simple concept in PDF for you, let me know what do you think about it.


Petr

P.S. Don't get scared I come with text only, I have done some coding already

[Michael Hartlef]

That is a nice idea. I'm curious how this will be able to communicate with the TBGL models and entities. IT would be also a good place for some build in physic functionalities.

[ErosOlmi]

Seems great Petr.

I too do not know how you can "bridge" elements from one module to the other but if you have any idea of new interface functions need to the target let me know and I will try to implement.

Ciao
Eros

[ISAWHIM]

I think he is saying that TB will read XYZ (etc) from TBGL or your own data...

You send the object info/type, prior to any "Detection". When a detection is required, you give the (XYZ, PYR)1 and (XYZ, PYR)2, and which detect method you want to check for. It would return a value or BOOL...

That would not be specific to only TBGL, which would allow it for use in say... TBDX, or graphs, or a TB2D...
(As opposed to being forced to create models, just to use the collision detection for another use.)

You just tell it that you want to know if there is a collision of a (diameter 6 sphere), and a (diameter 3 sphere), when they are (distance 41 apart). I think that is what he is suggesting... Possibly with more specific parameters... ByDistanceXY, ByDistanceXYZ, ByXYZ2XYZ (Would calculate distance if you did not know it)...

That would completely have some great gains with multi-threading. Technically, if those values (xyz, pyr) are in memory, a simple value-pass from TB to the module would allow the module to communicate with the other module data. Just as you pass a hWnd value from TB to windows. (ByVal or ByRef for some handles.)

However, for time-based collision, where time is not a constant... Knowing the "Point of collision" on a "Collision path", will be more important than "Have/Did I collided" (Because by then, it is too late. "Have/Did" = Preset/Past tense.) EG, You need to know... "A collision will occur at 3.56 meters.", because if this move is 10 meters, no collision would register on, "Have/Did I collided at 10 meters." (Will I collide between here and there. "Will" = Future tense.)

But that is just a specific. Point of impact would be an added feature that I don't believe GL can perform natively. I think GL only knows when something is in or out of something else.

Could also help with dynamic model building. Knowing that the intersect is at XYZ, could allow you to create surface to surface models, as opposed to point to point, where you have to guess an intersect, or live with simple designs that purposely overlap. (That is how a 3D editor performs a cut-out of a circle from a flat surface, like the old QED "Quake Edit", would use negative and positive space to carve structures out of the intersects of the surfaces, to create a new model.)

Hmm... We might even be able to use this to create our own 3D editor. (Well, a more complex editor.)

[Petr Schreiber]

Hi guys,

I wanted to keep the design usable for cooperation with TBGL, but not limited to. It is just geometry, it does not need to know anything about textures and other graphic things.

I agree with Mike physics would be nice, but to keep in mind my current time resources the ray collision will come first.

So basically as Jason says - you supply data first ( like complete mesh of track ), and then just query if ray at position x,y,z directed in dx, dy, dz collides with something in collision space or not, at which distance...
Cooperation with entities should be usable too, you could link them somehow to their bounding boxes in collision space and just resupply their position and orientation.

So from data traffic point of view - bigger in preparation stage ( to reconstruct scene layout ), but minimal in main game loop ( just queries for rays, or quick sync of moving entity bounding bodies ).

I would not recommend using threads though, I think pointers can do the job of syncing good. Will see.



I think GL only knows when something is in or out of something else.

OpenGL is just graphic library, it provides no collision mechanics... directly ;) Except the selection mode, which is thing I do not like very much as some vendors have problem with it.


Petr

P.S. I got the ray-triangle intersection working today, hurray, I was starting to be pesimistic :)

[ISAWHIM]

Threading will happen on its own... in separate modules (Dll or exe, etc.)

Windows separates into a pseudo-simultaneous thread where there is a dual-core. (That was part of the main issue with the timer-event... you don't get to select which core you are on. You could be time-sliced on one core, or each file operating on separate cores. Thus, both having a separate clock and clock-speed.)

Even simple things which don't require an immediate attention, being passed to that second process, will help simplify some of this code. More-so, if calls can be stacked by passing a whole array of commands at once.

Hehe... Be sure to include the common things...
Distance between points... Sent as an array with more than 2 points, (3 values each), it could tell you the total distance, and distance between each hop. Index #1 being the total, #2 being D1-2, #3being D2-3...etc.
3D_Axyz2Bxyz = SQR(((Ax-Bx)^2)+((Ay-By)^2)+((Az-Bz)^2))
With the 2D version also...
2D_Axyz2Bxyz = SQR(((Ax-Bx)^2)+((Ay-By)^2))

A_Deg2Rad
A_Rad2Deg
3A_Axyz2Bxyz = 3D Angle from point to point...
2A_Axyz2Bxyz = 2D Angle from point to point...

Eg, extending the function of collision-detection module, to also include output of many of the same formulas you will be using inside module for collision-detection. (Ones that we might also use for non-collision.)

[Petr Schreiber]

Hi Jason,

thanks for the suggestions.
The 2D angle functions are already in TBGL, so I am not giving them that much priority for now, but I will keep it in mind.
As I wrote: ray-mesh and ray-box ( maybe ellipsoid ) go first.


Petr

[ISAWHIM]

But the "2D angle" are only in TBGL and it only gives an angle of one item to another.

If we want to use that formula for another program which does not have TBGL... We have to write our own formula.

EG, if I had just made a "Trip Calculator", or some other text/numeric formulation program. I could load only this new module, and ask it what the angle of Axy to Bxy is...

Even if using it with TBGL... If you are using it to decide where to move an object... You want to know the angle of Axy to Bxy, so you can push and turn to a new destination. (If there is no entity there, it can not return an angle, which would be the case if you are going to move an entity where nothing is occupied.)

When you move something, you need to know an angle of the move, and calculate the distance to a location before you tell the object to turn +/-Angle.

In my specific case... I need that formula for angle calculation, for aligning objects to non-object locations. It only makes sense to include the 2D version if the 3D version is going to be there. (It is slower, but the 3D version could be used for the same calculations. But that will make any potential to use an array of data, a burden to the user.)

Using an array of data, for instance, would tell me the angles and associated distances in a distance array with the same numbers. I could use that to make a curved 3D wall using triangles, or whole objects, or to create an invisible path to follow, on a turn.

2A_Axy2Bxy(Ax,Ay,Bx,By) {NORMAL} Output = (42)
2A_Axy2Bxy(MyArray(Ax,Ay,Bx,By,Cx,Cy,Dx,Dy,Ex,Ey),0,0,0) {ARRAY} Output = CSV_STRING("5, 24.85, 21.01, -3.24, 7.24, 0.01, 180.03")

The output of the array would be a CSV, or an array, if that is possible.
1(Number of points processed), 2(A->B), 3(B->C), 4(C->D), 5(D->E), 6(E->A)

The number of points processed would let them know... Hey... I only found five locations in that array, or OMG I found five points in that array... (Depends what they "Think" they sent. How they react to that value.) The value allows them to setup a loop, without having to Ubound, Lbound, or guess how many values are in the array. (We don't always know that there will be 7 cars near point A, we might send 7 or 5 or whatever in a call.

E-A would be a return to complete a full circle... (Assumed, because people might want it, and the processing to do it is less than making a second call or having them put the same values at the end again, to force a loop return of values. If they don't need the 5th angle, they don't use it.)

Or, if it is an array... the other three values could be used for return setup...
(array-val, start-angle, angle-ABS, 180or360)
Start angle would be an offset to all angles returned... (If you were facing -90, that will be added to all positions.)
Angle ABS would return world-angles, not angle +/- from A to B.)
Non-ABS From 0 ({4},30,20,-40,10,{170})
ABS From 0 ({4},30,50,10,20,{180})

Again, that is only "a potential concept"... (Things that would be used in collision detection, prior to making a call for actual collision detection. EG... I need to move a ship on that path... will it collide at those angles/points? Angles are important, to tell you the angles needed to rotate, prior to checking collision. I just send the values from your array, to the detection code of choice.)

Good animation tools for calculation also, when it comes to moving things on pivots, which are usually limited to 2D motion, for simplicity. (Also used for time-segment of motion on a lineXY.)

[Petr Schreiber]

Hi Jason,

now I get it, you are right to keep it multipurpose I should add it too.
Added on TODO.


Petr

[ISAWHIM]

No rush... built like that, (With expansion in mind), you can prepare for it without having it function yet.

Scratch the "Rad2Deg" and "Deg2Rad", I found them in the math stuff...

Actually, those single-commands would be best in the Trig area... But the chained versions would be better in your MODULE. (Since chaining would be more suited to the needs collision assistance and calculation output.)

EG, if I only NEED one XYZ to XYZ, I could use the math... or I could use yours, with just the non-array value passed to it. (Provided that I am already using your module, and I intend to also pass it array values. Which the math module would take repeated calls for, with redundant info... Axyz to Bxyz, then Bxyz to Cxyz, then Cxyz to Dxyz... Three calls and six values, as opposed to one call to yours, with a single array of three values. EG... The module would make it faster, thus, gain even more importance. Plus, you know all that good matrix stuff that I don't understand!)

[Petr Schreiber]

Hi Jason,

thanks for explanations, I like the array approach.
ThinBasic module can have predefined UDTs for vectors and other stuff, so this would make the job even easier.


Petr