Hi,
I was wondering, since motions can also be done in torques also instead of just in straight lines, is there a way of coming up with “torque” casts? This could be useful in calculating how far a door with a hinge joint could go anywhere from an X degree angle to a 0 degree angle depending on if a collider is standing anywhere between its two angles, and stop anywhere between X and 0 degrees if there is a collider blocking the way. So far, I have a 3D door, but my character does not move the door UNLESS the door is in some kind of motion.
Couldn’t you set the door on a joint to the wall and as the character runs into it, it turns instead of moving forward. So then the door won’t turn pass any colliers.
I wish it were THAT easy, but like I wrote earlier, the door won’t budge UNLESS there is already a force applied to it and while it is in motion. I believe that is because the computer only calculates what happens if the door hits a collider while the door is in motion with a force applied to it, BUT the computer doesn’t calculate what happens if a collider hits a door especially when FPSWalker and Character controller I think only uses Translational vector changes as opposed to applied Forces. The invention of “Torque” casts would definitely solve that problem because just like ray casts, I wouldn’t have the object render until it is finished calculating where it should stop rotating from angle X1 to angle X2. I wouldn’t have to suggest this IF the door would move when the character hits it WHILE it is not in motion and no force is applied to it.
In which direction? I want it to be based on what side of the door the player collides into and also depending at what angle, and if it crashes into the middle of the door, I want nothing to happen. What if I also don’t want to use the function OnCollisionEnter in a separate script such as “FPSWalker.js” and only wish to use it in my own script (door.js) where each door has it’s own unique door.js that tells each unique door to stop between angles X1 and X2 WHEN it hits a collider?.. just as easy as if I had some shapes and I used a unique script per shape to move each shape as maximum forward as possible until there is a wall in the way. I would use a raycast for that. Why not “torque” casts then? It would feel more unprofessional if I had to alter FPSWalker.js every time I wanted a unique object to stop at a certain point when I could use raycasts in my individual scripts instead.
Can you give a little more info about the “between angles X1 and X2” bit? By more information, I mean why, in the context of the game, should the door be restricted to those angles? I ask because I think this will help me understand your problem better, and be more likely to help.
Also, functions like Rigidbody.AddTorque can be used, and are perfect for doors, while certain types of joints can be used to restrict the movement of rigidbodies in various ways (like restricting its rotation, perhaps?)
What I mean is that I have a door where by the time it gets rendered, eulerAngles.y should be rendered at angle 0 degrees IF no collider is standing at the door. 0 would be my X2 value, BUT before the door even gets rendered, eulerAngles.y should start off at angle 90 degrees. 90 is my X1 value. That’s what I mean by X1 and X2 (X1 being the start off angle and X2 being the destination angle). If no collider is between the door at its eulerAngles going from 90 to 0, it gets rendered as eulerAngles.y being 0 degrees (kind of like how a ray cast can go from point a to point b and if it hits nothing, I would have my character standing at point b). If a collider is in the way of the door going from 90 degrees to 0 degrees, the door should stop at that angle (kind of like how I would use a ray cast to calculate if there is a wall between points a and b and if there is, my character would stop there). It would be nice if doors could work the same way, (except this time using a “torque” cast)
I COULD use a series of small straight-lined raycasts going in a circle from the center of the door before the door gets rendered, but that would be based on a bunch of straight lines used in several raycast calculations instead of using just 1 simple “torque” cast calculation to save time, and the stop point would effect the positioning of the door and not the angle (which I want) and if I use as little as 8 circling raycast calculations per door, my game would probably run 8 times slower and I would only have an octogon of accuracy in each door.
If my doors could only move based on how the character controller hits them (without having to apply any outside torques to the doors), that would be great. The OnCollision functions in FPSWalker.js don’t always get called either and that’s mostly when the doors I run into have no force applied to them and are not in motion. Is there a character controller that moves by rigidbody forces instead of by transform translations? That would be another solution I think. I would also like it to move just as smoothly AS IF it was done by transform translations (where when it is in motion, it doesn’t stay in motion when the user stops pressing a key and if it is not in motion it becomes in motion when the user presses a key).
On Line 2, my first argument would be the starting point of the torque.
My second argument would be the distance between the starting point and the way. The higher the number, the bigger the ray’s circle and further away from the starting point. My third argument would be the axis of which the ray rotates, so at Vector3(0,1,0), that means the ray circles around on its Y axis. The fourth argument would be the starting eulerAngle, in this case, the y axis’ starting euler angle being at 90 degrees maximum. The fifth argument would be the y’s destination euler angle 0 degrees being minimum so we have a minimum/maximum joint movement (minimum being if no collider is between max and min). The final argument would store the hit contents (if there is any) just like raycasts do.
On line 3, I would then tell the door’s y euler angle to equal wherever the Torquecast’s y-axis ray had stopped IF it hit a collider while it was rotating around the y axis.
Let’s say I have an empty object called “hinge” at Vector3(0,0,0) (where the hinge joint is). Then I have a child object called “door” along with its mesh and collider at its central point Vector3(0,0,10) so as “hinge” rotates, “door” also rotates too but specifically around “hinge” which is at Vector3(0,0,0) because “hinge” is the parent. My script would be put in “hinge” and I would use the arguments in my code above because “door” would be 10 units away from its joint at “hinge”. That’s why I used the number 10 in my example above for argument 2 on line 2, but maybe the developers of Unity and/or I could help them implement this idea.
It sounds like you are more interested in talking about the benefits of a TorqueCast than getting your code working. If this is the case, I would suggest moving this thread to the Wish List thread instead.
Character controllers won’t apply forces to rigidbodies by default. Use something like Unity - Scripting API: ControllerColliderHit to determine when the player controller bumps into it and apply a force to the door based on the direction of impact, speed of the player controller, etc.
For the door just use a joint that allows rotation around the hinge point.