You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(390) 
_{Aug}
(767) 
_{Sep}
(940) 
_{Oct}
(964) 
_{Nov}
(819) 
_{Dec}
(762) 

2001 
_{Jan}
(680) 
_{Feb}
(1075) 
_{Mar}
(954) 
_{Apr}
(595) 
_{May}
(725) 
_{Jun}
(868) 
_{Jul}
(678) 
_{Aug}
(785) 
_{Sep}
(410) 
_{Oct}
(395) 
_{Nov}
(374) 
_{Dec}
(419) 
2002 
_{Jan}
(699) 
_{Feb}
(501) 
_{Mar}
(311) 
_{Apr}
(334) 
_{May}
(501) 
_{Jun}
(507) 
_{Jul}
(441) 
_{Aug}
(395) 
_{Sep}
(540) 
_{Oct}
(416) 
_{Nov}
(369) 
_{Dec}
(373) 
2003 
_{Jan}
(514) 
_{Feb}
(488) 
_{Mar}
(396) 
_{Apr}
(624) 
_{May}
(590) 
_{Jun}
(562) 
_{Jul}
(546) 
_{Aug}
(463) 
_{Sep}
(389) 
_{Oct}
(399) 
_{Nov}
(333) 
_{Dec}
(449) 
2004 
_{Jan}
(317) 
_{Feb}
(395) 
_{Mar}
(136) 
_{Apr}
(338) 
_{May}
(488) 
_{Jun}
(306) 
_{Jul}
(266) 
_{Aug}
(424) 
_{Sep}
(502) 
_{Oct}
(170) 
_{Nov}
(170) 
_{Dec}
(134) 
2005 
_{Jan}
(249) 
_{Feb}
(109) 
_{Mar}
(119) 
_{Apr}
(282) 
_{May}
(82) 
_{Jun}
(113) 
_{Jul}
(56) 
_{Aug}
(160) 
_{Sep}
(89) 
_{Oct}
(98) 
_{Nov}
(237) 
_{Dec}
(297) 
2006 
_{Jan}
(151) 
_{Feb}
(250) 
_{Mar}
(222) 
_{Apr}
(147) 
_{May}
(266) 
_{Jun}
(313) 
_{Jul}
(367) 
_{Aug}
(135) 
_{Sep}
(108) 
_{Oct}
(110) 
_{Nov}
(220) 
_{Dec}
(47) 
2007 
_{Jan}
(133) 
_{Feb}
(144) 
_{Mar}
(247) 
_{Apr}
(191) 
_{May}
(191) 
_{Jun}
(171) 
_{Jul}
(160) 
_{Aug}
(51) 
_{Sep}
(125) 
_{Oct}
(115) 
_{Nov}
(78) 
_{Dec}
(67) 
2008 
_{Jan}
(165) 
_{Feb}
(37) 
_{Mar}
(130) 
_{Apr}
(111) 
_{May}
(91) 
_{Jun}
(142) 
_{Jul}
(54) 
_{Aug}
(104) 
_{Sep}
(89) 
_{Oct}
(87) 
_{Nov}
(44) 
_{Dec}
(54) 
2009 
_{Jan}
(283) 
_{Feb}
(113) 
_{Mar}
(154) 
_{Apr}
(395) 
_{May}
(62) 
_{Jun}
(48) 
_{Jul}
(52) 
_{Aug}
(54) 
_{Sep}
(131) 
_{Oct}
(29) 
_{Nov}
(32) 
_{Dec}
(37) 
2010 
_{Jan}
(34) 
_{Feb}
(36) 
_{Mar}
(40) 
_{Apr}
(23) 
_{May}
(38) 
_{Jun}
(34) 
_{Jul}
(36) 
_{Aug}
(27) 
_{Sep}
(9) 
_{Oct}
(18) 
_{Nov}
(25) 
_{Dec}

2011 
_{Jan}
(1) 
_{Feb}
(14) 
_{Mar}
(1) 
_{Apr}
(5) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}
(37) 
_{Sep}
(6) 
_{Oct}
(2) 
_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(10) 
2013 
_{Jan}

_{Feb}
(1) 
_{Mar}
(7) 
_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2014 
_{Jan}
(14) 
_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

S  M  T  W  T  F  S 



1

2

3

4
(7) 
5

6

