gdalgorithms-list

Re: [Algorithms] VIPM and UV texturing

[Sebastian T. <s....@gm...>]

> But if I have the scenario where one triangle is mapped with UVs : u1,v1,
> u2,v2, u3,v3
> and an adjacent triangle mapped with u6,v6, u7,v7, u8,v8; the adjacency is
> along the edge
> of (u1,v1 & u6,v6) - (u3,v3 & u8,v8), where u1,v1 and u6,v6 actual
vertices
> are coincident, as is the case with u3,v3 and u8,v8.
>
> What happens when I drop out the edge ?

I think of edge collapses as edges that shrink into one point.

>
> Wouldn't the texture coords will be interpolated from u2,v2 to u7,v7 which
> may be totally screwed ?  I must be missing some fundamental stuff here
...

You don't interpolate anything. Your vertex data keeps the same for any of
the meshes. The only thing you change is the index list.

Sebastian

Re: [Algorithms] VIPM and UV texturing

[Sebastian T. <s....@gm...>]

>     Well, I think the thing you missed is that VIPM is mainly aimed
towards
> meshes that are more like skinned meshes (ie, all points only have a
single
> vertex associated with them

This is very limiting. VIPM can handle vertex attributes very well.

Sebastian

Re: [Algorithms] VIPM and UV texturing

[Mark W. <mwa...@to...>]

>     Well, I think the thing you missed is that VIPM is mainly aimed
towards
> meshes that are more like skinned meshes (ie, all points only have a
single
> vertex associated with them - Hence each set of adjacent triangles must be
> specifiable as a strip). I like to call these sort of meshes, highly
> connected meshes (HCM), for the simple purpose that with appearance to the
> renderer, they share vertices, and are therefore connected.

I cite different vertices because the actual UV coords are different
(eg. a vertex is NOT just gemoetry, as in the D3D definition)

Doesn't anyone use large meshes that are textured using multiple textures
with VIPM,
in that you would want the mesh as a whole to reduce, not the similarly
textured "pieces" ?

What I'm tending to now assume is that most users of VIPM are using it on
trivially textured
objects ... would this be a fair assumption, or once again have I missed
something ?

>     I've moved towards using HCM to describe more things in my engine
worlds
> now (although, I need to get some art together to show off the benefit -
Its
> not going to work as well with the incredibly simple cubes etc I  turn out
> by hand). This should provide higher performance on complex worlds (due to
> more vertex coherancy) and allow more LoD.
>
> Also, new today, I actually finally updated my column, on VIPM of all
things
> :) http://www.flipcode.com/dp/issue04.shtml

Cool, saw this, read it, but it didn't address my question :)

Thanks for the feedback,

Mark

Re: [Algorithms] VIPM and UV texturing

[Conor S. <cs...@tp...>]

> But if I have the scenario where one triangle is mapped with UVs : u1,v1,
> u2,v2, u3,v3
> and an adjacent triangle mapped with u6,v6, u7,v7, u8,v8; the adjacency is
> along the edge
> of (u1,v1 & u6,v6) - (u3,v3 & u8,v8), where u1,v1 and u6,v6 actual
vertices
> are coincident, as is the case with u3,v3 and u8,v8.
>
> What happens when I drop out the edge ?
>
> Wouldn't the texture coords will be interpolated from u2,v2 to u7,v7 which
> may be totally screwed ?  I must be missing some fundamental stuff here
...
>

    Well, I think the thing you missed is that VIPM is mainly aimed towards
meshes that are more like skinned meshes (ie, all points only have a single
vertex associated with them - Hence each set of adjacent triangles must be
specifiable as a strip). I like to call these sort of meshes, highly
connected meshes (HCM), for the simple purpose that with appearance to the
renderer, they share vertices, and are therefore connected.

    I've moved towards using HCM to describe more things in my engine worlds
now (although, I need to get some art together to show off the benefit - Its
not going to work as well with the incredibly simple cubes etc I  turn out
by hand). This should provide higher performance on complex worlds (due to
more vertex coherancy) and allow more LoD.

Also, new today, I actually finally updated my column, on VIPM of all things
:) http://www.flipcode.com/dp/issue04.shtml

