gdalgorithms-list

[Algorithms] Speculative Contacts

[Paul F. <pa...@wi...>]

Hi guys,

Just thought i'd post this here in case you've not already seen the
article in the thread on gamdev.net:

http://www.wildbunny.co.uk/blog/2011/03/25/speculative-contacts-an-continuous-collision-engine-approach-part-1/

Its my blog post on a new collision detection technique as seen in
games such as Little Big Planet...

Hope you enjoy it :)

Cheers, Paul.

-- 
Paul Firth
http://www.wildbunny.co.uk
http://www.facebook.com/WildbunnyLtd
email: pa...@wi...

Re: [Algorithms] Speculative Contacts

[Jon W. <jw...@gm...>]

This is pretty cool! Thanks for sharing.

What I've found when doing the "remove velocity" thing in the past (sweeping
spheres against trimeshes, mostly), is that the amount of bounce you get (if
you have >0 restitution) varies randomly. The reason being that "almost all"
versus "almost none" of the velocity will be removed for any given timestep,
depending on how soon within the timestep the object will intersect the
target.
It's possible to hack with things like "assumed velocity" being remembered
at the beginning of the time step -- do you have any thoughts on possibly
better solutions?
(There's also the discontinuity in motion from removing a random amount of
time, but as you say -- you gotta stop somewhere ;-)

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Mon, Mar 28, 2011 at 12:27 PM, Paul Firth <pa...@wi...> wrote:

> Hi guys,
>
> Just thought i'd post this here in case you've not already seen the
> article in the thread on gamdev.net:
>
>
> http://www.wildbunny.co.uk/blog/2011/03/25/speculative-contacts-an-continuous-collision-engine-approach-part-1/
>
> Its my blog post on a new collision detection technique as seen in
> games such as Little Big Planet...
>
> Hope you enjoy it :)
>
> Cheers, Paul.
>
> --
> Paul Firth
> http://www.wildbunny.co.uk
> http://www.facebook.com/WildbunnyLtd
> email: pa...@wi...
>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and publish
> your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>

Re: [Algorithms] Speculative Contacts

[Paul F. <pa...@wi...>]

> This is pretty cool! Thanks for sharing.

No probs :)

> What I've found when doing the "remove velocity" thing in the past (sweeping
> spheres against trimeshes, mostly), is that the amount of bounce you get (if
> you have >0 restitution) varies randomly. The reason being that "almost all"
> versus "almost none" of the velocity will be removed for any given timestep,
> depending on how soon within the timestep the object will intersect the
> target.

I have to admit, i've never tried this solution with a physics engine
which supported non zero restitution - none of the games i've worked
on have called for it :)

> It's possible to hack with things like "assumed velocity" being remembered
> at the beginning of the time step -- do you have any thoughts on possibly
> better solutions?

I not totally sure - you could always calculate what the 'restitution
portion' of the resulting velocity would have been and then just add
that back on as a target in the constraint solver, but i've no idea if
that would actually work :)

> (There's also the discontinuity in motion from removing a random amount of
> time, but as you say -- you gotta stop somewhere ;-)

It ends up being less of a discontinuity and more like a relaxation of
the response over a couple of frames - the more iterations you run,
the more resolved the final solution as ever :)

Cheers, Paul.

-- 
Paul Firth
http://www.wildbunny.co.uk
http://www.facebook.com/WildbunnyLtd
email: pa...@wi...

Re: [Algorithms] Speculative Contacts

[Jamie F. <ja...@qu...>]

On 01/04/2011 04:00, Jon Watte wrote:
> This is pretty cool! Thanks for sharing.
> What I've found when doing the "remove velocity" thing in the past
> (sweeping spheres against trimeshes, mostly), is that the amount of
> bounce you get (if you have >0 restitution) varies randomly. The reason
> being that "almost all" versus "almost none" of the velocity will be
> removed for any given timestep, depending on how soon within the
> timestep the object will intersect the target.
> It's possible to hack with things like "assumed velocity" being
> remembered at the beginning of the time step -- do you have any thoughts
> on possibly better solutions?
> (There's also the discontinuity in motion from removing a random amount
> of time, but as you say -- you gotta stop somewhere ;-)

I did stuff that looked a lot like this some years ago, off the back of 
the Jakobsen Hitman physics paper. It's pretty easy to eliminate the 
discontinuity and get the bounce right for this sort of simple collision...

I spent a lot more time generalizing the solution to 3D bodies (with 
constraints?), and I can't honestly remember if I got all the way 
there... have some notes somewhere....

