great idea!

Christoph Hormann wrote:
> 
> I just finished the first version of an include file for generating wood as
> isosurfaces.
> 
> Right now it only generates wooden planks and cylinders.  I also thought about
> profile planks, but i did not yet have any success.  Anyone who managed using
> object pattern for isosurfaces ? It's quite difficult and not very flexible
> doing them with mere mathematics...
> 
> The files and description is available here:
> 
> http://www.schunter.etc.tu-bs.de/~chris/iso_wood.html
> 
> A sample picture is in p.b.i.
> 
> Have fun, comments and suggestions for improvements are welcome.
> 
> Christoph
> 
> --
> Christoph Hormann <chr### [at] gmxde>
> Homepage: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Realistic wood in POV? You must be kidding! Sounds like a great util!
Perhaps, rather than having it generate the object, make a macro that defines a
wood function and pigment so the user can incorporate it into their own isourface
of whatever shape they want.

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

In article <39A16E72.BEA2DC81@schunter.etc.tu-bs.de>, 
chr### [at] gmxde wrote:

> I mean planks with more complicated shapes that can be put together 
> to plate a wall.  For example this shape:
...snip...

Ah, I see what you mean.


> I understand the problem, proximity pattern would probably be quite slow. 

Proximity currently is *very* slow for isosurfaces. I might be able to 
make a modification which allows separate proximity functions for 
specific shapes, though, so simple shapes like box, cone, sphere, etc. 
could be much faster. CSG's, text objects, and meshes will still use the 
current method though, at least at first.


>  I just thought it would be nice if you could define the shape with a 
> linear spline. 

How does a waveform modifier (like sine_wave, triangle_wave, etc.) which 
allows you to specify the mapping with a spline sound?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> >  I just thought it would be nice if you could define the shape with a
> > linear spline.
> 
> How does a waveform modifier (like sine_wave, triangle_wave, etc.) which
> allows you to specify the mapping with a spline sound?
> 

I'm not sure if i understand what you mean, but this would probably not help,
the spline is meant for defining the shape of the plank, so the only way that
would work would be using a radial pattern and giving the spline in polar
coordinates.

Christoph

--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <39A### [at] schunteretctu-bsde>, 
chr### [at] gmxde wrote:

> I'm not sure if i understand what you mean, but this would probably 
> not help, the spline is meant for defining the shape of the plank, so 
> the only way that would work would be using a radial pattern and 
> giving the spline in polar coordinates.

Sorry, I read "...proximity pattern would probably be quite slow. I just 
thought it would be nice if you could define the shape with a linear
spline." as defining the shape of the *function* with a linear spline. I 
understand what you mean now, but I don't see an easy way to do it...and 
prisms will probably be one of the objects which have to use the old 
proximity calculation.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Tue, 22 Aug 2000 10:33:21 -0500, Chris Huff wrote:
>Sorry, I read "...proximity pattern would probably be quite slow. I just 
>thought it would be nice if you could define the shape with a linear
>spline." as defining the shape of the *function* with a linear spline. I 
>understand what you mean now, but I don't see an easy way to do it...and 
>prisms will probably be one of the objects which have to use the old 
>proximity calculation.

Even linear spline prisms?  Whyever for?  There's a simple procedure to
determine the distance of a point from an arbitrary polygon[1].  The 
proximity is then the minimum over all the edges and the two caps of the 
prism.

Beware, though: the proximity function may be continuous, but it is not
continuously differentiable, and that might matter to the isosurface 
solver.

[1] determine the closest point on the plane in which the polygon lies.
If it's inside the polygon, the distance is the distance to that point.
Otherwise, it's the minimum of the distances to the line segments[2]
that bound the polygon.

[2] determine the closest point on the line in which the segment lies.
If it's inside the segment, the distance is the distance to that point.
Otherwise, it's the smaller of the distances to the endpoints of the
line segments.[3]

[3] Though for efficiency's sake, you should only compute it for one 
of the endpoints.  The other endpoint is either the endpoint of another
line segment for which you must check endpoints, or it's the closest 
point on that other line segment, or that other line segment contains 
a closer point.[4]

[4] The same argument applies to the line segments themselves (they're 
shared between polygons) and in the case of a prism, it's easy to decide
which you should check for a given face.[5]  For a mesh, you will have to 
mark the ones you've already checked (don't forget to mark the boundaries
of polygons that contained their respective nearest points.)

[5] But watch the orientations.  Nothing sucks worse than checking the 
same endpoint twice while ignoring the other endpoint altogether.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> Even linear spline prisms?  Whyever for?  There's a simple procedure to
> determine the distance of a point from an arbitrary polygon[1].  The 
> proximity is then the minimum over all the edges and the two caps of the 
> prism.

