POV-Ray : Newsgroups : povray.general : ANNOUNCE: Subdivision Surface Suite! Server Time
11 Aug 2024 09:27:53 EDT (-0400)
  ANNOUNCE: Subdivision Surface Suite! (Message 6 to 15 of 15)  
<<< Previous 5 Messages Goto Initial 10 Messages
From: Ken
Subject: Re: ANNOUNCE: Subdivision Surface Suite!
Date: 29 Aug 1999 01:56:20
Message: <37C8CB4A.28812D1F@pacbell.net>
Lance Birch wrote:
> 
> Very true, it seems that open source (kinda) programming works best and gets
> the good features in quickly.  I guess Linux is a good example of that.
> 
> Luckily MAX comes with a lot of plug-ins (MeshSmooth as it's called, being
> one of them) that are for mesh manipulation, but also work on patches, NURBS
> (well not MeshSmooth because the meshes are handled internally in that
> case), etc etc.
> 
> A feature that someone might consider making a macro for is an FFD (Free
> Form Deformation) box.  The basic idea is that it builds an imaginary box of
> verticies around an object and then as you move the vecticies it deforms the
> object it's attached to.  What do you think, possible with POV-Ray?
> (judging on all the cool mesh warps I've seen it should be)

> --
> Lance.

Colefax has written a mesh deformation macro utility though I haven't explored
it's possibilities yet. Another tool worth looking at external to Pov is one
called Elasticity and has some powerful features once you go through the learning
curve of using the program.

Elasticity:
http://www.flash.net/~drsledge/manual/manual.htm

-- 
Ken Tyler

See my 850+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html


Post a reply to this message

From: Ken
Subject: Re: ANNOUNCE: Subdivision Surface Suite!
Date: 29 Aug 1999 02:44:57
Message: <37C8D6AF.6EF71D6A@pacbell.net>
John VanSickle wrote:
> 
> After much pondering, I have developed a suite of macros for working
> with triangle meshes.  One of these macros will take a mesh of triangles
> and calculate the smoothing normals required.  Another will perturb the
> vertices of the mesh, making it rougher-looking.
> 
> However, the macro of interest is the divider, which takes a rough mesh
> of large triangles and replaces it with a mesh of smaller triangles that
> give a more curved appearance.  This process can be repeated, yielding
> a fine mesh of triangles that simulate a large variety of curved
> surfaces.  Its primary purpose is to allow a user to create a smooth
> organic shape, containing many triangles, by defining a rougher mesh of
> far fewer triangles, and refining that in an automated way.
> 
> The Subdivision Surface Suite (SSS) can be found at:
> 
>   http://users.erols.com/vansickl/sss.htm
> 
> Regards,
> John
> --
> ICQ: 46085459

 One question John - Will your macros read in a file containing a triangle
mesh or is it currently resticted to meshes that are generated internaly
using functions for their creation ? If it is the latter would it be possible
to extend it's capabilities to indlude reading existing meshes ?

-- 
Ken Tyler

See my 850+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html


Post a reply to this message

From: John VanSickle
Subject: Re: ANNOUNCE: Subdivision Surface Suite!
Date: 29 Aug 1999 14:39:44
Message: <37C981AB.3DAE589F@erols.com>
Ken wrote:
> 
>  One question John - Will your macros read in a file containing a
> triangle mesh or is it currently resticted to meshes that are
> generated internaly using functions for their creation ? If it is the
> latter would it be possible to extend its capabilities to include
> reading existing meshes?

One of the issues I had to deal with is the inability of macro code to
erase and re-declare arrays that are passed to it as arguments.  The
array can be accessed, and its elements altered, but the dimensions, and
the size of each dimension, cannot be altered within the macro.

For instance, consider the following macro:

#macro ResizeArray(MyArray)
  #local Size=dimension_size(MyArray,1)
  #undef MyArray
  #declare MyArray=array[Size*2]
#end

An array that is passed to this macro will not be affected by the macro
whatsoever; what appears to happen is that POV-Ray forgets that MyArray
was an argument passed to the macro, and consequently a global array
with the name "MyArray" is created.  I haven't fully tested this out,
but one thing is for certain:  If you pass an array to a macro, that
macro cannot resize the array.

This is a problem because the divider code (which is the whole reason I
wrote the SSS to begin with) has to resize the arrays for each
iteration, for the simple reason that the number of triangles quadruples
with each execution of the division process.

For this reason, the SSS uses three globally-declared arrays, and the
names of these arrays must be Points, Edges, and Triangles; so if you
are going to use the SSS, you have to treat these labels as reserved
keywords, for all intents and purposes.

Another issue that has to be dealt with involves the vertices in the
mesh.  Consider the following mesh:

mesh {
  triangle { <1,0,0>,<1,2,0>,<1,1,2> }
  triangle { <1,1,0>,<1,2,0>,<2,2,0> }

...

}

These two triangles each have a corner at <1,2,0>.  Are the two
triangles supposed to be connected (ie, form a surface together), or
not?  In order to resolve this ambiguity, the code would have to know
what the user wanted, and in this case, there's not enough info to make
the call; the user needs to be more specific.

In order to get something subdivided, all you have to do is to define
two arrays:

  Points[PointCount] is an array of vectors representing the vertices of
the mesh.
  Triangles[TriangleCount][3] is an array of indices to the vertices of
the mesh.  Points[Triangle[n][0]] is the first vertex of triangle n,
Points[Triangle[n][1]] is the second vertex of triangle n, and
Points[Triangle[n][2]] is the third vertex of triangle n.

  In this way the ambiguity is resolved; if the point shared by two
triangles is meant to link them together, then both indices can refer to
the exact same member of Points[].  If they are supposed to go their
separate ways, then the indices should point to different elements,
which will have the same starting value.

  Now the subidivider needs a lot more info that I have specified here,
but there is a macro in the SSS that will generate this info, making it
unnecessary for the user to do so.

  So basically, your only real problem is to get the mesh data into the
two arrays Points[] and Triangles[][].  Anything that accomplishes that
will work just fine.

Regards,
John
-- 
ICQ: 46085459


Post a reply to this message

From: John VanSickle
Subject: Re: ANNOUNCE: Subdivision Surface Suite!
Date: 29 Aug 1999 14:58:14
Message: <37C98601.D023F6F4@erols.com>
Ken wrote:
> 
> Colefax has written a mesh deformation macro utility though I haven't
> explored it's possibilities yet. Another tool worth looking at
> external to Pov is one called Elasticity and has some powerful
> features once you go through the learning curve of using the program.

One extra feature that I've already added to the SSS is a RoughenMesh
macro.  It perturbs the vertices of the mesh, thereby roughening it.
Put together with the right starting object, it makes rocks that are
just as good as the one my rock making .inc file kicks out, although
since the rock amker is a specialized script, it goes much faster on
what it does.

I'm already considering a macro to bend objects using a spline; if any
of you have seen the characters in the VeggieTales videos, and the way
they wiggle as they dance, you have some idea what I'm talking about.

The SSS relies on having the vertices and triangles in a set of arrays,
where they can be manipulated.  Consequently, whole boatloads of macros
can be written to do all manner of cool and obscene things to the mesh.
I'm sure that Chris' mesh stuff can easily be adapted to what I've got
in the SSS (and vice versa).

When the POV-Team gets around to adding UV support to POV, I will add
it to the SSS.  It will be a very simple addition to the code.

The RAM's the limit!

-- 
ICQ: 46085459


Post a reply to this message

From: Nieminen Juha
Subject: Re: ANNOUNCE: Subdivision Surface Suite!
Date: 30 Aug 1999 03:12:12
Message: <37ca2ecc@news.povray.org>
Couldn't these macros be used with the PCM format?
  You could convert an ordinary mesh to PCM format with the triangle
compressor program, then read it to arrays with Colefax's PCM macro and
then use these macros.
  Have you considered asking Colefax if you two could work together in
a "superset" of mesh handling macros?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/


Post a reply to this message

From: Ken
Subject: Re: ANNOUNCE: Subdivision Surface Suite!
Date: 30 Aug 1999 03:30:26
Message: <37CA32D8.4AA8320C@pacbell.net>
Nieminen Juha wrote:
> 
>   Couldn't these macros be used with the PCM format?
>   You could convert an ordinary mesh to PCM format with the triangle
> compressor program, then read it to arrays with Colefax's PCM macro and
> then use these macros.
>   Have you considered asking Colefax if you two could work together in
> a "superset" of mesh handling macros?

  I had similar thoughts when I read John's reply. It would be highly
advantagous if you could use his tools with existing mesh files instead
of only those you can generate yourself. For example many low polygon
count models are available for free on the net but are of poor quality
because of the low polygon count. The perfect solution of course if
subdivision of the existing triangles to help smooth curves and moderate
the number of seemingly flat faces. Sounds like a good suggestion to me.

-- 
Ken Tyler

See my 850+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html


Post a reply to this message

From: Cliff Bowman
Subject: Re: ANNOUNCE: Subdivision Surface Suite!
Date: 31 Aug 1999 13:17:30
Message: <37cacad7.92213858@news.povray.org>
On Sat, 28 Aug 1999 17:08:52 -0400, John VanSickle
<van### [at] erolscom> wrote:

>After much pondering, I have developed a suite of macros for working
>with triangle meshes.  One of these macros will take a mesh of triangles
>and calculate the smoothing normals required.  Another will perturb the
>vertices of the mesh, making it rougher-looking.
>
>However, the macro of interest is the divider, which takes a rough mesh
>of large triangles and replaces it with a mesh of smaller triangles that
>give a more curved appearance.  This process can be repeated, yielding
>a fine mesh of triangles that simulate a large variety of curved
>surfaces.  Its primary purpose is to allow a user to create a smooth
>organic shape, containing many triangles, by defining a rougher mesh of
>far fewer triangles, and refining that in an automated way.
>
>The Subdivision Surface Suite (SSS) can be found at:
>
>  http://users.erols.com/vansickl/sss.htm
>
This looks MOST useful.

I'll take a look at it as soon as poss :)


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/


Post a reply to this message

From: Chris Colefax
Subject: Re: ANNOUNCE: Subdivision Surface Suite!
Date: 31 Aug 1999 19:23:13
Message: <37cc63e1@news.povray.org>
Nieminen Juha wrote:
>   Couldn't these macros be used with the PCM format?
>   You could convert an ordinary mesh to PCM format with the triangle
> compressor program, then read it to arrays with Colefax's PCM macro and
> then use these macros.
>   Have you considered asking Colefax if you two could work together in
> a "superset" of mesh handling macros?

and Ken <tyl### [at] pacbellnet> replied:
>   I had similar thoughts when I read John's reply. It would be highly
> advantagous if you could use his tools with existing mesh files instead
> of only those you can generate yourself. For example many low polygon
> count models are available for free on the net but are of poor quality
> because of the low polygon count. The perfect solution of course if
> subdivision of the existing triangles to help smooth curves and moderate
> the number of seemingly flat faces. Sounds like a good suggestion to me.

For what it's worth, I can only add my support to such an idea: indeed, Warp
(Juha/Mika/whatever?!) and I had planned the PCM format to be expandable (as
the addition of bicubic patches shows).  Subdivision surfaces really
shouldn't be too difficult to implement with the PCM format (haven't we
heard that one before!), and although I haven't tried John's file as yet I
am, of course, happy to look into it....