But it all worked really surprisingly well in a number of tests. Lots of 
nasty situations Just Worked with no special cases (Newton's cradle was 
a favourite).

But if I read Paul's article correctly, the whole point of his 
Speculative Contacts approach is to make sure the objects are perfectly 
in contact at the start of the next frame. And, like you say, there'll 
be artefacts from that....

The way we did it way back when, it stabilized pretty decently in the 
first place without that... so what am I missing? :)

May be rambling, not nearly enough sleep!

Jamie

> Sincerely,
> jw
>
>
> --
> Americans might object: there is no way we would sacrifice our living
> standards for the benefit of people in the rest of the world.
> Nevertheless, whether we get there willingly or not, we shall soon have
> lower consumption rates, because our present rates are unsustainable.
>
>
>
> On Mon, Mar 28, 2011 at 12:27 PM, Paul Firth <pa...@wi...
> <mailto:pa...@wi...>> wrote:
>
>     Hi guys,
>
>     Just thought i'd post this here in case you've not already seen the
>     article in the thread on gamdev.net <http://gamdev.net/>:
>
>     http://www.wildbunny.co.uk/blog/2011/03/25/speculative-contacts-an-continuous-collision-engine-approach-part-1/
>
>     Its my blog post on a new collision detection technique as seen in
>     games such as Little Big Planet...
>
>     Hope you enjoy it :)
>
>     Cheers, Paul.
>
>     --
>     Paul Firth
>     http://www.wildbunny.co.uk <http://www.wildbunny.co.uk/>
>     http://www.facebook.com/WildbunnyLtd
>     email: pa...@wi... <mailto:pa...@wi...>

Re: [Algorithms] Speculative Contacts

[Jon W. <jw...@gm...>]

On Fri, Apr 1, 2011 at 1:41 AM, Jamie Fowlston <ja...@qu...> wrote:

> On 01/04/2011 04:00, Jon Watte wrote:
>


> > It's possible to hack with things like "assumed velocity" being
> > remembered at the beginning of the time step -- do you have any thoughts
> > on possibly better solutions?
>
>

> nasty situations Just Worked with no special cases (Newton's cradle was
> a favourite).
>
>
That actually brings up another favorite topic: conservation of momentum
when it's a body/body collision instead of a body/world collision. That,
too, needs to be updated to use the "pre-removal" velocities for
calculation. In the end, what I got at the time was one step where the
objects were "touching," but the correct relative velocities/spins were
applied so that the next step, the right bounce/spin/movement happened.

Sincerely,

jw

[Algorithms] Fast Filtered cubemap for a given specular lobe

[Sébastien L. <seb...@do...>]

Hello all, 

I actually try to reimplement the algorithm given in the following paper about filtering cubemap.
http://developer.amd.com/media/gpu_assets/Isidoro-CubeMapFiltering.pdf
But adapted to cosine power function.

My goal is to get the right blurred cubemap for a given specular lobe for the phong lighting model.
This is actually what allow HDRShop for the latlong environment format. But here I want a fast version directly from cubemap 
(HDRShop is slow - I suppose it used only brute force).

I already implement the algorithm for cubemap, taking count of solid angle and get the same result as HDRShop but faster with
the tricks provided (Precompute solid angle and direction vector in a lookup cubemap).

The algorithm looks like as follow

foreach(face)
{
  for(INT Y = 0; Y < Size; Y++)
   for(INT X = 0; X < Size; X++)
   {
     Wp = GetCubeDirection()
     IrradianceAtThisTexel = Integral(Wp)
   }
}

Integral(Wp)
{
foreach(face)
  for(INT Y = 0; Y < Size; Y++)
   for(INT X = 0; X < Size; X++)
   {
     Wi = GetCubeDirection()
     DotWiWp = dot(Wi,Wp);
     LobeShape = pow(DotWiWp, SpecularPower);
     WeightSum += LobeShape * SolidAngleForThisTexel;
     Irradiance = RadianceFromCubemap * DotWiWp * SolidAngleForThisTexel;
     Sum += Irradiance * LobeShape;
   }

   return Sum /= WeightSum;
}

Now I try to implement the second optimization:
"Determine bounding box regions for angular extent in each face on input cubemap."

But I a am little lost in math.
I understand that I need to take the solid angle sustented by the specular lobe then convert it to "cubemap region" and return
the bounding box of this region for each face but I don't know how to do that.

I googling for this topic but still not get good reference.
If someone can give me pointer or can explain me how to get the solid angle of specular lobe, and how to projected it on face,
I would much appreciate.

Thank you

Lagarde Sébastien