Open OBKF opened 5 years ago
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?
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
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
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.
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.
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.
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.
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.).
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.
"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: https://github.com/godotengine/godot-docs/issues/3390
@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 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.
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.
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