gdalgorithms-list

Re: [Algorithms] Up Vector in Projection Matrix

[Ron L. <ro...@do...>]

----- Original Message -----
From: "Kelmenson, Dan" <Dan...@br...>
To: <gda...@li...>
Sent: Wednesday, August 09, 2000 2:34 PM
Subject: RE: [Algorithms] Up Vector in Projection Matrix


> > -----Original Message-----
> > From: Pai-Hung Chen [mailto:pa...@ac...]
> >
> > >
> > > When you specify a point or direction to "look at",  you have only
> > specified
> > > two of the degrees of freedom of the system.  That object
> > could be in the
> > > middle of the screen - either upside-down - or right way up
> > - or at any
> > > 'roll' angle in between.
> > >
> > > The 'up' vector only has to be enough to resolve that issue
> > - and only one
> > > of its degrees of freedom is needed.  Hence, there are a
> > wide variety of
> > > vectors that will do the job.  The only constraint is that
> > the up vector
> > > and the 'look direction' are not parallel.
> > >
> > > Hence, so long as your character can't look absolutely
> > vertically upwards
> > > or absolutely vertically downwards, an 'up' vector of
> > (0,1,0) will do
> > fine.
> >
> > That explains everything (though I don't know why/how the
> > underlying math
> > works).  An ever-confusing question got explained!  Thanks a lot! :-)
> >
>
> The most likely reason the math worked (the reason the math worked in my
> program, and most likely in yours...) is that the main use of the 'up'
> vector is crossing it with the forward/view direction.  As long as your
> character/camera doesn't lean to the side, the true (0,1,0) up vector and
> the actual perpendicular-to-forward up vector will both be coplanar with
the
> forward vector, and therefore give you the same cross product.
>

Another way to think about it is that the "look-at" functions in the various
APIs and toolkits do not require that the up vector argument be
perpendicular to the look-at vector argument, but only that they be linearly
independent.  Then it's a fact that there is a unique unit up vector that IS
perpendicular to the look-at vector argument, in the plane determined by the
two vector arguments (why they must be linearly independent) and pointing,
in that plane, to the same side of the argument look-at vector as points the
argument up vector.  The API look-at routine computes that perpendicular up
vector from the argument vectors, either by iterated cross products or, more
likely, by the Gram-Schmidt formula, to use in constructing the correct view
matrix.

RE: [Algorithms] Up Vector in Projection Matrix

[Kelmenson, D. <Dan...@br...>]

> -----Original Message-----
> From: Pai-Hung Chen [mailto:pa...@ac...]
> 
> >
> > When you specify a point or direction to "look at",  you have only
> specified
> > two of the degrees of freedom of the system.  That object 
> could be in the
> > middle of the screen - either upside-down - or right way up 
> - or at any
> > 'roll' angle in between.
> >
> > The 'up' vector only has to be enough to resolve that issue 
> - and only one
> > of its degrees of freedom is needed.  Hence, there are a 
> wide variety of
> > vectors that will do the job.  The only constraint is that 
> the up vector
> > and the 'look direction' are not parallel.
> >
> > Hence, so long as your character can't look absolutely 
> vertically upwards
> > or absolutely vertically downwards, an 'up' vector of 
> (0,1,0) will do
> fine.
> 
> That explains everything (though I don't know why/how the 
> underlying math
> works).  An ever-confusing question got explained!  Thanks a lot! :-)
> 

The most likely reason the math worked (the reason the math worked in my
program, and most likely in yours...) is that the main use of the 'up'
vector is crossing it with the forward/view direction.  As long as your
character/camera doesn't lean to the side, the true (0,1,0) up vector and
the actual perpendicular-to-forward up vector will both be coplanar with the
forward vector, and therefore give you the same cross product. 

Dan Kelmenson
Mattel Interactive

Re: [Algorithms] View-Depend vs. View-Independent LOD

[Pai-Hung C. <pa...@ac...>]

In a HW T&L setting (GeForce), are VIPM/VDPM really worth the extra
management cost omposed on CPU?  Or a simple Quadtree/Octree paradigm will
suffice, in which I may well just send the un-LODed polys to the HW T&L
pipeline that is so fast at handling huge amount of polys that it still
beats the LOD optimization?

