Post a reply to this message

Post a reply to this message

In article <4219fc6a@news.povray.org>,
 "William Peska" <wil### [at] yahoocom> wrote:

It'd help if you gave a little more detail...for instance, maybe 
describing what you think such a feature would do. As it is, you're 
essentially asking for "magic".

There's nothing particularly special about UV coordinates, you pick a 
system that fits your purpose. For instance, for UV-mapping a sphere, 
you usually pick spherical coordinates...that would not work well for a 
torus. It could work for a box, but you'd probably pick a mapping 
designed specifically for boxes instead. The shape of an isosurface is 
very arbitrary, it could be a sphere, a torus, or something far more 
complex. There is simply no way for POV to guess what you might want.

One possibility that does come to mind would be to allow the user to 
specify a pair of functions mapping XYZ coordinates to UV coordinates. 
It would not be particularly easy to use, though. It is in fact already 
possible, though you have to jump through a few hoops...you need to use 
a function pattern that implements the desired mapping. For example 
(untested!):

#declare basePattern = function {pattern {checker scale 0.1}};

#declare uFn = function (x, y, z) {
    atan(x, z)/(2*pi) + 0.5
};

#declare vFn = function (x, y, z) {
    atan(y, sqrt(x*x + z*z))/(2*pi) + 0.5
};

isosurface {
    ...
    pigment {function {basePattern(uFn(x, y, z), vFn(x, y, z), 0)}
        ...
    }
}

-- 
Christopher James Huff <cja### [at] gmailcom>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Wasn't it Christopher James Huff who wrote:
>In article <4219fc6a@news.povray.org>,
> "William Peska" <wil### [at] yahoocom> wrote:
>
>It'd help if you gave a little more detail...for instance, maybe 
>describing what you think such a feature would do. As it is, you're 
>essentially asking for "magic".
>
>There's nothing particularly special about UV coordinates, you pick a 
>system that fits your purpose. For instance, for UV-mapping a sphere, 
>you usually pick spherical coordinates...that would not work well for a 
>torus. It could work for a box, but you'd probably pick a mapping 
>designed specifically for boxes instead. The shape of an isosurface is 
>very arbitrary, it could be a sphere, a torus, or something far more 
>complex. There is simply no way for POV to guess what you might want.
>
>One possibility that does come to mind would be to allow the user to 
>specify a pair of functions mapping XYZ coordinates to UV coordinates. 
>It would not be particularly easy to use, though. It is in fact already 
>possible, though you have to jump through a few hoops...you need to use 
>a function pattern that implements the desired mapping. For example 
>(untested!):
>
>#declare basePattern = function {pattern {checker scale 0.1}};
>
>#declare uFn = function (x, y, z) {
>    atan(x, z)/(2*pi) + 0.5
>};
>
>#declare vFn = function (x, y, z) {
>    atan(y, sqrt(x*x + z*z))/(2*pi) + 0.5
>};
>
>isosurface {
>    ...
>    pigment {function {basePattern(uFn(x, y, z), vFn(x, y, z), 0)}
>        ...
>    }
>}

I was wondering if something like that could be achieved.

For a sensible result you'd really want to find a set of functions that
had the property that uFn, vFn and the surface function be orthogonal
everywhere. That would be the 3d equivalent to what are called
"orthogonal trajectories" of a family of curves in 2d. In the 2d case,
there's a method for finding orthogonal trajectories if you can find a
differential equation that describes the family of curves and then solve
the inverse of that differential equation. Consider the family of
surfaces produced by using different values of "threshold", then find
two other families of surfaces that are the 3d orthogonal trajectories.

The 3d case is likely to be a bit more awkward to calculate, if for no
other reason than the fact that there isn't a unique solution like there
is in the 2d case.

In a really simple case, I happen to know that f_sphere(), f_th() and
f_ph() are orthogonal everywhere, so that gives us something we can
check. Here's a complete scene using the technique (in this case the
scale needs to be a fraction of pi to prevent a discontinuity). 

camera { location  <0, 0, -2.5> look_at <0, 0, 0>}
light_source {<-100,200,-100> colour rgb 1}

#include "functions.inc"
#declare basePattern = function {pattern {checker scale pi/20}};
#declare uFn = function{f_th(x,y,z)}
#declare vFn = function{f_ph(x,y,z)}
#declare Surface = function {f_sphere(x,y,z,1)}

isosurface {
  function { Surface(x,y,z) }
        max_gradient 2.2
        contained_by{sphere{0,1.1}}
        pigment {function {basePattern(uFn(x, y, z), vFn(x, y, z), 0)}}
}

All we need to do now is derive such orthogonal functions in the general
case.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Christopher James Huff" <cja### [at] gmailcom> wrote in message
news:cjameshuff-64B309.20125721022005@news.povray.org...
> It'd help if you gave a little more detail...for instance, maybe
> describing what you think such a feature would do.

1. A ray hits isosurface at point A = (x, y, z)
2. f(A) = (u, v, 0) = w
3. pigment(w)