Conor Stokes

Re: [Algorithms] VIPM and UV texturing

[Mark W. <mwa...@to...>]

Angel,

Thanks for the references, I will be sure to check them out.

Mark

----- Original Message -----
From: "Angel Popov" <ju...@bi...>
To: <gda...@li...>
Sent: Tuesday, August 08, 2000 9:11 PM
Subject: Re: [Algorithms] VIPM and UV texturing


> > Hey all,
> >
> > For those of you who are using/experimenting with VIPM, how are you
> > generating your texture coords when the mesh is reduced ?  Do you all
assume
> > planar mapping or what ?
> > Any info or discussion on this topic would be appreciated.
>
> This paper by Michael Garland and Paul Heckbert:
> "Simplifying Surfaces with Color and Texture using Quadric Error Metrics"
> explains an extention to the standart quadratic error metrics alghotithm
for
> meshes with apearance attributes (texture coordinates, color, normals... )
>
> If you are not familiar with QEM - read this paper first:
> "Surface Simplification Using Quadric Error Metrics"
>
> Both papers are avaiable at
> http://graphics.cs.uiuc.edu/~garland/research/quadrics.html
>
> A more efficient implementation was developped by Hugues Hoppe:
> "New quadric metric for simplifying meshes with appearance attributes"
> This paper can be found at
> http://www.research.microsoft.com/~hoppe/
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] VIPM and UV texturing

[Mark W. <mwa...@to...>]

Thanks for the response:

> Er... with the usual type of VIPM, you don't generate texture coords, or
> indeed any new vertices,  at all. All you do is throw one point away and
> collapse the edge onto the other one.
>
> There are variants where you generate some sort of new "average" midpoint,
> but (a) the quality improvement isn't very large and (b) it is quite a bit
> less efficient to render, because for a given LoD, you have vertices that
> are used by lower LoDs, but not the current one, which causes problems.

But if I have the scenario where one triangle is mapped with UVs : u1,v1,
u2,v2, u3,v3
and an adjacent triangle mapped with u6,v6, u7,v7, u8,v8; the adjacency is
along the edge
of (u1,v1 & u6,v6) - (u3,v3 & u8,v8), where u1,v1 and u6,v6 actual vertices
are coincident, as is the case with u3,v3 and u8,v8.

What happens when I drop out the edge ?

Wouldn't the texture coords will be interpolated from u2,v2 to u7,v7 which
may be totally screwed ?  I must be missing some fundamental stuff here ...

> A related question is how to calculate texture coords (and other
attributes)
> when creating subdiv surfaces. I just use linear - seems to work OK with
my
> data, but others prefer to use other methods, such as use the subdiv
surface
> method, but on the attributes data. This gives excellent results BUT it is
> possibly covered by a sneaky Pixar patent. It's still unclear exactly what
> this patent covers (as with all patents, it's extremely vague), but there
> may be some prior art that we can hide behind :-) In any case, simpler
> methods such as Loop subdivision is often perfectly acceptable for
> attributes, since perfect C1/G1 is not actually needed in most cases.

I've yet to look into subdiv surfs yet, but it'll no doubt arise ;)

Thanks again,

Mark

Re: [Algorithms] Pixar patent

[Corrinne Y. <cor...@ho...>]

-- I am friends with Tony Apodaca and a few of the founders / lead
programmers at Pixar. Let me ask them and find out where the patent stands,
and what their intentions are, and post the response on this list.

Corrinne Yu





----- Original Message -----
From: "Brian Marshall" <bma...@ra...>
To: <gda...@li...>
Sent: Tuesday, August 08, 2000 6:11 AM
Subject: RE: [Algorithms] Pixar patent


> I've had our lawyers check up on it. I'm not in a position of giving any
> kind of legal opinion on it, but if you get a specific idea checked out
then
> you may well be pleasantly surprised.
> It worth remembering that anything quoted as prior art for a patent can't
be
> part of the patent invention.
>
> -Brian.
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] Pixar patent

[Brian M. <bma...@ra...>]

I've had our lawyers check up on it. I'm not in a position of giving any
kind of legal opinion on it, but if you get a specific idea checked out then
you may well be pleasantly surprised.
It worth remembering that anything quoted as prior art for a patent can't be
part of the patent invention.

