StaticTriangleGroup; ramp<->Character

[J2T]

Hello,

first off all i have a theoretical question to the StaticTriangleGroup and the trianglesize!I noticed that when the character walks on long stretched triangles (a img could help) the framerate(frametime) decreases very much!My artist did smaller tris and now it works fine!
So i don't understand why the calculations on stretched big tringles are more intensive!?I thought it should be inverted so on smaller(more) triangles are the calucaltions more intensive!?

I also have much perfomance problems with ramps. Pleaso look at this picture: ramp_1 I hope u can see the ramp There are also stretched trinagles. When the character goes up the FPS decreases to under 10 FPS
We did a new version for the ramp like this: better version ramp_1 I hope u can see there are more trinagles and not stretched. Now the framerame 'only' decreases to the half.
Antoher ramp with only 2(4) tringles and the same problem. ramp_2

Whats the problem with such ramps?Are there to many forces?I hope u understand my problem and can give me some advice on how to handel this!

btw: at the moment everythins is okay so far. stairs, normal objects etc. but i also noticed that the character goes in the air when he walks over a ramp or sometimes a stair!Thats another point i have to rewrite in the charactercontroller. Maybe this could solve the perfomrance problem then?!

thanks for ure advice

[Norbo]

Those speeds are certainly not expected for your scene complexity. I'm not sure what could cause such a significant drop right now. Approximately how large were the offending triangles (in units)?

As for the character going into the air, do you mean it steps up too far and then has to fall down a significant distance, or does it do something else strange?

It's 6 AM here right now, so I'll sleep on it and see what I can come up with.

[J2T]

Here are the picture out of maya with the unitinformations: click me!

I mean when i go slow step by step the stairs everything is okay. But when i go faster after one or two singlestairs the character gets....uh how could i say...maybe an impulse and fly up/away!Not direct up(0,1,0) more in the movementdirection!

Antoher issu is at the ramp. When i go up the ramp at the end the character fly in the movementdirection and doesn't go normal on the 'flat-trail'!But i think thats normal at the moment in the character controller because i think u write it that an object flys after pushing over a ramp(like in Simulation 18-Spaceship)?!So in other word i need a Character that goes further normal after reaching the end of the ramp. btw here another picutre showing the end of the ramp where the character begins to fly: picture
But as i wrote i think i can solve this for my own...i hope!If u have suggestions or can me say quickly where i have to search in the charactercontroller i won't say no

So far good night

[Norbo]

If you're dealing with shapes on the scale of many thousands of units, that will cause issues.

The slowness you observed came from the huge number of broadphse grid cells occupied by the triangles. I'm guessing your grid size is still something like 10 units, so that triangle could be listed in millions of cells.

It's likely that all of the issues you are observing are caused by the scale. The engine is tuned to the scale of 1 unit = 1 meter (while this doesn't need to be held to exactly, it's good to stay on a similar order of magnitude). Basically, if you took that world and scaled it down, everything should work fine.

[J2T]

Thanks for this explainations!

But i'm a bit confused
I understand now the problems with the big scaled tris.
But when u're looking at the last picture(ramp_2) of the ramp the was only 2 small tris. Not greater then or ground and the perofmace decreases!But now i scaled the hole map and everything is okay

btw. i solved the 'bug' and now the char doesn't go in the air at the end of the ramp and goes straight through on the flat

Now there is only one issu left. When i setup the stepheight to go on stairs our char goes sometimes over our fences. I will do another detector/shape right in the middle of the character to solve this!

So far thank you...

[Norbo]

How tall are your stairs versus your fence, and how high is your stepheight? Also, what are the dimensions of the body capsule of the character?

[J2T]

Hi,
a good question i actually playing just around with the settings. But your question to the dimensions brings me to a good idea. Now i set the skinWidth to 12f and now the character don't go over the fences!But i actually do not know the real differencee between the skinWidth and bodyRadius?!
And yes the difference between the bodyDetecotr and the the feetdetector is clear but i also do not know exactly what the bodyshape is for!

But i will seperate the bodyDetector from the stepHeight!Because our character must walk on y=0!When i define a stepheight the bodydetector and even the shape grows and so the character stands higher then y=0!

[Norbo]

skinWidth is the body shape's collision margin. You can think of it as making the core shape a bit fatter. The normal value for this is usually around/below .1; is it possible that the scale is still too large? The reason that the skin width and body radius are separated here (despite the collision margin having the effect of a larger radius) is to both provide 'fattening' for shapes that aren't capsules and to improve robustness when undergoing stressful collisions (being shoved into a too-small crack and such).

bodyRadius is the radius of the core capsule itself. If you think of the capsule as a sphere swept along a line, the bodyRadius is the radius of that sphere.

bodyShape interacts with the world and provides collision detection/response. It floats above the ground a little bit to allow support candidates (things that can be stepped on and support the character) to go beneath it without first hitting the capsule. Despite this, the body capsule does not actually extend higher than the total body height; the capsule's height has the stepheight removed from its length. If you wanted to attach graphics to a character, it would be best to not center it on the character's capsule with the capsule's dimensions. Instead, you can use the whole character's center and dimensions.

[J2T]

Hi its me again

I read in the license that your interest in the results
Here they are: http://de.youtube.com/watch?v=yABfuT2AFbg

Btw is there a special reason for this license?Why you don't open the source under a OpenSource-Licence?!

[Norbo]

Very nice game there, keep it up

The main reasons for being closed source were the target developers, the consideration of the benefit that can be gained through the source versus the cost of additional maintenance of the source, and legal safety.

I didn't feel that the problems that could be fixed only through access to the source code would be problems that other developers would want to deal with, and I've tried (and will continue to try) to make the engine as extensible as possible so that developers don't need to work inside the engine to add something that they want. Some of the commercial licenses actually do offer the source code as an option to developers who need it.

You might have noticed that I do release some parts of the engine as open source under the zlib-style demos license, like the character controller. These are generally parts to which I don't feel I can add sufficient extensibility to match the needs of most or all developers. Sometimes, the value of the source as a learning tool also comes into play (such as the source to one of the force field classes on the forums).