koobas.hobune.stream
Unity and Raycasting/collision
Is there a limit to the collision detection that can happen between two objects? I have a cube and a ball in a game im working on, controller would be the cube as you move it around and direct the balls trajectory. For some reason when i move the cube too fast it ejects from the cube then goes on its merry way. Ive tried using the new dynamic colliders in unity 3 as well as tried a raycast to stop the ball from leaving the cube. Any insight/input would be appreciated.
Please specify again how your scene is setup. It's not clear how the cube and the sphere are connected and how you make use of the physics engine.
The only limit to the collision detection would be hardware, since colliders may hit very hard on performance. Specially mesh colliders.
And raycasting actually is your best bet.
Your question should rely mainly on the "too fast", and there are many many questions on that already. Here's my favourite.
In short, just use DontGoThroughThings. For more details, I'll quote myself from there:
The problem exists even if you use continuous dynamic collision detection because fast moving objects can move so fast that they are too far apart from itself from one frame to the next immediate frame. It's like they teleported and no collision detection would ever be triggered because no collision existed, from each frame perspective, and thus from all calculations processed.
For un unknown reason, DontGoThroughThings fails when deploying my app to iOS...
@attiksystem I've used it in iOS and I tend to doubt it's an issue with the script. Can you give more details?
Hi, sure. When attaching DontGoThroughThings to my object (Cloth Renderer, I'm not sure this has an effect), and deploying to iOS, it bombs at line 0x81a0, with error "Thread 1: EXC_BAD_ACCESS (code=1, address = 0x0)". Using Pro version of the tools, latest version of everything.
unity`DontGoThroughThings_Awake:
0x80bc: mov r12, sp
0x80c0: push {r7, lr}
0x80c4: mov r7, sp
0x80c8: push {r8, r10, r11, r12, lr}
0x80cc: sub sp, sp, #260
0x80d0: mov r11, sp
0x80d4: mov r10, r0
0x80d8: add r0, r11, #8
0x80dc: mov r1, #0
0x80e0: mov r2, #24
0x80e4: bl 0x9060 ; p_2
0x80e8: mov r0, #0
0x80ec: str r0, [r11, #32]
0x80f0: mov r0, #0
0x80f4: str r0, [r11, #36]
0x80f8: mov r0, #0
0x80fc: str r0, [r11, #40]
0x8100: add r0, r11, #44
0x8104: mov r1, #0
0x8108: mov r2, #24
0x810c: bl 0x9060 ; p_2
0x8110: mov r0, #0
0x8114: str r0, [r11, #68]
0x8118: mov r0, #0
0x811c: str r0, [r11, #72]
0x8120: mov r0, #0
0x8124: str r0, [r11, #76]
0x8128: add r0, r11, #80
0x812c: mov r1, #0
0x8130: mov r2, #24
0x8134: bl 0x9060 ; p_2
0x8138: mov r0, #0
0x813c: str r0, [r11, #104]
0x8140: mov r0, #0
0x8144: str r0, [r11, #108]
0x8148: mov r0, #0
0x814c: str r0, [r11, #112]
0x8150: mov r0, r10
0x8154: bl 0x9070 ; p_3
0x8158: str r0, [r10, #16]
0x815c: mov r2, r0
0x8160: add r0, r11, #224
0x8164: mov r1, r2
0x8168: ldr lr, [r2]
0x816c: bl 0x9080 ; plt_UnityEngine_Rigidbody_get_position
0x8170: add r0, r10, #40
0x8174: ldr r1, [r11, #224]
0x8178: str r1, [r0]
0x817c: ldr r1, [r11, #228]
0x8180: str r1, [r0, #4]
0x8184: ldr r1, [r11, #232]
0x8188: str r1, [r0, #8]
0x818c: mov r0, r10
0x8190: bl 0x9090 ; p_5
0x8194: mov r2, r0
0x8198: add r0, r11, #8
0x819c: mov r1, r2
0x81a0: ldr lr, [r2]
...
@attiksystem no render should present any effect on this. the "line" the assembly code doesn't help as I'm not fluent in it. also EXC_BAD_ACCESS tells me nothing without knowing what was in the original (rather than assembly) line that triggered it - since I don't have a "knowledge base" of the script possible errors... I advice you to create an empty scene, free of errors, and little by little build and test something that can emulate what you need. Then attach the script. If, by any chance, you find any errors there, you'll have a much better idea what could have caused it.
Thanks. I'll try that. But meanwhile, I found another trick in order to avoid objects to "go through" other objects: make one of them very thick. This might not work all the time, but for my particular application, it does!