-Brian.

[Algorithms] Pixar patent

[Peter W. <Pet...@vi...>]

> A related question is how to calculate texture coords (and 
> other attributes) when creating subdiv surfaces. I just use
> linear - seems to work OK with my data, but others prefer to
> use other methods, such as use the subdiv surface method,
> but on the attributes data. This gives excellent results BUT
> it is possibly covered by a sneaky Pixar patent. It's still
> unclear exactly what this patent covers (as with all patents,
> it's extremely vague), but there may be some prior art that
> we can hide behind :-)

For anybody else who's interested, the patent number is 6,037,949, and you
can look at the patent at http://www.uspto.gov/patft/index.html

As Tom said, after reading it I'm still unclear exactly what it's supposed
to cover. It seems to claim any interpolation of values across a subdivided
surface, which if true is pretty sneaky.

Peter

Re: [Algorithms] ROAM

[Paul A. <fr...@fu...>]

RE: [Algorithms] ROAMThanks all..

Paul..
  ----- Original Message -----=20
  From: Andrew Grant=20
  To: 'gda...@li...'=20
  Sent: Tuesday, August 08, 2000 10:25 AM
  Subject: RE: [Algorithms] ROAM


  I found an article on Gamasutra a great help when I was first writing =
my own implementation a while back;=20

  http://www.gamasutra.com/features/20000403/turner_pfv.htm=20

  It contains a pretty straightforward explanation and sample code. Step =
through the code and draw what it's doing to the landscape and patches =
on paper, you'll pick it up pretty quickly.

  Andrew Grant -=20
  HotHouse Creations=20




  >=20
  >=20
  > Hi all,=20
  >=20
  > I just checked out the image of the day on www.flipcode.com=20
  > that showed a=20
  > landscape using the ROAM algorithm.  The landscape does look nice so =
I=20
  > decided I may move my arse and look into landscape rendering which I =

  > promised myself I would do for some time now :-)=20
  >=20
  > Just wondered if there are any pointers to good documentation=20
  > about ROAM or=20
  > other such algorithms for LOD on landscapes...  I guess there=20
  > are plenty but=20
  > any ones that stick out from the rest ?=20
  >=20
  > (appolagies,  i am new to the list :)=20
  >=20
  > Thanks=20
  >=20
  > Paul.=20
  >=20

Re: [Algorithms] VIPM and UV texturing

[Angel P. <ju...@bi...>]

> Hey all,
> 
> For those of you who are using/experimenting with VIPM, how are you
> generating your texture coords when the mesh is reduced ?  Do you all assume
> planar mapping or what ?
> Any info or discussion on this topic would be appreciated.

This paper by Michael Garland and Paul Heckbert:
"Simplifying Surfaces with Color and Texture using Quadric Error Metrics"
explains an extention to the standart quadratic error metrics alghotithm for
meshes with apearance attributes (texture coordinates, color, normals... )

If you are not familiar with QEM - read this paper first:
"Surface Simplification Using Quadric Error Metrics"

Both papers are avaiable at
http://graphics.cs.uiuc.edu/~garland/research/quadrics.html

A more efficient implementation was developped by Hugues Hoppe:
"New quadric metric for simplifying meshes with appearance attributes"
This paper can be found at
http://www.research.microsoft.com/~hoppe/

RE: [Algorithms] ROAM

[Andrew G. <And...@ho...>]

I found an article on Gamasutra a great help when I was first writing my own
implementation a while back;

http://www.gamasutra.com/features/20000403/turner_pfv.htm

It contains a pretty straightforward explanation and sample code. Step
through the code and draw what it's doing to the landscape and patches on
paper, you'll pick it up pretty quickly.

Andrew Grant -
HotHouse Creations



> 
> 
> Hi all,
> 
> I just checked out the image of the day on www.flipcode.com 
> that showed a
> landscape using the ROAM algorithm.  The landscape does look nice so I
> decided I may move my arse and look into landscape rendering which I
> promised myself I would do for some time now :-)
> 
> Just wondered if there are any pointers to good documentation 
> about ROAM or
> other such algorithms for LOD on landscapes...  I guess there 
> are plenty but
> any ones that stick out from the rest ?
> 
> (appolagies,  i am new to the list :)
> 
> Thanks
> 
> Paul.
> 

