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}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

_{Dec}
(1) 
2016 
_{Jan}

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

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{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: 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 