gdalgorithms-list

[Algorithms] Rotation from 4 points

[Jose M. <jos...@ya...>]

Hi,

I'm trying to find the pitch, yaw and roll from a group of four points, but just can't do it wright!

The points are the corners of a box..

C
 \
  A--D
 /
B


For a unit box in the origin aligned with the XYZ axis, these are the coordinates of the points:

A(0, 0, 0)
B(0, 0, 1)
C(0, 1, 0)
D(1, 0, 0)


Well, the box may be at any rotation and position, but it's easy to get the points.

How to extract one of these informations:

1 - A quaternion representing the rotation
2 - The pitch, yaw and roll values or
3 - The angles for the rotated axis


Thank you!


Jose




      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: [Algorithms] Decals and deferred rendering

[Diogo de A. <dio...@ne...>]

Doh. I forgot about the D3DRS_SEPARATEALPHABLENDENABLE state, and while
looking it up I found the COLORWRITEENABLE1..4 which I never saw before...

So, ok, I can mask and apply operation on all the channels pretty well,
which kind of makes the G-Buffer approach the most interesting for all sorts
of reasons (can already smell particle systems in the G-Buffer aswell, for
lit particles...).

 

The only final issue is how to manage the system itself... Since we're on
topic, I'm thinking of writing a small tool that grabs a text definition of
a series of decal types and builds the shaders and renderstates for it,
something akin to:

 

Operations= { none, replace, replace_alpha, mul, mul_alpha, add, sub..... }

 

decal_type="bullet_hole"

{

color=mul_alpha

normal=replace

ambient=none

diffuse=none

specular_power=replace

specular_gloss=replace

emissive=replace

}

 

Decal_type="footprints_muddy"

{

            color=none

            normal=replace_alpha

            ambient=none

diffuse=none

specular_power=none

specular_gloss=none

emissive=none

}

 

Decal_type="footprints_dusty"

{

            color=mul_alpha

            normal=none

            ambient=none

diffuse=none

specular_power=none

specular_gloss=none

emissive=none

}

 

Decal_type="plasma_residue"

{

            color=replace

            normal=none

            ambient=none

diffuse=none

specular_power=none

specular_gloss=none

emissive=replace

}

 

Something like this... this assumes that the definition of the decal itself
contains enough data for the diffuse, normal, etc... I was thinking on using
a kind of "decal sheet" to minimize texture switches. Each decal sheet would
contain basically 3 textures (of which some could be NULL): diffuse (rgba),
normal (xyz), specular_power (x), specular_gloss (y), emissive (z). (to be
honest, I can't see the point of changing the ambient and/or the diffuse
components at this time on a decal). Besides the 3 textures, we would need
of course texture coordinates for each of the decals on the sheet.

 

Then, I'd only need one draw per decal type/decal sheet, which doesn't seem
like too bad, especially considering we can probably typify the decal types
so they aren't as specific as the above examples...

 

So, any ideas and/or suggestions?

Diogo

 

From: Jeff Russell [mailto:je...@8m...] 
Sent: quarta-feira, 13 de Janeiro de 2010 18:21
To: Game Development Algorithms
Subject: Re: [Algorithms] Decals and deferred rendering

 

Yes, use alpha blending (this is not done in the shader, but instead as
Steve described). You are right that you can't read and write the same
texture in a shader, but you don't need to. It's done in the output merger
stage, which runs after your pixel shader.

Jeff

On Wed, Jan 13, 2010 at 12:04 PM, Steve Legg <sm...@go...> wrote:

Why can't you use alphablending for this?  If you are worried that you need
to leave the alpha channel untouched then you can either use
D3DRS_COLORWRITEENABLE to write to just the RGB channels, or you could use
D3DRS_SEPARATEALPHABLENDENABLE and set the alpha blend mode to ZERO/ONE/ADD.

 

From: Diogo de Andrade [mailto:dio...@ne...] 
Sent: 13 January 2010 5:56pm


To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Decals and deferred rendering

 

Ehehe, I didn't explain myself too well. J

 

Let's imagine I just need to do an albedo change, and I want to do it with
blending (as you suggested, if I recal).

 

I'd get a pixel shader something like:

 

float4 decal_pixel_shader(INPUT_DATA in)

{

     float4 source_color=tex2D(rt1,in.uv_screen);

     float4 decal_color=tex2D(decal_texture,in.uv_decal);

     return float4(decal_color.xyz* decal_color.a+rt1.xyz*(1-decal_color.a);

}

 

So I need to use rt1 as both input and output, and I think that's a no-no in
a modern video card. So I fail to see how can I do blending operations on
the G-Buffer.

 

Diogo

 

From: Jeff Russell [mailto:je...@8m...] 
Sent: quarta-feira, 13 de Janeiro de 2010 17:20
To: Game Development Algorithms
Subject: Re: [Algorithms] Decals and deferred rendering

 

Well, since its a decal, you shouldn't need to use Rt3 as output (you're not
modifying positions of anything, just painting new material properties over
the existing geometry). So maybe we confused the terms, I was recommending
you render into albedo, normal, specular, etc. but not position.

Jeff

On Wed, Jan 13, 2010 at 11:14 AM, Diogo de Andrade
<dio...@ne...> wrote:

Hi all,

I'm not sure I understood what you and Jeff are recommending, to be
honest...

Clarifying:

I start rendering to the G-Buffer... I have the buffers organized like this:

Rt0.xyz=normal (world space)
Rt0.w=depth (0..1 normalized)
Rt1.xyz=albedo
Rt1.w=ambient intensity
Rt2.x=specular intensity
Rt2.y=specular gloss
Rt2.z=diffuse intensity
Rt2.w=emissive intensity
Rt3.xyz=position (world space)
Rt3.w=unused

Let's imagine I have a maze... I render all walls to these buffers, and now
it's time to render the decals themselves.

With the G-Buffer still as the rendertarget, I draw the geometry that makes
up the decals (obtained through intersection of the world geometry with the
decal frustum)...
Now, the part I don't understand is how to achieve blending (which would be
sweet), without having the G-Buffer simultaneously as a render target and as
input texture (which I think is not allowed under the majority of the
videocards). If I could have that, I'd be able to do whatever I wanted in
the way of blending and such...
To be honest, now that I think about it, I'm not even seeing how I can make
a shader to render the decal in a way it only influences the albedo, even if
it is a simple replace, without using colorwrite masks (which I didn't want
to use because they makes me have to switch states). What I'm trying to
achieve (but may be impossible) is to have a "decal sheet", which has all
the decals, so that with a single draw I can get all decals up... not sure
if that's possible...

Thanks all,

Diogo



----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
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


----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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

Re: [Algorithms] Decals and deferred rendering

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

Yes, use alpha blending (this is not done in the shader, but instead as
Steve described). You are right that you can't read and write the same
texture in a shader, but you don't need to. It's done in the output merger
stage, which runs after your pixel shader.

Jeff

On Wed, Jan 13, 2010 at 12:04 PM, Steve Legg <sm...@go...> wrote:

