Ken <tyl### [at] pacbellnet> writes:
> 
> No one is arguing that POV-Ray should tesselate every object by default.
> In fact I know I would never suggest such a thing. But there are certain
> features that could be added if POV-Ray could be set to tesselate objects.
> 
> Some features that would benefit from this would be -
> 
> 1. The ability to export .pov objects and scenes to other 3D file formats

As someone else already pointed out: POV-Ray is a renderer, so it's not
its task to export scenes. (To make it easier to write a parser for
modellers and converters I suggest using something like ANTLR for
POV-Ray 4.0.)

> 3. Displacement mapping - more accurate surface representations than are
>    currently possible with surface normal alone.

You think of something like 
http://www.fmi.uni-konstanz.de/~willhalm/bilder/displace.jpg ?
(This file has been generated with megapov.)

> 2. Surface subdivision - currently only possible with meshes and only
>    can be done through use of memory and process intensive operations.

Here I must confess that I don't know what this is in this context.
Or are you talking about mesh refinement for finite element methods?

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

On 07 Mar 2000 16:31:30 +0100, Thomas Willhalm wrote:
>> 2. Surface subdivision - currently only possible with meshes and only
>>    can be done through use of memory and process intensive operations.
>
>Here I must confess that I don't know what this is in this context.
>Or are you talking about mesh refinement for finite element methods?

See this site for a hopelessly technical explanation:

http://daisy.uwaterloo.ca/~hqle/subdivision/

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

ron### [at] povrayorg (Ron Parker) writes:

> On 07 Mar 2000 16:31:30 +0100, Thomas Willhalm wrote:
> >> 2. Surface subdivision - currently only possible with meshes and only
> >>    can be done through use of memory and process intensive operations.
> >
> >Here I must confess that I don't know what this is in this context.
> >Or are you talking about mesh refinement for finite element methods?
> 
> See this site for a hopelessly technical explanation:
> 
> http://daisy.uwaterloo.ca/~hqle/subdivision/

So, you (or Ken) are suggesting to extend this approach to other
surfaces like CSG objects?

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

Thomas Willhalm wrote:
> 
> ron### [at] povrayorg (Ron Parker) writes:
> 
> > On 07 Mar 2000 16:31:30 +0100, Thomas Willhalm wrote:
> > >> 2. Surface subdivision - currently only possible with meshes and only
> > >>    can be done through use of memory and process intensive operations.
> > >
> > >Here I must confess that I don't know what this is in this context.
> > >Or are you talking about mesh refinement for finite element methods?
> >
> > See this site for a hopelessly technical explanation:
> >
> > http://daisy.uwaterloo.ca/~hqle/subdivision/
> 
> So, you (or Ken) are suggesting to extend this approach to other
> surfaces like CSG objects?
> 
> Thomas

  Not being a programmer I can only suggest that it might be useful in
csg operations - if the program had the ability to internally tessellate
primitives. And yes I do see that this would be a definite plus for
the program. The ability to export to other 3d formats would be a side
benefit from this and not the major reason for implementing it.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
:   Not being a programmer I can only suggest that it might be useful in
: csg operations - if the program had the ability to internally tessellate
: primitives.

  Sorry, I didn't understand one thing:

  If we already have mathematically perfect objects, what's the point in
tesselating it and then calculating subdivisions? AFAIK subdivision is done
to approximate better the object the mesh is trying to represent, but we
already have the mathematically perfect model. So what's the point?
  And besides, couldn't it be done just by tesselating it with more accuracy?

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

Nieminen Juha wrote:
> 
> Ken <tyl### [at] pacbellnet> wrote:
> :   Not being a programmer I can only suggest that it might be useful in
> : csg operations - if the program had the ability to internally tessellate
> : primitives.
> 
>   Sorry, I didn't understand one thing:
> 
>   If we already have mathematically perfect objects, what's the point in
> tesselating it and then calculating subdivisions? AFAIK subdivision is done
> to approximate better the object the mesh is trying to represent, but we
> already have the mathematically perfect model. So what's the point?
>   And besides, couldn't it be done just by tesselating it with more accuracy?


  First I am really talking about adding two major processes here. The
first is the ability to internaly tessellate Pov primitives. The second
would be the addition of subdivision surfaces. The two together are a
powerful combination when applied in the correct circumstances.

  The point is that primitives are too perfect in some cases. Ever try
to make a realistic looking rock from a sphere primitive by applying a
normal to it ?

 I also think (and may be wrong) that with subdivision surfaces you can
create smooth curves between intersecting objects that would normally in
POV-Ray result only in perfect right angles. An example would be where
you had a cross shaped object. In Pov you would use two scaled boxes in
a union to create the cross. With subdivision you could also create a
radius where the intersecting surfaces meet. It is of course possible
to do this in Pov now but it requires several more csg operations to
get there.

There was a good example of this posted by Van Sickle when demonstrating
his Subdivision Surface Suite. He showed a crossing of two cylinders
before and after subdivision. In the final image the two cylinders
looked like they had been smoothly welded together with nice radiuses
in the corners.

Smoothing triangles with normals is not nearly as accurate or desirable
as have the ability to further tessellate an object mechanically. Another
benefit of adding subdivision surfaces.

And again I will point out that I am not saying primitives should be
replaced or that tessellating should be a default procedure. I would
like to see it as an optional process that could be turned on by the
user with a specific control function applied.

Also visit the site that Ron linked to. It is a good read.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: And again I will point out that I am not saying primitives should be
: replaced or that tessellating should be a default procedure. I would
: like to see it as an optional process that could be turned on by the
: user with a specific control function applied.

  I agree. Usually when you say "tesselating of primitives would be a good
