Softbody Mesh Problem

ruzhenchao
Posts: 4
Joined: Wed Oct 21, 2009 6:26 am

Softbody Mesh Problem

Post by ruzhenchao »

Hey!
I am new here ! Recently I want to use softbody in my Game , I use a kind of Ogre Engine , so I want to update the Ogre
Mesh base on the softbody every time after the bullet physics simulation.
The way I thought first is like this:
after simulation , I visit all softbody's nodes and write data , such as position and normal , into the vertexdata.
But I didn't do like that , I think that copy data to vertexData will lose time,So I thought another method that can update vertexData when updating softbody.
The method need to modify the softbody' s code: instead of using two extra btVector3 data to store the position and normal data for nodes in softbody , I use two btVector3 pointer to store the positon and normal address that in ogre vertexBuffer.
We must modify the btVector3's code too, because the btVector3 is 4*4 bytes , and we must make sure that the btVector3's function will not modify the forth data(i.e the w component) which in vertexBuffer may be represent other data , normal.x for example .
So after modify the bullet softbody's code , all the node will store the address of position and normal in vertexBuffer , all the simulation will affect the vertexBuffer .
The simulation and the speed is OK when only simulate with softbody ,
But...unfortunately..
When collision between softbody and rigid body (the scene is like this : a soft plane fall on the static plane rigid body), it will become very very slow !
Am I Wrong? Do I need to do extra things to save the performance!
Do you have idea about it?
Thanks
Sorlaize
Posts: 18
Joined: Sun Mar 29, 2009 5:00 pm

Re: Softbody Mesh Problem

Post by Sorlaize »

How about writing a custom shader to draw the softbody?

Does the performance behave the same if you don't draw it at all?
ruzhenchao
Posts: 4
Joined: Wed Oct 21, 2009 6:26 am

Re: Softbody Mesh Problem

Post by ruzhenchao »

Sorlaize wrote:How about writing a custom shader to draw the softbody?

Does the performance behave the same if you don't draw it at all?
Thanks for your reply!

Unfortunatily!The performance is still bad when I don't draw the softbody.

And I render everything with custom shaders!
Sorlaize
Posts: 18
Joined: Sun Mar 29, 2009 5:00 pm

Re: Softbody Mesh Problem

Post by Sorlaize »

No problem, I should have been more clear: I meant, how about writing a shader for drawing the vertices directly from the softbody, and not copying them to Ogre's format at all?

If you are creating a new vertex buffer object on the gpu every frame it's going to be very slow, I'm not sure how you are doing it but sending a list of vertices every frame seems a better way.

Ogre should have a way to access this through its drawing interface, in the case of DirectX:
http://doc.51windows.net/Directx9_SDK/g ... tiveUP.htm
This method is intended for use in applications that are unable to store their vertex data in vertex buffers.
And Ogre will allow you to define your own vertex declaration with the vertex elements (e.g. float3 for btVector3) for use with your shader. You then simply ensure that you're interpreting the data correctly in the shader.

How are you getting the data at the moment?
ruzhenchao
Posts: 4
Joined: Wed Oct 21, 2009 6:26 am

Re: Softbody Mesh Problem

Post by ruzhenchao »

I create a vertexbuffer on main memory side not on the gpu side, that i can modify the vertex data directly!
And I construct a softbody nodes according to the vertexbuffer data(the vertex data must have position element and normal element ); a softbody node stores the pointers of the position and normal , so when softbody changed , the vertexbuffer changed(i.e the softbody node 's position and normal store in vertexbuffer ).
Your approach is good too,But it can't use vbo .
Sorlaize
Posts: 18
Joined: Sun Mar 29, 2009 5:00 pm

Re: Softbody Mesh Problem

Post by Sorlaize »

Hmm, vbo's can't always make things faster, so it's worth a try ^^

Maybe if your softbody doesn't collide with many things, it could be simulated directly on the gpu? It seems it would be more suited for that.