>  Why can’t you use alphablending for this?  If you are worried that you
> need to leave the alpha channel untouched then you can either use
> D3DRS_COLORWRITEENABLE to write to just the RGB channels, or you could use
> D3DRS_SEPARATEALPHABLENDENABLE and set the alpha blend mode to ZERO/ONE/ADD.
>
>
>
> *From:* Diogo de Andrade [mailto:dio...@ne...]
> *Sent:* 13 January 2010 5:56pm
>
> *To:* 'Game Development Algorithms'
> *Subject:* Re: [Algorithms] Decals and deferred rendering
>
>
>
> Ehehe, I didn’t explain myself too well… J
>
>
>
> Let’s imagine I just need to do an albedo change, and I want to do it with
> blending (as you suggested, if I recal)…
>
>
>
> I’d get a pixel shader something like:
>
>
>
> float4 decal_pixel_shader(INPUT_DATA in)
>
> {
>
>      float4 source_color=tex2D(rt1,in.uv_screen);
>
>      float4 decal_color=tex2D(decal_texture,in.uv_decal);
>
>      return float4(decal_color.xyz*
> decal_color.a+rt1.xyz*(1-decal_color.a);
>
> }
>
>
>
> So I need to use rt1 as both input and output, and I think that’s a no-no
> in a modern video card… So I fail to see how can I do blending operations on
> the G-Buffer…
>
>
>
> Diogo
>
>
>
> *From:* Jeff Russell [mailto:je...@8m...]
> *Sent:* quarta-feira, 13 de Janeiro de 2010 17:20
> *To:* Game Development Algorithms
> *Subject:* Re: [Algorithms] Decals and deferred rendering
>
>
>
> Well, since its a decal, you shouldn't need to use Rt3 as output (you're
> not modifying positions of anything, just painting new material properties
> over the existing geometry). So maybe we confused the terms, I was
> recommending you render into albedo, normal, specular, etc. but not
> position.
>
> Jeff
>
> On Wed, Jan 13, 2010 at 11:14 AM, Diogo de Andrade <
> dio...@ne...> wrote:
>
> Hi all,
>
> I'm not sure I understood what you and Jeff are recommending, to be
> honest...
>
> Clarifying:
>
> I start rendering to the G-Buffer... I have the buffers organized like
> this:
>
> Rt0.xyz=normal (world space)
> Rt0.w=depth (0..1 normalized)
> Rt1.xyz=albedo
> Rt1.w=ambient intensity
> Rt2.x=specular intensity
> Rt2.y=specular gloss
> Rt2.z=diffuse intensity
> Rt2.w=emissive intensity
> Rt3.xyz=position (world space)
> Rt3.w=unused
>
> Let's imagine I have a maze... I render all walls to these buffers, and now
> it's time to render the decals themselves.
>
> With the G-Buffer still as the rendertarget, I draw the geometry that makes
> up the decals (obtained through intersection of the world geometry with the
> decal frustum)...
> Now, the part I don't understand is how to achieve blending (which would be
> sweet), without having the G-Buffer simultaneously as a render target and
> as
> input texture (which I think is not allowed under the majority of the
> videocards). If I could have that, I'd be able to do whatever I wanted in
> the way of blending and such...
> To be honest, now that I think about it, I'm not even seeing how I can make
> a shader to render the decal in a way it only influences the albedo, even
> if
> it is a simple replace, without using colorwrite masks (which I didn't want
> to use because they makes me have to switch states). What I'm trying to
> achieve (but may be impossible) is to have a "decal sheet", which has all
> the decals, so that with a single draw I can get all decals up... not sure
> if that's possible...
>
> Thanks all,
>
> Diogo
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> 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
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> 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

Re: [Algorithms] Decals and deferred rendering

[Steve L. <sm...@go...>]

Why can't you use alphablending for this?  If you are worried that you need
to leave the alpha channel untouched then you can either use
D3DRS_COLORWRITEENABLE to write to just the RGB channels, or you could use
D3DRS_SEPARATEALPHABLENDENABLE and set the alpha blend mode to ZERO/ONE/ADD.

 

From: Diogo de Andrade [mailto:dio...@ne...] 
Sent: 13 January 2010 5:56pm
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Decals and deferred rendering

 

Ehehe, I didn't explain myself too well. J

 

Let's imagine I just need to do an albedo change, and I want to do it with
blending (as you suggested, if I recal).

 

I'd get a pixel shader something like:

 

float4 decal_pixel_shader(INPUT_DATA in)

{

     float4 source_color=tex2D(rt1,in.uv_screen);

     float4 decal_color=tex2D(decal_texture,in.uv_decal);

     return float4(decal_color.xyz* decal_color.a+rt1.xyz*(1-decal_color.a);

}

 

So I need to use rt1 as both input and output, and I think that's a no-no in
a modern video card. So I fail to see how can I do blending operations on
the G-Buffer.

 

Diogo

 

From: Jeff Russell [mailto:je...@8m...] 
Sent: quarta-feira, 13 de Janeiro de 2010 17:20
To: Game Development Algorithms
Subject: Re: [Algorithms] Decals and deferred rendering

 

Well, since its a decal, you shouldn't need to use Rt3 as output (you're not
modifying positions of anything, just painting new material properties over
the existing geometry). So maybe we confused the terms, I was recommending
you render into albedo, normal, specular, etc. but not position.

Jeff

On Wed, Jan 13, 2010 at 11:14 AM, Diogo de Andrade
<dio...@ne...> wrote:

Hi all,

I'm not sure I understood what you and Jeff are recommending, to be
honest...

Clarifying:

I start rendering to the G-Buffer... I have the buffers organized like this:

Rt0.xyz=normal (world space)
Rt0.w=depth (0..1 normalized)
Rt1.xyz=albedo
Rt1.w=ambient intensity
Rt2.x=specular intensity
Rt2.y=specular gloss
Rt2.z=diffuse intensity
Rt2.w=emissive intensity
Rt3.xyz=position (world space)
Rt3.w=unused

Let's imagine I have a maze... I render all walls to these buffers, and now
it's time to render the decals themselves.

With the G-Buffer still as the rendertarget, I draw the geometry that makes
up the decals (obtained through intersection of the world geometry with the
decal frustum)...
Now, the part I don't understand is how to achieve blending (which would be
sweet), without having the G-Buffer simultaneously as a render target and as
input texture (which I think is not allowed under the majority of the
videocards). If I could have that, I'd be able to do whatever I wanted in
the way of blending and such...
To be honest, now that I think about it, I'm not even seeing how I can make
a shader to render the decal in a way it only influences the albedo, even if
it is a simple replace, without using colorwrite masks (which I didn't want
to use because they makes me have to switch states). What I'm trying to
achieve (but may be impossible) is to have a "decal sheet", which has all
the decals, so that with a single draw I can get all decals up... not sure
if that's possible...

Thanks all,

Diogo



----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
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

Re: [Algorithms] Decals and deferred rendering

[Diogo de A. <dio...@ne...>]

Ehehe, I didn't explain myself too well. J

 

Let's imagine I just need to do an albedo change, and I want to do it with
blending (as you suggested, if I recal).

 

I'd get a pixel shader something like:

 

float4 decal_pixel_shader(INPUT_DATA in)

{

     float4 source_color=tex2D(rt1,in.uv_screen);

     float4 decal_color=tex2D(decal_texture,in.uv_decal);

     return float4(decal_color.xyz* decal_color.a+rt1.xyz*(1-decal_color.a);

}

 

So I need to use rt1 as both input and output, and I think that's a no-no in
a modern video card. So I fail to see how can I do blending operations on
the G-Buffer.

 

Diogo

 

From: Jeff Russell [mailto:je...@8m...] 
Sent: quarta-feira, 13 de Janeiro de 2010 17:20
To: Game Development Algorithms
Subject: Re: [Algorithms] Decals and deferred rendering

 

Well, since its a decal, you shouldn't need to use Rt3 as output (you're not
modifying positions of anything, just painting new material properties over
the existing geometry). So maybe we confused the terms, I was recommending
you render into albedo, normal, specular, etc. but not position.

Jeff

On Wed, Jan 13, 2010 at 11:14 AM, Diogo de Andrade
<dio...@ne...> wrote:

Hi all,

I'm not sure I understood what you and Jeff are recommending, to be
honest...

Clarifying:

I start rendering to the G-Buffer... I have the buffers organized like this:

Rt0.xyz=normal (world space)
Rt0.w=depth (0..1 normalized)
Rt1.xyz=albedo
Rt1.w=ambient intensity
Rt2.x=specular intensity
Rt2.y=specular gloss
Rt2.z=diffuse intensity
Rt2.w=emissive intensity
Rt3.xyz=position (world space)
Rt3.w=unused

Let's imagine I have a maze... I render all walls to these buffers, and now
it's time to render the decals themselves.

With the G-Buffer still as the rendertarget, I draw the geometry that makes
up the decals (obtained through intersection of the world geometry with the
decal frustum)...
Now, the part I don't understand is how to achieve blending (which would be
sweet), without having the G-Buffer simultaneously as a render target and as
input texture (which I think is not allowed under the majority of the
videocards). If I could have that, I'd be able to do whatever I wanted in
the way of blending and such...
To be honest, now that I think about it, I'm not even seeing how I can make
a shader to render the decal in a way it only influences the albedo, even if
it is a simple replace, without using colorwrite masks (which I didn't want
to use because they makes me have to switch states). What I'm trying to
achieve (but may be impossible) is to have a "decal sheet", which has all
the decals, so that with a single draw I can get all decals up... not sure
if that's possible...