Post a reply to this message

From: John VanSickle
Subject: Re: ANNOUNCE: Subdivision Surface Suite!
Date: 31 Aug 1999 22:07:43
Message: <37CC8DB0.7BE1D4DB@erols.com>
Chris Colefax wrote:
> 
> For what it's worth, I can only add my support to such an idea:
> indeed, Warp (Juha/Mika/whatever?!) and I had planned the PCM format
> to be expandable (as the addition of bicubic patches shows).
> Subdivision surfaces really shouldn't be too difficult to implement
> with the PCM format (haven't we heard that one before!), and although
> I haven't tried John's file as yet I am, of course, happy to look into
> it....

The Subdivision Surface Suite uses triangles meshes to generate finer
triangles meshes, and consequently the type one PCM file works just
fine.  I've written a macro to read the PCM type one files into the
arrays that the SSS uses, and the results can be seen in a post on
povray.binaries.images.  I had the SSS read in the torus from torus.pcm,
and do two subdivisions on it; the original torus, the once-divided
torus, and the twice-divided torus, are all depicted, in both flat and
smoothed forms.

The PCM format seems to have been written from a different approach than
what I took when designing the SSS.  Specifically, the SSS was designed
with expectation that the smoothing normals would need to be
re-calculated after each subdivision; hence, it doesn't even bother to
maintain the data internally, but generates it when needed
(specifically, when the mesh object is declared).  For this reason, my
PCM reader ignores the normal data in the file and tosses all of the
triangles into one mesh; after the subdivider has a go at the mesh, the
normal data all has to be re-calculated anyway.  This has a side benefit
that a lot of people have asked for:  The SSS can read in a mesh without
normals, and generate them.

I have written a macro to write the SSS mesh as a PCM1 file with flat
triangles, and when I get some breathing room I'll write another macro
to generate smooth triangle data in the PCM1 format.

I'm also planning the ability to add basic geometric shapes to the mesh,
such as the tetrahedron, octahedron, and icosahedron (all made of
triangles), and also allow the user to add Bezier patches of the first
through the fourth degree (even allowing the u-splines and v-splines to
be of differing degrees in the same patch); however, they would be
converted to triangle meshes, and not be carried internally as Bezier
patches.

There still remains the issue of individually-texturing the triangles.
I'm also planning to add UV support when it becomes part of the official
POV-Ray release.

Regards,
John
-- 
ICQ: 46085459


Post a reply to this message

From: Cliff Bowman
Subject: Re: ANNOUNCE: Subdivision Surface Suite!
Date: 3 Sep 1999 17:10:52
Message: <37cef605.32231554@news.povray.org>
On Tue, 31 Aug 1999 22:21:36 -0400, John VanSickle
<van### [at] erolscom> wrote:

[snip]
>
>There still remains the issue of individually-texturing the triangles.
>I'm also planning to add UV support when it becomes part of the official
>POV-Ray release.
>
Have we been given any indication of how different the UV syntax is
likely to be in the official version?

Anyone?


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/


Post a reply to this message

<<< Previous 5 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.