Thank you,

Pai-Hung Chen

Re: [Algorithms] Up Vector in Projection Matrix

[Pai-Hung C. <pa...@ac...>]

> I'm no D3D expert - but I'll presume this is similar to the OpenGL
'glLookAt'
> stuff.
>
> When you specify a point or direction to "look at",  you have only
specified
> two of the degrees of freedom of the system.  That object could be in the
> middle of the screen - either upside-down - or right way up - or at any
> 'roll' angle in between.
>
> The 'up' vector only has to be enough to resolve that issue - and only one
> of its degrees of freedom is needed.  Hence, there are a wide variety of
> vectors that will do the job.  The only constraint is that the up vector
> and the 'look direction' are not parallel.
>
> Hence, so long as your character can't look absolutely vertically upwards
> or absolutely vertically downwards, an 'up' vector of (0,1,0) will do
fine.

That explains everything (though I don't know why/how the underlying math
works).  An ever-confusing question got explained!  Thanks a lot! :-)

Pai-Hung Chen

Re: [Algorithms] View-Depend vs. View-Independent LOD

[Daniel R. <dan...@ho...>]

>From: "Pai-Hung Chen" <pa...@ac...>
>Reply-To: gda...@li...
>To: <gda...@li...>
>Subject: Re: [Algorithms] View-Depend vs. View-Independent LOD
>Date: Wed, 9 Aug 2000 13:26:06 -0700
>
>Hi,
>
> > VIPM is where your collapse order is fixed - the only thing the 
>observer's
> > position does is choose how many tris to expand/collapse to.
> > VDPM varies the order of collapse depending on where the view is, so 
>bits
> > further away from the camera get collapsed before bits near the camera -
> > stuff like that.
>
>Does this mean VIPM collapses polys *evenly* across the whole mesh so that
>polys get the same degree of collapse regardless of their distance to the
>viewpoint, while in VDPM farer polys are collapsed more heavily than nearer
>polys?

exactly, this is one of the typical behaviours

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Algorithms] View-Depend vs. View-Independent LOD

[Pai-Hung C. <pa...@ac...>]

Hi,

> VIPM is where your collapse order is fixed - the only thing the observer's
> position does is choose how many tris to expand/collapse to.
> VDPM varies the order of collapse depending on where the view is, so bits
> further away from the camera get collapsed before bits near the camera -
> stuff like that.

Does this mean VIPM collapses polys *evenly* across the whole mesh so that
polys get the same degree of collapse regardless of their distance to the
viewpoint, while in VDPM farer polys are collapsed more heavily than nearer
polys?

Thank you,

Pai-Hung Chen

Re: [Algorithms] Up Vector in Projection Matrix

[Stephen J B. <sj...@li...>]

On Wed, 9 Aug 2000, Pai-Hung Chen wrote:

> I am manipulating projection matrix in my D3D program so that the player can
> lift up/down his head to view the world.  I do modify the viewing-direction
> component of the projection matrix but always leave the "up-direction"
> component as (0, 1, 0).  I think this should not work theoretically (at
> least introduce some weird effect).  However, it DOES work even I don't
> modify the "up-direction" component (such that it is perpendicular to the
> "viewing-direction").

I'm no D3D expert - but I'll presume this is similar to the OpenGL 'glLookAt'
stuff.

When you specify a point or direction to "look at",  you have only specified
two of the degrees of freedom of the system.  That object could be in the
middle of the screen - either upside-down - or right way up - or at any
'roll' angle in between.

The 'up' vector only has to be enough to resolve that issue - and only one
of its degrees of freedom is needed.  Hence, there are a wide variety of
vectors that will do the job.  The only constraint is that the up vector
and the 'look direction' are not parallel.

Hence, so long as your character can't look absolutely vertically upwards
or absolutely vertically downwards, an 'up' vector of (0,1,0) will do fine.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

RE: [Algorithms] View-Depend vs. View-Independent LOD