Thanks all,

Diogo



----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
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

Re: [Algorithms] Decals and deferred rendering

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

Well, since its a decal, you shouldn't need to use Rt3 as output (you're not
modifying positions of anything, just painting new material properties over
the existing geometry). So maybe we confused the terms, I was recommending
you render into albedo, normal, specular, etc. but not position.

Jeff

On Wed, Jan 13, 2010 at 11:14 AM, Diogo de Andrade <
dio...@ne...> wrote:

> Hi all,
>
> I'm not sure I understood what you and Jeff are recommending, to be
> honest...
>
> Clarifying:
>
> I start rendering to the G-Buffer... I have the buffers organized like
> this:
>
> Rt0.xyz=normal (world space)
> Rt0.w=depth (0..1 normalized)
> Rt1.xyz=albedo
> Rt1.w=ambient intensity
> Rt2.x=specular intensity
> Rt2.y=specular gloss
> Rt2.z=diffuse intensity
> Rt2.w=emissive intensity
> Rt3.xyz=position (world space)
> Rt3.w=unused
>
> Let's imagine I have a maze... I render all walls to these buffers, and now
> it's time to render the decals themselves.
>
> With the G-Buffer still as the rendertarget, I draw the geometry that makes
> up the decals (obtained through intersection of the world geometry with the
> decal frustum)...
> Now, the part I don't understand is how to achieve blending (which would be
> sweet), without having the G-Buffer simultaneously as a render target and
> as
> input texture (which I think is not allowed under the majority of the
> videocards). If I could have that, I'd be able to do whatever I wanted in
> the way of blending and such...
> To be honest, now that I think about it, I'm not even seeing how I can make
> a shader to render the decal in a way it only influences the albedo, even
> if
> it is a simple replace, without using colorwrite masks (which I didn't want
> to use because they makes me have to switch states). What I'm trying to
> achieve (but may be impossible) is to have a "decal sheet", which has all
> the decals, so that with a single draw I can get all decals up... not sure
> if that's possible...
>
> Thanks all,
>
> Diogo
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> 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

Re: [Algorithms] Decals and deferred rendering

[Diogo de A. <dio...@ne...>]

Hi all,

I'm not sure I understood what you and Jeff are recommending, to be
honest...

Clarifying:

I start rendering to the G-Buffer... I have the buffers organized like this:

Rt0.xyz=normal (world space)
Rt0.w=depth (0..1 normalized)
Rt1.xyz=albedo
Rt1.w=ambient intensity
Rt2.x=specular intensity
Rt2.y=specular gloss
Rt2.z=diffuse intensity
Rt2.w=emissive intensity
Rt3.xyz=position (world space)
Rt3.w=unused

Let's imagine I have a maze... I render all walls to these buffers, and now
it's time to render the decals themselves.

With the G-Buffer still as the rendertarget, I draw the geometry that makes
up the decals (obtained through intersection of the world geometry with the
decal frustum)...
Now, the part I don't understand is how to achieve blending (which would be
sweet), without having the G-Buffer simultaneously as a render target and as
input texture (which I think is not allowed under the majority of the
videocards). If I could have that, I'd be able to do whatever I wanted in
the way of blending and such...
To be honest, now that I think about it, I'm not even seeing how I can make
a shader to render the decal in a way it only influences the albedo, even if
it is a simple replace, without using colorwrite masks (which I didn't want
to use because they makes me have to switch states). What I'm trying to
achieve (but may be impossible) is to have a "decal sheet", which has all
the decals, so that with a single draw I can get all decals up... not sure
if that's possible...

Thanks all,

Diogo

Re: [Algorithms] Decals and deferred rendering

[Megan F. <sha...@gm...>]

I'd also suggest G-Buffer, including blending.  As far as the diffuse
channel of the G-Buffer goes, the results will always be right (since
decals are one of the few cases where you can guarantee sorting / not
require depth peeling / etc), and as far as any lighting parameters,
it "should" read right so long as the lighting parameters of your
decal aren't grossly different from the surface being decalled.

... but for that reason, you would need to reign in your decals and
keep them reasonable.  A high-specular shiny decal thrown onto a
low-specular muddy wall would look silly indeed unless it was
hard-edged, given that the lighting properties will be entirely
hard-edged.

I'd wonder, though, if you couldn't mask the edge with a bit of
alpha-blending even on those properties?  So long as you're not
changing any of the values that are rigid (ie. specular mul is
probably safe, but any ID-buffer-esque data is not), you'd be able to
mask the edges pretty nicely with the blend.  So, again, you're
seemingly safe so long as the lighting properties of your decal aren't
grossly removed from that of the surface.

Just depends what kind of game you're doing, really.  Personally, I'd
just make sure the decals matched, since that'd probably look better
period, and bake them into the G-Buffer to allow the much-improved
lighting, AO et al they'd get that way.

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

Re: [Algorithms] Decals and deferred rendering

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

My vote would be for drawing them into the G-buffer - proper lighting and
compositing are important. Depending on what you're storing, blending may
not actually be that bad (even if the blending math is not completely
correct, it may still look ok, you'd be surprised). Also some newer fancier
graphics APIs allow you to set separate blending functions for each render
target output, if that helps. And there's always alpha test.

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

[Algorithms] Decals and deferred rendering

[Diogo de A. <dio...@ne...>]

Hi all.

 

As some might have noticed in previous posts, I've been working on a
deferred rendering pipeline for my engine. 

I'm up to the phase where I'd like to have decals on the system.

 

The way I see it, there's two different ways to implement decals on deferred
rendering:

 

1)      The decals operates on the G-Buffer

2)      The decals operates on the frame buffer

 

The pros/cons I see in operating on the G-Buffer are:

 

-          Can get correctly lighted normal/emissive/specular mapped decals

-          Can't have blend operations on the decals (writing on the
G-Buffer has lots of data of different types, not all affected in the same
way, so alphablending or any other blend operation could spoil my data). So
all decals would have to "replace" what's already on the G-Buffer.

 

The pros/cons I see in operating on the frame buffer (the already lighted
scene, pre-glow pass):

 

-          Without checking the decal for every light, can't get lighted
decals

-          Can't do decals that glow/remove glow from the scene (the glow
intensity is on the G-Buffer, so that's what's used on the glow pass).

-          Blending operations are easier to define and control (and
possible without hocus-pocus)

 

At first sight, I'd say that operating on the G-Buffer is much simpler and
allows for more flexibility, but I still get the gnawing feeling that the
lack of alpha blending operations will bite me in the ass.

 

Consider these three decal types: bullet holes, footprints and plasma
residue.

 

On bullet holes, under the G-Buffer approach, I'd change the albedo of the
G-Buffer to a dark gray/black, while changing the normals to distort the
lighting on the bullet hole. On the frame buffer approach, I'd have to use a
subtract blending operation to darken the "wall" in the shape of the bullet
hole, without any distortion to the normals. The visual result might be good
in both cases.

On the footprints, for the G-Buffer approach, I'd have to just change the
normals to account for the footprint, without any change to the albedo,
which would be a realistic footprint in "muddy" environments, but I think it
would look silly in a dusty environment, which would be better done with an
albedo change to dark-brown or something like that, which might look
incorrect if the dust was on a metal floor. On the frame buffer approach,
I'd just have to alphablend a mid-alpha black texture in the shape of a
foot, using the alphablending hardware to get the correct footprint color on
different floors. It wouldn't look so good in muddy environments, but even
so it would look great.

On the plasma residue, I'd change the albedo and emissive component on the
G-Buffer to green and "high", which would lead to a glowy green goo on where
the plasma hit. On the frame buffer approach, I could only add a green color
to the frame buffer in the shape of the plasma residue, which wouldn't glow.

 

So, both approaches can be good or bad depending on what you're trying to
achieve. I even thought about having two kinds of decals (one that affects
the G-Buffer and another that affects the frame buffer) for different
usages, but to be honest I'm kind of at a loss on how to proceed.

 

The implementation seems pretty straightforward in both cases, it's just a
matter on where it goes in the pipeline, and all my searches on the Internet
been fruitless, since apparently nobody discusses decals at this level (only
building them and rendering them in the most primitive form).

 

So my question is: how do you guys handle decals in a deferred rendering
context? Any ideas, suggestions, pointing-at-and-laughing appreciated!

 

Thanks in advance