7
(5) 
8

9

10

11

12

13

14

15

16

17
(1) 
18

19

20

21

22

23

24
(1) 
25

26

27

28






From: Paul Firth <paul@wi...>  20110224 11:56:47

Hi guys, I know this list is mainly console developers, but i think there are a few guys doing web games on here, so i'll put this article out there in the hopes that its useful for someone :) Its about a different way to approach collision detection in an isometric 2d game, called "2d Isometric land – breaking out of the grid", i hope you like it: http://www.wildbunny.co.uk/blog/?p=63 :) Cheers, Paul.  Paul Firth http://www.wildbunny.co.uk http://www.facebook.com/WildbunnyLtd email: paul@... 
From: Diogo de Andrade <diogo.andrade@sp...>  20110217 10:47:14

Hi all! I've finally had the time to implement and use all your suggestions, and if you're interested you can see some of the results here: http://shadowcovenant.com/blog/2011/02/10/ambientocclusionmaps/ Most of the issues I solved by using barycentric coordinates, instead of using just gradients calculated through interpolation... Thanks for all the help everyone! Best regards, Diogo Original Message From: Olivier Galibert [mailto:galibert@...] Sent: sextafeira, 4 de Fevereiro de 2011 19:32 To: gdalgorithmslist@... Subject: Re: [Algorithms] Texel area On Fri, Feb 04, 2011 at 10:50:08AM 0000, Diogo de Andrade wrote: > So, what I want to do is, given > >  triangle T=(V1,V2,V3), in which V1, V2, V3 are vertexes that have > some properties (world space position, normal, diffuse color, texture > coordinates > 0 (in uniform space), texture coordinates 1 (in texture space, > [0..texture size[), etc), > >  texture size > >  position inside the triangle (absolute value in texture space) > > is to find out the rectangle that bounds the texel in world space > (origin+2 vectors)... If that's your real problem, the solution is reasonably simple and has nothing to do with the rasterization. You have three points when space/texture coordinates: (x0, y0, z0, u0, v0) (x1, y1, z1, u1, v1) (x2, y2, z2, u2, v2) Given u, v the position in texture space, you first want to find the barycentric coordinates (t1, t2):  u0 + t1*(u1u0) + t2*(u2u0) = u  v0 + t1*(v1v0) + t2*(v2v0) = v That's a rather usual linear system. Noting the inverse determinant di: di = 1/((v2v0)*(u1u0)  (u2u0)*(v1v0)) then:  t1 = di*((v2v0)*(uu0)  (u2u0)*(vv0))  t2 = di*((v1v0)*(uu0)  (u1u0)*(vv0)) >From these, you can easily find the world coordinates:  x = x0 + t1*(x1x0) + t2*(x2x0)  y = y0 + t1*(y1y0) + t2*(y2y0)  z = z0 + t1*(z1z0) + t2*(z2z0) You'll notice that all these are linear systems, which means a texel rectangle size is independant of its position. So you can get your vector once by computing the position differences between (0, 0), (0.5, 0) and (0, 0.5) for instance. You'll notice the equations simplify nicely when computing deltas if you do the math. I suspect it's not your real problem though, so feel free to correct it :) OG.   The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood  see how these rules translate into the virtual world? http://p.sf.net/sfu/oraclesfdevnlfb _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist 
From: Jason Hughes <jhughes@st...>  20110207 19:05:27

Actually, all this talk about triangles being flat is somewhat confusing. :) The only way a triangle really represents a sliver of a plane is if the vertex normals are all parallel. Otherwise, it's really an approximation to a curved surface, and you're inducing faceting in your samples by assuming they are planar. Shouldn't the correct mapping should be concave or convex, according to the flex in the curvature of the triangle? Just saying... JH On 2/7/2011 12:15 PM, David Neubelt wrote: > > The gradient will be constant across the triangle. If > it's constant in dx and it's constant in dy then it's constant > everywhere. If you know the gradient in the two directions then you > know it everywhere (dx, dy, 0) > > *From:*Manuel Massing [mailto:m.massing@...] > *Sent:* Monday, February 07, 2011 2:47 AM > *To:* Game Development Algorithms > *Subject:* Re: [Algorithms] Texel area > > Hi Diogo, > > > This seems counterintuitive... I understand your reasoning, and I can't > > > find a mistake in your logic, but it seems to me that the size > shouldn't be > > > constant (from an intuitive standpoint)... > > you are probably thinking about the usual texture mapping setup, where > > a projective mapping (from screen space to texture space) is performed. > > In this canonical case, the texture footprint is position dependent (you > > describe the mapping of projective planes by a homography, which is > > linear in homogenous coordinates, but nonlinear in texture/screen > coordinates due to the perspective division). > > Your setup is just a linear transform of a 2D subspace (you want to > transform > > the UV plane into the world space triangle plane), i.e. you seek a > mapping of the UVbasis vectors to their respective worldspace > counterparts. > > cheers, > > Manuel > > >  > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood  see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oraclesfdevnlfb > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist 
From: David Neubelt <david@re...>  20110207 18:27:43