[Daniel R. <dan...@ho...>]

(think about progressive mesh / mmr lod)
if you would crate a big landscape an choose its triangle
count via lod and change it completely it's View Independant

if you use a algorithm to calculate which landscpae
point should be colapsed you will do that mostly
via: far away => many collapses
     near => few collapes
and so this far/near is View Dependant

hope this helps, re...@ma...


>From: Tom Forsyth <to...@mu...>
>Reply-To: gda...@li...
>To: gda...@li...
>Subject: RE: [Algorithms] View-Depend vs. View-Independent LOD
>Date: Wed, 9 Aug 2000 20:05:51 +0100
>
>VIPM is where your collapse order is fixed - the only thing the observer's
>position does is choose how many tris to expand/collapse to.
>
>VDPM varies the order of collapse depending on where the view is, so bits
>further away from the camera get collapsed before bits near the camera -
>stuff like that.
>
>That's it.
>
>Tom Forsyth - Muckyfoot bloke.
>Whizzing and pasting and pooting through the day.
>
> > -----Original Message-----
> > From: Pai-Hung Chen [mailto:pa...@ac...]
> > Sent: 09 August 2000 19:57
> > To: gda...@li...
> > Subject: [Algorithms] View-Depend vs. View-Independent LOD
> >
> >
> > Hi,
> >
> > I've heard that there are two kinds of LOD: view-dependent and
> > view-independent.  Could somebody briefly explain what the essential
> > difference between the two?
> >
> > Thanks in advance,
> >
> > Pai-Hung Chen
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Algorithms] View-Depend vs. View-Independent LOD

[Stephen J B. <sj...@li...>]

On Wed, 9 Aug 2000, Pai-Hung Chen wrote:

> I've heard that there are two kinds of LOD: view-dependent and
> view-independent.  Could somebody briefly explain what the essential
> difference between the two?
 
* View-independent depends only on range to the object.

* View-dependent also depends on the orientation of the object
  with respect to the eye.

Hence, view-independent is generally easier to compute - but
can't reduce the polygon count quite so agressively as
view-dependent LOD can.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

[Algorithms] Texturing Terrain

[Pai-Hung C. <pa...@ac...>]

Hi,

I generate a huge, complicated terrain mesh from a heightmap.  How can I
generate a realistic texture bitmap and corresponding UV coords for the
mesh?  I was directed to search the archive with some subject titles.  But
the archive search seems not to work properly and I always get nothing in
return.  Could someone give some help on this?

Thanks in advance,

Pai-Hung Chen

[Algorithms] Up Vector in Projection Matrix

[Pai-Hung C. <pa...@ac...>]

Hi,

I am manipulating projection matrix in my D3D program so that the player can
lift up/down his head to view the world.  I do modify the viewing-direction
component of the projection matrix but always leave the "up-direction"
component as (0, 1, 0).  I think this should not work theoretically (at
least introduce some weird effect).  However, it DOES work even I don't
modify the "up-direction" component (such that it is perpendicular to the
"viewing-direction").  I do know different up-vector, when setup reasonably,
can have different effect with the same direction-vector.  But what if
up-vector is setup unreasonably (impossible to happen in the real world)?
Could someone give me some idea?

Thanks in advance,

Pai-Hung Chen

Re: [Algorithms] View-Depend vs. View-Independent LOD

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

----- Original Message -----
From: "Tom Forsyth" <to...@mu...>
To: <gda...@li...>
Sent: Wednesday, August 09, 2000 2:05 PM
Subject: RE: [Algorithms] View-Depend vs. View-Independent LOD

-- Tom F. described both PM's very well below. I am just adding a little.

> VIPM is where your collapse order is fixed - the only thing the observer's
> position does is choose how many tris to expand/collapse to.

-- VIPM generally has a higher degree of precomputability.

> VDPM varies the order of collapse depending on where the view is, so bits
> further away from the camera get collapsed before bits near the camera -
> stuff like that.

-- VDPM theoretically has fewer screenspace collapse artifact. It generally
has higher realtime computation costs.

