Hey let's switch away from bullet to anything else (discussion)
- AnyOldName3
- Posts: 2686
- Joined: 26 Nov 2015, 03:25
Re: Hey let's switch away from bullet to anything else
That's where you have a class with an operator() instead of just passing a function pointer? Google isn't giving me a clear answer (mainly because it sees "callback object" in quotation marks as an equivalent term to 'callback', so I'm not getting relevant results). I thought that had the advantage that you can use the type system to guarantee you're using a function intended for that task instead of one you found lying around with the right parameters and return type, which seems like enough justification for it to exist as an option to me.
Re: Hey let's switch away from bullet to anything else
Not to mention that not all languages treat functions as first class objects. Unless modern C++ has lambdas?
- psi29a
- Posts: 5362
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Hey let's switch away from bullet to anything else
Like C++11 (and furthered in C++14 which we can turn on at any time)?
"Modern C++ features – lambdas"
https://arne-mertz.de/2015/10/new-c-features-lambdas/
- AnyOldName3
- Posts: 2686
- Joined: 26 Nov 2015, 03:25
Re: Hey let's switch away from bullet to anything else
You don't even necessarily need lambdas - declaring any normal function and then using &functionName works just fine, and I think this was a thing pre-C++11
Re: Hey let's switch away from bullet to anything else
I believe we should write a list of things we don't like/can't do with bullet, but also what we use, and do a list of other physics engine to see if it's worth it to switch or not right? My idea is to write a list here and edit thie message with what comes up.
What we use:
What we use:
- arbitrary triangle shapes (static)
- convex shapes
- heightmaps
- raytracing, do we actually use it?
- trace function
- static intersection test
- dynamic objects (rigid bodies)
- ragdolles
- clothes?
- water?
- poor documentation
- no support from devs
- what do the margin even do?
- slow?
- newton dynamics
- https://www.reactphysics3d.com
- ODE - seems really old and not really updated
Long time no see I didn't contribute for a while, but it's really nice to see how far OpenMW has come! As a side note, I don't think it would be too complicated to add dynamic objects for modders. It would simply require an additional optional field in NIF files for the mass of the object, and an additional info when you add an object which indicates if collisions are on (no idea how to do that last one though).Agreed. What's up gus!
Regarding physics for everything, that really is a post-1.0 thing. I think the original intention of this thread was getting normal collision in the game as it stands now to be less of a mess.
Re: Hey let's switch away from bullet to anything else
In C++, the usual way to handle callbacks is either via a functor (an object that can basically call operator()), or inheritance with a virtual function (you pass in a pointer to an object of a class derived from a known type, implementing/overriding a virtual function so it gets called when the base class function is invoked).AnyOldName3 wrote: ↑31 Aug 2018, 23:26 You don't even necessarily need lambdas - declaring any normal function and then using &functionName works just fine, and I think this was a thing pre-C++11
The former is typically used with templates, since the compiler has all the necessary information on invoking what you pass in. This works for function pointers, lambdas, and object references to a class that implements operator(). If done properly, this can result in the function call being completely inlined, though since it's template magickery the code has to be visible to the compiler where used.
The latter is typically used in cases where pre-compiled/external code needs to invoke a user function that's carrying user data. You could instead do the C-style thing of a function pointer and opaque void pointer, which would be more flexible and a bit more efficient than a vtable call, but it's not recommended C++ practice since it deals with void* which messes with type safety.
- psi29a
- Posts: 5362
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Hey let's switch away from bullet to anything else
Isn't this already the case in NIFs for Oblivion? Supporting Oblivion style NIFs would net us this field.
http://niftools.sourceforge.net/wiki/Ob ... jects/Mass
We should ask cc9cii since he was doing that work already.
Re: Hey let's switch away from bullet to anything else
I sent him a PM.We should ask cc9cii since he was doing that work already.
Re: Hey let's switch away from bullet to anything else
Just to tie up this thread, after getting mad at bullet, I wrote my own cylinder-mesh tracing code in my personal 3d collision toy. It's not for OpenMW, my thing doesn't do mesh transformations of any kind (no scaling/rotation) and the broadphase is an octree where mesh locations can't be updated (so you can't bring statics out of the world and dynamics can't collide with each other), but it shows that getting cylinder-mesh tracing right shouldn't be hard, and if someone needs it, it shows how the math works.
https://pastebin.com/pFEFALeZ
(and https://pastebin.com/6fSYNKyL )
https://streamable.com/f4dtt
Entire single-file C++ nightmare: https://github.com/wareya/3dtest/blob/master/main.cpp
https://pastebin.com/pFEFALeZ
(and https://pastebin.com/6fSYNKyL )
https://streamable.com/f4dtt
Entire single-file C++ nightmare: https://github.com/wareya/3dtest/blob/master/main.cpp
Re: Hey let's switch away from bullet to anything else
My 2c:
First of all I've not looked too much into other physics engines so I have a limited perspective on this topic.
In terms of Oblivion and Skyrim (and Fallout), the NIF files contain a lot more physics info compared to Morrowind. From what I can tell, Bullet isn't too different from Havok and most of the data can be used directly with little or no transforms. So in terms of NIF, Bullet gets a thumbs up from me (that is not to say other engines won't work just as well - I have no idea).
On improving physics in OpenMW: this is probably one of the prime motivations when I embarked on going down the rabbit hole of looking at Oblivion NIF files. Never got around to it (yet) since there's never ending list of dependencies to complete first. I have to agree that Bullet's documentation is inadequate - basically one has to read the source and then try out each of the examples (which can take a lot of time). For someone like me with limited understanding of the underlying maths it can be even slower. So if there's another physics engine that has a clear and accurate documentation then I don't see why we couldn't switch over.
The question is whether the payoff will be greater than the pain. Given the nature of OpenMW the answer probably depends on whether some volunteer(s) have sufficient time & motivation to make it happen. For me, I've already invested too much into Bullet to make it worth while to learn a completely different engine. But that shouldn't be a factor for anyone else.
First of all I've not looked too much into other physics engines so I have a limited perspective on this topic.
In terms of Oblivion and Skyrim (and Fallout), the NIF files contain a lot more physics info compared to Morrowind. From what I can tell, Bullet isn't too different from Havok and most of the data can be used directly with little or no transforms. So in terms of NIF, Bullet gets a thumbs up from me (that is not to say other engines won't work just as well - I have no idea).
On improving physics in OpenMW: this is probably one of the prime motivations when I embarked on going down the rabbit hole of looking at Oblivion NIF files. Never got around to it (yet) since there's never ending list of dependencies to complete first. I have to agree that Bullet's documentation is inadequate - basically one has to read the source and then try out each of the examples (which can take a lot of time). For someone like me with limited understanding of the underlying maths it can be even slower. So if there's another physics engine that has a clear and accurate documentation then I don't see why we couldn't switch over.
The question is whether the payoff will be greater than the pain. Given the nature of OpenMW the answer probably depends on whether some volunteer(s) have sufficient time & motivation to make it happen. For me, I've already invested too much into Bullet to make it worth while to learn a completely different engine. But that shouldn't be a factor for anyone else.