Thread: [Algorithms] Texel area
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: Diogo de A. <dio...@sp...> - 2011-02-04 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 |
|
From: Diogo de A. <dio...@sp...> - 2011-02-04 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: Sebastian S. <seb...@gm...> - 2011-02-04 11:47:58
|
On Fri, Feb 4, 2011 at 10:50 AM, Diogo de Andrade < dio...@sp...> 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 A. <dio...@sp...> - 2011-02-04 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 world-relative 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:seb...@gm...] Sent: sexta-feira, 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 <dio...@sp...> 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: Jason H. <jh...@st...> - 2011-02-04 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 > world-relative 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:seb...@gm...] > *Sent:* sexta-feira, 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 > <dio...@sp... > <mailto:dio...@sp...>> 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/oracle-sfdevnlfb > > > _______________________________________________ > 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 |
|
From: Olivier G. <gal...@po...> - 2011-02-04 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*(u1-u0) + t2*(u2-u0) = u | v0 + t1*(v1-v0) + t2*(v2-v0) = v That's a rather usual linear system. Noting the inverse determinant di: di = 1/((v2-v0)*(u1-u0) - (u2-u0)*(v1-v0)) then: | t1 = di*((v2-v0)*(u-u0) - (u2-u0)*(v-v0)) | t2 = di*((v1-v0)*(u-u0) - (u1-u0)*(v-v0)) >From these, you can easily find the world coordinates: | x = x0 + t1*(x1-x0) + t2*(x2-x0) | y = y0 + t1*(y1-y0) + t2*(y2-y0) | z = z0 + t1*(z1-z0) + t2*(z2-z0) 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: Diogo de A. <dio...@sp...> - 2011-02-07 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 counter-intuitive... 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:gal...@po...] Sent: sexta-feira, 4 de Fevereiro de 2011 19:32 To: gda...@li... 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*(u1-u0) + t2*(u2-u0) = u | v0 + t1*(v1-v0) + t2*(v2-v0) = v That's a rather usual linear system. Noting the inverse determinant di: di = 1/((v2-v0)*(u1-u0) - (u2-u0)*(v1-v0)) then: | t1 = di*((v2-v0)*(u-u0) - (u2-u0)*(v-v0)) | t2 = di*((v1-v0)*(u-u0) - (u1-u0)*(v-v0)) >From these, you can easily find the world coordinates: | x = x0 + t1*(x1-x0) + t2*(x2-x0) | y = y0 + t1*(y1-y0) + t2*(y2-y0) | z = z0 + t1*(z1-z0) + t2*(z2-z0) 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/oracle-sfdevnlfb _______________________________________________ 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 |
|
From: Manuel M. <m.m...@wa...> - 2011-02-07 10:46:59
|
Hi Diogo, > This seems counter-intuitive... 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 non-linear 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 UV-basis vectors to their respective world-space counterparts. cheers, Manuel |
|
From: David N. <da...@re...> - 2011-02-07 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.m...@wa...] Sent: Monday, February 07, 2011 2:47 AM To: Game Development Algorithms Subject: Re: [Algorithms] Texel area Hi Diogo, > This seems counter-intuitive... 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 non-linear 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 UV-basis vectors to their respective world-space counterparts. cheers, Manuel |
|
From: Jason H. <jh...@st...> - 2011-02-07 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.m...@wa...] > *Sent:* Monday, February 07, 2011 2:47 AM > *To:* Game Development Algorithms > *Subject:* Re: [Algorithms] Texel area > > Hi Diogo, > > > This seems counter-intuitive... 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 non-linear 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 UV-basis vectors to their respective world-space > 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/oracle-sfdevnlfb > > > _______________________________________________ > 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 |
|
From: Olivier G. <gal...@po...> - 2011-02-07 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 counter-intuitive... 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 world-space triangle. The squares that are the texels stretch into parallelograms, but they all end up the same size. OG. |
|
From: Diogo de A. <dio...@sp...> - 2011-02-17 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/ambient-occlusion-maps/ 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:gal...@po...] Sent: sexta-feira, 4 de Fevereiro de 2011 19:32 To: gda...@li... 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*(u1-u0) + t2*(u2-u0) = u | v0 + t1*(v1-v0) + t2*(v2-v0) = v That's a rather usual linear system. Noting the inverse determinant di: di = 1/((v2-v0)*(u1-u0) - (u2-u0)*(v1-v0)) then: | t1 = di*((v2-v0)*(u-u0) - (u2-u0)*(v-v0)) | t2 = di*((v1-v0)*(u-u0) - (u1-u0)*(v-v0)) >From these, you can easily find the world coordinates: | x = x0 + t1*(x1-x0) + t2*(x2-x0) | y = y0 + t1*(y1-y0) + t2*(y2-y0) | z = z0 + t1*(z1-z0) + t2*(z2-z0) 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/oracle-sfdevnlfb _______________________________________________ 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X