Christoph Hormann wrote in message
<3A1E9A74.B6428D71@schunter.etc.tu-bs.de>...
> Every CSG made of cylinders, spheres, cones, boxes, torii should be
quite
> easy to convert to a smooth isosurface function, the more difficult
things
> are lathe, prism and meshes.


yes, I know
but as I said I'm looking for universal method (equations)
perhaps to code in source code

ABX -> just look -> http://www.mdk.art.pl/

Post a reply to this message

Wlodzimierz ABX Skiba wrote:
> 
> Chris Huff wrote in message ...
> >In article <3a1e6b2a@news.povray.org>, "Wlodzimierz ABX Skiba"
> ><abx### [at] abxartpl> wrote:
> >
> > > first I prepare CSG than I declare function{pigment{object{...}}} to
> > > describe interior of it and then I clone this as isosurface.
> > > Isosurface has artifacts even with accuracy 0.00005.
> > > I have calculated value (with eval) of max_gradient as 200000 but
> this
> > > not help.
> >
> > The object pattern has two states: on and off. It doesn't have any
> > "in-between" values. Patterns like this have an infinite gradient, and
> > cause the isosurface algorithm problems. Other patterns that have this
> > problem are checkers, hexagon, brick, and any pigment that has sharp
> > lines.
> 
> I know this but unfortunatly in current (unoficial) state of pov this is
> only way to play with described week ago nonlinear transformations.
> Everything is ok but normals.

The couple of images I posted a few weeks ago didn't use the object
pattern, but proximity.
I don't know if this is what you were talking abut though.

-- 

      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

In article <3a1e7cda@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> I know this but unfortunatly in current (unoficial) state of pov this is
> only way to play with described week ago nonlinear transformations.

The proximity pattern will be better for this, but in it's current state 
is too slow to make a practical pigment function.


> perhaps the problem can be resolved just like in smooth_triangle ?

I don't see how...in a smooth triangle, you manually specify the normal 
at each corner. Isosurfaces don't have such convenient control 
points...and the results would probably look horrible.

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

In article <3A1E9A74.B6428D71@schunter.etc.tu-bs.de>, 
chr### [at] gmxde wrote:

> Every CSG made of cylinders, spheres, cones, boxes, torii should be quite
> easy to convert to a smooth isosurface function, the more difficult things
> are lathe, prism and meshes.

A sor should be pretty easy, a lathe shouldn't be extremely difficult. A 
mesh may not be a huge problem either. Simple convex prisms also 
wouldn't be hard, but concave or self-intersecting prisms could be a 
bigger problem. 
Basically the distance of the nearest point on the surface, with a 
negative sign if inside the object and a positive sign if outside.
This is what my proximity pattern will eventually do.

-- 
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:
> 
> A sor should be pretty easy, a lathe shouldn't be extremely difficult. A
> mesh may not be a huge problem either. Simple convex prisms also
> wouldn't be hard, but concave or self-intersecting prisms could be a
> bigger problem.

With linear splines this should be easy too, but the others would involve
some more complicated math that would probably be quite slow when not hard
coded.

> Basically the distance of the nearest point on the surface, with a
> negative sign if inside the object and a positive sign if outside.
> This is what my proximity pattern will eventually do.

proximity pattern is quite slow right now, but for linear spline
prisms/lathe/sor, i could think of a different algorithm dividing space
into segments where proximity only depends on a single plane, that would
use quite a lot of memory, but it would be fast.  Of course this would
also have some problems with concave shapes, but since the isosurface use
only needs good results near the actual surface, this is not that
problematic.

Christoph

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

Post a reply to this message

Christoph Hormann wrote in message
<3A1F8692.ECF21C45@schunter.etc.tu-bs.de>...
> > Basically the distance of the nearest point on the surface, with a
> > negative sign if inside the object and a positive sign if outside.
> > This is what my proximity pattern will eventually do.
>
> proximity pattern is quite slow right now...

but don't need so much small accuracy and perhaps so big max_gradient
therefore this could be faster than pigment{object{}}
I'll tell you after (ray)tracing

ABX
VooVoo is not VooDoo -> http://www.voovoo.art.pl/

Post a reply to this message

In article <3a1f8d4b@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> but don't need so much small accuracy and perhaps so big max_gradient
> therefore this could be faster than pigment{object{}}

In order to get a smooth enough pattern that the isosurface algorithm 
can use it, you need to use a huge number of samples. It has been tried 
before, but was too slow to be of practical use.
However, I am working on an updated version that has specialized 
proximity functions for each object as well as the existing sampling 
function...this will be much faster for many objects.

-- 
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 in message ...
> However, I am working on an updated version that has specialized
> proximity functions for each object as well as the existing sampling
> function...this will be much faster for many objects.


sounds great

ABX

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: but 
: his color_map is [0 rgb 1][0 rgb 0][1 rgb 0], which looks like a mistake 
: to me...it is completely black, with no variation at all

  Did you actually try to render an object with that pigment?
  It's not completely black :)

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

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: What are you expecting this color_map to result in? It starts out as 
: white, but goes to black in 0 distance and ends in black, basically a 
: black pigment...

  Try rendering a plane with that pigment.

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

Post a reply to this message