Re: [Algorithms] ROAM

[Martin G. <bz...@wi...>]

Check out Ben Discoe's www.vterrain.org - excellent links, tutorials, etc.

-----Original Message-----
From: Paul Adams <fr...@fu...>
To: gda...@li...
<gda...@li...>
Date: 08 Àâãóñò 2000 ã. 12:09
Subject: [Algorithms] ROAM


>Hi all,
>
>I just checked out the image of the day on www.flipcode.com that showed a
>landscape using the ROAM algorithm.  The landscape does look nice so I
>decided I may move my arse and look into landscape rendering which I
>promised myself I would do for some time now :-)
>
>Just wondered if there are any pointers to good documentation about ROAM or
>other such algorithms for LOD on landscapes...  I guess there are plenty but
>any ones that stick out from the rest ?
>
>(appolagies,  i am new to the list :)
>
>Thanks
>
>Paul.
>
>
>
>
>
>
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

RE: [Algorithms] ROAM

[Jenny A. <aj...@fr...>]

Hi Paul,

Just start your search here :
www.vterrain.org

Alexandre JENNY
WWW.LE-GEO.COM

-----Message d'origine-----
De : Paul Adams [mailto:fr...@fu...]
Envoyé : mardi 8 août 2000 10:58
À : gda...@li...
Objet : [Algorithms] ROAM


Hi all,

I just checked out the image of the day on www.flipcode.com that showed a
landscape using the ROAM algorithm.  The landscape does look nice so I
decided I may move my arse and look into landscape rendering which I
promised myself I would do for some time now :-)

Just wondered if there are any pointers to good documentation about ROAM or
other such algorithms for LOD on landscapes...  I guess there are plenty but
any ones that stick out from the rest ?

(appolagies,  i am new to the list :)

Thanks

Paul.







_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] VIPM and UV texturing

[Tom F. <to...@mu...>]

Er... with the usual type of VIPM, you don't generate texture coords, or
indeed any new vertices,  at all. All you do is throw one point away and
collapse the edge onto the other one.

There are variants where you generate some sort of new "average" midpoint,
but (a) the quality improvement isn't very large and (b) it is quite a bit
less efficient to render, because for a given LoD, you have vertices that
are used by lower LoDs, but not the current one, which causes problems.

A related question is how to calculate texture coords (and other attributes)
when creating subdiv surfaces. I just use linear - seems to work OK with my
data, but others prefer to use other methods, such as use the subdiv surface
method, but on the attributes data. This gives excellent results BUT it is
possibly covered by a sneaky Pixar patent. It's still unclear exactly what
this patent covers (as with all patents, it's extremely vague), but there
may be some prior art that we can hide behind :-) In any case, simpler
methods such as Loop subdivision is often perfectly acceptable for
attributes, since perfect C1/G1 is not actually needed in most cases.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Mark Wayland [mailto:mwa...@to...]
> Sent: 08 August 2000 00:58
> To: gda...@li...
> Subject: [Algorithms] VIPM and UV texturing
> 
> 
> Hey all,
> 
> For those of you who are using/experimenting with VIPM, how are you
> generating your texture coords when the mesh is reduced ?  Do 
> you all assume
> planar mapping or what ?
> Any info or discussion on this topic would be appreciated.
> 
> Thanks,
> 
> Mark

[Algorithms] ROAM

[Paul A. <fr...@fu...>]

Hi all,

I just checked out the image of the day on www.flipcode.com that showed a
landscape using the ROAM algorithm.  The landscape does look nice so I
decided I may move my arse and look into landscape rendering which I
promised myself I would do for some time now :-)

Just wondered if there are any pointers to good documentation about ROAM or
other such algorithms for LOD on landscapes...  I guess there are plenty but
any ones that stick out from the rest ?

(appolagies,  i am new to the list :)

Thanks

Paul.

RE: [Algorithms] Some N-Patch questions...

[Gil C. <g.c...@ca...>]