-- For both PM's evaluate your PM marching costs versus your rasterization
costs. If marching costs you more than just rendering them, render them out.
:)

Re: [Algorithms] Image processing - FFT - Noise removing

[Kamil B. <no...@te...>]

Hello Lionel,

Wednesday, August 09, 2000, 3:48:29 PM, you wrote:

> Could anybody point me on a url, code source, algo for removing the noise of
> an image, with FFT ?

.. and I'm additionally looking URLs about DCT, DFT and some topics
from rendering: volumetric lightning and global illumintaion problem,
and special effects (eg. like fire/water rendering) and all related...
I'm looking for theory rather than sourcecodes, and rather advanced
things - I know basics of these things... 

Thx in advance.

-- 
Best regards,
 Kamil Burzynski

RE: [Algorithms] View-Depend vs. View-Independent LOD

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

VIPM is where your collapse order is fixed - the only thing the observer's
position does is choose how many tris to expand/collapse to.

VDPM varies the order of collapse depending on where the view is, so bits
further away from the camera get collapsed before bits near the camera -
stuff like that.

That's it.
 
Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Pai-Hung Chen [mailto:pa...@ac...]
> Sent: 09 August 2000 19:57
> To: gda...@li...
> Subject: [Algorithms] View-Depend vs. View-Independent LOD
> 
> 
> Hi,
> 
> I've heard that there are two kinds of LOD: view-dependent and
> view-independent.  Could somebody briefly explain what the essential
> difference between the two?
> 
> Thanks in advance,
> 
> Pai-Hung Chen

[Algorithms] View-Depend vs. View-Independent LOD

[Pai-Hung C. <pa...@ac...>]

Hi,

I've heard that there are two kinds of LOD: view-dependent and
view-independent.  Could somebody briefly explain what the essential
difference between the two?

Thanks in advance,

Pai-Hung Chen

Re: [Algorithms] VIPM and UV texturing

[Charles B. <cb...@cb...>]

Hi Jeff,

really, you should be including UV's and RGB's and Normals as 
part of the quadric error metric, so that this kind of thing
should be detected automagically, and should be put late in
the collapse list by the system.  I've found that if you
use a proper (eg. comprehensive and robust) error metric,
then almost zero artist intervention is necessary.  In fact,
I find that the system is generally much better at ordering
collapses than artists are.  Of course, there are exceptions,
which usually occur because of the fact that I'm not actually
looking in the texture bits; eg. changing the uv's slightly
in a region of the texture which is very high frequency
produces much more visual error than if you change the uv's in
a very low frequency region of the texture.  To handle this
correctly, you do need some sort of artist cue, as you propose.
I like Tom's method of reducing to a specific mesh.

At 10:06 AM 8/9/2000 -0700, you wrote:
>Now the problem as you would guess is you have the face with coordinates
like (1,0) -----  (0,0) ---- (1,0).  Obviously more granular then that.
There are no texture coordinate discontinuities so the algorithm says it is
ok.  The surface of the face is roughly flat so the internal vertex and
edges are good candidates for collapse.  However, you then get the nice
situation of  (1,0) ------ (1,0).  Doesn't look so hot.  I have the artists
tag reflected seam vertices as uncollapsable until very late in the order.>
--------------------------------------
Charles Bloom           www.cbloom.com

RE: [Algorithms] UV texturing and DOT3 (was:VIPM and UV texturing )

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

