The function that controls this is in src/dlls/physics_collisionevent.h:
int AdditionalCollisionChecksThisTick( int
currentChecksDone )
{
//CallbackContext check(this);
if ( currentChecksDone < 1200 )
{
DevMsg(1,"VPhysics Collision detection getting
expensive, check for too many convex pieces!\n");
return 1200 - currentChecksDone;
}
DevMsg(1,"VPhysics exceeded collision check limit
(%d)!!!\nInterpenetration may result!\n", currentChecksDone );
return 0;
}
If you get this message:
DevMsg(1,"VPhysics Collision detection getting
expensive, check for too many convex pieces!\n");
It means you're exceeding the design limits of the collision system.
It's letting you know that you may get performance problems.
If you get this message:
DevMsg(1,"VPhysics exceeded collision check limit
(%d)!!!\nInterpenetration may result!\n", currentChecksDone );
Then the physics system thinks there's a bug or infinite loop of some
kind and it's turning off collisions. So you can certainly get the
behavior you describe if you see this message.
The messages should be unrelated to system load. There isn't any
dependency there anyway. Vphysics does simulation at 66Hz regardless of
system load (unless you've changed the tick interval for physics) and
the limits are all per physics tick. You can always change this
function to do several more checks per tick if it makes sense for your
mod.
That said if you have something you suspect is related to system load,
just run with host_framerate 10. That should be the lowest framerate
the system will achieve since longer timestamps are clamped to 100ms.
Jay
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Saturday, July 01, 2006 10:57 PM
> To: hlcoders@list.valvesoftware.com
> Subject: RE: [hlcoders] Physical Mayhem bug again! Death by
> Touch considered harmful??
>
> Ah thanks very much. Those messages were from dm_resistance,
> so perhaps you can pass the message along to whoever at Valve
> made that map. :)
>
> (I still have the asserts in place from the first HL2DM SDK
> Physical Mayhem bug concerning ShouldCollide, so I haven't
> hit that issue.)
>
> After a few hours of testing, I've determined that the repro
> scenario has nothing to do with any code changes I've made.
> It turns out that it's caused by running a debug version of
> the server.dll, and having system cpu usage exceed 25% or so.
> So far it doesn't repro in release mode, even with the
> higher cpu usage. The reason it took 4 players to repro, is
> because in debug mode that's about where srcds.exe starts
> using 25% cpu.
>
> I can artificially launch some other program on the server
> box to use cpu, and it, combined with a debug server.dll,
> repros the vphysics bug. It's like... vphysics or one of the
> other core dlls says "hmm cpu load on the box is high, I
> don't have time to check whether these two objects should
> touch, so I'll just let them slide through each other"... Is
> there something like that in the core dlls side of things?
>
> The reason it's intermittent is that once cpu goes under the
> threshold vphysics suddenly wakes up and starts doing
> collisions correctly again.
>
> For now the work-around is apparently "never use debug
> versions of your mod."
>
> Now that I write this I'm starting to think it was no
> coincidence that I found that "VPhysics Collision detection
> getting expensive, check for too many convex pieces!" thing.
> That message seems to hint at the sort of vphysics logic I
> speculated on above.
>
> At 2006/07/01 06:03 PM, Jay Stelly wrote:
> >> The only physics-related console messages are:
> >>
> >> Object attached to Physcannon has no physics object SOLID_VPHYSICS
> >> static prop with no vphysics model!
> >> (models/props_foliage/shrub_01a.mdl)
> >> SOLID_VPHYSICS static prop with no vphysics model!
> >> (models/props_buildings/row_industrial_cluster.mdl)
> >> SOLID_VPHYSICS static prop with no vphysics model!
> >> (models/props_foliage/tree_deciduous_card_01_skybox.mdl)
> >>
> >> I'll try to figure out if those are actually bad or just overly
> >> verbose informative messages.
> >
> >These are warnings for the level designer who built the map. The
> >entities are set to use a vcollide, but they don't have one so it is
> >being disabled. There's no bad behavior other than missing
> collisions
> >that may be expected.
> >
> >Jay
> >
> >_______________________________________________
> >To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> >http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
