If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I also made a TODO list that's a mixture of bugs I want to fix and features I want to implement in the near future:http://wiki.blender.org/index.php/Us.../GSoC2012/todo
It's in no way complete of course an I'll be adding to (and removing from) this list all the time.

Right now I'm working on implementing point cache for the rigid body simulation. I's one of the more important tasks that takes time but unfortunately there is not much interesting I can show right now.

don't have to go through the clumsy process of running their simulations inside blenders game engine.

sounds good! exactly what's needed.

...when we have a stable base.

also good, I'm not that into C code, but will you make a kind of blender C API towards bulletphysics C. so when they [bulletphysics codes] updates with new features or renames function you can just fix the Blender C API to re-route and make it very robust and extensible? it might confuse though people similar with bulletphysics but new to blender code. other hand blender will be more stable and don't change so much for us similar to blender.

ideal scenario when they [bulletphysics coders] release a new version we can have it updated fast in blender.

Regarding all that what version will get into blender? http://bulletphysics.org/wordpress/?p=340 has some OpenCL acc. done! on the GPU. (much much much more than I've though they would put into bullet before 3.X versions. mainly thanks to that guy Takahiro Harada it's running pretty much 100% on GPU)

btw. you're GSoC is kinda my favorite in the list of stuf going to be worked on this GsoC.

Thank you very much for doing this! and congrats for the GSoC funding!

cool cool but if they gets it to run on GPU it will outperform CPU multi threading anyday. and official statement is that by 3.X it will be running on GPU but already the newest version seems 100% ready for OpenCL.

best case would be using newest bullet for integration.

demolition/fracturing

there are some python scripts, that does it. but python being python. a C API function to call from scripts to fracture would be way faster! and cooler. hope you get the time to do this.

Thank you all for the nice responses!
I'll answer the questions below.

Originally Posted by aermartin

also good, I'm not that into C code, but will you make a kind of blender C API towards bulletphysics C. so when they [bulletphysics codes] updates with new features or renames function you can just fix the Blender C API to re-route and make it very robust and extensible? it might confuse though people similar with bulletphysics but new to blender code. other hand blender will be more stable and don't change so much for us similar to blender.

We have to write a C-API anyway since blender is written in C and bullet is C++.
However bullet's API doesn't really change, the reason we use a somewhat outdated version is probably because nobody bothered to update it (for whatever reason).

ideal scenario when they [bulletphysics coders] release a new version we can have it updated fast in blender.

Regarding all that what version will get into blender? http://bulletphysics.org/wordpress/?p=340 has some OpenCL acc. done! on the GPU. (much much much more than I've though they would put into bullet before 3.X versions. mainly thanks to that guy Takahiro Harada it's running pretty much 100% on GPU)

I hope we can use the latest version.
But you'll have to be patient with the GPU stuff though. I know it's flashy but it's just not ready yet. When bullet 3.x gets released I'll look into it of course.

btw. you're GSoC is kinda my favorite in the list of stuf going to be worked on this GsoC.

Thank you very much for doing this! and congrats for the GSoC funding!

I'm flattered

Originally Posted by aermartin

cool cool but if they gets it to run on GPU it will outperform CPU multi threading anyday. and official statement is that by 3.X it will be running on GPU but already the newest version seems 100% ready for OpenCL.

Originally Posted by bashi

This GPU integration would be awesome. Working a lot with Simulations - my mouth is getting wet ;-)

It's not that simple unfortunately.
You cannot just flip a switch and have multi-threading.
There are many issues that need to be resolved first (Does it run on all platforms? Does it support all the features we need? Are there any bugs? ...) so it will be done towards the end of the project when everything else works reliably.

It's pretty much the same for the GPU stuff and as I mentioned above it's just not ready yet so we'll have to wait for bullet on that.
I want it to be as fast as possible of course but stability always comes first.

Originally Posted by aermartin

there are some python scripts, that does it. but python being python. a C API function to call from scripts to fracture would be way faster! and cooler. hope you get the time to do this.

We have a couple of people that work on this stuff so hopefully one of them will pick this up but if nobody else does it I'll work on it eventually. Having a streamlined workflow for this is really important to me.

Originally Posted by bashi

(I'm still dreaming of combine all sorts of simulations, like (fluid)particles with rigid-body with smoke and so on. But that's another Topic ;-)

Yeah maybe it can be done as part of Lukas Tönne's particle node work but it will definitely have to wait after GSoC.
Also thanks for the build bashi

We have a couple of people that work on this stuff so hopefully one of them will pick this up but if nobody else does it I'll work on it eventually. Having a streamlined workflow for this is really important to me.

Not sure if its possible during your GSOC, but it would be sweet if you could add in a fracturing option on each mesh... so that if it receives a force greater then a certain amount it fractures accordingly, based on where the force is....

@sergof nice to hear! no I know multi-threading isn't so easy. Thanks for your endeavors and I agree. Let the bulletphysics team sort that out and you focus on blender integration. I'm super happy if you manage just to get latest version in and make it so you guys can keep update phase with bullet. That in itself would be such a huge +1 interwebs for this GSoC project.

Can't wait until bulletphysics 3.0 is out and this GSoC is over it's gonna be so awesome!

Not sure if its possible during your GSOC, but it would be sweet if you could add in a fracturing option on each mesh... so that if it receives a force greater then a certain amount it fractures accordingly, based on where the force is....

I mentioned this in my proposal.
It would be neat to have a system that breaks objects dynamically controlled by material properties. However it's not trivial to implement and is definitely out of the scope for this years GSoC.
I might get to implement breakable constraints however, they would allow pieces to stick together and only break apart when a strong enough force acts on them.

Sorry to ask but honestly, I'm a bit confused.
The Bullet GSOC project is really great don't get me wrong but why can't we just start with what Phymec started with. ( for those who wonder what I'm talking about, just google/Youtube Phymec bullet physics)

I mean the code seam well advanced with what we can see on all his youtube vids he made it just seem to need some tweaking and some blender integration I guess (some user friendly interface possibly).

Is it because no one is able to contact him? That would explain it all but it would be a shame to waste all this coding.