gdalgorithms-list

Re: [Algorithms] 2d circular union nav-mesh

[Sebastian S. <seb...@gm...>]

On Wed, May 26, 2010 at 1:01 PM, Sebastian Sylvan <
seb...@gm...> wrote:

>
>
> On Wed, May 26, 2010 at 12:11 PM, <Pau...@sc...> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hi guys,
>>
>> Does anyone have any references or pointers for how to constrain a small
>> character (represented by a circle) within the interior of the union of a
>> set of larger circles?
>>
>> The background is, the larger circles define regions of land where the
>> small circle can navigate around (like a nav mesh), and the union of the
>> these circles defines the entire nav-mesh. The character is not allowed to
>> leave the interior of the nav-mesh and must remain wholly inside it at all
>> times.
>>
>> Some diagrams:
>>
>> The general case, the filled circle represents the character and the
>> hollow circles the land
>>
>> http://www.pfirth.co.uk/ex1.png
>>
>> My first attempt was to ensure the character was wholly inside at least
>> one land circle, but that fails in this case:
>>
>> http://www.pfirth.co.uk/ex2.png
>>
>> In that example, if the character moves any further up, it will not be
>> wholly contained in either circle and will fail, yet it should be able to
>> navigate between them.
>>
>>
> Maybe I'm missing something. But could you not shrink the circles of your
> "navmesh" by the radius of your character, and then check the centre *point*
> of the character against those?
>
>
Ah, that won't work for your second example. Ignore me.

-- 
Sebastian Sylvan

Re: [Algorithms] 2d circular union nav-mesh

[Simon F. <sim...@po...>]

Pau...@sc... wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi guys,
> 
> Does anyone have any references or pointers for how to constrain a
> small character (represented by a circle) within the interior of the
> union of a set of larger circles?  
> 
> The background is, the larger circles define regions of land where
> the small circle can navigate around (like a nav mesh), and the union
> of the these circles defines the entire nav-mesh. The character is
> not allowed to leave the interior of the nav-mesh and must remain
> wholly inside it at all times.    


I'm probably missing something entirely obvious here, but since your
items are all circles, can't you reduce the problem to just testing if
the exact centre of your character (with radius R) is entirely contained
in region circles whose radii have been reduced by R?

Simon

Re: [Algorithms] 2d circular union nav-mesh

[Sebastian S. <seb...@gm...>]

On Wed, May 26, 2010 at 12:11 PM, <Pau...@sc...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi guys,
>
> Does anyone have any references or pointers for how to constrain a small
> character (represented by a circle) within the interior of the union of a
> set of larger circles?
>
> The background is, the larger circles define regions of land where the
> small circle can navigate around (like a nav mesh), and the union of the
> these circles defines the entire nav-mesh. The character is not allowed to
> leave the interior of the nav-mesh and must remain wholly inside it at all
> times.
>
> Some diagrams:
>
> The general case, the filled circle represents the character and the
> hollow circles the land
>
> http://www.pfirth.co.uk/ex1.png
>
> My first attempt was to ensure the character was wholly inside at least
> one land circle, but that fails in this case:
>
> http://www.pfirth.co.uk/ex2.png
>
> In that example, if the character moves any further up, it will not be
> wholly contained in either circle and will fail, yet it should be able to
> navigate between them.
>
>
Maybe I'm missing something. But could you not shrink the circles of your
"navmesh" by the radius of your character, and then check the centre *point*
of the character against those?


-- 
Sebastian Sylvan

[Algorithms] 2d circular union nav-mesh

