Xiaobin Wu wrote:
> During one of my research projects, I needed to quickly create the
> ray-tracing images of subdivision surfaces. What I did is to subdivide
> the object offline and import the subdivided surface into Pov-Ray,
> which of course led to huge pov-ray files.
> 
> I found it extremely convenient to have the mesh2 object directly support
> the subdivision algorithms. So I and another student (Jianhua Fan) spent
> some
> time to expand the mesh2 object so that it can be directly used to
> generate smooth subdivision surfaces.
> 
> The new syntax would be:
>    mesh2 {
>         subdivision {
>              substeps n              // n= steps of subdivision
>              flatshading              // optional flag to set flat shading
>         }
> 
>        vertex_list ...
>        ...
>    }
> 
> Anyway, the examples and new executable can be downloaded from
> 
>   http://www.cise.ufl.edu/~xwu/Pov-Sub

The source would be important to evaluate your patch.  Concerning the 
syntax - 'flatshading' is a bad choice for the keyword - a simple 
'smooth' would be more descriptive and already exists from heightfields.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

in news:40a14e8c@news.povray.org Xiaobin Wu wrote:

> Comments and suggestions are welcome.
> 

Interesting!

An option to write the resulting file would be nice.



Ingo

Post a reply to this message

Xiaobin Wu wrote:
> First of all, thanks to all that responded or tested my patch.
> 
> I have posted the modified source. There are five files modified:
> tokenize.cpp, mesh.h, mesh.cpp, parse.h, parse.cpp
> ( I want to thank Andrew for testing it under Linux. )
> Also I wish the code is only used in Pov-Ray community. 

Thanks for the code, a first glance at the code revealed the following 
things:

- you seem to discard any normal vectors specified for the mesh - this 
might often not be what the user wants and more important using the 
normal vectors could save you quite some computations (i.e. determining 
the neighbouring triangles).

- i can't find a reason why it should only work for mesh2 and not mesh.

Please use the follow-up i set for this posting, the news-submissions 
group is not for discussion.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:c7v675$29l$1@chho.imagico.de...
>
> - you seem to discard any normal vectors specified for the mesh - this
> might often not be what the user wants and more important using the
> normal vectors could save you quite some computations (i.e. determining
> the neighbouring triangles).

I was pondering about the usual scenarios that users specify the normals
and apply the subdivision. Do they want part smooth/part flat shading,
or normal effect (bump mapping, etc) or maybe even crease controls?

Before I can get a sense of practical demand, I decided not to use the
supplied normal for anything. But this is really open for options. After
I see more examples that requires normal control, I would love to implement
that in.

About the computations, determining the neighboring triangles is needed
for subdivision. So it is a must anyways.

> - i can't find a reason why it should only work for mesh2 and not mesh.
>

There is really no reason that it would not work with mesh. But often
enough, mesh objects are built without precisely matching vertices. The
subdivision will result in surfaces with gaps (remember shrinking
boundaries).
take a look at the examples chesmsh.pov (knight object is subdivided)
http://www.cise.ufl.edu/~xwu/Pov-Sub/pics/chesmsh.jpg
With that said, I might still add the support for mesh in in the next
update.

Best wishes to all,
Xiaobin

Post a reply to this message

This is a repost from yesterday on news-submission. The newest versions is
0.01b.
http://www.cise.ufl.edu/~xwu/Pov-Sub

>
> Here are a few things that I have fixed/changed according to the feedback:
>
> 1.  Fixed a problem that leads to slower rendering of un-subdivided
meshes.
>     (Thanks, Mika)
>
>
> 2.  The syntax to switch on flat shading is changed to "smooth off" from
>    "flatshading". Christoph is right, and I do like "smooth" better. But I
want the
>     default to be smooth shaded, so you will need to add an "off" to
switch on flat shading.
>
> 3.  Removed the restriction on the maximum valence of the vertices.
(Thanks
>     Kristof).
>
> > Jms wrote:
> > I did a test under win98/win2000pro and the return is always:
> > "out of memory : cannot allocate - 304 bytes for triangle mesh data".
> > For just two triangles without anything else nor texture, nor normal
> > indices.
>
> 4.   This problem is a little bit more complex. When you subdivide an
object
>      with open boundary, the behavior of the faces on the boundary is not
>      well-defined.The strategy that I used is to simply discard those new
boundary faces.
>
>     What happened to the two triangle cases is that there is no more faces
>     left after 1-step subdivision.
>
>     I fixed the memory allocation error and spit out a warning instead
when
>     the similar case happens.
>     The object will disappear naturally.
>
>     Eventually one would like to have other strategies on the boundary.
But
>     that is  currently on the Wish List.  For more information about this
issue,
>    please refer to papers such as:
>
>       *Towards Hardware Implemention of Loop Subdivision*
>       by S. Bischoff, L. Kobbelt and H-P. Seidel.
>      in Proceedings of the 2000 SIGGRAPH/EUROGRAPHICS  Workshop on
Graphics
>      Hardware
>

