ingo wrote:
> 

> 
> > would you expect the textures of the tesselated object to be taken in
> > the generated mesh ?
> 
> No.
> 
> > Or would you only expect to get the form with
> > only the default texture ?
> 
> Yes, as it is not a copy of an object but a new one.

Ok, that would be simpler for the code.

> 
> > Or something else ?
> 
> uv-coordinates?

Sincerely, forgets about UV, because there is no way to do that for
all finite solid objects.
Even if one only considers the UV mapping of a sphere, the UV mapping of
the union of two spheres is mind-boggling and too hard to generalise.

But I notice that sampling RGB at the vertices does not seems to suit either.
Ok.

-- 
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,

Post a reply to this message

<jer### [at] atosorigincom> wrote:
> > I imagine all above should be optional.
>
> That's not really an answer.
> May be, the intersection test based could get a copy of the texture structure at
> the intersection,
> Whereas the ones using insideness might just inherit a texture if explicitely 
> specified by the SDL ?

So do it at least for intersection methids (if I understand your answer
correctly)

>For the time being, I will just forget about UV-mapping for general tesselation.

:-(

ABX

Post a reply to this message

> 
> [...]
> 
> Sort of, I currently have 6 differents ways to tesselate an object:
>  2 based on marching tetrahedrons, using intersection test (IIRC);
>  4 based on marching cube, using insideness and various way to do the triangles;
>  (but for the latest 2, I still need to check the PD aspect of the tesselation,
>  because what I can do ok in my kitchen might not be ok in exported code.)
> 
> All workings fine with sphere/box/cone/cylinder/torus, but still need to check
> with more fancy objects (such as julia_fractal, blob, CSG and so on...).
> 

How about adaptive (curvature or distance dependant) methods.  See for
example:

http://www.cs.queensu.ca/home/jstewart/papers/cga01.html

I think some kind of adaptation would be possible with a marching
algorithm too.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 06 Feb. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> How about adaptive (curvature or distance dependant) methods.  See for
> example:
> 
> http://www.cs.queensu.ca/home/jstewart/papers/cga01.html

From Page 2:
The algorithm requires an evaluator for the implicit function defined at all points in
space, 
an evaluator for the function gradient defined at points near the surface, 
and a bounding box around the surface.

The bounding box, we have.
Alas, the only function available is "Insideness test", and the result is only 0 or 1
 (usually).
So, no easy way to have an evaluator for the gradient (we could make one based
on soft variation of the value of the implicit function, if the answer was smoother).

But even requiring each Pov-object to provide this kind of function is probably not
worth it, because of the various transformation that might apply to an object.
Anyway, try getting a smooth evaluation for a julia_fractal, it might be possible
but really horrible.

The link may nevertheless be of interest for optimisation of the parametric object,
which I do not know.

-- 
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,

Post a reply to this message

> 
> > http://www.cs.queensu.ca/home/jstewart/papers/cga01.html
> 
> From Page 2:
> The algorithm requires an evaluator for the implicit function defined at all points
in space,
> an evaluator for the function gradient defined at points near the surface,
> and a bounding box around the surface.
> 
> [...]

I mainly cited this paper since it also mentions some other tesselation
methods producing curvature dependant resolution meshes.

An algorithm only suited for isosurfaces might be useful though since a
lot of basic shapes can be represented as isosurfaces without problems.  

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 06 Feb. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3C70EA64.D2E842C9@atosorigin.com>,


> I'm wondering about the possible tesselation of Pov object: 
> 
> would you expect the textures of the tesselated object to be taken in the 
> generated mesh ?
> Or would you only expect to get the form with only the default texture ?
> Or something else ?

I don't see a reason for an object rendered using tesselation to have a 
different texture. I'm assuming tesselation is done as an object option 
though, not as generating a new object.


> Should the actual texture be used?
>  or sampled at the triangle vertex, keeping only a RGB(TF) vector ?

The actual texture. Vertex coloring would require a high-resolution mesh 
just for proper texturing, but that won't work for some objects (for 
example, a box can be tesselated with just 12 triangles, and a plane 
with 2, and a triangle with 1).

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> 
> In article <3C70EA64.D2E842C9@atosorigin.com>,

> 
> > I'm wondering about the possible tesselation of Pov object:
> >
> > would you expect the textures of the tesselated object to be taken in the
> > generated mesh ?
> > Or would you only expect to get the form with only the default texture ?
> > Or something else ?
> 
> I don't see a reason for an object rendered using tesselation to have a
> different texture. I'm assuming tesselation is done as an object option
> though, not as generating a new object.

I think that it would be a great pity if
a POV-patch were to perform tessellation
of an object without providing the possi-
bility to texture different copies of it
differently.


Tor Olav

Post a reply to this message

In article <3C7### [at] onlineno>,
 Tor Olav Kristensen <tor### [at] onlineno> wrote:

> I think that it would be a great pity if
> a POV-patch were to perform tessellation
> of an object without providing the possi-
> bility to texture different copies of it
> differently.

I wasn't talking about copies, but an alternate rendering method. A 
"tesselate" flag that would cause the object to be tesselated and 
rendered (and traced) as a mesh. Copies would be textured the same way 
any other object copies are textured.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:

> I wasn't talking about copies, but an alternate rendering method. A
> "tesselate" flag that would cause the object to be tesselated and
> rendered (and traced) as a mesh. Copies would be textured the same way
> any other object copies are textured.

Well, I wasn't talking about tesselating for rendering but mainly to
get an mesh object. What is done with the mesh is then upto the user.
It would be rendered at the end, but also may be in the meantime some non-linear
transformation might be performed on it.
Or thousand of copies of the mesh made, instead of thousand of copies of
some memory consuming objects.
Or whatever the user wants.

The main objective I want to stick with is: 
One object (which might be very complex, but it is bounded, finite and solid) is
provided,
you get back a closed mesh which is somehow similar to the provided object.

I do not want to make any change in the rendering engine.
I do not want to provide a global setting which would tesselate all objects in a scene
before rendering the tesselated set of objects.

It's just a kind of 'avoid the modeler & parsing time of mesh files'.

-- 
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,

Post a reply to this message

> Sort of, I currently have 6 differents ways to tesselate an object:
>  2 based on marching tetrahedrons, using intersection test (IIRC);
>  4 based on marching cube, using insideness and various way to do the
triangles;
>  (but for the latest 2, I still need to check the PD aspect of the
tesselation,
>  because what I can do ok in my kitchen might not be ok in exported code.)
>
> All workings fine with sphere/box/cone/cylinder/torus, but still need to
check
> with more fancy objects (such as julia_fractal, blob, CSG and so on...).

have you considered assigning standard pov objects (eg sphere) a pre defined
mesh, marching for all non regular objects (such as blobs) then deal with
csg


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message