Diogo de Andrade

 

Re: [Algorithms] Re : Re : R: Sphere to rectangle

[Gino v. d. B. <gin...@gm...>]

You may want to check this article

http://web4.cs.ucl.ac.uk/staff/t.weyrich/projects/quadrics/pbg06.pdf

Basically, you need to find the bounding box in clip space (after 
applying the perspective projection). As you can see there are no 
trigonometric functions involved here.

Gino


On 1/11/2010 1:02 PM, Diogo de Andrade wrote:
>
> Hi Benjamin,
>
> I’ve looked at your explanation, and after you put it like that, I was 
> all “doh!”… The problem is way simpler to solve in that form 
> (extending the main line (center to red) so the projected point has 
> the same characteristics of the purple points). After that it was 
> pretty simple to get right…
>
> Thanks a lot for the help!
>
> Diogo
>
> *From:* Benjamin Rouveyrol [mailto:pth...@ya...]
> *Sent:* sexta-feira, 8 de Janeiro de 2010 16:36
> *To:* Game Development Algorithms; dri...@li...
> *Subject:* [Algorithms] Re : Re : R: Sphere to rectangle
>
> Hi Diogo,
>
> You pretty much spotted the problem with 
> http://www.spellcasterstudios.com/sphere_problem.jpg
>
> What I wanted to do is to keep the old direction (ie center of the 
> sphere towards the red dots), but change the vector's magnitude so 
> that the point is on the line made by the camera position and the pink 
> dot.
> So you compute first an angle (alpha = asin(R/D) ) on the triangle 
> made by light center, camera position and pink dot.
> Then you apply Thales (tan(alpha) = x / D <=> x = D * tan(alpha) )  to 
> get your final point outside the circle, and which is on the pink 
> line. And yes, I computed the right/up vectors the same way you did 
> (with a normalize for Right ;-) )
>
> When I look at my source code, I see that the 2D bounding rectangle 
> checks all the xy coordinates of all the points to get the 
> left/right/top/bottom.
> I can't remember why I did that, but I believe this was to solve the 
> problem you're showing.
>
> Ben
>
> ------------------------------------------------------------------------
>
> *De :* Diogo de Andrade <dio...@ne...>
> *À :* Game Development Algorithms 
> <gda...@li...>; dri...@li...
> *Envoyé le :* Ven 8 Janvier 2010, 10 h 51 min 22 s
> *Objet :* Re: [Algorithms] Re : R: Sphere to rectangle
>
> Hi Benjamin,
>
> Your solution almost works for me…
>
> It works when the camera is head on to the center of the sphere:
>
> http://www.spellcasterstudios.com/sphere_rect_problem01.jpg
>
> But when I turn left or right, I get:
>
> http://www.spellcasterstudios.com/sphere_rect_problem02.jpg
>
> http://www.spellcasterstudios.com/sphere_rect_problem03.jpg
>
> This might be related to the projection part, I’ll look into it…
>
> What do you mean by: “Up and right vectors based on the camera and 
> light positions (and the camera Up).”? I’m just accounting for camera 
> orientation to calculate the up and right vectors… Are you suggesting 
> something like:
>
> View=LightPos-CameraPos
>
> Right=cross(CameraUp,View)
>
> Up=cross(View,Right)
>
> ?
>
> From the more practical standpoint, from what I understand, you’re 
> applying a scale factor to the radius to account for distance… How did 
> you came about this formula?
>
> You didn’t happen to need something similar for spotlights/cones?
>
> Thanks,
>
> Diogo
>
> *From:* Benjamin Rouveyrol [mailto:pth...@ya...]
> *Sent:* sexta-feira, 8 de Janeiro de 2010 15:03
> *To:* Game Development Algorithms; dri...@li...
> *Subject:* [Algorithms] Re : R: Sphere to rectangle
>
> Hi,
>
> The way I solved this (but a bit math heavy):
> If R is the light Radius and D the distance between the camera and the 
> light:
> NewR = D * tan(asin(R/D))
>
> Then you compute Up and right vectors based on the camera and light 
> positions (and the camera Up).
> You end up with 4 corners: LightCenter +|- Up * NewR  +|- Right * NewR
>
>
> You can project them and this should give you your bounding rectangle. 
> If someone has a simpler solution, I'd be most interested ^_^
>
> Ben
>
> ------------------------------------------------------------------------
>
> *De :* Diogo de Andrade <dio...@ne...>
> *À :* dri...@li...; Game Development Algorithms 
> <gda...@li...>
> *Envoyé le :* Ven 8 Janvier 2010, 9 h 28 min 54 s
> *Objet :* Re: [Algorithms] R: Sphere to rectangle
>
> Hi!
>
> That's basically what I'm trying to do with the "wrong" solution, 
> although I don't tell it like that...
> It was a good thought... I had to think about it for 2 mins before I 
> understood that was exactly what I was trying to do...
>
> Visually, you can see the problem at 
> http://www.spellcasterstudios.com/sphere_problem.jpg
>
> With your solution (and my initial one), I'd get the red points (and 
> their projection, the yellow line), which is smaller than the correct 
> solution (the purple points/projection), which has the correct size...
>
> Thanks!
>
> Diogo
>
>
> -----Original Message-----
> From: dri...@li... <mailto:dri...@li...> 
> [mailto:dri...@li... <mailto:dri...@li...>]
> Sent: sexta-feira, 8 de Janeiro de 2010 13:54
> To: gda...@li... 
> <mailto:gda...@li...>
> Subject: [Algorithms] R: Sphere to rectangle
>
> ----Messaggio originale----
> Da: dio...@ne... <mailto:dio...@ne...>
> Data: 08/01/2010 13.45
>
> > Hi all…
> >
> > I’ve been wrestling with a problem for some days now, and I
> > honestly can’t seem to figure an elegant solution…
> >
> > I want to find the rectangle that bounds a omni light source,
> > so the problem is: given a sphere with center C=(x0,y0,z0) and radius
> RADIUS, what is the bounding rectangle rect=(rx1,ry1,rx2,ry2) on screen?
>
> Ok, I read this ML only for educational purpose, so...well, I'm sure I 
> will
> suggest the wrong solution :-D
>
> Arent'you simply trying to do screen-aligned billboarding?
> I mean...the bounding rectangle around a sphere of a given radius, on
> screen...is not always the same rectangle simply billboarded?
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast 
> and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li... 
> <mailto:GDA...@li...>
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast 
> and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li... 
> <mailto:GDA...@li...>
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
>
>
> _______________________________________________
> 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] Re : Re : R: Sphere to rectangle

[Diogo de A. <dio...@ne...>]

Hey everyone…

 

I’ve done a simple algorithm to get the cone area (for spot lights)… 

It’s basically the same as the omni light, but I find the bounding rectangle of a sphere S=(C,R), where C=LightPos+LightDir*range and R=range*tan(light_fov). 

After I do that, I calculate the projection of the position of light source, and do a min/max test to build the final bounding rectangle.

 

I’m sure there’s probably a much better way to do this, but this one actually works pretty well, considering how simple it is…

 

Again, thanks all for the help!

 

Diogo

 

From: Diogo de Andrade [mailto:dio...@ne...] 
Sent: segunda-feira, 11 de Janeiro de 2010 12:03
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Re : Re : R: Sphere to rectangle

 

Hi Benjamin,

 

I’ve looked at your explanation, and after you put it like that, I was all “doh!”… The problem is way simpler to solve in that form (extending the main line (center to red) so the projected point has the same characteristics of the purple points). After that it was pretty simple to get right…

 

Thanks a lot for the help!

 

Diogo

 

From: Benjamin Rouveyrol [mailto:pth...@ya...] 
Sent: sexta-feira, 8 de Janeiro de 2010 16:36
To: Game Development Algorithms; dri...@li...
Subject: [Algorithms] Re : Re : R: Sphere to rectangle

 

Hi Diogo,

You pretty much spotted the problem with http://www.spellcasterstudios.com/sphere_problem.jpg

What I wanted to do is to keep the old direction (ie center of the sphere towards the red dots), but change the vector's magnitude so that the point is on the line made by the camera position and the pink dot.
So you compute first an angle (alpha = asin(R/D) ) on the triangle made by light center, camera position and pink dot.
Then you apply Thales (tan(alpha) = x / D <=> x = D * tan(alpha) )  to get your final point outside the circle, and which is on the pink line. And yes, I computed the right/up vectors the same way you did (with a normalize for Right ;-) )

