Wednesday, January 4, 2012

Bullet Integration Todo List (Poll)

After reviewing the state of the preview I posted yesterday and comparing this against the demos posted by various people over the past 2 years (for what they've been doing and/or need), here is the set of current unsupported functionality that would need to be implemented before this is really suitable for mass consumption:
  • Ability to apply rigid bodies to large arrays of objects. These are often similar in many regards, be it shape or colour, and usually need to have the same settings applied to all. E.g. bricks or blocks making up some structure.
  • Ability to use rigid body constraints to define how things hold together.
  • Stability and integration usability polish. This includes all kinds of book-keeping things such as ensuring that copying, deleting, and changing associations all work without any crashes or weird behaviour.  


In addition to these core demands, we have a few other "nice to haves", but which we could probably do without in an initial release:
  • Tighter integration with the scene evaluation loop, to allow other physics systems and tools to interact with rigidbodies somewhat. In particular, this is supposed to allow rigid bodies to be used to control other objects (e.g. ragdolls), but also to trigger drivers and other stuff. I'm not sure whether this perhaps even needs to go in the above category of "must have"'s, since this could also potentially end up being one of those things that will have to wait on the depsgraph project providing us with more powerful ways of setting up scene graphs to support this kind of stuff easier.
  • Ragdoll support - potentially will be a subset of constraints + tighter evaluation loop integration.
  • Pointcache support - for faster playback of complicated scenes.
  • Fracturing frameworks integrated with this? Related to how we manage large numbers of related objects I guess...
So yeah, this is probably the grand roadmap for what needs to be done. It should be noted that the items on top will probably require a bit of refactoring of the data structures, depending on the approach taken. The approach taken with these depends quite a bit though on how as artists you'd like to tackle such scenarios (dupli's with some suitable initial framework? individual objects placed into such a configuration?).

Comments? Suggestions for other key things missed off here?  
Posted by Aligorith at 1:05 PM
Labels: , , ,

15 comments:

  1. MoguriJanuary 4, 2012 at 4:42 PM

    If you add ragdoll or fracture code, I would really like to see it setup in such a way that the BGE could hook into it as well.

    ReplyDelete
  2. CarloJanuary 4, 2012 at 5:00 PM

    Baking out the simulation is also helpful for network rendering...

    ReplyDelete
  3. AnonymousJanuary 5, 2012 at 2:03 AM

    Are you able to have animated objects simulate with dynamic objects and be able to bake the two together. I have not been able to achieve this with current version of blender. please advise if possible.

    ReplyDelete
  4. Gianmichele MarianiJanuary 5, 2012 at 2:03 AM

    I thought you were holding of on Bullet cause there's an imminent dep graph update. Since you're talking about geometry cache, why not jump the ship and have a look at Alembic? From this one the whole Blender can probably benefit.

    ReplyDelete
  5. tungeeJanuary 5, 2012 at 2:39 AM

    ALigorith, this would be awesome!
    If this would be bundled with the Phymec-tools ( http://www.youtube.com/watch?v=FIPu9_OGFgc&list=UUSO_wccIgWaT7Zha99EZpEg&index=1&feature=plcp )
    than this will push blender to another level!

    I coolected all related links to this tools on blenderartist: http://blenderartists.org/forum/showthread.php?240109-Voronoi-shattering-tools-by-Phymec&highlight=phymec

    Here is the link to the democode of phymec : http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=17&t=7707

    Thanx

    Ps.: I would be nice if you could make answers to your posts ;)

    ReplyDelete
  6. fahrJanuary 5, 2012 at 5:40 AM

    Hi Aligorith! Another feature I think is important is the ability to start and stop physiscs on objects. Or to be able to animate an object manaully, then switch on the physics, having it inherit the keyframed animation of the previous frame. For example, keyframe a box moving on the x-axis, and rotating on it's local y. Then switch on physics while it's still moving. The sim would treat it's rate of motion as velocity and act accordingly. That would be huge.

    Secondly, +1 for alembic. It acts as an excellent geometry cache that could help blender for all sims, even caching characters for faster interactive playback, or exporting/importing with other apps. Can't stress enough how important alambic could be for blender moving forward.

    Thanks for the efforts!

    ReplyDelete
  7. gustavJanuary 5, 2012 at 6:40 AM

    I think more fancy features can wait. It would be awesome just to have the soc branch features in trunk. Thanks!

    ReplyDelete
  8. fahrJanuary 5, 2012 at 9:14 AM

    Gustav: Yes, you are right. Let's start there. :)

    ReplyDelete
  9. 3duaunJanuary 5, 2012 at 9:16 AM

    +1 for Phymec !! Absolutely amazing & useful physics tech.

    I'd also like to add another +1 for alembic, this would REALLY speed up Blender internals with its native vert cacheing abilities, and allow for the added benefit of better blender integration into professional pipelines.

    Animating an even slightly detailed rig in blender can take so long to update, compared to other 3d apps, cant wait for the depsgraph rework,

    ReplyDelete
  10. JeromeJanuary 5, 2012 at 12:21 PM

    I would be happy to just be able to play with the bullet integration as is.
    Unless it is very unstable.

    But,I would also like some sort of fracturing tools. The Fracture tools addon crashes blender at around >150 objects.

    Thanks for updating all of us. I can see light at the end of the tunnel. :)

    ReplyDelete
  11. -jayJanuary 6, 2012 at 6:48 AM

    I'm guessing ragdoll support would act as dynamic, springy constraints? That would be a nice addition if so.

    ReplyDelete
  12. Eonmach RealmJanuary 7, 2012 at 12:00 PM

    Bullet physics without the GE involved?
    sounds awesome. Even minimal Miku Miku Dance 3D app uses bullet and does it brilliantly. Is not open source, but freeware. Try it with Miku Hatsune any other character... just works.
    Also, Ton talked about depgraph refactoring in a developer log...you should be in for sure!!!

    ReplyDelete
  13. daniliusJanuary 12, 2012 at 9:05 PM

    This might sound weird, but bullet physics would make many scenes that much easier to build, especially those where one wants things scattered around in a natural manner. Think pouring out a load of coffee beans, or throwing things around in a room.

    ReplyDelete
  14. icchaJanuary 25, 2012 at 11:00 PM

    stability an polish is definitely number 1 for production.

    some side wishes:
    I would love to see some ability to bind events to collisions. Like on first hit of an object/particle start some animation (strip) or something.
    Also, It would be great if bullet was used for all simulation it supports - rigidbodies, softbodies, spm fluids, cloth. Its weird gameengine cloth works much better than the one in blender, and it is able to interact with rigidbodies in both directions...

    ReplyDelete
  15. James CampbellMarch 23, 2012 at 9:47 PM

    One of the key areas not looked at would be the application of secondary motion for character work. At the moment we have to use soft bodies and bake the results but dynamic bones would sovle this (but still have baking for network rendering though).Think jiggle bones similar to the 3ds max flex modifier. Also as mentioned having the ability to influence drivers would be amazing.

    ReplyDelete

Subscribe to: Post Comments (Atom)