Hi Norbo
thanks for the new update...we've updated without problems and as you anounced with a performance boost
I have some problems with a terrace modelmesh!I think the lag/massive decrease of fps is caused by the small gaps between shelves. Please look at this picture...
Sometimes when i just stand still the fps inceases to normal. but just one step deceases the fps again!
I've tested a plane(streched box) which i layed direct of the terrace!Without success When i put the plane > 100 heigher on y its okay. Smaller values also dont suceed. But i think you know that i can't to the plane heigher then around 5.
So do you know what could be the problem or better to say how i could solve this. btw i don't set any values to the box so default. and to the map(trianglestaticgroup) just a friction of .6f!
the only other soultion i think which could succeed is that i exclude the modelmesh part from physic and add a plane insteed. But i think there must be a better way
The geometry alone of that mesh doesn't look complicated enough to cause any issues (unless each plank is composed of 2,000 triangles or something), so I think it might be similar to your previous problem with the ramp slowing down. If the triangles are added into a very large number of PersistentUniformGrid cells, it will slow down quite a bit.
You can test to see if this is the problem by passing in a much larger number to the PersistentUniformGrid constructor, such as 10000 instead of 10. If you have many active dynamic objects, this will cause a significant but constant slowdown. If you still notice an unusual drop in performance on the planks specifically, then it's something else. If not, then it is most likely the scale of the model.
The two ways to address this issue are to either increase the cell size (maybe not as much as 10000, but something to fit your simulation), or scale everything down. Generally, keeping to a smaller scale where 1 unit is approximately 1 meter makes everything work well. You can scale StaticTriangleGroups by changing their worldMatrix property.
Okay i increase the cells and now it works perfect
But there is a theoretical problem for me
We also have had some bigger drop downs at the wallbrick when the character or primitvies like spheres collides with. Okay so the wallbrick is made with large tris so i understood that now the problem is solved there because each triangle is now added to less grid cells, correct?!
But the tris of each planks of the terrace are only 6 and they are scaled normal(not such like the ramp). So before i used 20 cells and i think that the terrace at all is registered in maybe 2 or 3!
Yes, in theory, the reason why it got faster is because each object is in fewer cells. Generally the grid size is picked so that a single object doesn't inhabit more than a few cells (usually a single cell, but it will occupy more when crossing the boundary between two or more other cells).
Does each plank have only 6 triangles, or is it only 6 units long?
A size of 10 should have worked perfectly in the case of 6 unit long triangles. Generally you will start noticing slowdowns once you get into the thousands of occupied cells for a single object (the ramp had millions if I remember correctly). If the planks were that small, I'm not really sure why the broadphase change would have sped it up.
As you can see 6 triangles with large units long
But i do not understand why now the the cellsize solved the problem!For the wallbrick it's clear for me no problem but here?!because at the wallbrick there is one triangle near half as long the whole terrace.
btw. we know that we have a scale problem in general and we will solve this in the near future
At those sizes, a single one of those triangles would occupy something around 500 to 4000 cells (for a size 10 cubic cell). For each plank, there's 6 of these triangles, requiring as many as 20000 cell updates per frame depending on the way the triangles are set up. If the plank isn't axis aligned, this number would balloon significantly. A 10000 size grid cell takes this number down to just a couple of cells occupied per triangle.
The system can be thought of drawing a shape on gridded graph paper. A very large shape overlaps a lot of the squares on the paper since the cells are so tiny in comparison. In 3D, cubic voxels take the place of square grid cells, adding another dimension to keep track of.
This particular problem should be addressed by a SAP implementation I'm working on since it does not create more work as the scene gets larger. It's still a good idea for collision detection to keep things down to size though
When i put the plane > 100 heigher on y its okay. Smaller values also dont suceed. But i think you know that i can't to the plane heigher then around 5.