Post a reply to this message

Xiaobin Wu wrote:
> 
>>- you seem to discard any normal vectors specified for the mesh - this
>>might often not be what the user wants and more important using the
>>normal vectors could save you quite some computations (i.e. determining
>>the neighbouring triangles).
> 
> 
> I was pondering about the usual scenarios that users specify the normals
> and apply the subdivision. Do they want part smooth/part flat shading,
> or normal effect (bump mapping, etc) or maybe even crease controls?

In POV-Ray the way to get interpolated normal vectors (or 'smooth 
shading' if you want so) is to specify the normals,  This offers more 
control than simply specifying if an edge is sharp or smooth.  If there 
is a mesh with some smooth triangles and some not the most convenient 
approach would be to only subdivide the smooth ones (which of course 
requires special handling of edges between smooth and flat triangles).

> Before I can get a sense of practical demand, I decided not to use the
> supplied normal for anything. But this is really open for options. After
> I see more examples that requires normal control, I would love to implement
> that in.
> 
> About the computations, determining the neighboring triangles is needed
> for subdivision. So it is a must anyways.

That depends on the method used.  Most methods for doing on-the-fly 
subdivision (which is an interesting feature for a raytracer BTW) do not 
use the neighbouring triangles.

>>- i can't find a reason why it should only work for mesh2 and not mesh.
> 
> There is really no reason that it would not work with mesh. But often
> enough, mesh objects are built without precisely matching vertices. The
> subdivision will result in surfaces with gaps (remember shrinking
> boundaries).

You will need an adjustable threshold to determine if two vectors are 
considered identical or not.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph,

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:c80akk$ovb$1@chho.imagico.de...
> >
> > About the computations, determining the neighboring triangles is needed
> > for subdivision. So it is a must anyways.
>
> That depends on the method used.  Most methods for doing on-the-fly
> subdivision (which is an interesting feature for a raytracer BTW) do not
> use the neighbouring triangles.

I wish you could give a link or reference on this. For all that I know, you
need to have neighboring faces to apply subdivision mask.  Only on the
regular parts, there is a closed Bezier representation. But to compute the
Bezier coeffcients, you will need one-ring neighbor of triangles.

Xiaobin
http://www.cise.ufl.edu/~xwu/Pov-Sub

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> In POV-Ray the way to get interpolated normal vectors (or 'smooth 
> shading' if you want so) is to specify the normals,  This offers more 
> control than simply specifying if an edge is sharp or smooth.  If there 
> is a mesh with some smooth triangles and some not the most convenient 
> approach would be to only subdivide the smooth ones (which of course 
> requires special handling of edges between smooth and flat triangles).

  Note also that two smooth triangles might not share the same normal
vectors in their shared vertices. That is, the triangles are smooth, but
their common edge has a sharp change in lighting (which is often a useful
feature).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Christoph Hormann wrote:
> 
> Xiaobin Wu wrote:
> > First of all, thanks to all that responded or tested my patch.
> >
> > I have posted the modified source. There are five files modified:
> > tokenize.cpp, mesh.h, mesh.cpp, parse.h, parse.cpp
> > ( I want to thank Andrew for testing it under Linux. )
> > Also I wish the code is only used in Pov-Ray community.
> 
> Thanks for the code, a first glance at the code revealed the following
> things:
> 
> - you seem to discard any normal vectors specified for the mesh - this
> might often not be what the user wants and more important using the
> normal vectors could save you quite some computations (i.e. determining
> the neighbouring triangles).

And determining if the edge between two triangles is sharp or smooth,
which is very important for subdivision surfaces.

> - i can't find a reason why it should only work for mesh2 and not mesh.

Mesh2 allows you to explicitly specify that two triangles share their
corner vertices (instead of having different vertices that happen to be
identical).

Regards,
John

Post a reply to this message

>> 
>> About the computations, determining the neighboring triangles is needed
>> for subdivision. So it is a must anyways.
> 
> That depends on the method used.  Most methods for doing on-the-fly 
> subdivision (which is an interesting feature for a raytracer BTW) do not 
> use the neighbouring triangles.
> 

I've implemented this in my own raytracer, the neighbouring triangles are
required to satisfy boundary conditions for subdivision, unless these
conditions are specified manually (which is rather awkward).  The
implementation really is quite interesting, if you are interested check
out the paper:
http://www.seanet.com/~myandper/abstract/eg03.htm

Andrew

Post a reply to this message