[sldev] ATTN-LL: Adding / Extending SL wiki to discuss Havok-4 ?

Andrew Meadows andrew at lindenlab.com
Tue Oct 2 07:17:47 PDT 2007


It's a wiki.

I'd recommend creating your own pages and putting links on the
Havok_4_Beta_Home page.  Eventually Havok_4_Beta_Home should
go away when th Beta is old hat, however information relevant
to how the physics engine works should stay.

The effect you're noticing where large contiguous piles hit
the physics engine harder than smaller distributed piles is
their "simulation island" (SI) management.  Each SI is
a data structure that has a list of potentially colliding objects
and an axis aligned bounding box (AABB) that encloses all of
the objects.  When two SI's meet they are merged into one; when
the pile spreads out the SI may be split into multiple SI.

Havok4 uses the SI AABB's to rapidly cull the input for the
"broadphase collision" test (the rough test that builds a
list of "might  be colliding" pairs of objects). The list of
pairs is then passed to the "narrowphase collision" tests which
generate the detailed contact points where the objects are
actually hitting, if any.  You could think of the SI system as
a meta broadphase, so Havok4 has three layers of collision tests.

When all of the dynamic objects are in a single pile, the
SI layer collapses to a point and all you're left with is
the broad- and narrowphase tests.  The SI management is the main
source of Havok4's speed over Havok1 -- there are lots of other
improvements, but the SI layer is the biggest win.  So a huge
pile of dynamic objects is going to lag Havok4, but without
the crashing.

Havok1 doesn't actually crash... it just blocks.  It might
block for 20 seconds, or maybe an hour, but it would eventually
return.  Years ago the simulator could return from 15 minutes of
blockage and you'd still be logged on, and you could IM the whole
time.  Now, if the simulator blocks for more that 90 seconds there
is a watchdog process that sends it a signal to bring it down --
that is the "crash in Havok1" that you're all familiar with.

Turns out that Havok4 can also block, but not as long (I was able
to get it to block for about 10 seconds without pushing too hard)
by using their hkListShape colliding against another hkListShape,
which would generate N^2 potential collision points.  Hence the use
of the memory optimized partial polytope (MOPP) that I mentioned
in an earlier email.

There, link some new wiki pages to the Havok_4_Beta_Home
page about how Havok4 works and I'll help fill in the gaps.

It's a wiki.

- Andrew


Dale Mahalko wrote:
> Well, I'd like to help expand on the information in the SL wiki and
> help document the features and limitations of the new engine, but I'm
> not sure what the protocol should be for this. Should a subpage be
> started linked from the main page, or is it okay to extend off the
> main page for now, until enough content accumulates to justify a
> subpage?
> 
> I've experimentally added a new section to the bottom of the Havok 4
> Beta Home page, though this is possibly not a good spot to add
> anything since it may seem like what I've added speaks for LL as part
> of the announcement of the beta grid. But, the page isn't locked
> against editing by us non-LL editors.... I don't know what to do.
> 
> 
> I'm going to leave it there for review, and if you (at LL) don't like
> it, then move it, edit it, or whatever is you think is appropriate:
> 
> == New experiences that are normal ==
> === Simulator lag from huge piles of stacked objects ===
> === Thousands of objects that don't touch do not lag ===
> 
> https://wiki.secondlife.com/wiki/Havok_4_Beta_Home
> 
> I've also created two documentary Google Videos to go along with the
> new sections, in order to make what's going on more visually
> understandable. (The second video is a bit long, and I'll probably
> redo it with an automated cube-dropper.)
> 
> 
> -Scalar Tardis / Dale Mahalko
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html


More information about the SLDev mailing list