For 2: To calculate u and v it is necessary to know the basis point (u = v =
0) on the surface of the isosurface and in which directions u, v are + or -.

This method is theoretically applicable for isosurfaces with 1 surface.
A more advanced algorithm can keep record of each separate surface
(iso-object) of the isosurface in database-like extensible structure. Every
iso-object will have its own basis point and directions for u, v(manually or
automatically set) and therefore own function for co-ordinates
transformation.

> As it is, you're essentially asking for "magic".
Is the above algorithm mathematically impossible(analytically and
numerically)?

Thank you,
William

Post a reply to this message

On Tue, 22 Feb 2005 06:38:50 +0000, Mike Williams <nos### [at] econymdemoncouk>
wrote:
> I was wondering if something like that could be achieved.

Yes, the tutorial is in the tutorial group since about 4 years. IIRC it was
title with "isomaze tutorial". I do not rember what was the last POV-Ray
version I tried it with.

ABX

Post a reply to this message

In article <421b4484$1@news.povray.org>,
 "William Peska" <wil### [at] yahoocom> wrote:

> > As it is, you're essentially asking for "magic".
> Is the above algorithm mathematically impossible(analytically and
> numerically)?

Yes. You could come up with a numeric method for finding separate 
surfaces, but only with great difficulty and it would be either very 
unreliable or very slow. (One method that comes to mind would be 
building a voxel map and searching for disconnected regions of voxels. 
Another would require tessellating the isosurface and searching for 
unconnected groups of triangles. Neither would succeed if you have a 
contiguous surface enclosing multiple separate volumes.)

Once you have that, you've still got the first "magic" step of finding a 
sensible mapping between spatial coordinates and surface coordinates. So 
you pick an origin point and two basis vectors...where do you go from 
there? As far as I can tell, that's only enough for "height field" type 
isosurfaces, a simple sheet displaced vertically without any overhangs. 
There are many surfaces that simply can't be seamlessly mapped to a 2D 
plane. The sphere is the simplest example. How would your hypothetical 
algorithm UV map a sphere?

And assuming you finally figure out how to automatically define a 
mapping, you'll just get something that doesn't make any sense to a 
human. If the mapping is unpredictable, it's useless. The only practical 
option is to design the mapping specifically for the object and intended 
purpose, and doing so is impossible for something as flexible as an 
isosurface.

-- 
Christopher James Huff <cja### [at] gmailcom>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" <cja### [at] gmailcom> wrote in message
news:cjameshuff-53CA25.10221222022005@news.povray.org...
> There are many surfaces that simply can't be seamlessly mapped to a 2D
> plane. The sphere is the simplest example. How would your hypothetical
> algorithm UV map a sphere?

I'm confused, uv-mapping a sphere isn't difficult, is it?

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

In article <421b6daf@news.povray.org>,
 "Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote:

> "Christopher James Huff" <cja### [at] gmailcom> wrote in message
> news:cjameshuff-53CA25.10221222022005@news.povray.org...
> > There are many surfaces that simply can't be seamlessly mapped to a 2D
> > plane. The sphere is the simplest example. How would your hypothetical
> > algorithm UV map a sphere?
> 
> I'm confused, uv-mapping a sphere isn't difficult, is it?

It's very easy, there are several ways to do it, but none are seamless, 
and I see no reasonable way for a general algorithm to automatically UV 
map a sphere. You need to specifically specify that you want to use a 
sphere mapping.

The basic problem is this...given a point where u and v coordinates are 
zero, and basis vectors for the u and v axii at that point, what are the 
UV coordinates at some other point? That's all the information you have, 
unless you somehow collect other information beforehand. You don't have 
the sphere center or radius, because you don't know it's a sphere. You 
could probably do some analysis of the surface to determine if it's 
close enough to spherical and find the approximate center, but that's 
slow, complicated, unreliable, and you'll need to make additional 
special cases for other basic shapes.

The only reasonable solution is to require the user to specify what he 
wants. That's only slightly awkward to do with function patterns...it's 
worse with things like image_maps though. A general (not specific to 
isosurfaces) user-defined UV mapping using functions could be useful, 
but it's hardly a critical feature.

-- 
Christopher James Huff <cja### [at] gmailcom>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> And assuming you finally figure out how to automatically define a 
> mapping, you'll just get something that doesn't make any sense to a 
> human.

I agree that many mappings one might pick would be unintuitive, but that 
does not mean that it's impossible to define a good mapping.  For 
example, having the u and v coordinates follow the lines of principal 
curvature I imagine would often give pretty good results (provided one 
takes care of the ambiguities in this definition, like where to put the 
origin, what to do with planar regions, etc).

That said, I wholeheartedly agree that it would be difficult to 
implement such a system, and that it would probably render unreasonably 
slowly anyway.  This is probably the sort of thing that would be better 
solved by having a scripting language for materials, so that ambitious 
users could program in their curvature-based uv mapping or whatever 
suites their needs for the object they wish to model.

Post a reply to this message