Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unstable RigidBody when adding/applying forces/torque #25468

Open
Tracked by #45333
OBKF opened this issue Jan 29, 2019 · 13 comments
Open
Tracked by #45333

Unstable RigidBody when adding/applying forces/torque #25468

OBKF opened this issue Jan 29, 2019 · 13 comments

Comments

@OBKF
Copy link
Contributor

OBKF commented Jan 29, 2019

Godot version:
3.0/3.1 Bullet physics engine (Godot internal doesn't even work)

Issue description:
Applying torque on a RigidBody leads into strange behavior, tested using Cylinder and Sphere collision shapes. The wheel (rigidbody) that I want to simulate rolls normally at first while trying to go threw the flat surface ground (big cube) which is strange enough, then it starts to jump and sometimes just snap in place and start to dance and never stops.
Here are two videos I recorded for the problem:
Wheel alone
A Vehicle with 4 wheels and Joints

Steps to reproduce:
Add a RigidBody with cylinder collision shape to the world with a flat static ground, then apply torque.

Minimal reproduction project:
rigidbody_physics_bug.zip

@OBKF
Copy link
Contributor Author

OBKF commented Jan 29, 2019

As seen in the video bellow the problem isn't Bullet issue when other people can do it using just bullet or other engines.
https://www.youtube.com/watch?v=y_bTpadwO0o
@AndreaCatania any thoughts?

@OBKF OBKF changed the title Unstable RigidBody when applying torque Unstable RigidBody when adding/applying forces/torque Jun 22, 2019
@OBKF
Copy link
Contributor Author

OBKF commented Jun 22, 2019

After some time I decided to go back to the project and change things, but even applying forces does the same thing.

More examples:
mine:
https://www.youtube.com/watch?v=21uYkO0WvTc&list=PLwf_z9369gcOfjESA4zUyPFmusF4Z2WvN&index=3&t=0s

someone on youtube:
https://www.youtube.com/watch?v=RCWuBCohtUY

@eyeEmotion
Copy link

Don't know if it is related (I think it is), but I have similar issues. Maybe it has improved since then, but I've got a recent version of Godot and get "wobbly" physics when using the VehicleBody/Wheels setup, when driving on any kind of slope/angle, downhill or uphill.
Sometimes there are points where the car just flies of for no reason.

I checked my collision mesh and everything is fine. I've enabeld the "Smooth Trimesh Collision" option in the project settings, but that only helped slightly.

Unwanted launch at : 6:21, 1:37
Noticeable wobbly physics at : 0:25, 0:39, 2:03, 5:26, 6:01, 6:43 (all more noticeable in real than on video.
https://youtu.be/suT_heUgWig

@AndreaCatania
Copy link
Contributor

Yep, that one is an issue on the bullet physics engine. Sometimes, a trimesh triangle collides with the border of the box and you can see that behaviour.

Time ago I've debugged that issue and provided a partial fix by introducing the smooth Trimesh Collision.

In order to make sure that it works it's necessary that the controlled box shape and the trimesh shape are both at the origin so the body COM is at center. This should help a bit.

@eyeEmotion
Copy link

Yep, that one is an issue on the bullet physics engine. Sometimes, a trimesh triangle collides with the border of the box and you can see that behaviour.

Time ago I've debugged that issue and provided a partial fix by introducing the smooth Trimesh Collision.

In order to make sure that it works it's necessary that the controlled box shape and the trimesh shape are both at the origin so the body COM is at center. This should help a bit.

With the controlled box shape, you mean the collision box around the body of my car?
This is how I currently have my car setup with the box. First I had the box only surrounding the body of the car, but then I lowered it to the wheels aswel, since I read somewhere that the collisionshape also acts as some kind of weight distribution and it also seemed that my doesn't jump so easily anymore with smaller "jumps" in the track.

wipCCR_carCollisionShape

@OBKF
Copy link
Contributor Author

OBKF commented Apr 17, 2020

I gave-up on the trying to fix the vehicle code and made my own implementation using GDscript following some unity/ue4 tutorial and some research, I recommend you doing the same.

Start with a simple raycast vehicle (Start here). and then you get that going well just implement what you need from Tork Open-Source Project.

@eyeEmotion
Copy link

Ok, thanks for pointing me in the direction. Going to research it. In the meantime, this will need to suffice, since I'm a starter at game-development and at this moment, the only thing that bothers me is the "wobbling" and the too much slowing down when driving uphill or turning.

Haven't been able to get a drift in there, even though they advice to set the wheel_friction_slip of the rear wheels slightly lower than the front wheels to get a drift.
Getting started with VehicleBody proves easy, but getting it to do other things more "gamey" is another story, so it seems.

@OBKF
Copy link
Contributor Author

OBKF commented Apr 19, 2020

I recommend to just start from scratch, I have learned a lot doing that, and I made my own solution which I am 90% satisfied with (I didn't really have time to finish it yet.).

@eyeEmotion
Copy link

There is just a lot to do when you're alone in doing it and everything is new. I also have an interactive environment (just managed to get one hazard triggering today) which isn't without its challenges for a beginner game-developer. Assets are created by myself too. Especially since I'm a designer, that's one thing I don't want to compromise on :).

It's definitely a learning curve. There are so many things to like about Godot and even easy to do, but then there is also the same amount of moments where you think "Why does it work like that and not like" or you just need a good dose of coffée :). I mostly get stuck and just finding the right information.

Not related to this issue, but something that is putting me off as a beginner and get me stuck on things I shouldn't.
Information is the biggest problem though. It's obvious the Docs are written by different people, some sections are very clear and explain things very well and other parts are just missing a lot of information (especially for beginners). And for the 3D there is even less to find. Information (or obtaining information) is too fragmented and common problems not always addressed.
The Docs aren't beginner friendly either in some parts. For example, just got stuck with the AudioStreamPlayer3d. Didn't get any sound if I selected an Attenuation Model. Nothing in the Docs "tutorial" mentioned anything helpful. So I was trying values anywhere. Apparently it was just setting the Unit Size anything other then 0. Yet something that simple yet essential wasn't mentioned in the Docs.
There is too much of "Oh, we're doing it in 2D, but don't worry, it's ALMOST the same for 3D" and then it isn't.

If they want to attract more users, they definitely need to focus on a lot more and better tutorials and making the Docs not for themselves but for everybody.

@cbscribe
Copy link
Contributor

cbscribe commented Apr 23, 2020

"Beginner" means something very different to every person who comes along. I've seen everything from people who've never written a line of code before to those with coding experience but no game development background. One set of docs that addresses all of those types of beginners is impossible.

That said, even if everything was perfect game development is complicated. There's no way around it. Personally, I spend a lot of my time helping people with the math that they either don't understand or never studied. Godot docs are not really a place for remedial math lessons. :P

If they want to attract more users, they definitely need to focus on a lot more and better tutorials and making the Docs not for themselves but for everybody.

Who is "they"? Godot and its documentation is made by volunteers. People work on what they're able to work on and contribute at their level of ability and interest. Of course there are going to be gaps where more is needed, and the number of people who are able and willing to write documentation (a very different skill from programming) is limited.

If you've identified a place where information is missing or incorrect, the best thing you can do is open an issue on https://github.com/godotengine/godot-docs/issues so someone can see it and hopefully address it. There's a push right now to completely revamp the docs for the upcoming 4.0 release, so now's the time to raise issues: godotengine/godot-docs#3390

@Calinou
Copy link
Member

Calinou commented Apr 23, 2020

@eyeEmotion Looking at the class reference, AudioStreamPlayer3D's default Unit Size value seems to be 1.0. Which attenuation model did you use? Maybe we could display a node configuration warning if Unit Size is set to 0.

@eyeEmotion
Copy link

@eyeEmotion Looking at the class reference, AudioStreamPlayer3D's default Unit Size value seems to be 1.0. Which attenuation model did you use? Maybe we could display a node configuration warning if Unit Size is set to 0.

@Calinou
First time mine was on 0 for some reason (maybe changed it without knowing). Adding a new one is indeed on 1, but still not hearing any sound then. At 5 I start to hear a little bit when I check Playing in the Inspector.
But I'm beginning to realize what the problem is. The distance sound is already working in the Editor. So if I'm not close to where my AudioStreamplayer3D is in the editor, I don't hear it. As it should be in-game, but kinda confusing in Editor (for first timer that is). So a warning of some sort in the info pop up or something would be advisable, that you also need to be close to the audioplayer icon in the Editor to hear something. Now it's actually kinda funny 😅, even "3D" when I rotate around the editor during playback.
On default the Attenuation Model was on Inverse. Mine currently is on Log... don't know why I did that, just did sound more of what I needed. Don't yet really understand the differences between them.

@pouleyKetchoupp
Copy link
Contributor

As a note, the original issue seems to be specific to Bullet.

Using a sphere shape, I can still reproduce it in 3.2.3 stable using Bullet, but it doesn't occur with Godot Physics.
Cylinder is not supported (yet) in Godot Physics so I can't compare this case.

Calinou added a commit to Calinou/godot that referenced this issue May 6, 2021
This makes it easier to hear sound while setting up the node.

Since this changes the default value, this may break existing projects
slightly.

This also tweaks the Unit Size editor property hint for better usability.

See discussion in godotengine#25468.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants