Forums

I forgot to add that I'm using a revision from few months back.
Surface rollingDrag is ok, I set it at 80 or more on terrain outside road.

So Tread is a property of tire, and those 2 friction values come from surface.
Most cars have it like so
[ tire-rear ]
tread = 0.0
this would mean that only one friction value is used. Should this tread value be different for gravel tires ?
Or is it the same, just to use it with tread = 0 and changing only FrictionNonTread for surfaces (that is how I've set it for now) ?

Quote:So Tread is a property of tire, and those 2 friction values come from surface.

Yes.

Quote:Most cars have it like so
[ tire-rear ]
tread = 0.0

There are tires with tread = 0.25 (touring tires).

Quote:this would mean that only one friction value is used.

The friction factor(coefficient) is interpolated linearly between frictionTread and frictionNonTread according to the tire tread value(0.0 - 1.0).

Quote:Should this tread value be different for gravel tires ?
Or is it the same, just to use it with tread = 0 and changing only FrictionNonTread for surfaces (that is how I've set it for now) ?

tread = 0 means surface.frictionTread is ignored.

Looks like good progress! You should show some of the track editor in a video.

I do think that some method of altering the pacejka coefficients for different surfaces is probably needed for realistic rally-style tracks.

I've made a video tutorial for Track Editor. It's in 2 parts, 18 minutes total.
Hope that editing will be clear now. All constructive comments or ideas are welcomed.

Featured on Free Gamer!
http://freegamer.blogspot.com/2011/01/st...r-and.html

Hi again. We are now 3 developers.
Game and Editor now run on Linux too (and compile using CMake), there is also a package for Ubuntu for quick install.
We have repositories for code, data and tracks on Mercurial hg (they work fine), at our project's Home page:
http://code.google.com/p/vdrift-ogre/

Finally trees have collision, but this lowers fps somewhat from 83 to 72 in jungle, (12ms instead of 4ms for physics simulate). I can't imagine this is normal so, I think there souldn't be such a penalty.
Total now 49 tracks, you can check screens from newest ones on gallery:
https://picasaweb.google.com/CryHam/StuntRallyVer10#

Looks great!

Have tried to compile it under windows but gave up on trying to build mygui.

Anyways, in SceneTrees.cpp line 238 add col->setActivationState(DISABLE_SIMULATION);

To get an idea where you are spending your time, in collision_world.cpp after world.stepSimulation(dt, maxSubsteps, fixedTimestep); add CProfileManager::dumpAll();

Post the output here, I'll be glad to help.

Thank for help NaN.
I've added this in code, didn't change much.
I had 12ms with very many trees.

On my test track in jungle I have 3696 collision shapes added for vegetation. It shows around 6 ms.
Should there be one btCollisionObject for each tree (like it is now) or should they be somehow grouped ?
And the profiled log outputs this:

----------------------------------

Profiling: Root (total running time: 4.650 ms) ---

0 -- stepSimulation (99.96 %) :: 4.648 ms / frame (1 calls)

Unaccounted: (0.043 %) :: 0.002 ms
...
----------------------------------
...
Profiling: stepSimulation (total running time: 4.648 ms) ---
...
0 -- synchronizeMotionStates (0.04 %) :: 0.002 ms / frame (2 calls)
...
1 -- internalSingleStepSimulation (98.49 %) :: 4.578 ms / frame (2 calls)
...
Unaccounted: (1.463 %) :: 0.068 ms
......
----------------------------------
......
Profiling: internalSingleStepSimulation (total running time: 4.578 ms) ---
......
0 -- updateActivationState (0.00 %) :: 0.000 ms / frame (2 calls)
......
1 -- updateActions (22.80 %) :: 1.044 ms / frame (2 calls)
......
2 -- integrateTransforms (0.09 %) :: 0.004 ms / frame (2 calls)
......
3 -- solveConstraints (6.49 %) :: 0.297 ms / frame (2 calls)
......
4 -- calculateSimulationIslands (3.25 %) :: 0.149 ms / frame (2 calls)
......
5 -- performDiscreteCollisionDetection (67.06 %) :: 3.070 ms / frame (2 calls)
......
6 -- predictUnconstraintMotion (0.13 %) :: 0.006 ms / frame (2 calls)
......
Unaccounted: (0.175 %) :: 0.008 ms
.........
----------------------------------
.........
Profiling: solveConstraints (total running time: 0.297 ms) ---
.........
0 -- solveGroup (1.68 %) :: 0.005 ms / frame (2 calls)
.........
1 -- processIslands (35.69 %) :: 0.106 ms / frame (2 calls)
.........
2 -- islandUnionFindAndQuickSort (59.26 %) :: 0.176 ms / frame (2 calls)
.........
Unaccounted: (3.367 %) :: 0.010 ms
............
----------------------------------
............
Profiling: solveGroup (total running time: 0.005 ms) ---
............
0 -- solveGroupCacheFriendlyIterations (40.00 %) :: 0.002 ms / frame (2 calls)
............
1 -- solveGroupCacheFriendlySetup (40.00 %) :: 0.002 ms / frame (2 calls)
............
Unaccounted: (20.000 %) :: 0.001 ms
.........
----------------------------------
.........
Profiling: performDiscreteCollisionDetection (total running time: 3.070 ms) ---
.........
0 -- dispatchAllCollisionPairs (19.64 %) :: 0.603 ms / frame (2 calls)
.........
1 -- calculateOverlappingPairs (0.07 %) :: 0.002 ms / frame (2 calls)
.........
2 -- updateAabbs (80.23 %) :: 2.463 ms / frame (2 calls)
.........
Unaccounted: (0.065 %) :: 0.002 ms

----------------------------------

You also have to:
in the collision_world constructor to reduce
I thought it was already disabled in the old implementation.

Great this was it. I get around 3 ms now, so half of that before. Thanks.

Should I also update to latest bullet from svn ? (this here is 2.76) and switch to dynamic bvt broadphase like in here:
http://vdrift.net/Forum/viewtopic.php?t=...c&start=15

Current profiling:
----------------------------------

Profiling: Root (total running time: 1.874 ms) ---

0 -- stepSimulation (99.95 %) :: 1.873 ms / frame (1 calls)

Unaccounted: (0.053 %) :: 0.001 ms
...
----------------------------------
...
Profiling: stepSimulation (total running time: 1.873 ms) ---
...
0 -- synchronizeMotionStates (0.11 %) :: 0.002 ms / frame (2 calls)
...
1 -- internalSingleStepSimulation (96.64 %) :: 1.810 ms / frame (2 calls)
...
Unaccounted: (3.257 %) :: 0.061 ms
......
----------------------------------
......
Profiling: internalSingleStepSimulation (total running time: 1.810 ms) ---
......
0 -- updateActivationState (0.00 %) :: 0.000 ms / frame (2 calls)
......
1 -- updateActions (50.99 %) :: 0.923 ms / frame (2 calls)
......
2 -- integrateTransforms (0.17 %) :: 0.003 ms / frame (2 calls)
......
3 -- solveConstraints (15.52 %) :: 0.281 ms / frame (2 calls)
......
4 -- calculateSimulationIslands (6.85 %) :: 0.124 ms / frame (2 calls)
......
5 -- performDiscreteCollisionDetection (25.75 %) :: 0.466 ms / frame (2 calls)
......
6 -- predictUnconstraintMotion (0.39 %) :: 0.007 ms / frame (2 calls)
......
Unaccounted: (0.331 %) :: 0.006 ms
.........
----------------------------------
.........
Profiling: solveConstraints (total running time: 0.281 ms) ---
.........
0 -- solveGroup (1.78 %) :: 0.005 ms / frame (2 calls)
.........
1 -- processIslands (33.45 %) :: 0.094 ms / frame (2 calls)
.........
2 -- islandUnionFindAndQuickSort (62.99 %) :: 0.177 ms / frame (2 calls)
.........
Unaccounted: (1.779 %) :: 0.005 ms
............
----------------------------------
............
Profiling: solveGroup (total running time: 0.005 ms) ---
............
0 -- solveGroupCacheFriendlyIterations (0.00 %) :: 0.000 ms / frame (2 calls)
............
1 -- solveGroupCacheFriendlySetup (40.00 %) :: 0.002 ms / frame (2 calls)
............
Unaccounted: (60.000 %) :: 0.003 ms
.........
----------------------------------
.........
Profiling: performDiscreteCollisionDetection (total running time: 0.466 ms) ---
.........
0 -- dispatchAllCollisionPairs (87.12 %) :: 0.406 ms / frame (2 calls)
.........
1 -- calculateOverlappingPairs (0.43 %) :: 0.002 ms / frame (2 calls)
.........
2 -- updateAabbs (12.45 %) :: 0.058 ms / frame (2 calls)
.........
Unaccounted: (0.000 %) :: 0.000 ms

----------------------------------

Quote:Should I also update to latest bullet from svn

You don't have to. There will be a 2.78 release soon I think.

Quote:dynamic bvt

You won't notice much difference performance wise. The good thing about dbvt is that it doesn't require explicit world bounds.

Okay, thanks for advice.
It's now 65 fps without vegetation collision and 60 fps with it. And there were already 5668 vegetation shapes (1.5x the default value).

I installed ubuntu package via ppa repository and when I launch I get :


I don't know if this is the right forum to post it but I did not find a better one.

We had some issues with seg faults today. This is probably the best place to report any problems:
http://code.google.com/p/vdrift-ogre/issues/list
But it needs a gmail account and google code user to post there.

I don't know much from your log. It seem that I may be connected to either GPU driver or Ogre is installed twice and plugin entries are wrong then.
What GPU do you have ?
Don't know if it's the same problem:
http://code.google.com/p/vdrift-ogre/iss...tail?id=33

Tried under windows, yeah, thats cool, drift on zandvoort was awesome!