feature" what people actually read is: "let's remove all the current
primitives and replace them with equivalent tesselated meshes".

  This happens everywhere. If I say "the command line is much more powerful
than a GUI" what most people read is: "I never use a GUI and I hate GUI's and
they should be removed from every OS and is completely impossible to use
both, the GUI and the command line, at the same time" :)

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

Ken <tyl### [at] pacbellnet> writes:
> 
>   First I am really talking about adding two major processes here. The
> first is the ability to internaly tessellate Pov primitives. The second
> would be the addition of subdivision surfaces. 

I agree (at least) on the second. We should also add NURBS support.
Both would make it easier for modellers to export to POV-Ray.

>   The point is that primitives are too perfect in some cases. Ever try
> to make a realistic looking rock from a sphere primitive by applying a
> normal to it ?
> 
>  I also think (and may be wrong) that with subdivision surfaces you can
> create smooth curves between intersecting objects that would normally in
> POV-Ray result only in perfect right angles.

I had completely understood your motivation (and I share it). Displacements
and smoothing are important tasks for the generation of high quality
images.

However, I think we should try another approach in POV-Ray than triangulate
the objects. I really like the fact that POV-Ray has a variety of objects
like spheres, boxes, cylinders, planes, etc. That's why I don't like
the idea of converting them into triangles, even if it only the case for
some objects. Particularly, I don't like this idea, because we have an
alternative which fits better in the philosophy of POV-Ray IMO:
isosurfaces. For me, they are something like an extension of blobs and 
polynomial objects.

Why should we choose to use isosurfaces when the rest of the world likes
triangles? First, we already have them in the megapatch and will have 
them in POV-Ray 3.5 (as far as I know). Second, at least displacement maps
are possible with them. You didn't comment on my picture
(http://www.fmi.uni-konstanz.de/~willhalm/bilder/displace.jpg), but I
think that it is not too far away from the image at
http://graphics.stanford.EDU/papers/displace/
(I even consider my picture as a proof of concept.)
I'm almost sure, that smooth conjunctions are possible as well. The
recent images in p.b.i with blobs suggest this.

So, what we need is a mechanism to automagically convert CSG objects
to isosurfaces inside POV-Ray.

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

In article <qqm### [at] ramsenfmiuni-konstanzde>, Thomas 
Willhalm <tho### [at] willhalmde> wrote:

> I agree (at least) on the second. We should also add NURBS support.
> Both would make it easier for modellers to export to POV-Ray.

At the very least, adding subdivision capabilities to the mesh object 
would be useful. You could just export the NURBS object to a medium 
resolution mesh, and use adaptive subdivision to get rid of the 
faceting. Adding NURBS support isn't a bad idea, just not as useful.


> However, I think we should try another approach in POV-Ray than 
> triangulate the objects. I really like the fact that POV-Ray has a 
> variety of objects like spheres, boxes, cylinders, planes, etc. 
> That's why I don't like the idea of converting them into triangles, 
> even if it only the case for some objects. Particularly, I don't like 
> this idea, because we have an alternative which fits better in the 
> philosophy of POV-Ray IMO: isosurfaces. For me, they are something 
> like an extension of blobs and polynomial objects.
> 
> Why should we choose to use isosurfaces when the rest of the world 
> likes triangles? First, we already have them in the megapatch and 
> will have them in POV-Ray 3.5 (as far as I know). Second, at least 
> displacement maps are possible with them. You didn't comment on my 
> picture 
> (http://www.fmi.uni-konstanz.de/~willhalm/bilder/displace.jpg), but I 
> think that it is not too far away from the image at 
> http://graphics.stanford.EDU/papers/displace/ (I even consider my 
> picture as a proof of concept.) I'm almost sure, that smooth 
> conjunctions are possible as well. The recent images in p.b.i with 
> blobs suggest this.

Isosurfaces can be slow, they are one of the objects that would benefit 
the most from tesselating. Even if the tesselated version was just used 
to bound the "conventional" version.


> So, what we need is a mechanism to automagically convert CSG objects
> to isosurfaces inside POV-Ray.

An interesting idea, but isosurfaces are already capable of CSG...and 
making sharp edges smooth would still be quite difficult. This is 
possible with isoblobs, though you still have to come up with the 
density equations, and it only does union-like things.
How would you do CSG on the isosurfaces to end up with rounded edges? 
They are basically density fields...if you defined a desity field for 
every shape, how would you manipulate them to simulate difference, 
intersection, and merge(union would be impossible this way), and still 
retain accuracy and something close to the current CSG syntax?

What I am thinking of is a separate set of commands for operating on 
meshes, and maybe including a "make_mesh()" function that takes an 
object and some parameters and returns a mesh. Things like:

// These operate differently from ordinary CSG, they only use meshes.
// Maybe they should be functions, I'm not sure...
merge_meshes {}
union_meshes {}
difference_meshes {}
intersect_meshes {}

// If used on an object which can't be reduced to a mesh, like
// an infinite plane, these either make a close approximation
// or return an empty mesh(and make a warning).
make_mesh(OBJECT, PARAMETERS)         // returns a mesh
  // make_mesh() is more consistant with the others, maybe tesselate()?
subdivide_mesh(MESH, PARAMETERS)      // returns a mesh
smooth_mesh(MESH, PARAMETERS)         // returns a mesh
displace_mesh(MESH, WARP, PARAMETERS) // returns a mesh
  // Uses a warp to displace the mesh. Displacements should also work
  // on pigments, textures, etc.
  // Maybe add a new warp type that uses 3 (x,y,z) functions.

There would also be parameters for the mesh object itself to adjust 
render-time subdivision, like bezier patches do.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message