PDA

View Full Version : Bullet Dynamics - Faster Plugin?



Airwaves
03-13-2017, 01:47 PM
Quick question if anybody knows if there is a faster bullet dynamics plugin or other software that works with Lightwave?

Currently I believe that Lightwave only uses one core to complete the bullet dynamics for a scene. It is way too slow for me at times and I use it a lot so it would be nice to have it go faster.

If there is not such a software or plugin that works with Lightwave what other 3d animation software do you recommend that has fast bullet dynamics?

Thanks in advance.

Oldcode
03-13-2017, 03:25 PM
If you want to use dynamics to do clothing, then the obvious choice is Syflex.

http://www.syflex.biz/index.html

https://www.youtube.com/watch?v=0-cXiAohXpI

circleofsmoke
03-13-2017, 03:34 PM
Im quite shocked LW only uses one core???? feels like its using everything - it chuggs so much and reduces my twelve core to an unresponsive crawl

gamedesign1
03-13-2017, 03:55 PM
If you want to use dynamics to do clothing, then the obvious choice is Syflex.

http://www.syflex.biz/index.html

https://www.youtube.com/watch?v=0-cXiAohXpI

Its amazing the difference in speed

Airwaves
03-13-2017, 04:58 PM
I use it a lot for objects smashing other things. Breaking items and knocking things over.

Airwaves
03-13-2017, 05:06 PM
Im quite shocked LW only uses one core???? feels like its using everything - it chuggs so much and reduces my twelve core to an unresponsive crawl

It was my understanding that it only could use one core. I will try and dig up where I found that. In the meantime here is a simple dynamics scene that hardly takes up any cpu at all.136277

Airwaves
03-13-2017, 06:09 PM
Here is the link to another thread talking about Bullet in Lightwave. I do believe it is not multi threaded and that is why I asked the question if there is a plugin or other software that does it really well.

http://forums.newtek.com/showthread.php?153080-Multi-Thread-In-General-and-Specifically-Bullet&highlight=cpu+usage+bullet

Greenlaw
03-14-2017, 04:03 PM
Yeah, AFAIK, LightWave Bullet isn't multi-threaded. I'm not sure if this is a Bullet limitation or a LightWave Bullet limitation.

FWIW, I haven't found Bullet especially slow but then I'm always optimizing the crap out of everything. It's all relative anyway, and I'm certainly for faster dynamics. I hope LW3DG puts more work into it for a future release. :)

Edit: I just ran a quick test and looked at Task Manager. It does look like only one thread is being used.

tyrot
03-14-2017, 04:30 PM
but then I'm always optimizing the crap out of everything. It's all relative anyway, .

any tips ?

Dodgy
03-15-2017, 12:23 AM
Just doing a quick google, it seems Bullet is only multi-threaded in certain parts, so it's going to be limited whatever you use.

darkChief
03-15-2017, 06:29 AM
Planning to use Bullet in my projects, and been looking at the source. It has opencl support, but the implementation is buggy according to documentation. It's seems to be a compatibility issue, so Newtek could branch their own version Bullet and enhance the opencl code. If they wanted to of course.

kolby
03-15-2017, 08:44 AM
I think Jarno said some time ago that Bullet in LW Next will be multi-threaded.

mummyman
03-15-2017, 09:01 AM
Damn.. Bullet in LW seems pretty damn fast to me. Faster the better!

Greenlaw
03-15-2017, 09:57 AM
any tips ?

Just the usual stuff:

- Calculate your sims in their own scene with only the items necessary for the sim; MDD the result and then use that data in your final scene
- Don't use more polygons in your geometry than you actually need for the sim.
- For accuracy, try to use meshes that have polygons that are more or less the same size. You'll probably need to customize the geometry for the sim.
- This is more of a Fracture tip but still related: use meshes that have polygons that are more or less the same size to get cleaner breaks, with few to zero errors. This will mean making more polygons than you probably think the object should have but it's important if you want a valid object that sims well with Bullet.
- If you need bevels on the insides of cracks, use a edge shader like DP Edge on the inner surfaces. This way, the edges will be 'hidden' until after the object breaks, and save you a lot of unnecessary extra modeling. Note that DP Edge needs clean meshes, so see the note about Fracture.
- Cloth sim is where you actually want more polygons to get realisitic folds and wrinkles. Don't rely on Sub-D surfaces--you'll be dissappointed because Bullet is always looking at the 'real', un-subdivided mesh. The polygons should be pretty regular and about the same size as much as possible.
- Use proxy geometry for collision, and Kinematic instead of Deformable for collision wherever possible. Most of the time, it's many times faster with nearly the same results. (It will probably wind up being more predictable too.)
- If you need to use Deformable for collision, use a proxy object. Deformable can really drag the system down when using it for collision, and a higher resolution collision object is probably doing a lot less for the simulation than you think.

There's a bunch of other stuff I can list but I think this covers the basics. Mostly it's just observing and understanding what Bullet is seeing and doing with what it sees, and then removing everything from the scene that Bullet doesn't need. Anything extra is just wasting time at this stage.

tyrot
03-15-2017, 12:05 PM
awesome thanks !

MonroePoteet
03-15-2017, 01:24 PM
I find that changing a Parts object to "Convex Pieces" rather than "Mesh" really speeds it up. If you don't need accurate collision detection (e.g. simulation is in the distance, and the view is cut off before the end "jitters" are seen), you can also reduce the Dynamics Framerate in the World tab.

mTp

Greenlaw
03-15-2017, 01:42 PM
Good tips!

Speaking of Parts objects, here's one that's not really related to calc speed but should help with 'jitters':

In a production shot, we usually cut away from the scene before any jittering is noticeable but in those situations where you absolutely can't have jittering, I find it's better if you don't use a Parts object, and instead break out the object into separate layers.

Why? When evaluating for deactivation, I think Bullet is waiting for the object to 'settle down', but with a Parts object that almost never happens because some little part is always colliding with another part, or some bit of it has escaped and is falling endlessly in space. Since the object is being evaluated as a whole, it's an all or nothing situation before deactivation can occur.

But if you break out the fractured object into separate layers, Bullet can evaluate each piece separately and decide the deactivation state for each piece individually.

I don't think that's explained in the manual, it's just something I observed a while back.

To manage the high number of objects this can create for Layout, I like to parent all the fracture layers to a null. This makes it easier to 'hide' them in the Scene editor.

allabulle
03-15-2017, 02:01 PM
Nice tips guys. Thanks!

MonroePoteet
03-15-2017, 02:34 PM
RE: jittering, I've also had some luck ramping up the Angular and Linear Damping using an envelope. I run the simulation with low damping values, then find a frame where all the parts should be settled, and ramp up Angular and Linear Damping to 100% at that frame. It affects all the parts, so everything "settles" at once, but it can work OK.

It'd be great if there was an envelope on the Dynamics Framerate to allow fine-tuning the intra-frame collision detection at problem spots, like when the jittering starts, or when a really obvious collision detection failure happens.

mTp

tyrot
03-15-2017, 03:12 PM
guys you are awesome! great tips!