When I look at my source code, I see that the 2D bounding rectangle checks all the xy coordinates of all the points to get the left/right/top/bottom.
I can't remember why I did that, but I believe this was to solve the problem you're showing.

Ben

 

  _____  

De : Diogo de Andrade <dio...@ne...>
À : Game Development Algorithms <gda...@li...>; dri...@li...
Envoyé le : Ven 8 Janvier 2010, 10 h 51 min 22 s
Objet : Re: [Algorithms] Re : R: Sphere to rectangle

Hi Benjamin,

 

Your solution almost works for me… 

 

It works when the camera is head on to the center of the sphere:

 

 <http://www.spellcasterstudios.com/sphere_rect_problem01.jpg> http://www.spellcasterstudios.com/sphere_rect_problem01.jpg

 

But when I turn left or right, I get:

 

 <http://www.spellcasterstudios.com/sphere_rect_problem02.jpg> http://www.spellcasterstudios.com/sphere_rect_problem02.jpg

 <http://www.spellcasterstudios.com/sphere_rect_problem03.jpg> http://www.spellcasterstudios.com/sphere_rect_problem03.jpg

 

This might be related to the projection part, I’ll look into it…

What do you mean by: “Up and right vectors based on the camera and light positions (and the camera Up).”? I’m just accounting for camera orientation to calculate the up and right vectors… Are you suggesting something like:

 

View=LightPos-CameraPos

Right=cross(CameraUp,View)

Up=cross(View,Right)

 

?

 

>From the more practical standpoint, from what I understand, you’re applying a scale factor to the radius to account for distance… How did you came about this formula?

 

You didn’t happen to need something similar for spotlights/cones?

 

Thanks,

Diogo

 

 

From: Benjamin Rouveyrol [mailto:pth...@ya...] 
Sent: sexta-feira, 8 de Janeiro de 2010 15:03
To: Game Development Algorithms; dri...@li...
Subject: [Algorithms] Re : R: Sphere to rectangle

 

Hi,

The way I solved this (but a bit math heavy):
If R is the light Radius and D the distance between the camera and the light:
NewR = D * tan(asin(R/D))

Then you compute Up and right vectors based on the camera and light positions (and the camera Up).
You end up with 4 corners: LightCenter +|- Up * NewR  +|- Right * NewR


You can project them and this should give you your bounding rectangle. If someone has a simpler solution, I'd be most interested ^_^

Ben

 

  _____  

De : Diogo de Andrade <dio...@ne...>
À : dri...@li...; Game Development Algorithms <gda...@li...>
Envoyé le : Ven 8 Janvier 2010, 9 h 28 min 54 s
Objet : Re: [Algorithms] R: Sphere to rectangle

Hi!

That's basically what I'm trying to do with the "wrong" solution, although I don't tell it like that...
It was a good thought... I had to think about it for 2 mins before I understood that was exactly what I was trying to do...

Visually, you can see the problem at http://www.spellcasterstudios.com/sphere_problem.jpg

With your solution (and my initial one), I'd get the red points (and their projection, the yellow line), which is smaller than the correct solution (the purple points/projection), which has the correct size...

Thanks!

Diogo


-----Original Message-----
From: dri...@li... [mailto:dri...@li...] 
Sent: sexta-feira, 8 de Janeiro de 2010 13:54
To: gda...@li...
Subject: [Algorithms] R: Sphere to rectangle

----Messaggio originale----
Da: dio...@ne...
Data: 08/01/2010 13.45

> Hi all…
>  
> I’ve been wrestling with a problem for some days now, and I 
> honestly can’t seem to figure an elegant solution…
>  
> I want to find the rectangle that bounds a omni light source, 
> so the problem is: given a sphere with center C=(x0,y0,z0) and radius 
RADIUS, what is the bounding rectangle rect=(rx1,ry1,rx2,ry2) on screen?

Ok, I read this ML only for educational purpose, so...well, I'm sure I will 
suggest the wrong solution :-D

Arent'you simply trying to do screen-aligned billboarding?
I mean...the bounding rectangle around a sphere of a given radius, on 
screen...is not always the same rectangle simply billboarded?



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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] Re : Re : R: Sphere to rectangle

[Diogo de A. <dio...@ne...>]

Hi Benjamin,

 

I’ve looked at your explanation, and after you put it like that, I was all “doh!”… The problem is way simpler to solve in that form (extending the main line (center to red) so the projected point has the same characteristics of the purple points). After that it was pretty simple to get right…

 

Thanks a lot for the help!

 

Diogo

 

From: Benjamin Rouveyrol [mailto:pth...@ya...] 
Sent: sexta-feira, 8 de Janeiro de 2010 16:36
To: Game Development Algorithms; dri...@li...
Subject: [Algorithms] Re : Re : R: Sphere to rectangle

 

Hi Diogo,

You pretty much spotted the problem with http://www.spellcasterstudios.com/sphere_problem.jpg

What I wanted to do is to keep the old direction (ie center of the sphere towards the red dots), but change the vector's magnitude so that the point is on the line made by the camera position and the pink dot.
So you compute first an angle (alpha = asin(R/D) ) on the triangle made by light center, camera position and pink dot.
Then you apply Thales (tan(alpha) = x / D <=> x = D * tan(alpha) )  to get your final point outside the circle, and which is on the pink line. And yes, I computed the right/up vectors the same way you did (with a normalize for Right ;-) )

When I look at my source code, I see that the 2D bounding rectangle checks all the xy coordinates of all the points to get the left/right/top/bottom.
I can't remember why I did that, but I believe this was to solve the problem you're showing.

Ben

 

  _____  

De : Diogo de Andrade <dio...@ne...>
À : Game Development Algorithms <gda...@li...>; dri...@li...
Envoyé le : Ven 8 Janvier 2010, 10 h 51 min 22 s
Objet : Re: [Algorithms] Re : R: Sphere to rectangle

Hi Benjamin,

 

Your solution almost works for me… 

 

It works when the camera is head on to the center of the sphere:

 

 <http://www.spellcasterstudios.com/sphere_rect_problem01.jpg> http://www.spellcasterstudios.com/sphere_rect_problem01.jpg

 

But when I turn left or right, I get:

 

 <http://www.spellcasterstudios.com/sphere_rect_problem02.jpg> http://www.spellcasterstudios.com/sphere_rect_problem02.jpg

 <http://www.spellcasterstudios.com/sphere_rect_problem03.jpg> http://www.spellcasterstudios.com/sphere_rect_problem03.jpg

 

This might be related to the projection part, I’ll look into it…

What do you mean by: “Up and right vectors based on the camera and light positions (and the camera Up).”? I’m just accounting for camera orientation to calculate the up and right vectors… Are you suggesting something like:

 

View=LightPos-CameraPos

Right=cross(CameraUp,View)

Up=cross(View,Right)

 

?

 

>From the more practical standpoint, from what I understand, you’re applying a scale factor to the radius to account for distance… How did you came about this formula?

 

You didn’t happen to need something similar for spotlights/cones?

 

Thanks,

Diogo

 

 

From: Benjamin Rouveyrol [mailto:pth...@ya...] 
Sent: sexta-feira, 8 de Janeiro de 2010 15:03
To: Game Development Algorithms; dri...@li...
Subject: [Algorithms] Re : R: Sphere to rectangle

 

Hi,

The way I solved this (but a bit math heavy):
If R is the light Radius and D the distance between the camera and the light:
NewR = D * tan(asin(R/D))

Then you compute Up and right vectors based on the camera and light positions (and the camera Up).
You end up with 4 corners: LightCenter +|- Up * NewR  +|- Right * NewR


You can project them and this should give you your bounding rectangle. If someone has a simpler solution, I'd be most interested ^_^

Ben

 

  _____  

De : Diogo de Andrade <dio...@ne...>
À : dri...@li...; Game Development Algorithms <gda...@li...>
Envoyé le : Ven 8 Janvier 2010, 9 h 28 min 54 s
Objet : Re: [Algorithms] R: Sphere to rectangle

Hi!

That's basically what I'm trying to do with the "wrong" solution, although I don't tell it like that...
It was a good thought... I had to think about it for 2 mins before I understood that was exactly what I was trying to do...

