>OBB is just the bounding box around the model
>
>USE_OBB_COLLISION_BOUNDS is probably there for other support that was never
>implemented/never needed to be
So you think it's bad if every entity in the world is set to
USE_OBB_COLLISION_BOUNDS? Valve, is this bad?
Garry, are you talking about a feature in the SDK that can be enabled to do
this? If so, what is the steps to do so? If you're talking about code
changes, maybe.
If you just want to compare the origin of the CBaseEntity to the origin of the
CBaseEntity's IPhysicsObject, I can do that. By breaking on the "if (
origin.IsValid() )" line in baseentity_shared.cpp I see:
+ origin {x=7434.0000 y=6504.0000 z=-1504929.6 } Vector
+ prevOrigin {x=7434.0000 y=6504.0000 z=-1504900.0 } Vector
So the entity is falling 29.6 units per frame. Seems reasonable for an entity
that fell right out of the world and is falling forever due to gravity.
I checked several entities, they all have constant x and y but are falling
between 10 and 30 units per frame.
Maybe I'm not using the word "frame" correctly above. Perhaps it should be
"tick"?
At 2006/04/20 04:25 AM, Garry Newman wrote:
>--
>[ Picked text/plain from multipart/alternative ]
>Objects are asleep when they're at rest and it isn't calculating the
>physics. If the objects are all moving it'd be pretty weird that they're all
>asleep.
>
>When they're moving around can you make it wireframe their physics object -
>is that moving around too?
>
>
>On 4/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>wrote:
>>
>> What is IsAsleep()? I can't find any documentation on it, but is it weird
>> that all the objects are IsAsleep() true?
>>
>> I notice it because the closed-source side calls back to
>> WorldSpaceSurroundingBounds which calls ComputeSurroundingBox, and in
>> there it always goes to check and is always false. m_nSurroundType is
>> always set to USE_OBB_COLLISION_BOUNDS for all callbacks from the
>> closed-source. I can't find any documentation on that either - what does
>> OBB stand for?
>>
>> I ran for several seconds with custom breakpoints, and all
>> CCollisionProperty objects that got callbacks from the closed-source side
>> were USE_OBB_COLLISION_BOUNDS and IsAsleep(). I'm not certain that means
>> all CCollisionProperty objects are that way. Is it possible some just
>> aren't getting callbacks?
>>
>> -bk
>>
>> At 2006/04/19 07:53 PM, [EMAIL PROTECTED] wrote:
>> >I'm seeing plenty of callbacks to WorldSpaceSurroundingBounds from the
>> core engine side of things, and for what it's worth the SDK side is
>> returning seemingly valid, albeit hugely negative z, values.
>> >
>> >+ pVecMins 0x0012ddc0 {x=4984.7964 y=5646.7964 z=-1191362.9}
>> > Vector *
>> >+ pVecMaxs 0x0012ddb4 {x=4991.2036 y=5653.2036 z=-1191346.1}
>> > Vector *
>> >
>> >I'm not ever seeing MarkEntitiesAsTouching getting a callback. That
>> actually makes sense in a way, since when Physical Mayhem occurs, you can
>> grav gun objects right through other objects.
>> >
>> >It also is consistent with all the hugely negative z values. I guess
>> nothing ever got a "touch" callback for impacting the ground, so everything
>> just falls right through forever?
>> >
>> >Why don't players fall through the map? I guess players don't obey
>> vphysics.dll in the same way the other entities do?
>> >
>> >At 2006/04/18 11:58 PM, Jay Stelly wrote:
>> >>The z values are interesting - I'm not sure what to make of that.
>> >>Obviously those are out of the world coordinate range.
>> >>If it helps, the code for solidmoved is basically this:
>> >>
>> >> // pSolidCollide is the CollisionProp of the entity that
>> >>moved
>> >> pSolidCollide->WorldSpaceSurroundingBounds(
>> >>&vecWorldMins, &vecWorldMaxs );
>> >>
>> >> // builds a list of trigger entities touching the box
>> >>into m_TouchedEntities
>> >> SpatialPartition()->EnumerateElementsInBox(
>> >>PARTITION_ENGINE_TRIGGER_EDICTS,
>> >> vecWorldMins, vecWorldMaxs, false,
>> >>&touchEnumerator );
>> >>
>> >> // call the game DLL's touch functions
>> >> for ( int i = 0; i < m_TouchedEntities.Count(); ++i )
>> >> {
>> >> serverGameEnts->MarkEntitiesAsTouching(
>> >>m_TouchedEntities[i], m_pTriggerEntity );
>> >> }
>> >>
>> >>
>> >>Jay
>> >>
>> >>
>> >>> -----Original Message-----
>> >>> From: [EMAIL PROTECTED]
>> >>> [mailto:[EMAIL PROTECTED] On Behalf Of
>> >>> [EMAIL PROTECTED]
>> >>> Sent: Tuesday, April 18, 2006 9:08 PM
>> >>> To: hlcoders@list.valvesoftware.com
>> >>> Subject: Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
>> >>>
>> >>> Inside engine->SolidMoved the engine.dll does a few callbacks
>> >>> to the open source side to get collision properties and
>> >>> origins. Then it loops around for a very long time, walking
>> >>> some sort of closed-source linked-list.
>> >>>
>> >>> Is engine->SolidMoved supposed to be doing looping and
>> >>> cpu-intensive things? Or is the fact that that's happening
>> >>> bad unto itself?
>> >>>
>> >>> Anybody know of a good x86 asm manual?
>> >>>
>> >>> At 2006/04/18 08:51 PM, [EMAIL PROTECTED] wrote:
>> >>> >I noticed that most of the objects in the world have z values like:
>> >>> > z -880609.44 float
>> >>> > z -861464.81 float
>> >>> > z -1501742.9 float
>> >>> >
>> >>> >So I guess when the Physical Mayhem bug is happening and all
>> >>> the items disappear, they aren't getting removed from the
>> >>> game, they're just falling forever.
>> >>> >
>> >>> >Could it be the "player bodies falling out of the map" bug
>> >>> might be an unusual symptom of the Physical Mayhem bug?
>> >>> >
>> >>> >At 2006/04/18 08:43 PM, [EMAIL PROTECTED] wrote:
>> >>> >>So I happened to catch my server when the Physical Mayhem
>> >>> bug was in progress but the server had not (yet) crashed.
>> >>> >>
>> >>> >>(See
>> >>> >>http://forums.steampowered.com/forums/showthread.php?s=&thre
>> >>> adid=24842
>> >>> >>5 for anyone unfamiliar with this bug.)
>> >>> >>
>> >>> >>Anything I can do to help debug this? As usual with the
>> >>> Physical Mayhem bug, it's constantly using maximum cpu. If I
>> >>> break in, it's almost always sitting in engine->SolidMoved in
>> >>> this trace:
>> >>> >>
>> >>> >> engine.dll!0da8aab8()
>> >>> >> engine.dll!0da8aea4()
>> >>> >> engine.dll!0da8b063()
>> >>> >> engine.dll!0da8b094()
>> >>> >> engine.dll!0dabfeba()
>> >>> >> engine.dll!0dac0460()
>> >>> >> server.dll!CBaseEntity::SetSimulationTime(float
>> >>> st=2.4733254e-012) Line 178 C++
>> >>> >> engine.dll!0dab5fa4()
>> >>> >>> server.dll!CBaseEntity::PhysicsTouchTriggers(const
>> >>> Vector * pPrevAbsOrigin=0x0012df3c) Line 2025 C++
>> >>> >>
>> >>> server.dll!CBaseEntity::VPhysicsUpdate(IPhysicsObject *
>> >>> pPhysics=0x05552ca0) Line 941 C++
>> >>> >>
>> >>> server.dll!CPhysicsProp::VPhysicsUpdate(IPhysicsObject *
>> >>> pPhysics=0x05552ca0) Line 2252 C++
>> >>> >> server.dll!PhysFrame(float deltaTime=0.015000000)
>> >>> Line 1359 C++
>> >>> >>
>> >>> server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line
>> >>> 441 + 0x9 C++
>> >>> >> server.dll!InvokeMethod(void (void)* f=0x2242ac00)
>> >>> Line 244 C++
>> >>> >>
>> >>> server.dll!IGameSystem::FrameUpdatePostEntityThinkAllSystems()
>> >>> Line 221 + 0xa C++
>> >>> >> server.dll!CServerGameDLL::GameFrame(bool
>> >>> simulating=true) Line 920 C++
>> >>> >> engine.dll!0daa0691()
>> >>> >> engine.dll!0da9b0e7()
>> >>> >> engine.dll!0da9cc75()
>> >>> >> engine.dll!0da03cd7()
>> >>> >> engine.dll!0da04376()
>> >>> >> engine.dll!0da0f025()
>> >>> >> engine.dll!0da0f112()
>> >>> >> user32.dll!77d496b8()
>> >>> >> engine.dll!0da0f1af()
>> >>> >> engine.dll!0daacefc()
>> >>> >> engine.dll!0daac4ed()
>> >>> >> dedicated.dll!1000c084()
>> >>> >> dedicated.dll!1000c553()
>> >>> >> materialsystem.dll!00cd0dae()
>> >>> >> materialsystem.dll!00cd0f38()
>> >>> >> materialsystem.dll!00cd0dae()
>> >>> >> materialsystem.dll!00cd0f05()
>> >>> >> materialsystem.dll!00cd7f64()
>> >>> >> materialsystem.dll!00cd9502()
>> >>> >> tier0.dll!0087299f()
>> >>> >> materialsystem.dll!00cda349()
>> >>> >> tier0.dll!008764b5()
>> >>> >> tier0.dll!0087105a()
>> >>> >> tier0.dll!008731d0()
>> >>> >> tier0.dll!008738de()
>> >>> >> datacache.dll!00e7daa2()
>> >>> >> datacache.dll!00e7e08e()
>> >>> >> datacache.dll!00e733ae()
>> >>> >> datacache.dll!00e73e6b()
>> >>> >> engine.dll!0db556b8()
>> >>> >> engine.dll!0db552dc()
>> >>> >> engine.dll!0d9adc0d()
>> >>> >> dedicated.dll!10021d0b()
>> >>> >> dedicated.dll!10022c00()
>> >>> >> dedicated.dll!10022c00()
>> >>> >> dedicated.dll!1000c7f7()
>> >>> >> ntdll.dll!7c9106eb()
>> >>> >>
>> >>> >>_______________________________________________
>> >>> >>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
>> >
>> >_______________________________________________
>> >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
