Ok, the "too many convex pieces" message only occurs on that one spot in
dm_steamlab. It appears to be a feature of the map and has no affect on the
critical vphysics issues.
I tried host_framerate set to 0, 1, 10 and 100. I didn't notice any difference
in physics interactions, or any difference in anything else at all, at any
setting. The vphysics continued to be broken at all host_framerate settings
with a debug mod dll and high cpu usage. The vphysics continued to work fine
at host_framerate settings with a release mode dll, regardless of cpu usage.
I speculated that maybe the ShouldCollide_Default assert code you recommended
might be what was causing debug builds to break, so I tried taking that out as
well, but it still broke.
Has this not reprod for anyone else? Does Valve run large stresstests on debug
HL2DM?
At 2006/07/02 12:19 PM, Jay Stelly wrote:
>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: [email protected]
>> 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
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