Because I didn't know this algorithm. :-)
Hmm, does this take the caps into account? It looks like an infinitely 
long prism(or proximity to a polygon in a 2D plane).
When mesh proximity is implemented, it should be possible to do some 
shapes fairly accurately by simply tesselating them. Prisms should be 
fairly easy to tesselate...


> Beware, though: the proximity function may be continuous, but it is not
> continuously differentiable, and that might matter to the isosurface 
> solver.

It should still give better results than the raw object pattern in most 
cases, and better than a blurred object pattern(since the only way I can 
figure out to do the blur gives several "steps" of values).
BTW, what exactly do you mean by "continuously differentiable"? Do you 
mean that the function may be continuous but the derivative may not be? 
Where would the function "break"?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Tue, 22 Aug 2000 12:23:01 -0500, Chris Huff wrote:
>In article <slr### [at] fwicom>, ron### [at] povrayorg 
>wrote:
>
>> Even linear spline prisms?  Whyever for?  There's a simple procedure to
>> determine the distance of a point from an arbitrary polygon[1].  The 
>> proximity is then the minimum over all the edges and the two caps of the 
>> prism.
>
>Because I didn't know this algorithm. :-)
>Hmm, does this take the caps into account? It looks like an infinitely 
>long prism(or proximity to a polygon in a 2D plane).

Yes, it does take the caps into account.  You find the distance to each face,
including the two caps, using the method described, then find the minimum.  
None of what I described is in 2D.

>BTW, what exactly do you mean by "continuously differentiable"? Do you 
>mean that the function may be continuous but the derivative may not be? 
>Where would the function "break"?

Exactly.  It "breaks" in the "corners."  For example, in the interior of a
square, the 2D version of a proximity pattern is undifferentiable along 
the diagonals of the square (as you cross the diagonal, the derivative of
the proximity function abrubtly changes sign and possibly magnitude) and
on the edges (the function is undifferentiable wherever it has a value of
zero, since it is the absolute value of a different function.)

What this means to the isosurface solver is that if it happens to look at
the wrong points, it may miss some intersections.  What really sucks is 
that the function is undifferentiable in exactly the same places that the
object pattern is discontinuous (and thus undifferentiable as well), and 
probably in other places as well.

You can remove some of the areas of concern by making a proximity function
that returns negative values for points on the inside of the shape, but
you can't remove them all.

This problem is not unique to prisms and meshes, either.  The proximity
function is undifferentiable at the center of a sphere, too.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> Yes, it does take the caps into account.  You find the distance to 
> each face, including the two caps, using the method described, then 
> find the minimum.  None of what I described is in 2D.

Ok, I will have to take a closer look at this algorithm...


> You can remove some of the areas of concern by making a proximity 
> function that returns negative values for points on the inside of the 
> shape, but you can't remove them all.

One way to flip the inner function's sign would be to use an object 
pattern, though I may add this capability to the pattern itself.
And wouldn't this remove *all* the areas which are causing trouble with 
the object pattern? There are still other areas, but this would remove 
the problem at the surface of the proximity object, which is where the 
discontinuity is with the object pattern.


> This problem is not unique to prisms and meshes, either.  The proximity
> function is undifferentiable at the center of a sphere, too.

And the axis of a cylinder/cone, and a circle along the major radius of 
a torus, I think...actually, I think all objects generated from a 
proximity function would have this problem, fortunately, it doesn't 
always appear. Isn't the maximum gradient used to help prevent missing 
these intersections?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Tue, 22 Aug 2000 17:06:35 -0500, Chris Huff wrote:
>One way to flip the inner function's sign would be to use an object 
>pattern, though I may add this capability to the pattern itself.
>And wouldn't this remove *all* the areas which are causing trouble with 
>the object pattern? 

Yes.  That is, it'd remove the surface of the object.

>And the axis of a cylinder/cone

Actually, not the axis.  For a cylinder, two cones at the ends, and the line 
segment connecting their apexes.  For a cone, a different cone at the base 
and the line segment connecting its apex with the containing cone.  
There are external places where it's undifferentiable as well.

>Isn't the maximum gradient used to help prevent missing 
>these intersections?

No.  It's used to help the solving algorithm know when there can't possibly
be a solution in the test interval.  I've been thinking about the problem,
though, and I think it might be okay after all if there are some isolated 
spots where it's not differentiable, so long as it's continuous.  After all,
min/max have the same problem.  This whole thread may be a false alarm.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message