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 ?

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



P.S.: Cross-posted in p.g and p.u.p, FU2 set to p.u.p
-- 
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'm wondering about the possible tesselation of Pov object: 

This question sounds great becouse it's suggestion you are near final
implementation.

> 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 ?
> Should the actual texture be used?
> or sampled at the triangle vertex, keeping only a RGB(TF) vector ?

I imagine all above should be optional. For example: there is no simple way to
recreate texture of differently colored blob's components, so sampling colors
(or even all texture components) for vertices should be possible. But when
complicated iso-stone is tesselated then there is no need to store texture for
every vertex but whole mesh should inherit texture from mesh.

Also it could be great to inherit uv-coordinates when available. For example
parametric object is very slow in rendering but looks it could be possible to
apply uv-mapping to it. Recreating this object with loop along functions gives
not optimized mesh. Recreating it with tesselation gives optimized triangles
but without uv-mapping.

ABX

Post a reply to this message

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

> Or something else ?

uv-coordinates?

Ingo

Post a reply to this message

> 

> <jer### [at] atosorigincom> wrote:
> > I'm wondering about the possible tesselation of Pov object:
> 
> This question sounds great becouse it's suggestion you are near final
> implementation.
> 

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

> > 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 ?
> > Should the actual texture be used?
> > or sampled at the triangle vertex, keeping only a RGB(TF) vector ?
> 
> 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 ?

> For example: there is no simple way to
> recreate texture of differently colored blob's components, so sampling colors
> (or even all texture components) for vertices should be possible. But when
> complicated iso-stone is tesselated then there is no need to store texture for
> every vertex but whole mesh should inherit texture from mesh.

I will have to think about that too! Thanks.

> 
> Also it could be great to inherit uv-coordinates when available. For example
> parametric object is very slow in rendering but looks it could be possible to
> apply uv-mapping to it. Recreating this object with loop along functions gives
> not optimized mesh. Recreating it with tesselation gives optimized triangles
> but without uv-mapping.

That's a different problem. It would be optimising the parametric object,
not tesselating any solid finite object.
For the time being, I will just forget about UV-mapping for general tesselation.

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

Post a reply to this message

On 18 Feb 2002 07:43:02 -0500, ingo <ing### [at] homenl> wrote:
> > 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.

IIRC every object in POV (except mesh and parametric) is new one becouse has
own memory representation. Why not to allow optional behaviour ? In case of
tesselated blob it could be very difficoult to recreate texture for mesh.

ABX

Post a reply to this message

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