Curious - I never had any problem with it, and our artists mirror things all
over the place. I suspect we're using slightly different equations to find
our surface-local basis matrices. I'll have to check the code to see exactly
what equations I'm using, but I'm pretty sure I calculate the N, U and V
basis vectors independently of each other (for each, you just use vertex
positions and the factor you are interested in, so U is never used to
calculate V's vector and vice versa), which means that the whole
"handedness" thing just isn't an issue as far as texture coords. As long as
the triangle indices are ordered clockwise, it all just works.

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

> -----Original Message-----
> From: Sim Dietrich [mailto:SDi...@nv...]
> Sent: 09 August 2000 18:29
> To: 'gda...@li...'
> Subject: RE: [Algorithms] VIPM and UV texturing
> 
> 
> This mirroring is a huge problem when doing per-pixel 
> lighting with DOT3
> bump mapping, because texels don't have a facing.  In some 
> cases, you can
> detect backwards facing textures and just flip the local 
> coordinate system,
> but not in the case you mention below.
> 
> -----Original Message-----
> From: Jeff Lander [mailto:je...@di...]
> Sent: Wednesday, August 09, 2000 10:06 AM
> To: gda...@li...
> Subject: Re: [Algorithms] VIPM and UV texturing
> 
> 
> Hi all.  New to this discussion but I have recently had a 
> couple of projects
> where this issue has been very important.
> 
> The issue you bring up about texture coordinates and any sort 
> of mesh LOD
> system is critical.  That is why I insist that the LOD tools 
> allow artists
> to hand designate edges that will not collapse.  Any 
> algorithmic method you
> try and find will fail in certain cases.  The algorithms 
> handle texture
> projections like sphere and cylinder wraps pretty well but 
> arbitrary UV
> texturing is a real problem.
> 
> One particular problem I will share that comes up often is 
> when texturing
> characters.  My system automatically will preserve vertices that have
> texture coordinate discontinuities.  However, artists will 
> often model a
> character with only half of the texture (particularly in the 
> face) then just
> reflect the texture coords to save texture space.
> 
> Now the problem as you would guess is you have the face with 
> coordinates
> like (1,0) -----  (0,0) ---- (1,0).  Obviously more granular 
> then that.
> There are no texture coordinate discontinuities so the 
> algorithm says it is
> ok.  The surface of the face is roughly flat so the internal 
> vertex and
> edges are good candidates for collapse.  However, you then 
> get the nice
> situation of  (1,0) ------ (1,0).  Doesn't look so hot.  I 
> have the artists
> tag reflected seam vertices as uncollapsable until very late 
> in the order.
> 
> Let me paraphrase you by saying the algorithms are most efficient when
> working on trivially textured objects.  Anything else 
> requires good artist
> tools and some TLC.
> 
> -Jeff

RE: [Algorithms] VIPM and UV texturing

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

This is also solved if you start with a low-poly mesh from the artists,
tesselate and displace up to a high-poly mesh, then VIPM down again, but
preserving the original edges. Because the tesselation only uses linear
interpolation for non-geometry attributes, you don't have to deal with nasty
cases like this. Fortunately, coz they are a real pain.

http://www.muckyfoot.com/downloads/tom.shtml

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

> -----Original Message-----
> From: Jeff Lander [mailto:je...@di...]
> Sent: 09 August 2000 18:06
> To: gda...@li...
> Subject: Re: [Algorithms] VIPM and UV texturing
> 
> 
> Hi all.  New to this discussion but I have recently had a 
> couple of projects where this issue has been very important.
> 
> The issue you bring up about texture coordinates and any sort 
> of mesh LOD system is critical.  That is why I insist that 
> the LOD tools allow artists to hand designate edges that will 
> not collapse.  Any algorithmic method you try and find will 
> fail in certain cases.  The algorithms handle texture 
> projections like sphere and cylinder wraps pretty well but 
> arbitrary UV texturing is a real problem.
> 
> One particular problem I will share that comes up often is 
> when texturing characters.  My system automatically will 
> preserve vertices that have texture coordinate 
> discontinuities.  However, artists will often model a 
> character with only half of the texture (particularly in the 
> face) then just reflect the texture coords to save texture space.
> 
> Now the problem as you would guess is you have the face with 
> coordinates like (1,0) -----  (0,0) ---- (1,0).  Obviously 
> more granular then that. There are no texture coordinate 
> discontinuities so the algorithm says it is ok.  The surface 
> of the face is roughly flat so the internal vertex and edges 
> are good candidates for collapse.  However, you then get the 
> nice situation of  (1,0) ------ (1,0).  Doesn't look so hot.  
> I have the artists tag reflected seam vertices as 
> uncollapsable until very late in the order.
> 
> Let me paraphrase you by saying the algorithms are most 
> efficient when working on trivially textured objects.  
> Anything else requires good artist tools and some TLC.
> 
> -Jeff

RE: [Algorithms] VIPM and UV texturing

[Sim D. <SDi...@nv...>]

This mirroring is a huge problem when doing per-pixel lighting with DOT3
bump mapping, because texels don't have a facing.  In some cases, you can
detect backwards facing textures and just flip the local coordinate system,
but not in the case you mention below.

-----Original Message-----
From: Jeff Lander [mailto:je...@di...]
Sent: Wednesday, August 09, 2000 10:06 AM
To: gda...@li...
Subject: Re: [Algorithms] VIPM and UV texturing


Hi all.  New to this discussion but I have recently had a couple of projects
where this issue has been very important.

The issue you bring up about texture coordinates and any sort of mesh LOD
system is critical.  That is why I insist that the LOD tools allow artists
to hand designate edges that will not collapse.  Any algorithmic method you
try and find will fail in certain cases.  The algorithms handle texture
projections like sphere and cylinder wraps pretty well but arbitrary UV
texturing is a real problem.

One particular problem I will share that comes up often is when texturing
characters.  My system automatically will preserve vertices that have
texture coordinate discontinuities.  However, artists will often model a
character with only half of the texture (particularly in the face) then just
reflect the texture coords to save texture space.

Now the problem as you would guess is you have the face with coordinates
like (1,0) -----  (0,0) ---- (1,0).  Obviously more granular then that.
There are no texture coordinate discontinuities so the algorithm says it is
ok.  The surface of the face is roughly flat so the internal vertex and
edges are good candidates for collapse.  However, you then get the nice
situation of  (1,0) ------ (1,0).  Doesn't look so hot.  I have the artists
tag reflected seam vertices as uncollapsable until very late in the order.

Let me paraphrase you by saying the algorithms are most efficient when
working on trivially textured objects.  Anything else requires good artist
tools and some TLC.

-Jeff

At 06:44 PM 8/9/2000 +1000, you wrote:
> >     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 ?


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

Re: [Algorithms] VIPM and UV texturing

[Jeff L. <je...@di...>]

Hi all.  New to this discussion but I have recently had a couple of projects where this issue has been very important.

The issue you bring up about texture coordinates and any sort of mesh LOD system is critical.  That is why I insist that the LOD tools allow artists to hand designate edges that will not collapse.  Any algorithmic method you try and find will fail in certain cases.  The algorithms handle texture projections like sphere and cylinder wraps pretty well but arbitrary UV texturing is a real problem.

One particular problem I will share that comes up often is when texturing characters.  My system automatically will preserve vertices that have texture coordinate discontinuities.  However, artists will often model a character with only half of the texture (particularly in the face) then just reflect the texture coords to save texture space.

Now the problem as you would guess is you have the face with coordinates like (1,0) -----  (0,0) ---- (1,0).  Obviously more granular then that. There are no texture coordinate discontinuities so the algorithm says it is ok.  The surface of the face is roughly flat so the internal vertex and edges are good candidates for collapse.  However, you then get the nice situation of  (1,0) ------ (1,0).  Doesn't look so hot.  I have the artists tag reflected seam vertices as uncollapsable until very late in the order.

Let me paraphrase you by saying the algorithms are most efficient when working on trivially textured objects.  Anything else requires good artist tools and some TLC.

-Jeff

At 06:44 PM 8/9/2000 +1000, you wrote:
> >     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 ?

Re: [Algorithms] VIPM and UV texturing

[Jeff L. <je...@di...>]

Hi all.  New to this discussion but I have recently had a couple of projects where this issue has been very important.

The issue you bring up about texture coordinates and any sort of mesh LOD system is critical.  That is why I insist that the LOD tools allow artists to hand designate edges that will not collapse.  Any algorithmic method you try and find will fail in certain cases.  The algorithms handle texture projections like sphere and cylinder wraps pretty well but arbitrary UV texturing is a real problem.

One particular problem I will share that comes up often is when texturing characters.  My system automatically will preserve vertices that have texture coordinate discontinuities.  However, artists will often model a character with only half of the texture (particularly in the face) then just reflect the texture coords to save texture space.

Now the problem as you would guess is you have the face with coordinates like (1,0) -----  (0,0) ---- (1,0).  Obviously more granular then that. There are no texture coordinate discontinuities so the algorithm says it is ok.  The surface of the face is roughly flat so the internal vertex and edges are good candidates for collapse.  However, you then get the nice situation of  (1,0) ------ (1,0).  Doesn't look so hot.  I have the artists tag reflected seam vertices as uncollapsable until very late in the order.

Let me paraphrase you by saying the algorithms are most efficient when working on trivially textured objects.  Anything else requires good artist tools and some TLC.

-Jeff

At 06:44 PM 8/9/2000 +1000, you wrote:
> >     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 ?

Re: [Algorithms] VIPM and UV texturing

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

> >     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)

