Hello all,
I'm going to code a thing with bullet, lots of graphics, lots of libraries, can you guess what? Yeah, I'm that "make my own game engine" guy
gotta love us; except I'm ten years down that terrible-hellish path.
I'm having trouble finding a decent reference for the status of OpenCL/GPU support in bullet.
Some posts say yes, some say no, 2.80 has an openCL demo at least, is 2.83 the same as Bullet-3? Does it have production ready OpenCL? the plot thickens.
blah-blah I'm a good 'ol veteran of programming - lots of years, etc. So I'll skip to the good part.
1. Does 2.83.5 have OpenCL/GPU support.
2. If yes, where is the reference for it? Dyoxygen, docs, wiki, post-it notes on your monitor... anything.
and less so:
3. Should I look out for anything that might need patch/pull requests when I'm working with this Lib?
Beyond that, looks like a fine mature project - how many developers are currently active?
OpenCL and Bullet 2.84
-
Mako_energy02
- Posts: 171
- Joined: Sun Jan 17, 2010 4:47 am
Re: OpenCL and Bullet 2.84
Oh, hey! I'm one of those guys too! There are literally dozens of us!
1) Seriously though, the OpenCL/GPU support does exist but it's somewhat sparse and not rigorously tested as I understand. I mean...Erwin has tested it in the demos he's made but there aren't a ton of other devs that have tried to make something out of it and see what all it can do, again, as I understand. Prior to Bullet 3 the OpenCL support was primarily done through MiniCL, which I can understand some confusion. In Bullet 3 only the rigid body pipeline has support for OpenCL acceleration, but not soft bodies and such(though that was listed as a planned feature).
One thing I am still very unsure of is how intact the CPU pipeline/classes are in Bullet 3. Last I heard Bullet 2 was for CPU acceleration, and Bullet 3 was for GPU. Although in Bullet 2 the multithreaded library was given the axe recently. A community version of a new multithreaded provider was created and shared on these forums, but I haven't delved into how it hooks into everything yet to know if it's appropriate for my needs, or can/will be submitted mainstream.
2) Documentation in Bullet is approaching non-existent. It's been this way since I started with Bullet a while back. The demos tend to be the documentation, along with asking people here and hoping someone has tried to do something vaguely similar to what you are trying. I'd start with the demos, and altering them until you have a better idea of what affects what.
3) I'm not entirely sure how to answer this question. Nothing is really fundamentally broken in the library, however a few things are grossly under documented and hard to understand (soft bodies come to mind). Other things provide just a base implementation and expect to be tuned to specific needs (such as the btKinematicCharacterController or the btRaycastVehicle). Neither are broken in terms of their functionality though. If you find bugs patches are welcome, but I don't have any reason to believe that you will in any particular part of the library.
1) Seriously though, the OpenCL/GPU support does exist but it's somewhat sparse and not rigorously tested as I understand. I mean...Erwin has tested it in the demos he's made but there aren't a ton of other devs that have tried to make something out of it and see what all it can do, again, as I understand. Prior to Bullet 3 the OpenCL support was primarily done through MiniCL, which I can understand some confusion. In Bullet 3 only the rigid body pipeline has support for OpenCL acceleration, but not soft bodies and such(though that was listed as a planned feature).
One thing I am still very unsure of is how intact the CPU pipeline/classes are in Bullet 3. Last I heard Bullet 2 was for CPU acceleration, and Bullet 3 was for GPU. Although in Bullet 2 the multithreaded library was given the axe recently. A community version of a new multithreaded provider was created and shared on these forums, but I haven't delved into how it hooks into everything yet to know if it's appropriate for my needs, or can/will be submitted mainstream.
2) Documentation in Bullet is approaching non-existent. It's been this way since I started with Bullet a while back. The demos tend to be the documentation, along with asking people here and hoping someone has tried to do something vaguely similar to what you are trying. I'd start with the demos, and altering them until you have a better idea of what affects what.
3) I'm not entirely sure how to answer this question. Nothing is really fundamentally broken in the library, however a few things are grossly under documented and hard to understand (soft bodies come to mind). Other things provide just a base implementation and expect to be tuned to specific needs (such as the btKinematicCharacterController or the btRaycastVehicle). Neither are broken in terms of their functionality though. If you find bugs patches are welcome, but I don't have any reason to believe that you will in any particular part of the library.
Re: OpenCL and Bullet 2.84
Well, brilliant! I love meeting other insane people (and you have to be insane to do the game-dev thing).
So, if I want to use the OpenCL solvers, I should do my own testing? Perhaps create some tests.... hmmm...
As for Documentation, that's a pretty sad state of affairs, understandable, but sad. Has anyone ever considered documenting things properly?
and "nothing is broken" is what I consider to be a golden-thought.
So, if I want to use the OpenCL solvers, I should do my own testing? Perhaps create some tests.... hmmm...
As for Documentation, that's a pretty sad state of affairs, understandable, but sad. Has anyone ever considered documenting things properly?
and "nothing is broken" is what I consider to be a golden-thought.
-
Mako_energy02
- Posts: 171
- Joined: Sun Jan 17, 2010 4:47 am
Re: OpenCL and Bullet 2.84
Like I said, start with the demos for your proof of concept. If you have something in mind that is very different from how the demos use it, then you can probably create a new demo or add to the existing one as a proof of concept and submit it upstream.
Just about everyone has considered adding documentation. But you have to understand the items keenly first, which is a hurdle a ton of people don't pass. Even then, there have been several documentation patches submitted over time, but didn't get in for one reason or another. A few of them were because they were submitted through the forums, which isn't ideal for Erwin and many patches get lost that way. Use the github issue tracker to submit patches. Or even better, fork the repo and make your changes there then submit a pull request.
Just about everyone has considered adding documentation. But you have to understand the items keenly first, which is a hurdle a ton of people don't pass. Even then, there have been several documentation patches submitted over time, but didn't get in for one reason or another. A few of them were because they were submitted through the forums, which isn't ideal for Erwin and many patches get lost that way. Use the github issue tracker to submit patches. Or even better, fork the repo and make your changes there then submit a pull request.