The gradient will be constant across the triangle. If it's constant in dx and it's constant in dy then it's constant everywhere. If you know the gradient in the two directions then you know it everywhere (dx, dy, 0) From: Manuel Massing [mailto:m.massing@...] Sent: Monday, February 07, 2011 2:47 AM To: Game Development Algorithms Subject: Re: [Algorithms] Texel area Hi Diogo, > This seems counterintuitive... I understand your reasoning, and I can't > find a mistake in your logic, but it seems to me that the size shouldn't be > constant (from an intuitive standpoint)... you are probably thinking about the usual texture mapping setup, where a projective mapping (from screen space to texture space) is performed. In this canonical case, the texture footprint is position dependent (you describe the mapping of projective planes by a homography, which is linear in homogenous coordinates, but nonlinear in texture/screen coordinates due to the perspective division). Your setup is just a linear transform of a 2D subspace (you want to transform the UV plane into the world space triangle plane), i.e. you seek a mapping of the UVbasis vectors to their respective worldspace counterparts. cheers, Manuel 
From: Olivier Galibert <galibert@po...>  20110207 10:55:54

Hi, On Mon, Feb 07, 2011 at 10:04:23AM 0000, Diogo de Andrade wrote: > I'm just unclear on a couple of things: > > > That's a rather usual linear system. Noting the inverse determinant > > How does this matter? Not questioning it, just trying to understand what > follows from here... It matters just because equation systems of the form: ax+by = c dx+ey = f have a well known solution. > > You'll notice that all these are linear systems, which means a texel > rectangle size is independant of its position. > > This seems counterintuitive... I understand your reasoning, and I can't > find a mistake in your logic, but it seems to me that the size shouldn't be > constant (from an intuitive standpoint)... Your intuition is thinking "projected on the screen" while your question was "in world space". In world space, camera position doesn't matter. Mapping the texture is equivalent to cutting a triangle in the texture with points on the (u, v) positions, and streching it like is was made of rubber to fit the worldspace triangle. The squares that are the texels stretch into parallelograms, but they all end up the same size. OG. 
From: Manuel Massing <m.massing@wa...>  20110207 10:46:59

Hi Diogo, > This seems counterintuitive... I understand your reasoning, and I can't > find a mistake in your logic, but it seems to me that the size shouldn't be > constant (from an intuitive standpoint)... you are probably thinking about the usual texture mapping setup, where a projective mapping (from screen space to texture space) is performed. In this canonical case, the texture footprint is position dependent (you describe the mapping of projective planes by a homography, which is linear in homogenous coordinates, but nonlinear in texture/screen coordinates due to the perspective division). Your setup is just a linear transform of a 2D subspace (you want to transform the UV plane into the world space triangle plane), i.e. you seek a mapping of the UVbasis vectors to their respective worldspace counterparts. cheers, Manuel 
From: Diogo de Andrade <diogo.andrade@sp...>  20110207 10:21:37