At 03:13 AM 8/7/00 -0500, you wrote:
>welcome to the world of subdivision.
>
>there was a zip file somewhere on the web.
>the name of the actual file was sig99notes.pdf
>there was a big presention done and they just wrapped all the "mini"
>presenations into one big file.

http://www.multires.caltech.edu/pubs/sig99notes.pdf

There's a *heap* of subdivision papers at the more general 
http://www.multires.caltech.edu/pubs page, including this year's SIGGRAPH 
notes...

Gil
---------------------------------------------------------------------
3D Graphics Programmer
CSIRO Minesite Imaging Group
Pinjarra Hills, QLD, AUSTRALIA
http://www.cat.csiro.au/automation/projects/SurMap.htm

"Experience is something you don't get until just after you need it"
---------------------------------------------------------------------

[Algorithms] VIPM and UV texturing

[Mark W. <mwa...@to...>]

Hey all,

For those of you who are using/experimenting with VIPM, how are you
generating your texture coords when the mesh is reduced ?  Do you all assume
planar mapping or what ?
Any info or discussion on this topic would be appreciated.

Thanks,

Mark

Re: [Algorithms] fast triangle-segment test *with precomputation*

[<SHA...@ao...>]

In a message dated 07/08/00 17:36:44 !!!First Boot!!!, 
al...@ex... writes:

<< A few questions about your 3rd test:
 - Are you testing line or line segment intersection?
 - Why do you need to use the diagonal?
 - Doesnt the test hold for any bbox edge as well.
 - Also why are you testing 8 lines?  Four parrallel
   bbox edges should be enough to cover any case where
   a corner 'punches through the triangle'
 
 Alex >>

This third test is done because of the possibility of a triangle location 
which has 

1) No vertices inside the box
2) No edges which intersect any box face

In this case I compute 4 ( you are right, I overestimated when I tried to 
visualise this! :) ) line segments and test if these intersect the face of 
the triangle.

Having just looked at your reply you are also right in that 4 parallel box 
edges would do exactly the same thing as 4 diagonal lines.

My bbox structure does not actually contain edges, only 2 3d points which are 
enough to describe a square cube so for me it is just a matter of choice 
whether to use parallel or diagonal edges/lines.

Regards,

John.

RE: [Algorithms] fast triangle-segment test *with precomputation*

[Alex P. <al...@Ex...>]

A few questions about your 3rd test:
- Are you testing line or line segment intersection?
- Why do you need to use the diagonal?
- Doesnt the test hold for any bbox edge as well.
- Also why are you testing 8 lines?  Four parrallel
  bbox edges should be enough to cover any case where
  a corner 'punches through the triangle'

Alex

-----Original Message-----
From: SHA...@ao... [mailto:SHA...@ao...]
Sent: Saturday, August 05, 2000 4:55 AM
To: gda...@li...
Subject: Re: [Algorithms] fast triangle-segment test *with
precomputation*


In a message dated 05/08/00 01:53:24 !!!First Boot!!!,=20
Chr...@Pl... writes:

<< That only works as a conservative test, but not as an exact test.
=20
 If the box, straddling the triangle plane, is just outside one of the
 vertices of the triangle, then both criteria are met, but there's no
 actual intersection. >>

I am currently doing a triangle/aabb test for an octree implimentation.
This=20
test is as near as exact as I can think of. It does 3 tests, each one
more=20
time consuming than the last...

1) Are any of the 3 tri vertices inside bbox...if so return true
2) Does any tri edge intersect bbox face...if so return true
3) Generate 8 lines, each one connects a corner of the aabb to it's
diagonal=20
opposite then test, does this line intersect tri face...if so return
true
return false.

The last test is in case any corner of the aabb punches through the face
of=20
the tri, in which case the tri is technically inside the aabb.

How do you do yours??

John.

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

[Algorithms] texture space

[Vladimir K. <vka...@si...>]

Hi All,

I know similar question was discussed here some time ago.
But I need a bit more info.

I want to put dot3 bumpmapping onto animated character.
To transform light vector into texture space I need to calculate
orthonormal basis for the tangent space for vertex.

How can I calculate tangent vector of this basis ?
How it depends on texture coordinates of face ?

