Armory physics have too much issues making gameplay physic based not working.
Should RTX ray tracing or some Voxel real time running fine only on 1000$ 3D cards become no more priority ?
Instead make good physics priority ?
Why gameplay doesn’t work :
- driven physic objects passing through each other when velocity is not low
- projectiles passing through physic volumes
- objects , player or projectile passing through a physic door
- objects or player passing through moving physic platforms
- Dynamic physic objects with gravity not applied after some time or stuck
- Physic joints is a must needed and it doesn’t work or is not implemented
- Cloth physics not working when we try ourselves to make new examples
I hope Lubos won’t close the issue again and won’t label it as Player controller , because it’s really physics issues.
3D physics volumes that are dynamic and moving or animated passe through other volumes most of the time.
The other physic issue is gravity is not working as it should be, objects staying in strange positions in space.
Physics stuck :
Physic joints are not working
Cloth physics not working.
I really hope Armory will get some months focused on working on physics to get good working and stable physics.
Should Armory provide Nvidia Physix also ?
It’s a stable and prooven physics library updated frequently.
What does that mean? What is a player controller label? You created two issues named
Continous collision detection and
Continous collision detection needed, so I simply linked them together into one. Let me know if there was a misunderstanding.
Also, keep in mind Armory is marked as 0.x software on purpose, it needs fixes.
I understand it’s 0.x, i’m just surprised priority has been graphics instead of good physics gameplay first.
The thread is a helpfull compilation reference about the most blocking physics issues we found as very early adopters if we could name it that way
When they will get fixed, Armory will start to be great
Could Nvidia Physix be included as an optional physic engine ?
Perhaps it’s a choice to be made before Physic work starts ?
(Nvidia Physix is better, has lot more features and it’s stable and prooven)
Just to remember that Armory is a free/libre and open source software, so the implemented libraries should be compatible with Armory zlib/libpng license.
While Physix license is not zlib/libpng , it is free of use.
It should be possible to create a specific license to use Nvidia Physix in Armory 3D for interested people. There is other 3D engines using it.
Physicx have more possibilities.
Perhaps the actual 3D Physics engine worth it, if it could cover the features supposed to work ( physics, joints, cloth, soft body) and those features would really work well.
I don’t see why not. But Bullet engine is not bad either, i mean look at blender’s realistic simulation. It just matter of implementation. Bullet implementation is not complete in haxe, I searched for things like continuous collosion but could not find. I agree with you saying that armory should focus more on physics related issue.
0.6 is focused on graphics.
0.7 is focused on gameplay mechanism(like ECS)(from what i have seen in roadmap).
But it is up to lubos deciding when to do it, he himself got alot on his plate.
I am not great with physics programming, but if someone tell me or guide me on how to implement and how to do it then i will be more than happy to help (like book/resource on game engine physics, Bullet engine, etc.).
0.7 or 0.8 or 1.0 , it’s doesn’t matter, Lubos is the one who knows what to do or when, bring or not Nvidia Physix, while i can understand the need to be fully zlib/libpng license.
I just put together the show stopper physic issues, we will be able to check lot later if they got fixed.
Graphics are already good in Armory, while solid physic gameplay is a must need and lot more important.
Would you continue play a game where characters, projectiles or dynamic physic objects passes through doors, platforms or other static level objects ?
Or would you instead play a game with not as great graphics, but having great and solid physics gameplay ?
Well … Armory will need lot of months to improve, perhaps physics will become very solid and reliable.
Can you please mention other free/libre open source engines that use it?
I read the EULA and in my personal opinion is not compatible as source code.
Anyway i agree with the need of improvement about physic, if someone of the community can help Lubos with it is more than welcomed.
I don’t know why people what to use other physics engine, Bullet physics engine is itself awesome, it just need better implementation.
When you read Armory manual , it’s written in a way it looks like any physic engine could be used with ease
Armory is designed to work with any physics engine. Internally, a glue code is written which binds the physics simulation. This lets you pick the most suitable physics engine depending on project needs and makes Armory future-proof.
Is the actual 3D engine really able to handle physics supposed to work ?
Nvidia Physix is perhaps not needed.
Personally, I don’t find the physics engine hard to use - There might be some quirks every once in a while, but the engine is both in alpha state and open source, so there’s nothing keeping you from trying to implement Nvidia Physx yourself if you need it.
Yeah, I think that overall the physics fixes are probably going to be pretty easy, with just a little bit of work. We already have enough evidence from other engines and software that Bullet can do a very good job for realtime physics. All we need is more Bullet bindings to Haxe ( easy if you know what you are doing ) and modifications to the current implementations of the Armory physics traits.
I’m planning on doing some work on Armory, hopefully in the near future, and I might see if I can take a hack at the physics issues I run into while trying to implement a 3rd/1st person shooter type gameplay. I don’t know any C++ or Bullet, but I don’t think it should be way too hard to figure out.
While I have found many of the issues you have here to be true, I have fixed most of the passing through issues with a slightly thicker collision box. What drives me nuts is the fact that the collisions have a space between them from the get go and make some types of games not working.
I do think that bullet is the answer in that it is what blender is already using so that in the long run what we see in Blender and what happens in Armory should be the same.
Blender has never been great for making real time games, physic simulation is not real time optimized games.
Continous collision detection does not seem complicated to use
From this example :
This could fix physic objects passing through others physic objects.
Armory needs to include those options to physic dynamic objects.
I have a fairly good example of a physics simulation made in BGE. My project though, is figuratively speaking, locked within Blenders Game Engine. I tried the BGE publishing methods but all yield poor performance when on another machine. Even the exports to runtime. These were not actual exports but attempts to go around GPL (excluding export to runtime).
The simulation as a whole is not optimized to its best. Many objects may have excess vertices weird (quick) UV mapping, baked textures that were botched and more. I did go through a process to link objects to a library .blend but this seems to turn into a pain since all objects must reside in the absolute center of the linked library blend file. Additionally, making the link groups and assigning them proved rather finicky.
I even tried moving the assets into UE4 and it looks great but UE4 uses PhysX which only allows convex collision shapes. You cannot have a one piece concave collision shape. That blows my mind for an engine like UE4 to have that limitation. You can make a concave collision shape but you need to make separate UCX objects and import your asset with it. I tried it on my launch track which is sensitive to collision surface and had rather poor results. It gets caught in the joints of those individual UCX collision shapes that make up the spiral.
During the early days of my testing I was having problems with collisions in BGE. Mainly pass-throughs. The biggest improvement came from increasing [Physics Steps] in [World Tab]. You have two options : [Max] and [Substeps]. I turned these both to a Maximum of 5, literally everything was then colliding with great results.
The machine will process small simulated steel shots (tickets) and even pay out little physical ones to the tray where they can be drained following a small interior path below the tray. This is why Bullet impresses me. Collision with MESH! Profiling, I get 60 FPS unless the machine spawns a bunch of shots to the tray but I could optimize those better. They use the same collision shape as the main shot.
I’m going through Armory right now to see if I can achieve the same with it. I do love the fact that Armory uses Bullet. It’s a great physics engine. If I’m not mistaken RAGE integrates bullet.
Keep up the incredible work on Armory!
I did not understand what the bullet’s problem is. If I remember correctly it is used by Rockstar in gta IV and V.
There isn’t really, and they do. Plus here’s a little proof. Mind you this is running in BGE 2.76, but that’s bullet for you.
There is quite a bit going on with collisions here at any time while playing and it would run at 60 FPS if not for the capture process.
The small gate at the upper left corner is using ray detection for collision to “open” it (it just flips between ghost checked on/off, the object is set as static). it retains shots within the field.
As you see there is a small payout to the tray that is another collision plus I have the drain open so they don’t pile up. The shot will pass through a marker that tags it with information, it will travel trough the back panel down a ramp and queue into a virtual regulator, all with very consistent reliability.
I think bullet, even BGE is quite capable you just need to know how to calibrate it correctly.