I agree actually :) A point is the geometry, and a vertex is the other
associated bits.
I was just saying that these meshes are not good candidates for VIPM.

>
> 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" ?

    You could probably do that - But it would be more work. I think it would
involve making the edge collapse storage more generic. An edge collapse
would have to move more than one vertice, and know in each collapsed
instance which vertice needs to replace it. This should work - But, it would
take more in implementation, and bloat the size a little. It may just be
easiest to force edges between non similarly textured primitives to remain
uncollapsed.

>
> 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 ?

Thats a fair assumption. Dead on the money in most cases - And even in the
cases they are not, they tend to force edges adjacent to two objects to stay
uncollapsed. (ie, the joint between a model with a seperate texture for
legs/torso).

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

Well, it was more just a coincidence. :)

>
> Thanks for the feedback,

Anytime :)

Conor Stokes

[Algorithms] Image processing - FFT - Noise removing

[Lionel F. <li...@mi...>]

Hello,

Could anybody point me on a url, code source, algo for removing the noise of
an image, with FFT ?

Thank you in advance !

Lionel.

Re: [Algorithms] VIPM and UV texturing

[Pierre T. <p.t...@wa...>]

> 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 ?

There are two obvious ways:
1) don't collapse edges along texture seams. (or even along "smoothing
groups seams"). This is the easiest solution, and it only implies a minimal
number of vertices for the minimal LOD - after which you can't collapse
anything anymore.
2) when you collapse a texture-seam edge, collapse the other edge as well.
By "other edge" I mean, of course, the counterpart edge in the opposite
triangle using another texture.