Visually, you can see the problem at http://www.spellcasterstudios.com/sphere_problem.jpg

With your solution (and my initial one), I'd get the red points (and their projection, the yellow line), which is smaller than the correct solution (the purple points/projection), which has the correct size...

Thanks!

Diogo


-----Original Message-----
From: dri...@li... [mailto:dri...@li...] 
Sent: sexta-feira, 8 de Janeiro de 2010 13:54
To: gda...@li...
Subject: [Algorithms] R: Sphere to rectangle

----Messaggio originale----
Da: dio...@ne...
Data: 08/01/2010 13.45

> Hi all…
>  
> I’ve been wrestling with a problem for some days now, and I 
> honestly can’t seem to figure an elegant solution…
>  
> I want to find the rectangle that bounds a omni light source, 
> so the problem is: given a sphere with center C=(x0,y0,z0) and radius 
RADIUS, what is the bounding rectangle rect=(rx1,ry1,rx2,ry2) on screen?

Ok, I read this ML only for educational purpose, so...well, I'm sure I will 
suggest the wrong solution :-D

Arent'you simply trying to do screen-aligned billboarding?
I mean...the bounding rectangle around a sphere of a given radius, on 
screen...is not always the same rectangle simply billboarded?



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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] Sphere to rectangle

[Diogo de A. <dio...@ne...>]

Hi Fabian,

I've just plugged in your code into mine and it works like a charm!

I've looked into Eric Lengyel's explanation, but I've been unable to make it
work properly (probably did the same mistake in implementing the equations I
did on my own derivation, since the result was exactly the same)...
Looking forward to see your derivation, although I think I understood the
gist of it...

By any chance you don't have something similar for a cone for spotlights? :)

Thanks a million!
Diogo

-----Original Message-----
From: Fabian Giesen [mailto:f.g...@49...] 
Sent: sexta-feira, 8 de Janeiro de 2010 15:57
To: Game Development Algorithms
Subject: Re: [Algorithms] Sphere to rectangle

Benjamin Rouveyrol wrote:
> Hi,
> 
> The way I solved this (but a bit math heavy):
> If R is the light Radius and D the distance between the camera and the 
> light:
> NewR = D * tan(asin(R/D))
> 
> Then you compute Up and right vectors based on the camera and light 
> positions (and the camera Up).
> You end up with 4 corners: LightCenter +|- Up * NewR  +|- Right * NewR
> 
> 
> You can project them and this should give you your bounding rectangle. 
> If someone has a simpler solution, I'd be most interested ^_^

Eric Lengyel explains one way to solve this on the last page of his "The 
Mechanics of Robust Stencil Shadows" article:

http://www.gamasutra.com/view/feature/2942/the_mechanics_of_robust_stencil_.
php?page=6

I derived an alternative method for some hobby project around 2004 that 
is somewhat more straightforward. I don't have the original derivation 
anymore, but I remember that it was fairly straightforward trig:

// Calculates bounding rectangle in normalized device coordinates for
// the view-space sphere with center "center" and radius "r". "zoom"
// contains the first two diagonal entries of your projection matrix
// (which is assumed to be perspective). You should do a rough rejection
// test of the sphere against the frustum first.

static void CalcSphereBounds(const Vector& center, float r, const float 
zoom[2], float minb[2], float maxb[2])
{
   // by default, assume that full screen covered
   minb[0] = minb[1] = -1.0f;
   maxb[0] = maxb[1] =  1.0f;

   // once for x, once for y
   for(int i=0;i<2;i++)
   {
     float x = center[i];
     float z = center.z;
     float ds = x*x + z*z;
     float l = ds - r * r;

     if(l > 0.0f)
     {
       float s,c;
       l = sqrt(l);

       s = x * l - z * r; // ds*sin(alpha)
       c = x * r + z * l; // ds*cos(alpha)
       if(z*ds > -r*s) // left/top intersection has positive z
         minb[i] = max(-1.0f, s*zoom[i]/c);

       s = z * r + x * l; // ds*sin(beta)
       c = z * l - x * r; // ds*cos(beta)
       if(z*ds > r*s) // right/bottom intersection has positive z
         maxb[i] = min(1.0f, s*zoom[i]/c);
     }
   }
}

I'll try to re-derive this so as not to leave a bunch of unexplained 
formulas standing in the room, but it's a relatively short solution and 
it's worked fine for me, so I guess it's of interest.

Kind regards,
-Fabian

----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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] Re : Re : R: Sphere to rectangle

[Benjamin R. <pth...@ya...>]

Hi Diogo,

You pretty much spotted the problem with http://www.spellcasterstudios.com/sphere_problem.jpg

What I wanted to do is to keep the old direction (ie center of the sphere towards the red dots), but change the vector's magnitude so that the point is on the line made by the camera position and the pink dot.
So you compute first an angle (alpha = asin(R/D) ) on the triangle made by light center, camera position and pink dot.
Then you apply Thales (tan(alpha) = x / D <=> x = D * tan(alpha) )  to get your final point outside the circle, and which is on the pink line. And yes, I computed the right/up vectors the same way you did (with a normalize for Right ;-) )

When I look at my source code, I see that the 2D bounding rectangle checks all the xy coordinates of all the points to get the left/right/top/bottom.
I can't remember why I did that, but I believe this was to solve the problem you're showing.

Ben




________________________________
De : Diogo de Andrade <dio...@ne...>
À : Game Development Algorithms <gda...@li...>; dri...@li...
Envoyé le : Ven 8 Janvier 2010, 10 h 51 min 22 s
Objet : Re: [Algorithms] Re :  R:  Sphere to rectangle

 
Hi Benjamin,
 
Your solution almost works for me… 
 
It works when the camera is head on to the center of the sphere:
 
http://www.spellcasterstudios.com/sphere_rect_problem01.jpg
 
But when I turn left or right, I get:
 
http://www.spellcasterstudios.com/sphere_rect_problem02.jpg
http://www.spellcasterstudios.com/sphere_rect_problem03.jpg
 
This might be related to the projection part, I’ll look into it…
What do you mean by: “Up and right vectors based on
the camera and light positions (and the camera Up).”? I’m just accounting for
camera orientation to calculate the up and right vectors… Are you suggesting
something like:
 
View=LightPos-CameraPos
Right=cross(CameraUp,View)
Up=cross(View,Right)
 
?
 
From the more practical standpoint, from what I understand, you’re
applying a scale factor to the radius to account for distance… How did you came
about this formula?
 
You didn’t happen to need something similar for spotlights/cones?
 
Thanks,
Diogo
 
 
From:Benjamin Rouveyrol
[mailto:pth...@ya...] 
Sent: sexta-feira, 8 de Janeiro de 2010 15:03
To: Game Development Algorithms; dri...@li...
Subject: [Algorithms] Re : R: Sphere to rectangle
 
Hi,

The way I solved this (but a bit math heavy):
If R is the light Radius and D the distance between the camera and the light:
NewR = D *
tan(asin(R/D))

Then you compute Up and right vectors based on the camera and light positions
(and the camera Up).
You end up with 4 corners: LightCenter
+|- Up * NewR  +|- Right * NewR


You can project them and this should give you your bounding rectangle.
If someone has a simpler solution, I'd be most interested ^_^

Ben
 

________________________________
 
De
:Diogo de Andrade <dio...@ne...>
À : dri...@li...; Game Development Algorithms
<gda...@li...>
Envoyé le : Ven 8 Janvier 2010, 9 h 28 min 54 s
Objet : Re: [Algorithms] R: Sphere to rectangle

Hi!

That's basically what I'm trying to do with the "wrong" solution,
although I don't tell it like that...
It was a good thought... I had to think about it for 2 mins before I understood
that was exactly what I was trying to do...

Visually, you can see the problem at http://www.spellcasterstudios.com/sphere_problem.jpg

With your solution (and my initial one), I'd get the red points (and their
projection, the yellow line), which is smaller than the correct solution (the
purple points/projection), which has the correct size...

Thanks!

Diogo


-----Original Message-----
From: dri...@li... [mailto:dri...@li...] 
Sent: sexta-feira, 8 de Janeiro de 2010 13:54
To: gda...@li...
Subject: [Algorithms] R: Sphere to rectangle

----Messaggio originale----
Da: dio...@ne...
Data: 08/01/2010 13.45