I found not bad example for this at nvidia site - md2shader.
But I don't understand how it's done here.
In md2shader used only one tex coordinate for calculations.
I think it's wrong.

I know you say that it's school level question.
But may be somebody can point me good code example 
or explanation.

Thanks
vlad

RE: [Algorithms] Some N-Patch questions...

[Peter W. <Pet...@vi...>]

> 
> I use each of these midpoints as a new vertex to split the 
> original triangle
> into 4. To calculate the normals at each new vertex, I 
> interpolate halfway
> between the two adjacent original normals, eg
> MidNorm=Cos(45)*Norm0+Sin(45)*Norm1.

I know it's bad form to reply to your own post, but I want to correct the
normal interpolation method I gave above. The formula above only works when
the two normals are perpendicular, in general I think you'll actually need
to add the two normals, and then renormalise the resultant vector to get the
new normal,
eg MidNorm=(Norm0+Norm1) / (|Norm0+Norm1|)

As far as I can see, any desired method can be used to interpolate the
normals, as long as it's deterministic and continuous you'll get some
variety of smooth surface. I'd like to try applying some normal perturbation
stuff like bump-maps to the interpolation code, I think you'd get
interesting effects as the surface tried to match the perturbed normals.

Peter Warden

RE: [Algorithms] 3d Lines Intersection

[Graham S. R. <gr...@se...>]

There is a nice closed form solution for this determinant (since the matrix
is small). I worked it out a few years ago, and I *might* still have it
lying around somewhere. (It was sent to some newsgroup.)

I'll see if I can dig it up or redo it if anyone is interested and doesn't
want to take the time to do it themselves.

Graham

Eric Haines wrote,

> -----Original Message-----
> I looked it up on my 3D objects intersection page:
> http://www.realtimerendering.com/int/. I really need
> to find time to put down actual algorithms and code
> on this page (anyone want to give me a grant? ;^> ).
>
> Anyway, for two lines P1 _ V1*t and P2 + V2*s, where V1 and V2 are
> the direction vectors and P1 & P2 some points on the lines, the answer is:
>
>    s = Determinant{(P2-P1),V1,V1 X V2} / | V1 X V2 |^2
>
> If the lines are parallel, the denominator is 0. If the lines are skew
> (don't intersect), s and t represent the parameters of the points of
> closest approach - measure the distance between these two points and
> you'll know how far apart they are.

Eric

[Algorithms] re: vipm instancing

[Paul F. <pa...@ar...>]

> >I thought of maybe using some kind of linked triangle list with the extra
> >tris being paged in, stuck in a different chunk of ram then linked to the
> >last chunk. Bad fragmentation and cache trouble I fear, though...
>
> Why do you say that?  You could have a chunk of ram, say 2 MB, which you
> reserve for all your VIPM index lists.  Then you could write your own,
> simple memory manager for the VIPM index lists.  You actually wouldn't need
> linked lists, you could implement a "pushing" manager where you moved other
> lists around to make room for you to just grow your list linearly.

Wouldn't that be slow? If you have a mesh currently containing 50,000 tris
and you need to up it but havent the ram in the current location, you'd need
to move 50,000*3*2 (~300k) bytes of ram to some other location. Surely that
would ruin the cache etc?

How much allowance would you make in terms of padding each time you
allocated a new chunk of ram for the higher lod mesh?

Cheers, Paul.

RE: [Algorithms] Info about quadtree

[Odin J. <od...@it...>]

There's a OpenGL Quadtree engine for download on www.flipcode.com (Or was it
www.gamedev.net ?)


Med venlig hilsen/best regards :

Odin Jensen
R&D Programmer
ITE ApS, Denmark
Work : od...@it...
Home : od...@nu...

(The point of view presented here is solely my own
 and DOES NOT represent that of ITE ApS)


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of JB
Sent: 7. august 2000 09:06
To: gda...@li...
Subject: [Algorithms] Info about quadtree


Hi
I'm looking dor infos about quadtrees. It doesn't seem to be too complex,
but It would be fine if I could find some example...
Thx
Mandor

ma...@sd...
SDF Public Access UNIX System - http://sdf.lonestar.org



_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list