I don't know what is the "official" method, I don't play in the gamedev
field anymore. But I did both of them, and 1) is often well enough. 2) can
be very tedious to implement, it all depends on your data structures,
architecture, and how you deal with meshes made of multiple textures &
smoothing groups in the first place.

Pierre

RE: [Algorithms] VIPM and UV texturing

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

> From: Mark Wayland [mailto:mwa...@to...]
[snip]
> 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" ?

Ugh - no. Who would want to do that? :-)

Actually, yes. Edges where two textures meet (or indeed any discontinuous
data - colours, normals, etc) are what I call "feature" edges. The way I
deal with them is that you find all your feature eges, and then only allow
collapses _along_ edges and _onto_ edges. But I never allow collapses of a
vertex on a feature edge onto a another vertex that isn't on the same edge
(remember to disallow collapses of one feature vertex to another feature
vertex that _isn't_ on the same edge, e.g. between two parallel feature
edges).

But the fewer feature edges you have on your model, the better VIPM can cope
with it, and the better it collapses.

> 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 dunno about "trivially" - mapping textures onto humanoid models (and
indeed the not-so-humanoid - we have slugs, two-headed creatures and ones
with four arms in Startopia) can get quite tricky.

But yes, VIPM only works well when there are comparatively few feature
edges.

There are some schemes that try to perform collapses across feature edges.
One is Jan Svarovsky's (follow the GDC link from the ultra-minimalist
homepage: http://www.svarovsky.com/), which has a discussion of these
collapses. But they're not pretty, and they complicate the collapse process.
By far the best way to proceed is to use friendly persuasion and Pavlovian
conditioning (a big stick is handy for this) until the artists to create
models with few feature edges.

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