> Hi all…
>  
> I’ve been wrestling with a problem for some days now, and I 
> honestly can’t seem to figure an elegant solution…
>  
> I want to find the rectangle that bounds a omni light source, 
> so the problem is: given a sphere with center C=(x0,y0,z0) and radius 
RADIUS, what is the bounding rectangle rect=(rx1,ry1,rx2,ry2) on screen?

Ok, I read this ML only for educational purpose, so...well, I'm sure I will 
suggest the wrong solution :-D

Arent'you simply trying to do screen-aligned billboarding?
I mean...the bounding rectangle around a sphere of a given radius, on 
screen...is not always the same rectangle simply billboarded?



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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] Sphere to rectangle

[Fabian G. <f.g...@49...>]

Benjamin Rouveyrol wrote:
> Hi,
> 
> The way I solved this (but a bit math heavy):
> If R is the light Radius and D the distance between the camera and the 
> light:
> NewR = D * tan(asin(R/D))
> 
> Then you compute Up and right vectors based on the camera and light 
> positions (and the camera Up).
> You end up with 4 corners: LightCenter +|- Up * NewR  +|- Right * NewR
> 
> 
> You can project them and this should give you your bounding rectangle. 
> If someone has a simpler solution, I'd be most interested ^_^

Eric Lengyel explains one way to solve this on the last page of his "The 
Mechanics of Robust Stencil Shadows" article:

http://www.gamasutra.com/view/feature/2942/the_mechanics_of_robust_stencil_.php?page=6

I derived an alternative method for some hobby project around 2004 that 
is somewhat more straightforward. I don't have the original derivation 
anymore, but I remember that it was fairly straightforward trig:

// Calculates bounding rectangle in normalized device coordinates for
// the view-space sphere with center "center" and radius "r". "zoom"
// contains the first two diagonal entries of your projection matrix
// (which is assumed to be perspective). You should do a rough rejection
// test of the sphere against the frustum first.

static void CalcSphereBounds(const Vector& center, float r, const float 
zoom[2], float minb[2], float maxb[2])
{
   // by default, assume that full screen covered
   minb[0] = minb[1] = -1.0f;
   maxb[0] = maxb[1] =  1.0f;

   // once for x, once for y
   for(int i=0;i<2;i++)
   {
     float x = center[i];
     float z = center.z;
     float ds = x*x + z*z;
     float l = ds - r * r;

     if(l > 0.0f)
     {
       float s,c;
       l = sqrt(l);

       s = x * l - z * r; // ds*sin(alpha)
       c = x * r + z * l; // ds*cos(alpha)
       if(z*ds > -r*s) // left/top intersection has positive z
         minb[i] = max(-1.0f, s*zoom[i]/c);

       s = z * r + x * l; // ds*sin(beta)
       c = z * l - x * r; // ds*cos(beta)
       if(z*ds > r*s) // right/bottom intersection has positive z
         maxb[i] = min(1.0f, s*zoom[i]/c);
     }
   }
}

I'll try to re-derive this so as not to leave a bunch of unexplained 
formulas standing in the room, but it's a relatively short solution and 
it's worked fine for me, so I guess it's of interest.

Kind regards,
-Fabian

Re: [Algorithms] Re : R: Sphere to rectangle

[Diogo de A. <dio...@ne...>]

Hi Benjamin,

 

Your solution almost works for me… 

 

It works when the camera is head on to the center of the sphere:

 

 <http://www.spellcasterstudios.com/sphere_rect_problem01.jpg> http://www.spellcasterstudios.com/sphere_rect_problem01.jpg

 

But when I turn left or right, I get:

 

 <http://www.spellcasterstudios.com/sphere_rect_problem02.jpg> http://www.spellcasterstudios.com/sphere_rect_problem02.jpg

 <http://www.spellcasterstudios.com/sphere_rect_problem03.jpg> http://www.spellcasterstudios.com/sphere_rect_problem03.jpg

 

This might be related to the projection part, I’ll look into it…

What do you mean by: “Up and right vectors based on the camera and light positions (and the camera Up).”? I’m just accounting for camera orientation to calculate the up and right vectors… Are you suggesting something like:

 

View=LightPos-CameraPos

Right=cross(CameraUp,View)

Up=cross(View,Right)

 

?

 

>From the more practical standpoint, from what I understand, you’re applying a scale factor to the radius to account for distance… How did you came about this formula?

 

You didn’t happen to need something similar for spotlights/cones?

 

Thanks,

Diogo

 

 

From: Benjamin Rouveyrol [mailto:pth...@ya...] 
Sent: sexta-feira, 8 de Janeiro de 2010 15:03
To: Game Development Algorithms; dri...@li...
Subject: [Algorithms] Re : R: Sphere to rectangle

 

Hi,

The way I solved this (but a bit math heavy):
If R is the light Radius and D the distance between the camera and the light:
NewR = D * tan(asin(R/D))

Then you compute Up and right vectors based on the camera and light positions (and the camera Up).
You end up with 4 corners: LightCenter +|- Up * NewR  +|- Right * NewR


You can project them and this should give you your bounding rectangle. If someone has a simpler solution, I'd be most interested ^_^

Ben

 

  _____  

De : Diogo de Andrade <dio...@ne...>
À : dri...@li...; Game Development Algorithms <gda...@li...>
Envoyé le : Ven 8 Janvier 2010, 9 h 28 min 54 s
Objet : Re: [Algorithms] R: Sphere to rectangle

Hi!

That's basically what I'm trying to do with the "wrong" solution, although I don't tell it like that...
It was a good thought... I had to think about it for 2 mins before I understood that was exactly what I was trying to do...

Visually, you can see the problem at http://www.spellcasterstudios.com/sphere_problem.jpg

With your solution (and my initial one), I'd get the red points (and their projection, the yellow line), which is smaller than the correct solution (the purple points/projection), which has the correct size...

Thanks!

Diogo


-----Original Message-----
From: dri...@li... [mailto:dri...@li...] 
Sent: sexta-feira, 8 de Janeiro de 2010 13:54
To: gda...@li...
Subject: [Algorithms] R: Sphere to rectangle

----Messaggio originale----
Da: dio...@ne...
Data: 08/01/2010 13.45

> Hi all…
>  
> I’ve been wrestling with a problem for some days now, and I 
> honestly can’t seem to figure an elegant solution…
>  
> I want to find the rectangle that bounds a omni light source, 
> so the problem is: given a sphere with center C=(x0,y0,z0) and radius 
RADIUS, what is the bounding rectangle rect=(rx1,ry1,rx2,ry2) on screen?

Ok, I read this ML only for educational purpose, so...well, I'm sure I will 
suggest the wrong solution :-D

Arent'you simply trying to do screen-aligned billboarding?
I mean...the bounding rectangle around a sphere of a given radius, on 
screen...is not always the same rectangle simply billboarded?



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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] Re : R: Sphere to rectangle

[Benjamin R. <pth...@ya...>]

Hi,

The way I solved this (but a bit math heavy):
If R is the light Radius and D the distance between the camera and the light:
NewR = D * tan(asin(R/D))

Then you compute Up and right vectors based on the camera and light positions (and the camera Up).
You end up with 4 corners: LightCenter +|- Up * NewR  +|- Right * NewR


You can project them and this should give you your bounding rectangle. If someone has a simpler solution, I'd be most interested ^_^

Ben




________________________________
De : Diogo de Andrade <dio...@ne...>
À : dri...@li...; Game Development Algorithms <gda...@li...>
Envoyé le : Ven 8 Janvier 2010, 9 h 28 min 54 s
Objet : Re: [Algorithms] R:  Sphere to rectangle

Hi!

That's basically what I'm trying to do with the "wrong" solution, although I don't tell it like that...
It was a good thought... I had to think about it for 2 mins before I understood that was exactly what I was trying to do...

Visually, you can see the problem at http://www.spellcasterstudios.com/sphere_problem.jpg

With your solution (and my initial one), I'd get the red points (and their projection, the yellow line), which is smaller than the correct solution (the purple points/projection), which has the correct size...

Thanks!

Diogo


-----Original Message-----
From: dri...@li... [mailto:dri...@li...] 
Sent: sexta-feira, 8 de Janeiro de 2010 13:54
To: gda...@li...
Subject: [Algorithms] R: Sphere to rectangle

