Some Questions about the closed editor and physics

#1

Hello

if i understood right as an indie you get full runtime access but the editor is closed and therefore editor changes have to be made via plugin. Thats fine by me so far.

What im wondering about is if i can then use parts of the bullet physics engine that are not implemented yet like cloth and use them in my game code even if its not part of the editor?

And i would really like to see a good car model in the engine that would be the one thing that physx was bad in and its still not fixed in unity or ue4 since they havent included the sweep test wheels which nvidia has made by now in the engines yet.

So i would like to know if that is something that may come to the engine sometime?

And how does bullet compare performance wise with physx when not used over an plugin.
I did some tests in unity and compared physx and the available bullet plugin. As test i used just stacks of cubes and let them fall in each other.

That gives around 500 in realtime for bullet on my machine and 2000 for physx. It would be interesting to know if bullet gets a little more competitive when used native.

#2

Hello :slight_smile:

As far as I know, the core of Xenko and most of it’s component aside of the editor are open-source. So you can basically take a look really easily at how they implemented Physics to “mimic” it to implement the parts, bits and pieces that you may be missing.
I know, with experience, that, for example, there is no joint component by default in Xenko, you have to write you own physics joints, for now at least.

If you’re looking for a car example, the best I could give you so far is a link to a thread I made when I decided to write my own physics joint constraint script. (it also has some of the code I use there)
It’s not perfect, but it uses physics completely (including in the double wishbone suspension):

6DOF constraint script code
Car example with full physics + sort of how to setup

I don’t know if bullet’s car-related classes will ever be implemented in the engine, but as soon as they get the time to give physics some love. I guess so. :slight_smile:

Hm. I never really compared physics to bullet, so I could not tell you, sorry! I’m sure that some people benchmarked it though!
Also, don’t forget that initially, bullet is a c++ library that got a C# wrapper (BulletSharp If I can remember) and then is use by Xenko as a dependency and declares it’s own classes dependant on those. :slight_smile:

Cheers,

#3

Thank you for your reply that stuff about the car seems to get in the right direction.

You’re using a cylinder for collision and not a multiple raycast sort of sweep test from the look of it.
From the thread i read that your using the body as tire and therefore friction and driving behaviou will depend on that.
In physx its impossible to model a fast car with that workflow. The car would start to bounce or loose collision at some point and behave very badly so this would only work for very slow vehicles and even then may not produce a correct driving model if that is what one is after.
In unity physx has also very bad bone stiffnees so that the wheel setup would look silly in certain situations.

The physx wheel collider doesent have that problem as it is a racast model but then it doesen have collision that would be desired for offroad vehicles. And as i wrote before that one isnt in ue4 or unity in this moment available. In ue4 you could implement it but that requires an visual studio 2012 or 2010 because otherwise you cant compile physx.

Gta 5 which has a version of bullet implemented uses raycast cars with multiple rays per wheel. Im pretty certain of it and i like that driving model and its collision behaviour as it is close to perfect in the game fun realism ratio.

Copy and paste in the editor is a nightmare when copying large amounts btw. I did that when i made the cube stacks and it takes ages to copy 500 cubes for example. Never had that problem in unity or ue4. Editor also becomes absolute unresponsive and windows is nagging but it will do end the job fine after a while.

I had problems setting up bones in the editor and getting them to behave as i would have expected or at all.
Never had that much of a problem with physx.
Im a bit preoccupied at his moment in time but i will return to xenko later.

That bullet is only used over a plugin may take a bit of speed. I wonder how much.
Unity itself is using c++under the hood so no wonder that physx is working so good.