How do you check collision ?

Hi,

regarding this old 2009 post #5 and subsequent #6. Today, how would you check for collision between a 3d triangle (poly) and other geometry (triangle, quad or box) ?
( 20 ~ 100+ entity, 60fps)

Hi Sebastian,

I remember those times, I started working on collision library, but then I decided it was not good idea to bloat TBGL further.

As of today, I think it would be the best to create dedicated collision module - or #compiled booster at least.


Petr

Quote:

---

Originally Posted by Petr Schreiber

As of today, I think it would be the best to create dedicated collision module - or #compiled booster at least.

---

can't this be done by the gpu ?

Hi DirectuX
there is a collision engine posted here some time ago, the 2 examples are for cubes, but the *.inc file contains a sphere and other shapes, i haven't checked it more
https://www.thinbasic.com/community/...rcial-license)
here is a one week link
http://wikisend.com/download/996384/TB_TrueAxis.zip

edit: i checked the package with virusTotal and it is fully clean.
edit2: don't know if you know about xord3d (abandonware) , since i have posted here http://www.thinbasic.com/community/s...l-with-physics in a mediafire link a full package containing a spiral and a knot and when you press 'W' you see the meshes in wire mode and there is a sphere rolling inside the tubes. a collision between the sphere and inside the tubes.

Quote:

---

can't this be done by the gpu ?

---

Sure, what I wrote does not contradict that :) Both module and #compiled can use for example OpenCL or Vulkan. But I would suggest to make it optional - the presence of support for both technologies is not guaranteed on non-gaming rigs.


Petr

Hi,

@Primo, thanks, I'll have a look soon !
@Petr, remember about ArrayFire ? It comes with a CPU fallback too !

Well,

• I like the idea of not reinventing the well. A library can be nice, Primo suggested XORS 3d or TrueAxis. There is also a Thinbasic sub-forum for ODE - Open Dynamics Engine (but ... ? ) and this : TBCDL Collision Dection Library (but ... ?). There are many others on the web ncollide , FCL (I like this part: No special topological constraints (...) required for input models all that is necessary is a list of the model's triangles), reactphysics3d.
  
• I like too the idea of a dedicated collision module "thinBasic crafted" and opensourced

For the context of this thread : I was looking for a light answer, more of a thinBasic & TBGL dialect. So: both of the previous suggestions, despite being attractive, are of excessive power. Therefore, I'll try with TBGL_PointInside3D and overlapping %TBGL_OBJ_CUBE shapes and if it gives nothing good, I'll keep my idea for later.



For the subject of a collision module, I think this should not be launched savagely but rather with community's needs or not discussion and weighted according to the time resources each will be willing to share for such project. Thinking further on that, I don't think I am willing to engage in a big work on this yet.

Quote:

---

or #compiled booster at least.

---

Would this be pertinent, compared to a (very) light module ?



What I think a collision module should be able. (Please discuss this) That's a quick thought. Do you think these 4 functionality would suffice to extend to all other collision-only functionality ?

Something near to TBGL_PointInside3D but working with lists.

1. Input n lists of triangles.
   Return which triangle of which list intersects with which other triangles of which list (including self)
2. Input n lists of triangles as closed volumes
   Input n₂ lists of 3D points
   Return which point of which list is inside which volume.
3. Input n lists of triangles as surfaces
   Input n₂ lists of 3D points as lines
   Return which segment of which list crosses which triangle.
4. Possibly return shortest distance between each lists

Hi,

I also think using already existing library/technology is wise. The benefit of creating something from scratch has high educational value, but from practical point of view, thinBasic include file with declares for already existing solution (prefferably "in active development") would make most sense :)

As for #compiled approach - again, it would have great educational value, could reveal some challenging parts of thinBASIC/FreeBASIC interop. That would be the main and primary benefit.

If one needs something to get the job done for a specific project, we really should look at already existing, actively maintained library and make it accessible from TB.


Petr