Hello.
I see that JME has rather narrow Collidable implementation (interface), supported by Ray, BoundingVolume and Triangle, and not much else.
While I guess I could do all my collision through a physics engine my game doesn’t actually need any kind of physics just a collision detection between simple 3d objects like box, sphere, ray, line, line segment and such. Pure math calculations allows much faster optimizations by restricting your objects more.
Has anyone implemented in their game more collision detection? I would like to use and improve on it. Collision detection (intersection), containment (object inside another) and such. I’ve already have some code for 2d geometry if anybody needs it (Rectangle, Circle, Line, LineSegment, Polygon).
I’m curious what you plan to do with those collisions.
The reason I ask is that 50% of a physics engine is collision detection and the other 50% is collision resolution. (And if you are wondering about where the integration happens that’s so relatively simple in comparison that it does not deserve its own percentage. ;))
Unless it’s axis-aligned, the box is going to be your hardest shape to handle. Sphere, ray, line, and line segment are relatively easy.
I’m pretty sure you could just use the collision part of JME’s bullet.
Yeah, I suggest using bullet for the collision, just put kinematic rigidbodies to your spatials and perform rayTests and sweepTests
I don’t understand what you’re asking. We support collision between all the shapes you mentioned. Ray, bounding volume, and triangle which means you can do box vs. ray or sphere vs. mesh/spatial. The only thing you can’t do is triangle vs. triangle, as that sort of collision is rarely used in games, it has not been implemented.
@momoko_fan
Yeah it’s great that collision between meshes is supported, but for example I want to put invisible walls and test against them. Since they’re invisible, they could be represented only with a single Rectangle instance. No need for adding them to the scene and computing meshes and their triangles. I’m asking for collision support directly on those classes, like Rectangle, Sphere, Line, LineSegment… and so on. You could do:
[java]CollisionResult result = rectangle.intersects(rectangleOther);
CollisionResult result = line.intersects(someSphere);[/java]
I’m also asking for detection of one volume inside another another, that would be also neat to have.
Collision this way would also be as fast as possible, mostly solving math equations of 3d objects, and you could easily optimize by extending and overwriting the intersect() with your own code if you have additional restrictions on the objects.
@pspeed
I was really trying to avoid physics engine as I only need collision with walls and with objects represented with a sphere (so far…). My approach to most things is to keep it simple and direct, and I don’t need gravity, push/pull, rolling, applying forces to dynamic objects or anything near that.
In meantime I tried physics engine and didn’t have much luck (see questions here)… so yeah using engine is great but you must learn all about it and setup everything, … basically I want to say using the physics engine seems to be overkill for I want.
I wont give up on physics engine now, but still I would prefer pure math collision if it was available.
So if anyone out there has the same idea as me, contact me and we can start with implementation 
p.s. please take a look at my physics engine problems also
So you want collision with 2D shapes? I still don’t understand what your problem is with the jME3 collision system since you can do exactly what you wrote in the code with any of the 3D shapes included in jME3. Also what is the use for containment checking instead of intersection? Do you have a particular use case in mind?
@Momoko_Fan
Yes I want collision for 2d shapes, for example LineSegment vs Rectangle to check if bullet hits the wall.
@Momoko_Fan said:
you can do exactly what you wrote in the code with any of the 3D shapes included in jME3.
If by that you mean sphere vs box.. then yes. Butt those are only two 3d objects. I would like to see:
cylinder vs cube
pyramid vs sphere
frostum vs cube (haven't really checked if it exists but I assume it must somewhere for culling stuff off camera)
.. and so on
@Momoko_Fan said:
Also what is the use for containment checking instead of intersection? Do you have a particular use case in mind?
for example to check if player is in an area to trigger something if he is. There are so many possible examples.
And to further clarify for you, when you speak of “boxes” you mean non-axis aligned boxes. That’s the real trick.
This is not simple stuff. Even physics engines struggle with this to some degree.
yeah, not axis aligned boxes also. That would be the hardest part, but if everything was easy anybody could do it
A possible solution for the problem is to pick the collision variables, import then to another script (built in C, that probably have a better number precision than Java) and the script send back the results to you (numerically, what EXACTLY is going to happen to the object). Not sure if JME can use this resource, just and idea …
@franciscobudaszewskizanatta said:
A possible solution for the problem is to pick the collision variables, import then to another script (built in C, that probably have a better number precision than Java) and the script send back the results to you (numerically, what EXACTLY is going to happen to the object). Not sure if JME can use this resource, just and idea ...
:? Why detour over C? It doesn't have "better number precision", the precision depends on the data type in both languages.
Well why not simply use the jme bullet stuff? It even supports with gimpact triangle vs triangle. Also it is faster than aything you will come up with in several years.
You can also try to adapt your problem to the resources that are offered. Just saying.
@normen said:
:? Why detour over C? It doesn't have "better number precision", the precision depends on the data type in both languages.
The only difference is the presence of unsigned integers...not that they ever really have much practical significance...and entirely useless when dealing with floating point values...
@zarch said:
The only difference is the presence of unsigned integers...not that they ever really have much practical significance...and entirely useless when dealing with floating point values...
Heh, okay but I don't really think of unsigned integers first when I hear "better number precision" ;)
I don’t think it’s what he was thinking of either.
There are some really weird misconceptions about Java floating around.
@normen said:
Heh, okay but I don't really think of unsigned integers first when I hear "better number precision" ;)
No, It's the exact same precision but just a different range. You can simulate unsigned int just by adding everything to the median.
re: precision, in fact, built into Java is much higher precision than anything you get by default with C. BigDecimal and BigInteger can handle any precision. And even Java longs are 64 bit and ints are 32 bit... which is better than C which longs are generally 32 bit and int size used to vary with architecture. C/C++ actually specifies no specific sizes, just minimum guidelines. I shed a small tear of happiness when I no longer had to write things like sizeof(int).
Well inc you can force precision on datatypes when using a good compiler, like force the use of cairo integer 128bit
He’ll use 12 bytes long double, gonna find collisions at the molecule level. This is an important thread!!
I am actually working on a similar thing (but very passively). It’s a system to divide the world up into non-rectangular, non-overlapping sections by connecting points, then check which zone a coordinate (or object or w/e) is in. The idea is to add “collisions” by assigning each zone an integer value (0 means not accessible, 1 means movement is slow, 2 means it’s less slow etc.). It could be used to make solid walls and stuff without using physics I guess.
Generally it will be used to assign stuff to zones, you could say, but without having to use strictly rectangular ones. The zone numbers could determine what ambient sounds to play as well, etc. doesn’t have to be movement related.
I think I’m gonna rasterize the zones to make search algorithms more efficient tho, so it is probably not useful for your kind of fine grain stuff.