koobas.hobune.stream
Custom collision detection
I'm trying to make a custom collision detection to get rid of the physics of unity but it doesn't work, it doesn't detect collisions correctly. I'm using sweeptest and sweeptestAll to listen collision around a sphere to a mesh (scene). The goal is to make a character that move along the tangent of the collided surface. However it fails critically at inward curve and at wall obstacle! Typical rigidboy non kinetic collision slow the computer down to a slide show, that is the reason for the custom code (intel atom n455).
What should I do to fix my solution? is there other solution to try?
Here is the current code:
private void UpdateSurfacePosition()
{
Ray//origine, direction
ground_check_ray = new Ray( gameObject.transform.position, -gameObject.transform.up);// * (Momentum.magnitude + 1));
RaycastHit
raycast_result;
Rigidbody
rigid_body = gameObject.rigidbody;
rigid_body.detectCollisions = false;
rigid_body.isKinematic = true;
bool onGround;// =
//Physics.Raycast( ground_check_ray, out raycast_result );//ray, hit
//rigid_body.SweepTest(-gameObject.transform.up, out raycast_result);//direction, hit, distance
raycast_result = new RaycastHit();
RaycastHit[] contacts = rigid_body.SweepTestAll(-gameObject.transform.up);
rigid_body.SweepTest(-gameObject.transform.up, out raycast_result);
if (contacts.Length > 0)
{
onGround = true;
int i=0; while (i != contacts.Length)
{
raycast_result.normal += contacts[i].normal;
i++;
}
raycast_result.normal = raycast_result.normal.normalized;
}
else
{
onGround = false;
}
debug1 = "Normal > " + raycast_result.normal.ToString()
+ " Position > "+ raycast_result.point.ToString()
//+" transform > "+ raycast_result.transform.name.ToString()
+ " Contact > " + contacts.Length
;
if ( onGround )
{
Vector3
next_position;
//UpdateOrientation( gameObject.transform.forward, raycast_result.normal );
UpdateMoveOrientation( gameObject.transform.forward, raycast_result.normal );
next_position = GetNextPosition( raycast_result.point );
rigid_body.MovePosition( next_position );
//ground_direction = raycast_result.normal;
}
else//onAir
{
//if forward close to dot.Y = abs(1) choose -up if 1 and up if -1
UpdateMoveOrientation( gameObject.transform.forward, raycast_result.normal );
}
}
O$$anonymous$$AY it's just that unity can't make any kind of complex gameplay at all, he confuse physics for collision, I just need a good system to resolve collision not to rewrite physX from scratch. No wonder any sane dev avoid unity for AAA. It's cute for some simple game, nothing serious or too complex. I'm glad I haven't bought the expensive useless license ...
You do know that PhysX is Nvidia right and not Unity? If you are building an FPS which for some reason needs very accurate collision detection then yep, PhysX is crap with mesh based colliders due to back face culling and the need for convex meshes if they are to collide with each other.
Well unity choose what they add in their package, it is sold as a kind of ultimate game dev package and yet failed at most basics level. It make sense commercially as it port to multiple platform, but creatively it's a mess.
I'm not trying crazy hard stuff here, 1 single Sphere to scene $$anonymous$$esh is like basic requirement, except: 1 - I'm on a low end machine, not only rigid bodies is crazy expensive but it came with physics stuff I don't need and which fucked up the collision resolution. I have just one scene and one object and it's a slide show! 2 - It fails at a convenience because collision resolution tools are weak and don't provide enough data and have many quirks to find out. You can't even properly write your own collision resolution using primitive tools. 3 - It fails for game because the most important things is collision detection and automatic resolution (not going through wall and object) which unity fail to provide without extra code, and the unnecessary expensive physics is not typical gameplay case. Research show that's the most common problem people have with unity, so it's not an isolate accident. $$anonymous$$ost complain goes to how rigidbody act weird, is expensive and how the character controller is shit. That's like the basic of most actions games! It's sold as a game engine, proper collision handling in the context of game is a very basic requirement!
But it lead to a larger problem with so called collision engine, most coder feel the urge to do a full physics engine that user are quick to try neutralizing. I have yet to see a collision engine that is design for typical gameplay and have things like moving platform just work without extra code. Blitz3D is the closest to my knowledge, it has collision, layer, no physics and handle automatically resolution to prevent overlap, and send you all the data you need like contacts and normal for you to decide gameplay. It does not handle moving platform automatically but that's as close as possible to video games oriented collision engine. Too bad its renderer is obsolete in most modern card.
Now $$anonymous$$aybe there is alternative to unity, Do you know some?
Walking the perimeter of a concave 3D shape is one of the most complex things you can do with physics. Casting in only the character-down direction is unlikely to solve the problem.
Raycast works. Sweeptest works. They do what they say they do, you just need to tell them to do the right thing. Unity has collision layers, physics contact information (from Raycasts and from OnCollision triggers), things don't go through each other unless they're physics-ally impractical objects to begin with (where the problem would appear regardless of engine, and that can be fixed easily on a per-case basis).
Here is a similar question, with a possible solution - Link
I made of a rant for sure, I have been working on this simple thing for 3 years, fighting gimbal lock, quaternion and finally hairy ball ...
In fact I solved the wall hugging problem with a sphere collider with rigidbody at the expense of performance (slide show fps) then try to replicate with casting but I don't have enough precision.
BUT I tried to reuse the same rigidbody back into the code ... and it break, it does not work anymore ...
https://dl.dropboxusercontent.com/u/24530447/flash%20build/litesonicengine/LiteSonicEngine8.html New code with solved control but broken collisions, much simpler strip down code to focus on the main problem of control.
https://dl.dropboxusercontent.com/u/24530447/flash%20build/flash%20sonic/flash%20sonic.html This version has much more advance version but suffer from gimbal locks problems (arrow and mice to control, jump with lmb, try to go inside the tube). In this version collision is really solid, wall hugging works well but have directional discri$$anonymous$$ation for ceiling and wall direction.
If I solved this correctly, and integrate everything in once package, I'll released the controller for everyone with extra goodies (most notably input lock to reverse intelligently control on ceiling, ie when the user is no more holding the move button).