[<Pau...@sc...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi guys,

Does anyone have any references or pointers for how to constrain a small 
character (represented by a circle) within the interior of the union of a 
set of larger circles?

The background is, the larger circles define regions of land where the 
small circle can navigate around (like a nav mesh), and the union of the 
these circles defines the entire nav-mesh. The character is not allowed to 
leave the interior of the nav-mesh and must remain wholly inside it at all 
times.

Some diagrams:

The general case, the filled circle represents the character and the 
hollow circles the land

http://www.pfirth.co.uk/ex1.png

My first attempt was to ensure the character was wholly inside at least 
one land circle, but that fails in this case:

http://www.pfirth.co.uk/ex2.png

In that example, if the character moves any further up, it will not be 
wholly contained in either circle and will fail, yet it should be able to 
navigate between them.

Cheers, Paul.
**********************************************************************
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify pos...@sc...
This footnote also confirms that this email message has been checked for 
all known viruses.
Sony Computer Entertainment Europe Limited
Registered Office: 10 Great Marlborough Street, London W1F 7LP, United 
Kingdom
Registered in England: 3277793
**********************************************************************
P Please consider the environment before printing this e-mail

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.9.1 (Build 287)
Charset: US-ASCII

wsBVAwUBS/0BJ3ajGqjtoMHxAQg3qwf/Tm6Az23UjEAY74p59oYl/orGaER6D8e+
5fIBti3CPtE6S0+BgwA5r9BRmh4gEC8D67ZloK4C+XuGIHhdJ5VOf4lvr/dtT8FZ
YwrDbAi7lWMsZQc8eEzTzNWMhay530ZoCT185yRD2EvPnqQPWvKDw4gW+LbK+FlB
Cuefhck6JWG24qLZLnnbU5r8NBMjDYKJLf8AuBguR9zsNvNas0SWjwPWAiUPYYgd
9cw7lEM6rATI84Bpp+emZGWy8nasK+9MfLOcOtXF7bbUo+x2QSkOC6JzDAq56eHZ
pK8tDhcfX3iH2s1+Tf6GORIiHvockZKxYZ5jt/vNoSuVOfawQlSNgw==
=mS+v
-----END PGP SIGNATURE-----

Re: [Algorithms] Converting floats to a specific range

[Richard F. <ra...@gm...>]

NP, but remember, if you're going for performance: try all the different
techniques you can find and don't assume anything. Different solutions are
optimal for different hardware situations. All the solutions presented here
except mine which is crapola no matter what hardware you have, have their
merits.

On 10 May 2010 13:41, Zafar Qamar <zaf...@co...> wrote:

> Cheers for your responses. And for the comedy one :)
>
> A couple of interesting ways of achieving the solution there.
>
> Much appreciated
> Zafar
>
>
> -----Original Message-----
> From: Chris Jenner [mailto:Chr...@ub...]
> Sent: 07 May 2010 12:57
> To: Game Development Algorithms
> Subject: Re: [Algorithms] Converting floats to a specific range
>
> float wrap(float x)
> {
>        Const float wrapSize = 1.0f;
>
>        Return x - floorf(x/wrapSize)*wrapSize;
> }
>
> -----Original Message-----
> From: Zafar Qamar [mailto:zaf...@co...]
> Sent: 07 May 2010 12:36
> To: Game Development Algorithms
> Subject: [Algorithms] Converting floats to a specific range
>
> Hi,
>
> I'm sure this problem is pretty simple, but here goes...
>
> I have a set of float numbers that I'm trying to auto-wrap within a
> specific range of 0.0 to wrapSize (wrapSize is positive, and not a power of
> 2)
>
> So, if I choose a wrapSize of 1.0 then I want the following to happen when
> I feed in numbers...
>
> -739.8 --> 0.2
> :
> :
> -1.1 --> 0.9
> -1.0 --> 0.0
> -0.9 --> 0.1
> :
> -0.2 --> 0.8
> -0.1 --> 0.9
> 0.0 --> 0.0
> 0.1 --> 0.1
> :
> 0.9 --> 0.9
> 1.0 --> 0.0
> 1.1 --> 0.1
> :
>
> Can anyone think of a bit of maths for this please? Note that it needs to
> work for any positive value of wrapSize (not just 1.0)
>
> Cheers
> Zafar
>
> **********************************************************************************
> Disclaimer
>
> The information and attached documentation in this e-mail is intended for
> the use of the addressee only and is confidential. If you are not the
> intended recipient please delete it and notify us immediately by telephoning
> or e-mailing the sender. Please note that without Codemasters’ prior written
> consent any form of distribution, copying or use of this communication or
> the information in it is strictly prohibited and may be unlawful.
>
> Attachments to this e-mail may contain software viruses. You are advised to
> take all reasonable precautions to minimise this risk and to carry out a
> virus check on any documents before they are opened.
>
> Any offer contained in this communication is subject to Codemasters’
> standard terms & conditions and must be signed by both parties. Except as
> expressly provided otherwise all information and attached documentation in
> this e-mail is subject to contract and Codemasters’ board approval.
> Any views or opinions expressed are solely those of the author and do not
> necessarily represent those of Codemasters.
>
> This footnote also confirms that this email message has been swept by
> SurfControl for the presence of computer viruses.
>
> **********************************************************************************
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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
>
> **********************************************************************************
> Disclaimer
>
> The information and attached documentation in this e-mail is intended for
> the use of the addressee only and is confidential. If you are not the
> intended recipient please delete it and notify us immediately by telephoning
> or e-mailing the sender. Please note that without Codemasters’ prior written
> consent any form of distribution, copying or use of this communication or
> the information in it is strictly prohibited and may be unlawful.
>
> Attachments to this e-mail may contain software viruses. You are advised to
> take all reasonable precautions to minimise this risk and to carry out a
> virus check on any documents before they are opened.
>
> Any offer contained in this communication is subject to Codemasters’
> standard terms & conditions and must be signed by both parties. Except as
> expressly provided otherwise all information and attached documentation in
> this e-mail is subject to contract and Codemasters’ board approval.
> Any views or opinions expressed are solely those of the author and do not
> necessarily represent those of Codemasters.
>
> This footnote also confirms that this email message has been swept by
> SurfControl for the presence of computer viruses.
>
> **********************************************************************************
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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
>



-- 
fabs();
Just because the world is full of people that think just like you, doesn't
mean the other ones can't be right.

Re: [Algorithms] Converting floats to a specific range

[Zafar Q. <zaf...@co...>]

Cheers for your responses. And for the comedy one :)

A couple of interesting ways of achieving the solution there.

Much appreciated
Zafar


-----Original Message-----
From: Chris Jenner [mailto:Chr...@ub...] 
Sent: 07 May 2010 12:57
To: Game Development Algorithms
Subject: Re: [Algorithms] Converting floats to a specific range

float wrap(float x)
{
	Const float wrapSize = 1.0f;

	Return x - floorf(x/wrapSize)*wrapSize;
}

-----Original Message-----
From: Zafar Qamar [mailto:zaf...@co...] 
Sent: 07 May 2010 12:36
To: Game Development Algorithms
Subject: [Algorithms] Converting floats to a specific range

Hi,

I'm sure this problem is pretty simple, but here goes...

I have a set of float numbers that I'm trying to auto-wrap within a specific range of 0.0 to wrapSize (wrapSize is positive, and not a power of 2)

So, if I choose a wrapSize of 1.0 then I want the following to happen when I feed in numbers...

-739.8 --> 0.2
:
:
-1.1 --> 0.9
-1.0 --> 0.0
-0.9 --> 0.1
:
-0.2 --> 0.8
-0.1 --> 0.9
0.0 --> 0.0
0.1 --> 0.1
:
0.9 --> 0.9
1.0 --> 0.0
1.1 --> 0.1
:

Can anyone think of a bit of maths for this please? Note that it needs to work for any positive value of wrapSize (not just 1.0)

Cheers
Zafar
**********************************************************************************
Disclaimer

The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. 

Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened.

Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters.

This footnote also confirms that this email message has been swept by
SurfControl for the presence of computer viruses.
**********************************************************************************


------------------------------------------------------------------------------

_______________________________________________
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
------------------------------------------------------------------------------

_______________________________________________
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
**********************************************************************************
Disclaimer

The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. 

Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened.

Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters.

This footnote also confirms that this email message has been swept by
SurfControl for the presence of computer viruses.
**********************************************************************************

Re: [Algorithms] Converting floats to a specific range

[Tom F. <tom...@ee...>]

>    x - floor(x)
> 
> which is always nonnegative.

Obscure fact - I *think* it is always non-negative, but it might not be less
than 1.0. For example, if x is very small and negative, for example x=-1e-10
then floor(x) = -1.0f (correct), and then -1e-10 + 1.0f = 1.0f. It's
possible you may be able to change your math rounding mode to "round down"
and then it will return the smallest number less than 1.0f - I've never
tried it.

But yeah, frac(x) can counter-intuitively return 1.0f sometimes.

TomF.


> -----Original Message-----
> From: Fabian Giesen [mailto:ry...@gm...]
> Sent: Friday, May 07, 2010 4:56 AM
> To: Game Development Algorithms
> Subject: Re: [Algorithms] Converting floats to a specific range
> 
> On 07.05.2010 13:36, Zafar Qamar wrote:
> > Hi,
> >
> > I'm sure this problem is pretty simple, but here goes...
> >
> > I have a set of float numbers that I'm trying to auto-wrap within a
> specific range of 0.0 to wrapSize (wrapSize is positive, and not a
> power of 2)
> >
> > So, if I choose a wrapSize of 1.0 then I want the following to happen
> when I feed in numbers...
>  > [..]
> 
> There's a standard C library function, fmod, that nearly does what you
> want. The one thing you need to fix is that fmod(x, wrapSize) is
> negative whenever x is. So the solution to your problem is
> 
>    fmod(x, wrapSize) + (x < 0.0 ? wrapSize : 0.0);
> 
> The special case for wrapSize == 1 is quite easy, and worth
> remembering,
> since you get to avoid the conditional: You can just compute
> 
>    x - floor(x)
> 
> which is always nonnegative.
> 
> If your target platform/language doesn't have fmod but does have floor,
> you can usually make do with
> 
>    x - wrapSize * floor(x / wrapSize)
> 
> but if you use this you need to watch out if you might encounter very
> large values of x in your application - as soon as floor(x / wrapSize)
> gets to the range where neighboring floats are more than 1 apart, this
> expression will break.
> 
> -Fabian
> 
> -----------------------------------------------------------------------
> -------
> 
> _______________________________________________
> 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
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.437 / Virus Database: 271.1.1/2838 - Release Date:
> 05/06/10 18:26:00

Re: [Algorithms] Converting floats to a specific range

[Richard F. <ra...@gm...>]

I don't "know", but MOD is meant to be remainder on computers. It flummoxed
me as I came from a more mathematical background and MOD is defined as not
having negative numbers in the number field stuff

On 7 May 2010 13:35, Danny Kodicek <dr...@we...> wrote:

>  There's a standard C library function, fmod, that nearly does what you
>
> want. The one thing you need to fix is that fmod(x, wrapSize) is
>
> negative whenever x is. So the solution to your problem is
>
>
> A quick unlurk - I've often wondered why mod functions always seem to do
> this. Can anyone explain that? I can think of very few occasions when you
> want to take the mod of a number and not restrict it to a single range,
> rather than maintaining the positive or negative value. I understand that
> doing it this way makes the function faster, but given that you usually have
> to override it anyway that would seem a bit of a meaningless saving.
>
> Danny
>
>>
>>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> 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
>



-- 
fabs();
Just because the world is full of people that think just like you, doesn't
mean the other ones can't be right.

Re: [Algorithms] Converting floats to a specific range

[Fabian G. <ry...@gm...>]

On 07.05.2010 14:35, Danny Kodicek wrote:
> A quick unlurk - I've often wondered why mod functions always seem to do
> this. Can anyone explain that? I can think of very few occasions when
> you want to take the mod of a number and not restrict it to a single
> range, rather than maintaining the positive or negative value. I
> understand that doing it this way makes the function faster, but given
> that you usually have to override it anyway that would seem a bit of a
> meaningless saving.

It has to do with the rounding semantics of division. The basic 
requirement they're trying to fulfill is that if

   q = a / b;
   r = a % b;

then a should be equal to "q * b + r" (all sensible, so far). Now, C 
doesn't actually specify what (integer) division does when diving a 
negative number by a positive one. The two primary options are truncate 
(round towards zero) and floor (always round down).

If the target platform has "floor" semantics, then r is always 
nonnegative, and e.g. "-1 / 2" evaluates to -1 (this is also the 
behavior you get when you replace divisions by powers of two with 
arithmetic right shifts).

If the target platform has "truncate" semantics, "-1 / 2" evaluates to 
0, and hence the remainder has to be -1. All platforms I've worked with 
so far use this convention, even though it's (as said) not required by 
the C standard - floor would be equally fine.

Interestingly, the C standard does seem to specify that fmod returns 
results as if a truncate-rounding division was used. It's only left 
undefined for integer operations.

-Fabian

[Algorithms] Splat Rendering With Large Model - feedback

[Cedric P. <ced...@pl...>]

Hi,

I would like some inputs about splat rendering. I try to display huge
model with vertex and normal and colors, no triangles.
http://graphics.stanford.edu/software/qsplat/

I tried different papers some on this page
( http://rich5264.wordpress.com/2009/05/26/quick-introduction-to-point-based-rendering/ ) to improve the quality of the image with a decent framerate.

Here some test I did:
input meshes 18 000 000 vertexes it does not run well on my hardware and
it would takes about 823MB (normal color vertexes)

The mesh generation part:
using basic qsplat algo the rendering is limited by the cpu because at
each frame it generates a mesh dependant of the view. I changed the way
qsplat work to generate a mesh only when I ask one and with a given
'lod' I want. Then I can keep a mesh longer and I dont need to refresh
it by frame. To improve the path I put this mesh generation in a thread
to avoid breaking framerate when generating a new mesh. Off course I
will not draw 18,000000 at the same time, and the best resolution of the
mesh will be clipped clipped on the screen plane. In fact you can see
those details only if you are really near. So i change the policy of
generation when really near of the mesh and it becomes more view
dependant.

The rendering part:
o Brutal approach 
The rendering part is really simple, you adjust the size of point sprite
depending of point radius (selected from a 'lod') and z. So if you
select a good resolution, then you have more point but the size of point
is smaller, with this method I am able to display between 1,000000 to
3,500000 at 60 to 30 fps. It's a lot of point but limited overdraw.

o Deferred Shading
I tried some method related to deferred shading, and even if it smooth
the rendering, it's too slow because of the fillrate. I am new to
deferred shading so I could have done some mistake. Here the what I did:
- fill zbuffer for early z rejection
- write normal in additive and color with z test and readonly
- compose normal and color smoothing stuff with a blur. (3x3 matrix)
The buffer used for MRT is GL_RGBA16F_ARB


With what I tried it seems better to draw a lot of small point instead
of doing fancy stuff with deferred shading for the same framerate.

My experiment was on a Quadro FX 880M/PCI/SSE2,

If someone has tried this kind of rendering with success, I would be
happy to have their feedback.

-- 
Provide OpenGL services around OpenSceneGraph and more
+33 659 598 614 Cedric Pinson mailto:ced...@pl...
http://www.plopbyte.net

Re: [Algorithms] Converting floats to a specific range

[Danny K. <dr...@we...>]

>
> There's a standard C library function, fmod, that nearly does what you

want. The one thing you need to fix is that fmod(x, wrapSize) is

negative whenever x is. So the solution to your problem is


A quick unlurk - I've often wondered why mod functions always seem to do
this. Can anyone explain that? I can think of very few occasions when you
want to take the mod of a number and not restrict it to a single range,
rather than maintaining the positive or negative value. I understand that
doing it this way makes the function faster, but given that you usually have
to override it anyway that would seem a bit of a meaningless saving.

Danny

>
>

Re: [Algorithms] Converting floats to a specific range

[Richard F. <ra...@gm...>]

I'll let you use the code i coded for this free of charge!

float makeRight( float val, float wrapsize )
{
 val /= wrapsize;
 switch( (int)val )
{
case 0:
 return wrapsize * val;
case 1:
 return wrapsize * (val-1.0f);
case 2:
 return wrapsize * (val-2.0f);
case 3:
 return wrapsize * (val-3.0f);
case -1:
 return wrapsize * (val+1.0f);
case -2:
 return wrapsize * (val+2.0f);
case -3:
 return wrapsize * (val+2.0f);
}
// just in case you haven't written the case for the incoming value:
return 0.0f;
}

On 7 May 2010 12:36, Zafar Qamar <zaf...@co...> wrote:

> Hi,
>
> I'm sure this problem is pretty simple, but here goes...
>
> I have a set of float numbers that I'm trying to auto-wrap within a
> specific range of 0.0 to wrapSize (wrapSize is positive, and not a power of
> 2)
>
> So, if I choose a wrapSize of 1.0 then I want the following to happen when
> I feed in numbers...
>
> -739.8 --> 0.2
> :
> :
> -1.1 --> 0.9
> -1.0 --> 0.0
> -0.9 --> 0.1
> :
> -0.2 --> 0.8
> -0.1 --> 0.9
> 0.0 --> 0.0
> 0.1 --> 0.1
> :
> 0.9 --> 0.9
> 1.0 --> 0.0
> 1.1 --> 0.1
> :
>
> Can anyone think of a bit of maths for this please? Note that it needs to
> work for any positive value of wrapSize (not just 1.0)
>
> Cheers
> Zafar
>
> **********************************************************************************
> Disclaimer
>
> The information and attached documentation in this e-mail is intended for
> the use of the addressee only and is confidential. If you are not the
> intended recipient please delete it and notify us immediately by telephoning
> or e-mailing the sender. Please note that without Codemasters’ prior written
> consent any form of distribution, copying or use of this communication or
> the information in it is strictly prohibited and may be unlawful.
>
> Attachments to this e-mail may contain software viruses. You are advised to
> take all reasonable precautions to minimise this risk and to carry out a
> virus check on any documents before they are opened.
>
> Any offer contained in this communication is subject to Codemasters’
> standard terms & conditions and must be signed by both parties. Except as
> expressly provided otherwise all information and attached documentation in
> this e-mail is subject to contract and Codemasters’ board approval.
> Any views or opinions expressed are solely those of the author and do not
> necessarily represent those of Codemasters.
>
> This footnote also confirms that this email message has been swept by
> SurfControl for the presence of computer viruses.
>
> **********************************************************************************
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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




-- 
fabs();
Just because the world is full of people that think just like you, doesn't
mean the other ones can't be right.

Re: [Algorithms] Converting floats to a specific range

[Simon F. <sim...@po...>]

Zafar Qamar wrote:
> Hi,
> 
> I'm sure this problem is pretty simple, but here goes...
> 
> I have a set of float numbers that I'm trying to auto-wrap within a
> specific range of 0.0 to wrapSize (wrapSize is positive, and not a
> power of 2)  
> 
> 
> Can anyone think of a bit of maths for this please? Note that it
> needs to work for any positive value of wrapSize (not just 1.0) 
> 
> Cheers
> Zafar

Do you mean like multiplying by the reciprocal of your range, taking
frac, and scaling back up again? 

Simon

PS: I hope you don't need this to be accurate for huge values (e.g. in
range reducing operations for, say sin(maxfloat))

Re: [Algorithms] Converting floats to a specific range

[Chris J. <Chr...@ub...>]

float wrap(float x)
{
	Const float wrapSize = 1.0f;

	Return x - floorf(x/wrapSize)*wrapSize;
}

-----Original Message-----
From: Zafar Qamar [mailto:zaf...@co...] 
Sent: 07 May 2010 12:36
To: Game Development Algorithms
Subject: [Algorithms] Converting floats to a specific range

Hi,

I'm sure this problem is pretty simple, but here goes...

I have a set of float numbers that I'm trying to auto-wrap within a specific range of 0.0 to wrapSize (wrapSize is positive, and not a power of 2)

So, if I choose a wrapSize of 1.0 then I want the following to happen when I feed in numbers...

-739.8 --> 0.2
:
:
-1.1 --> 0.9
-1.0 --> 0.0
-0.9 --> 0.1
:
-0.2 --> 0.8
-0.1 --> 0.9
0.0 --> 0.0
0.1 --> 0.1
:
0.9 --> 0.9
1.0 --> 0.0
1.1 --> 0.1
:

Can anyone think of a bit of maths for this please? Note that it needs to work for any positive value of wrapSize (not just 1.0)

Cheers
Zafar
**********************************************************************************
Disclaimer

The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. 

Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened.

Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters.

This footnote also confirms that this email message has been swept by
SurfControl for the presence of computer viruses.
**********************************************************************************


------------------------------------------------------------------------------

_______________________________________________
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] Converting floats to a specific range

[Fabian G. <ry...@gm...>]

On 07.05.2010 13:36, Zafar Qamar wrote:
> Hi,
>
> I'm sure this problem is pretty simple, but here goes...
>
> I have a set of float numbers that I'm trying to auto-wrap within a specific range of 0.0 to wrapSize (wrapSize is positive, and not a power of 2)
>
> So, if I choose a wrapSize of 1.0 then I want the following to happen when I feed in numbers...
 > [..]

There's a standard C library function, fmod, that nearly does what you 
want. The one thing you need to fix is that fmod(x, wrapSize) is 
negative whenever x is. So the solution to your problem is

   fmod(x, wrapSize) + (x < 0.0 ? wrapSize : 0.0);

The special case for wrapSize == 1 is quite easy, and worth remembering, 
since you get to avoid the conditional: You can just compute

   x - floor(x)

which is always nonnegative.

If your target platform/language doesn't have fmod but does have floor, 
you can usually make do with

   x - wrapSize * floor(x / wrapSize)

but if you use this you need to watch out if you might encounter very 
large values of x in your application - as soon as floor(x / wrapSize) 
gets to the range where neighboring floats are more than 1 apart, this 
expression will break.

-Fabian

Re: [Algorithms] Converting floats to a specific range

[Oscar F. <os...@tr...>]

Unless I'm being daft isn't it just:

x = fmodf( 1.0f + fmodf( f, 1.0f ), 1.0f );

?

And btw 1.0 IS a power of 2.  2^0 in fact ;)

On 7 May 2010 12:36, Zafar Qamar <zaf...@co...> wrote:

> Hi,
>
> I'm sure this problem is pretty simple, but here goes...
>
> I have a set of float numbers that I'm trying to auto-wrap within a
> specific range of 0.0 to wrapSize (wrapSize is positive, and not a power of
> 2)
>
> So, if I choose a wrapSize of 1.0 then I want the following to happen when
> I feed in numbers...
>
> -739.8 --> 0.2
> :
> :
> -1.1 --> 0.9
> -1.0 --> 0.0
> -0.9 --> 0.1
> :
> -0.2 --> 0.8
> -0.1 --> 0.9
> 0.0 --> 0.0
> 0.1 --> 0.1
> :
> 0.9 --> 0.9
> 1.0 --> 0.0
> 1.1 --> 0.1
> :
>
> Can anyone think of a bit of maths for this please? Note that it needs to
> work for any positive value of wrapSize (not just 1.0)
>
> Cheers
> Zafar
>
> **********************************************************************************
> Disclaimer
>
> The information and attached documentation in this e-mail is intended for
> the use of the addressee only and is confidential. If you are not the
> intended recipient please delete it and notify us immediately by telephoning
> or e-mailing the sender. Please note that without Codemasters’ prior written
> consent any form of distribution, copying or use of this communication or
> the information in it is strictly prohibited and may be unlawful.
>
> Attachments to this e-mail may contain software viruses. You are advised to
> take all reasonable precautions to minimise this risk and to carry out a
> virus check on any documents before they are opened.
>
> Any offer contained in this communication is subject to Codemasters’
> standard terms & conditions and must be signed by both parties. Except as
> expressly provided otherwise all information and attached documentation in
> this e-mail is subject to contract and Codemasters’ board approval.
> Any views or opinions expressed are solely those of the author and do not
> necessarily represent those of Codemasters.
>
> This footnote also confirms that this email message has been swept by
> SurfControl for the presence of computer viruses.
>
> **********************************************************************************
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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

[Algorithms] Converting floats to a specific range

[Zafar Q. <zaf...@co...>]

Hi,

I'm sure this problem is pretty simple, but here goes...

I have a set of float numbers that I'm trying to auto-wrap within a specific range of 0.0 to wrapSize (wrapSize is positive, and not a power of 2)

So, if I choose a wrapSize of 1.0 then I want the following to happen when I feed in numbers...

-739.8 --> 0.2
:
:
-1.1 --> 0.9
-1.0 --> 0.0
-0.9 --> 0.1
:
-0.2 --> 0.8
-0.1 --> 0.9
0.0 --> 0.0
0.1 --> 0.1
:
0.9 --> 0.9
1.0 --> 0.0
1.1 --> 0.1
:

Can anyone think of a bit of maths for this please? Note that it needs to work for any positive value of wrapSize (not just 1.0)

Cheers
Zafar
**********************************************************************************
Disclaimer

The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. 

Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened.

Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters.

This footnote also confirms that this email message has been swept by
SurfControl for the presence of computer viruses.
**********************************************************************************

[Algorithms] SIGGRAPH Deadlines

[Nathaniel H. <na...@io...>]

Although most of the SIGGRAPH submission deadlines are past, there are
still several of interest to people in this group.

The late-breaking deadline for talks and posters is the most relevant
(since that's where you would describe actual algorithms). That deadline
is on May 6; instructions on how to submit SIGGRAPH talks are here:
http://www.siggraph.org/s2010/for_submitters/talks. These are 20-minute
talks and are great for describing new graphics algorithms, as well as
practical game production tips and tricks.

Of more indirect relevance:

Live Real-Time Demos
(http://www.siggraph.org/s2010/for_submitters/live_real-time_demos) are
the real-time counterpart to the famous SIGGRAPH Electronic Theater. Your
entire team can show off their abilities by showing your game at Live
Real-Time Demos. The deadline is on April 28 and this submission probably
will take longer to approve at your studio than the others (since it
involves showing the entire game), so if you're interested you need to
move fast!

Finally, the artists on your team can show off their best models /
animations / particle effects in the new SIGGRAPH Dailies! program
(http://www.siggraph.org/s2010/for_submitters/siggraph_dailies). The
deadline for this one is on May 6.

A recent post on my book blog has more information on all three options:
http://www.realtimerendering.com/blog/three-ways-to-show-off-your-game-at-siggraph-2010/

Thanks,

Naty Hoffman

Re: [Algorithms] Network prediction algorithms specific to racing?

[Stuart C. <sca...@to...>]

The approach I've used on a few games in the past is to imagine a point out in front of the car that represents a location where some other authoritative machine says it should be some period of time from now, with rope attached to the steering of the car that pulls it towards that point at a fixed distance. With infreqent updates you might get the vehicle trying to cut corners or do other weird things, but for the most-part it worked pretty well with variable lag.

If you've got a proper tyre friction model, just be careful to turn the wheels towards where you want to steer rather than relying on a force from some point on the car to pull it into line.

Stuart

-----Original Message-----
From: Megan Fox [mailto:sha...@gm...] 
Sent: Friday, 16 April 2010 7:51 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] Network prediction algorithms specific to racing?

At present, we have a fairly terrible scheme that amounts to no real rectification or prediction AND a dead-space that allows out-of-sync conditions to get around how jumpy it would be without it.  Not so good.  I was pulled off my other tasks and re-assigned to make it not suck / take it to polished instead of prototype, basically.

My suspicion is that dead reckoning (ie. like you say, simple extrapolation from last known pos/vel) will be "ok", but that it will tend to not produce the smooth arcs I'd like to see in a cart racer.
I'm also not convinced that a second or third degree prediction from sampling the prior positions would be anywhere near usable if the player ever deviated from smooth arc driving.  So, just thought I'd see if there were any particular known-better-case solutions, given that it's a well-trodden domain.

On Thu, Apr 15, 2010 at 3:25 PM, Jason Hughes <jh...@st...> wrote:
> I guess there are two aspects of this: prediction and visual rectification.
>
> We've been doing a networked basketball game recently, where one team 
> is entirely controlled remotely.  Even with fairly high latency, slow 
> moving objects (like players) will look okay using a smooth 
> rectification algorithm, but they're a little delayed from real-time.
> High velocity objects  (ie. bullets or ballistic objects) are pretty 
> easy to sync as well, provided they are not controlled or intelligent.
> The main issues we've had thus far involve rectifying the ball 
> physical state after a collision with a player, since that's often 
> incorrect and delayed.  Luckily, most collisions in basketball games 
> result in the ball being grabbed, so this isn't always an issue.  For 
> reference, our simple rectification code is X = Lerp(X, X', f), where 
> f could vary depending on the latency and current error.  Spline 
> rectification would be nicer, and we might implement that, though it may be overkill for us.
>
> I haven't tried prediction beyond simple linear extrapolation based on 
> the last single sample (position, velocity, orientation).  1st order 
> prediction would likely close most of the gaps for generally smooth 
> functions like position and orientation, but for velocity, I'm not 
> sure it would help in our case, since the velocity is basically 
> joystick angle for us and is generally discontinuous.
>
> Sorry I can't be more help with racing specifically.  Out of 
> curiosity, what have you tried and how did it work?
>
> Thanks,
> JH
>
> Jason Hughes
> President
> Steel Penny Games, Inc.
> Austin, TX
>
>
> On 4/15/2010 3:34 PM, Megan Fox wrote:
>> I'm currently fiddling with dead reckoning for a racing game I'm 
>> working on, but this seems like a specific enough domain that there 
>> ought to be specific-to-racing prediction approaches.  We have a 
>> fairly good idea of what the player is doing (trying to stay on the 
>> track), and that would seem to give more data that isn't really being 
>> exploited with standard approaches - but googling isn't turning up 
>> much.
>>
>> Do such algorithms exist?  Or, in practice, are the same approaches 
>> used in FPSes et al still the ones to use here?
>>
>>
>
> ----------------------------------------------------------------------
> -------- Download Intel&#174; Parallel Studio Eval Try the new 
> software tools for yourself. Speed compiling, find bugs proactively, 
> and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-l
> ist
>



--
Megan Fox
http://www.shalinor.com/

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
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] Silhouette determination for the world's shadow volume

[<der...@he...>]

Remember also that the shadow volumes for static world geometry vs
fixed-position lights are also static and can be created off-line. The
static volumes need to be extruded a distance based on the maximum
run-time intensity of the fixed position light sources.

If fill rate proves to be a bottleneck then the CC shadow volumes paper
(http://gamma.cs.unc.edu/CCSV/) would be worth a look. I've never tried to
implement the algorithm but it promises impressive reductions in fill
rate.

Cheers
Derek


> Well, the shadow volume mesh topology rules really aren't any different
> for
> light sources inside a mesh vs outside - as long as your geometry faces
> inwards (and it will), the idea is the same (find and extrude edges that
> border lit & unlit faces). Sometimes world geometry is stored in funny
> ways
> depending on your game/engine (BSP trees or what have you), that might
> make
> finding edges trickier, but the algorithm is the same.
>
> A good optimization for fill rate if you are using local light sources is
> to
> make sure and only extrude shadow volumes for the areas of the world that
> intersect the light's attenuation radius.
>
> Jeff
>
> On Sun, Apr 18, 2010 at 3:12 PM, Damian Coventry <
> Dam...@m8...> wrote:
>
>> Morning,
>>
>> WRT shadow volumes, what's a common approach for determining the
>> silhouette for the world mesh?  Let's say it's an indoor only game. In
>> this case the camera and lights are both "inside" the world mesh, and
>> the world mesh is concave.
>>
>> For the other meshes that move around inside the world, silhouette
>> determination is well documented - "The set of all edges that connect a
>> toward-face to an away-face form the silhouette with respect to the
>> light source. The edges forming the silhouette are extruded away from
>> the light to construct the faces of the shadow volume".
>>
>> What about the world mesh though? My initial thoughts are to use all
>> world mesh polygons that don't face the light source, and create
>> individual shadow volumes for each polygon.  This would get costly if
>> the world mesh had many back facing polygons at any given time.  How
>> else is it done?
>>
>>
>> ~Damian();
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> 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
>>
>
>
>
> --
> Jeff Russell
> Engineer, 8monkey Labs
> www.8monkeylabs.com
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev_______________________________________________
> 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] Silhouette determination for the world's shadow volume

[Matt J <mjo...@gm...>]

A lot seem to forget finding edges on the CPU is 'optional'...and time
consuming.

So you have two options here..you could do the edge finding using a geometry
shader. Another approach that works on earlier hardware is have a shadow
mesh, simplified, and independent of the primary mesh. You can duplicate
each edge (with opposite winding, and connected as quad to the first edge)
except store the coordinates of the extra edge with a 0 w coordinate... and
then all you have to do in the vertex shader is extrude out the edge with 0
w coordinate to infinity. At the cost of extra geometry (which can be
simplified independently), you keep the processing on the GPU. This works
fine as long as the geometry is solid. It doesn't need to be convex, nor
really solid either (although you really want too, to avoid artifacts).
You're extruding it as a preprocessing step, at the expense of greater
geometry. However, you can use a simplified mesh so you just keep the core
'features' of the mesh, e.g. you can use a few AABB to represent a building
mesh.Finally, you can hide the shadow artifacts on the backside using
reverse extrusion.

With modern shadow algorithms though you are going to get much nicer shadows
using a shadow buffer.

Thanks,
Matthew

Well, the shadow volume mesh topology rules really aren't any different for
> light sources inside a mesh vs outside - as long as your geometry faces
> inwards (and it will), the idea is the same (find and extrude edges that
> border lit & unlit faces). Sometimes world geometry is stored in funny ways
> depending on your game/engine (BSP trees or what have you), that might make
> finding edges trickier, but the algorithm is the same.
>
> A good optimization for fill rate if you are using local light sources is
> to make sure and only extrude shadow volumes for the areas of the world that
> intersect the light's attenuation radius.
>
> Jeff
>
>
> On Sun, Apr 18, 2010 at 3:12 PM, Damian Coventry <
> Dam...@m8...> wrote:
>
>> Morning,
>>
>> WRT shadow volumes, what's a common approach for determining the
>> silhouette for the world mesh?  Let's say it's an indoor only game. In
>> this case the camera and lights are both "inside" the world mesh, and
>> the world mesh is concave.
>>
>> For the other meshes that move around inside the world, silhouette
>> determination is well documented - "The set of all edges that connect a
>> toward-face to an away-face form the silhouette with respect to the
>> light source. The edges forming the silhouette are extruded away from
>> the light to construct the faces of the shadow volume".
>>
>> What about the world mesh though? My initial thoughts are to use all
>> world mesh polygons that don't face the light source, and create
>> individual shadow volumes for each polygon.  This would get costly if
>> the world mesh had many back facing polygons at any given time.  How
>> else is it done?
>>
>>
>> ~Damian();
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> 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
>>
>
>
>
> --
> Jeff Russell
> Engineer, 8monkey Labs
> www.8monkeylabs.com
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> 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
>



-- 
-----
Matt Johnson
http://otowngraphics.blogspot.com

Re: [Algorithms] Silhouette determination for the world's shadowvolume

[Damian C. <Dam...@m8...>]

Yup, some sort of "potentially shadowed set" scheme will have to be in
place, as well as 2D scissoring in view space before constructing the
volume.  If the idea is the same for the world mesh, then how would one
build the near and far caps for the shadow volume in order to make it a
closed volume?

 

The world is essentially self shadowing itself, so I guess you'd only
need to cap far end of the volume, and ignore the near end.  You'd have
to cap it, otherwise you'd have holes in your shadows.  Would one
project every polygon in the potentially shadowed set to infinity? Or is
there some other commonly used scheme to cap the far end of the volume?

 

Damian Coventry

Senior Software Developer

M86 Security

T: +64 9 984 5725

F: +64 9 984 5720

M: +64 21 539 839

 

From: Jeff Russell [mailto:je...@8m...] 
Sent: Monday, 19 April 2010 9:19 a.m.
To: Game Development Algorithms
Subject: Re: [Algorithms] Silhouette determination for the world's
shadowvolume

 

Well, the shadow volume mesh topology rules really aren't any different
for light sources inside a mesh vs outside - as long as your geometry
faces inwards (and it will), the idea is the same (find and extrude
edges that border lit & unlit faces). Sometimes world geometry is stored
in funny ways depending on your game/engine (BSP trees or what have
you), that might make finding edges trickier, but the algorithm is the
same.

A good optimization for fill rate if you are using local light sources
is to make sure and only extrude shadow volumes for the areas of the
world that intersect the light's attenuation radius.

Jeff

On Sun, Apr 18, 2010 at 3:12 PM, Damian Coventry
<Dam...@m8...> wrote:

Morning,

WRT shadow volumes, what's a common approach for determining the
silhouette for the world mesh?  Let's say it's an indoor only game. In
this case the camera and lights are both "inside" the world mesh, and
the world mesh is concave.

For the other meshes that move around inside the world, silhouette
determination is well documented - "The set of all edges that connect a
toward-face to an away-face form the silhouette with respect to the
light source. The edges forming the silhouette are extruded away from
the light to construct the faces of the shadow volume".

What about the world mesh though? My initial thoughts are to use all
world mesh polygons that don't face the light source, and create
individual shadow volumes for each polygon.  This would get costly if
the world mesh had many back facing polygons at any given time.  How
else is it done?


~Damian();


------------------------------------------------------------------------
------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t




-- 
Jeff Russell
Engineer, 8monkey Labs
www.8monkeylabs.com

Re: [Algorithms] Silhouette determination for the world's shadow volume

[Jeff R. <je...@8m...>]

Well, the shadow volume mesh topology rules really aren't any different for
light sources inside a mesh vs outside - as long as your geometry faces
inwards (and it will), the idea is the same (find and extrude edges that
border lit & unlit faces). Sometimes world geometry is stored in funny ways
depending on your game/engine (BSP trees or what have you), that might make
finding edges trickier, but the algorithm is the same.

A good optimization for fill rate if you are using local light sources is to
make sure and only extrude shadow volumes for the areas of the world that
intersect the light's attenuation radius.

Jeff

On Sun, Apr 18, 2010 at 3:12 PM, Damian Coventry <
Dam...@m8...> wrote:

> Morning,
>
> WRT shadow volumes, what's a common approach for determining the
> silhouette for the world mesh?  Let's say it's an indoor only game. In
> this case the camera and lights are both "inside" the world mesh, and
> the world mesh is concave.
>
> For the other meshes that move around inside the world, silhouette
> determination is well documented - "The set of all edges that connect a
> toward-face to an away-face form the silhouette with respect to the
> light source. The edges forming the silhouette are extruded away from
> the light to construct the faces of the shadow volume".
>
> What about the world mesh though? My initial thoughts are to use all
> world mesh polygons that don't face the light source, and create
> individual shadow volumes for each polygon.  This would get costly if
> the world mesh had many back facing polygons at any given time.  How
> else is it done?
>
>
> ~Damian();
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> 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
>



-- 
Jeff Russell
Engineer, 8monkey Labs
www.8monkeylabs.com

[Algorithms] Silhouette determination for the world's shadow volume

[Damian C. <Dam...@m8...>]

Morning,

WRT shadow volumes, what's a common approach for determining the
silhouette for the world mesh?  Let's say it's an indoor only game. In
this case the camera and lights are both "inside" the world mesh, and
the world mesh is concave.

For the other meshes that move around inside the world, silhouette
determination is well documented - "The set of all edges that connect a
toward-face to an away-face form the silhouette with respect to the
light source. The edges forming the silhouette are extruded away from
the light to construct the faces of the shadow volume".

What about the world mesh though? My initial thoughts are to use all
world mesh polygons that don't face the light source, and create
individual shadow volumes for each polygon.  This would get costly if
the world mesh had many back facing polygons at any given time.  How
else is it done?


~Damian();

Re: [Algorithms] Network prediction algorithms specific to racing?

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

If you do physical simulation of each entity on each client, then you can
"interpolate" the assumed control inputs, rather than the position/state of
the vehicle. You can assume that the player will want to turn into turns,
accelerate on straights, etc. When you find out that you predicted the
controls wrong, you apply a delta-control to the follow-on input controls
(allowing super-natural acceleration/braking for the sake of "catching up").
There is some risk that you'll end up oscillating if you over-compensate, so
there has to be a balance between compensating quickly and dampening the
response.

An alternative is to delay all the remote players by X amount of time, so
that you actually have their input when it comes time to simulate them, but
then you're out of "extrapolation" and into "lag compensation" territory.

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 Thu, Apr 15, 2010 at 1:34 PM, Megan Fox <sha...@gm...> wrote:

> I'm currently fiddling with dead reckoning for a racing game I'm
> working on, but this seems like a specific enough domain that there
> ought to be specific-to-racing prediction approaches.  We have a
> fairly good idea of what the player is doing (trying to stay on the
> track), and that would seem to give more data that isn't really being
> exploited with standard approaches - but googling isn't turning up
> much.
>
> Do such algorithms exist?  Or, in practice, are the same approaches
> used in FPSes et al still the ones to use here?
>
> --
> Megan Fox
> http://www.shalinor.com/
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> 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
>