Hi Olivier, I was already having similar thoughts on how to solve this (use the barycentric coordinates to solve a linear system), so it seems to me that you got the jist of it, I'm going to try implementing... I'm just unclear on a couple of things: > That's a rather usual linear system. Noting the inverse determinant How does this matter? Not questioning it, just trying to understand what follows from here... > You'll notice that all these are linear systems, which means a texel rectangle size is independant of its position. This seems counterintuitive... I understand your reasoning, and I can't find a mistake in your logic, but it seems to me that the size shouldn't be constant (from an intuitive standpoint)... Best regards, Diogo Original Message From: Olivier Galibert [mailto:galibert@...] Sent: sextafeira, 4 de Fevereiro de 2011 19:32 To: gdalgorithmslist@... Subject: Re: [Algorithms] Texel area On Fri, Feb 04, 2011 at 10:50:08AM 0000, Diogo de Andrade wrote: > So, what I want to do is, given > >  triangle T=(V1,V2,V3), in which V1, V2, V3 are vertexes that have > some properties (world space position, normal, diffuse color, texture > coordinates > 0 (in uniform space), texture coordinates 1 (in texture space, > [0..texture size[), etc), > >  texture size > >  position inside the triangle (absolute value in texture space) > > is to find out the rectangle that bounds the texel in world space > (origin+2 vectors)... If that's your real problem, the solution is reasonably simple and has nothing to do with the rasterization. You have three points when space/texture coordinates: (x0, y0, z0, u0, v0) (x1, y1, z1, u1, v1) (x2, y2, z2, u2, v2) Given u, v the position in texture space, you first want to find the barycentric coordinates (t1, t2):  u0 + t1*(u1u0) + t2*(u2u0) = u  v0 + t1*(v1v0) + t2*(v2v0) = v That's a rather usual linear system. Noting the inverse determinant di: di = 1/((v2v0)*(u1u0)  (u2u0)*(v1v0)) then:  t1 = di*((v2v0)*(uu0)  (u2u0)*(vv0))  t2 = di*((v1v0)*(uu0)  (u1u0)*(vv0)) >From these, you can easily find the world coordinates:  x = x0 + t1*(x1x0) + t2*(x2x0)  y = y0 + t1*(y1y0) + t2*(y2y0)  z = z0 + t1*(z1z0) + t2*(z2z0) You'll notice that all these are linear systems, which means a texel rectangle size is independant of its position. So you can get your vector once by computing the position differences between (0, 0), (0.5, 0) and (0, 0.5) for instance. You'll notice the equations simplify nicely when computing deltas if you do the math. I suspect it's not your real problem though, so feel free to correct it :) OG.   The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood  see how these rules translate into the virtual world? http://p.sf.net/sfu/oraclesfdevnlfb _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist 
From: Manuel Massing <m.massing@wa...>  20110204 20:03:18

Hi Diogo, >  triangle T=(V1,V2,V3), in which V1, V2, V3 are vertexes that have some > properties (world space position, normal, diffuse color, texture > coordinates 0 (in uniform space), texture coordinates 1 (in texture space, > [0..texture size[), etc), > >  texture size > >  position inside the triangle (absolute value in texture space) > > > > is to find out the rectangle that bounds the texel in world space (origin+2 > vectors)... if I understand your setup correctly, you're dealing with a linear transform (from a plane in UVspace to a plane in world space), so the partial derivatives with respect to u and v are constants across the triangle. If this is not too much setup overhead, you could proceed by finding the world space directions U and V corresponding to the u/v axes for the triangle by solving for a 3x2 matrix with the worldspacedirections U and V as columns: matrix(U V) * (AB) = A.worldpos  B.worldpos matrix(U V) * (BC) = B.worldpos  C.worldpos where A, B are 2D u/v coordinates (in pixel units). cheers, Manuel 
From: Olivier Galibert <galibert@po...>  20110204 19:51:26

On Fri, Feb 04, 2011 at 10:50:08AM 0000, Diogo de Andrade wrote: > So, what I want to do is, given > >  triangle T=(V1,V2,V3), in which V1, V2, V3 are vertexes that have some > properties (world space position, normal, diffuse color, texture coordinates > 0 (in uniform space), texture coordinates 1 (in texture space, [0..texture > size[), etc), > >  texture size > >  position inside the triangle (absolute value in texture space) > > is to find out the rectangle that bounds the texel in world space (origin+2 > vectors)... If that's your real problem, the solution is reasonably simple and has nothing to do with the rasterization. You have three points when space/texture coordinates: (x0, y0, z0, u0, v0) (x1, y1, z1, u1, v1) (x2, y2, z2, u2, v2) Given u, v the position in texture space, you first want to find the barycentric coordinates (t1, t2):  u0 + t1*(u1u0) + t2*(u2u0) = u  v0 + t1*(v1v0) + t2*(v2v0) = v That's a rather usual linear system. Noting the inverse determinant di: di = 1/((v2v0)*(u1u0)  (u2u0)*(v1v0)) then:  t1 = di*((v2v0)*(uu0)  (u2u0)*(vv0))  t2 = di*((v1v0)*(uu0)  (u1u0)*(vv0)) >From these, you can easily find the world coordinates:  x = x0 + t1*(x1x0) + t2*(x2x0)  y = y0 + t1*(y1y0) + t2*(y2y0)  z = z0 + t1*(z1z0) + t2*(z2z0) You'll notice that all these are linear systems, which means a texel rectangle size is independant of its position. So you can get your vector once by computing the position differences between (0, 0), (0.5, 0) and (0, 0.5) for instance. You'll notice the equations simplify nicely when computing deltas if you do the math. I suspect it's not your real problem though, so feel free to correct it :) OG. 
From: Jason Hughes <jhughes@st...>  20110204 18:19:14

Maybe this is an oddball suggestion but... perhaps you could go about sampling the triangle in one pass first using jittered barycentric coordinates and creating a bucketful of samples without regard to pixel stepping. Then, in a second pass step through the triangle in and find the nearest several samples and interpolate them with respect to their barycentric coordinates to get the value at the pixel center. This would give you some flexibility in sampling density (not requiring a sample per pixel), for faster runs with fewer samples, or higher quality runs with more samples and more added to the interpolation. Then again, it could just be horribly slow. And certainly I haven't helped address your questions. ;) JH On 2/4/2011 7:12 AM, Diogo de Andrade wrote: > > Hi Sebastian, > > Well, no my rasterizer (which might be a piece of trash...) is a > scanline rasterizer... > > So, for the following triangle: > > A > > x > > xx > > xxx > > xxxx > > xxxxx > > xxxxxx > > xxxxxxx > > B C > > I know the left gradient, and the right gradient... Problem is that > the position gradient of AC (for example) is something like > scalar*(sqrt(2)/2,sqrt(2)/2) and not the "down" scalar*(0,1) gradient > I'd like... The horizontal gradient works allright, since I'm > interpolating between the spans... > > As far as I understand the problem, the issue is that for every pixel, > I know how to reach the next horizontal lumel (which is one of the > things I need), and on the edges, I know how to go to the next lumel > on the edge (which most of the time doesn't match the actual "down" > position I need). > > For communication purposes, I'm calling the "down" position to the > worldrelative vector that takes me from the position of the current > lumel, to the one that's right below it in UV space... The "next > horizontal lumel" is the one that's right to the right of the current > one in UV space. > > Don't know if this was clear enough, I'm starting to have a hard time > getting my head around the problem (maybe too close to it by now)... > > Best regards, > > Diogo > > *From:*Sebastian Sylvan [mailto:sebastian.sylvan@...] > *Sent:* sextafeira, 4 de Fevereiro de 2011 11:48 > *To:* Game Development Algorithms > *Subject:* Re: [Algorithms] Texel area > > On Fri, Feb 4, 2011 at 10:50 AM, Diogo de Andrade > <diogo.andrade@... > <mailto:diogo.andrade@...>> wrote: > > Hi all! > > I've been struggling with a problem and I hope somebody can point me > in the right direction... > > I'm making a lightmap/ambient occlusion map generator system, and for > that I built a rasterizer that calls a function that does the > computations and fills the target image. > > The rasterizer works in UV space, but all parameters of the triangle > are interpolated. > > Now, I wanted to add multisampling, so that I don't get just a single > sample for the ambient occlusion, and I want to "jitter" the source > point (not only the raycast direction), > > and for that I need to find out what's the area of the target lumel. > By area, I mean not only the actual area value, but the "rectangle" > that bounds the lumel, in world space... > > So, what I want to do is, given > >  triangle T=(V1,V2,V3), in which V1, V2, V3 are vertexes that have > some properties (world space position, normal, diffuse color, texture > coordinates 0 (in uniform space), texture coordinates 1 (in texture > space, [0..texture size[), etc), > >  texture size > >  position inside the triangle (absolute value in texture space) > > is to find out the rectangle that bounds the texel in world space > (origin+2 vectors)... > > I've been thinking about this, but can't seem to find an approach that > works correctly... I'm expecting some error in this calculation (due > to the rasterizing process itself), but it's not a big deal since it's > for sampling purposes, but even so I can't seem to make it work... > > So, if anyone got any links, keywords, or just a simple algorithm he > doesn't mind sharing, I'd appreciate it! > > The interpolator in the rasterizer should already know the gradient > for the position w.r.t. the pixel (i.e.lumel, in this case) position > right? So you once you know the center position for a given pixel > (lumel) it should be easy to compute the world space positions of the > corners of that pixel (just take the position gradient multiplied by > +/ 0.5pixels and add it to the center position), which gives you the > quadraliteral in world space. > > >  > Sebastian Sylvan > > >  > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood  see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oraclesfdevnlfb > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist 
From: Diogo de Andrade <diogo.andrade@sp...>  20110204 13:30:37

Hi Sebastian, Well, no my rasterizer (which might be a piece of trash...) is a scanline rasterizer. So, for the following triangle: A x xx xxx xxxx xxxxx xxxxxx xxxxxxx B C I know the left gradient, and the right gradient. Problem is that the position gradient of AC (for example) is something like scalar*(sqrt(2)/2,sqrt(2)/2) and not the "down" scalar*(0,1) gradient I'd like. The horizontal gradient works allright, since I'm interpolating between the spans. As far as I understand the problem, the issue is that for every pixel, I know how to reach the next horizontal lumel (which is one of the things I need), and on the edges, I know how to go to the next lumel on the edge (which most of the time doesn't match the actual "down" position I need). For communication purposes, I'm calling the "down" position to the worldrelative vector that takes me from the position of the current lumel, to the one that's right below it in UV space. The "next horizontal lumel" is the one that's right to the right of the current one in UV space. Don't know if this was clear enough, I'm starting to have a hard time getting my head around the problem (maybe too close to it by now). Best regards, Diogo From: Sebastian Sylvan [mailto:sebastian.sylvan@...] Sent: sextafeira, 4 de Fevereiro de 2011 11:48 To: Game Development Algorithms Subject: Re: [Algorithms] Texel area On Fri, Feb 4, 2011 at 10:50 AM, Diogo de Andrade <diogo.andrade@...> wrote: Hi all! I've been struggling with a problem and I hope somebody can point me in the right direction... I'm making a lightmap/ambient occlusion map generator system, and for that I built a rasterizer that calls a function that does the computations and fills the target image. The rasterizer works in UV space, but all parameters of the triangle are interpolated. Now, I wanted to add multisampling, so that I don't get just a single sample for the ambient occlusion, and I want to "jitter" the source point (not only the raycast direction), and for that I need to find out what's the area of the target lumel. By area, I mean not only the actual area value, but the "rectangle" that bounds the lumel, in world space... So, what I want to do is, given  triangle T=(V1,V2,V3), in which V1, V2, V3 are vertexes that have some properties (world space position, normal, diffuse color, texture coordinates 0 (in uniform space), texture coordinates 1 (in texture space, [0..texture size[), etc),  texture size  position inside the triangle (absolute value in texture space) is to find out the rectangle that bounds the texel in world space (origin+2 vectors)... I've been thinking about this, but can't seem to find an approach that works correctly... I'm expecting some error in this calculation (due to the rasterizing process itself), but it's not a big deal since it's for sampling purposes, but even so I can't seem to make it work... So, if anyone got any links, keywords, or just a simple algorithm he doesn't mind sharing, I'd appreciate it! The interpolator in the rasterizer should already know the gradient for the position w.r.t. the pixel (i.e.lumel, in this case) position right? So you once you know the center position for a given pixel (lumel) it should be easy to compute the world space positions of the corners of that pixel (just take the position gradient multiplied by +/ 0.5pixels and add it to the center position), which gives you the quadraliteral in world space.  Sebastian Sylvan 
From: Sebastian Sylvan <sebastian.sylvan@gm...>  20110204 11:47:58

On Fri, Feb 4, 2011 at 10:50 AM, Diogo de Andrade < diogo.andrade@...> wrote: > Hi all! > > > > I've been struggling with a problem and I hope somebody can point me in the > right direction... > > I'm making a lightmap/ambient occlusion map generator system, and for that > I built a rasterizer that calls a function that does the computations and > fills the target image. > > The rasterizer works in UV space, but all parameters of the triangle are > interpolated. > > > > Now, I wanted to add multisampling, so that I don't get just a single > sample for the ambient occlusion, and I want to "jitter" the source point > (not only the raycast direction), > > and for that I need to find out what's the area of the target lumel. By > area, I mean not only the actual area value, but the "rectangle" that bounds > the lumel, in world space... > > > > So, what I want to do is, given > > > >  triangle T=(V1,V2,V3), in which V1, V2, V3 are vertexes that have some > properties (world space position, normal, diffuse color, texture coordinates > 0 (in uniform space), texture coordinates 1 (in texture space, [0..texture > size[), etc), > >  texture size > >  position inside the triangle (absolute value in texture space) > > > > is to find out the rectangle that bounds the texel in world space (origin+2 > vectors)... > > > > I've been thinking about this, but can't seem to find an approach that > works correctly... I'm expecting some error in this calculation (due to the > rasterizing process itself), but it's not a big deal since it's for sampling > purposes, but even so I can't seem to make it work... > > > > So, if anyone got any links, keywords, or just a simple algorithm he > doesn't mind sharing, I'd appreciate it! > The interpolator in the rasterizer should already know the gradient for the position w.r.t. the pixel (i.e.lumel, in this case) position right? So you once you know the center position for a given pixel (lumel) it should be easy to compute the world space positions of the corners of that pixel (just take the position gradient multiplied by +/ 0.5pixels and add it to the center position), which gives you the quadraliteral in world space.  Sebastian Sylvan 
From: Diogo de Andrade <diogo.andrade@sp...>  20110204 11:21:12

Hi all! I've been struggling with a problem and I hope somebody can point me in the right direction... I'm making a lightmap/ambient occlusion map generator system, and for that I built a rasterizer that calls a function that does the computations and fills the target image. The rasterizer works in UV space, but all parameters of the triangle are interpolated. Now, I wanted to add multisampling, so that I don't get just a single sample for the ambient occlusion, and I want to "jitter" the source point (not only the raycast direction), and for that I need to find out what's the area of the target lumel. By area, I mean not only the actual area value, but the "rectangle" that bounds the lumel, in world space... So, what I want to do is, given  triangle T=(V1,V2,V3), in which V1, V2, V3 are vertexes that have some properties (world space position, normal, diffuse color, texture coordinates 0 (in uniform space), texture coordinates 1 (in texture space, [0..texture size[), etc),  texture size  position inside the triangle (absolute value in texture space) is to find out the rectangle that bounds the texel in world space (origin+2 vectors)... I've been thinking about this, but can't seem to find an approach that works correctly... I'm expecting some error in this calculation (due to the rasterizing process itself), but it's not a big deal since it's for sampling purposes, but even so I can't seem to make it work... So, if anyone got any links, keywords, or just a simple algorithm he doesn't mind sharing, I'd appreciate it! Best regards, Diogo de Andrade 
From: Diogo de Andrade <diogo.andrade@sp...>  20110204 11:17:01

Hi all! I've been struggling with a problem and I hope somebody can point me in the right direction... I'm making a lightmap/ambient occlusion map generator system, and for that I built a rasterizer that calls a function that does the computations and fills the target image. The rasterizer works in UV space, but all parameters of the triangle are interpolated. Now, I wanted to add multisampling, so that I don't get just a single sample for the ambient occlusion, and I want to "jitter" the source point (not only the raycast direction), and for that I need to find out what's the area of the target lumel. By area, I mean not only the actual area value, but the "rectangle" that bounds the lumel, in world space... So, what I want to do is, given  triangle T=(V1,V2,V3), in which V1, V2, V3 are vertexes that have some properties (world space position, normal, diffuse color, texture coordinates 0 (in uniform space), texture coordinates 1 (in texture space, [0..texture size[), etc),  texture size  position inside the triangle (absolute value in texture space) is to find out the rectangle that bounds the texel in world space (origin+2 vectors)... I've been thinking about this, but can't seem to find an approach that works correctly... I'm expecting some error in this calculation (due to the rasterizing process itself), but it's not a big deal since it's for sampling purposes, but even so I can't seem to make it work... So, if anyone got any links, keywords, or just a simple algorithm he doesn't mind sharing, I'd appreciate it! Best regards, Diogo de Andrade 