----Messaggio originale----
Da: dio...@ne...
Data: 08/01/2010 13.45

> Hi all…
>  
> I’ve been wrestling with a problem for some days now, and I 
> honestly can’t seem to figure an elegant solution…
>  
> I want to find the rectangle that bounds a omni light source, 
> so the problem is: given a sphere with center C=(x0,y0,z0) and radius 
RADIUS, what is the bounding rectangle rect=(rx1,ry1,rx2,ry2) on screen?

Ok, I read this ML only for educational purpose, so...well, I'm sure I will 
suggest the wrong solution :-D

Arent'you simply trying to do screen-aligned billboarding?
I mean...the bounding rectangle around a sphere of a given radius, on 
screen...is not always the same rectangle simply billboarded?



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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] R: Sphere to rectangle

[Diogo de A. <dio...@ne...>]

Hi!

That's basically what I'm trying to do with the "wrong" solution, although I don't tell it like that...
It was a good thought... I had to think about it for 2 mins before I understood that was exactly what I was trying to do...

Visually, you can see the problem at http://www.spellcasterstudios.com/sphere_problem.jpg

With your solution (and my initial one), I'd get the red points (and their projection, the yellow line), which is smaller than the correct solution (the purple points/projection), which has the correct size...

Thanks!

Diogo


-----Original Message-----
From: dri...@li... [mailto:dri...@li...] 
Sent: sexta-feira, 8 de Janeiro de 2010 13:54
To: gda...@li...
Subject: [Algorithms] R: Sphere to rectangle

----Messaggio originale----
Da: dio...@ne...
Data: 08/01/2010 13.45

> Hi all…
>  
> I’ve been wrestling with a problem for some days now, and I 
> honestly can’t seem to figure an elegant solution…
>  
> I want to find the rectangle that bounds a omni light source, 
> so the problem is: given a sphere with center C=(x0,y0,z0) and radius 
RADIUS, what is the bounding rectangle rect=(rx1,ry1,rx2,ry2) on screen?
 
Ok, I read this ML only for educational purpose, so...well, I'm sure I will 
suggest the wrong solution :-D

Arent'you simply trying to do screen-aligned billboarding?
I mean...the bounding rectangle around a sphere of a given radius, on 
screen...is not always the same rectangle simply billboarded?



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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] R: Sphere to rectangle

[<dri...@li...>]

----Messaggio originale----
Da: dio...@ne...
Data: 08/01/2010 13.45

> Hi all…
>  
> I’ve been wrestling with a problem for some days now, and I 
> honestly can’t seem to figure an elegant solution…
>  
> I want to find the rectangle that bounds a omni light source, 
> so the problem is: given a sphere with center C=(x0,y0,z0) and radius 
RADIUS, what is the bounding rectangle rect=(rx1,ry1,rx2,ry2) on screen?
 
Ok, I read this ML only for educational purpose, so...well, I'm sure I will 
suggest the wrong solution :-D

Arent'you simply trying to do screen-aligned billboarding?
I mean...the bounding rectangle around a sphere of a given radius, on 
screen...is not always the same rectangle simply billboarded?

[Algorithms] Sphere to rectangle

[Diogo de A. <dio...@ne...>]

Hi all.

 

I've been wrestling with a problem for some days now, and I honestly can't
seem to figure an elegant solution.

 

I want to find the rectangle that bounds a omni light source, so the problem
is: given a sphere with center C=(x0,y0,z0) and radius RADIUS, what is the
bounding rectangle rect=(rx1,ry1,rx2,ry2) on screen? 

 

My first guess was to find the extents of the sphere from the camera point
of view:

 

0)      Given a camera with position O=(x2,y2,z3) and view vectors
V=(v1,v2,v3), U=(u1,u2,u3) and R=(r1,r2,r3)

1)      Compute E1=C+R*RADIUS and E2=C+U*RADIUS

2)      E1'=proj(E1)

3)      E2'=proj(E2)

4)      O'=proj(O)

5)      rect=(O'.x-E1.x,O'.y+E2.y,O'.x+E1.x,O'.y+E2.y)

 

This almost works (specially at larger distances), but it is wrong, because
the points I find aren't the real bounds of the sphere from the camera
(after projection, the rectangle is smaller than needed), because I'm using
a perspective projection and not a orthogonal projection (took me alots of
diagrams to understand why).

 

After some more thinking, I arrived to the conclusion that what I want is to
find out the point E  that fulfill these two conditions:

 

||E-C||=r -> The point belongs to the sphere

dot(E-O,E-C)=0 -> The line defined by O and E is tangent to the sphere at
point E.

 

I started crushing the equations, but then I found that I was looking at
this problem really in 2d, and not 3d, and I have no idea on how to convert
this to 3d, to be honest.

 

My first guess is that I project all the relevant points (C and O) first
onto the plane with normal U (to extract the "horizontal" extents) and then
onto the plane with normal R (to extract the "vertical" extents) and then
treat the problem as a 2d problem, and combine the solutions to obtain a
point E1 and E2, which then are projected onto the screen (following from
point 2 on the algorithm above). But I'm not sure if this is the right
answer.

 

I'm not even sure if there isn't a better solution, to be honest. Saw
somewhere that I could find the intersection between the sphere and an
"imaginary" sphere with center C'=mid(O,C) and radius RADIUS'=||C'||/2, and
that seems like it can be easier to manage, but again, I'm not sure.

 

To compound the problem, afterwards I want to do the same for a spotlight,
which complicates matters (I need to find the bounding rectangle of a cone,
which seems like a bigger nightmare!).

 

So, can someone lend me a hand on this? Just being pointed in the right
direction (book, site, mathematical direction, etc), would be appreciated.
Even more, would be code to do both of these, but that might be a bit much
to ask. ;)

 

Thanks in advance

Diogo de Andrade

Re: [Algorithms] Quadric surface extraction

[Gino v. d. B. <gin...@gm...>]

Quadratic surfaces in general are represented implicitly as a solution 
to a quadratic equation, so if you want to generate a mesh from a 
generic quadratic equation you will either need to resort to an implicit 
surface generation algorithm such as Marching Cubes, or find some clever 
way of parameterizing the surface (anyone?). For specific quadric 
surfaces such as ellipsoids, cones, cylinders you can straightforwardly 
derive a parametric representation. Code for generating meshes for these 
surface types is widely available. For instance, check out the 
quadric.c  in the OpenGL sample implementation 
(http://oss.sgi.com/projects/ogl-sample/) or OpenSceneGraph 
(http://www.openscenegraph.org/projects/osg).

Gino


On 6-1-2010 5:07, Tom Sparks wrote:
> Quadric surfaces how do I convert them to polygons meshes?
>
> tom_a_sparks
>
>
>        __________________________________________________________________________________
> See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> 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] Quadric surface extraction

[Tom S. <tom...@ya...>]

Quadric surfaces how do I convert them to polygons meshes?

tom_a_sparks


      __________________________________________________________________________________
See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/

Re: [Algorithms] Frame independent Camera Shake

[Andy F. <pad...@ob...>]

Damping would be important to a realistic effect. Scale the
sine impulses by a  square or cubic function with a decay
of around a second. As Will says, the blur simulates high frequency
shake, so you don't really need to add higher harmonics onto
your sine waves if you have that - make it proportional to
the rms amplitude of the movement.

Andy  


On Mon, Dec 21, 2009 at 11:57:11PM +1300, Will Vale wrote:
> 
> If you have the ability to blur your output image, you can layer this on  
> top of camera shake in very small amounts - e.g. one frame of blur when  
> you hit something. It can be quite effective - I reckon it looks like high  
> frequency shake, as a counterpoint to the (relatively) low frequency shake  
> provided by moving the camera.
> 
> If you already have *motion* blur there isn't much point, but there are  
> platforms where that isn't practical still.
> 
> Will
> 
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> 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] Frame independent Camera Shake

[Will V. <wi...@se...>]

If you have the ability to blur your output image, you can layer this on  
top of camera shake in very small amounts - e.g. one frame of blur when  
you hit something. It can be quite effective - I reckon it looks like high  
frequency shake, as a counterpoint to the (relatively) low frequency shake  
provided by moving the camera.

If you already have *motion* blur there isn't much point, but there are  
platforms where that isn't practical still.

Will