The questions were:
%}
%}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 ?
%}

to which the answers were:

From abx### [at] babilonorg:
> 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.
To which I provide more info and ended up with:
%> 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)
>

From ing### [at] homenl:
%> 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.
To which abx### [at] babilonorg objects with:
#>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.

From chr### [at] maccom:
> 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.
To which tor### [at] onlineno objects with:
#>I think that it would be a great pity if a POV-patch were to perform tessellation
#>of an object without providing the possibility to texture different copies of it
#>differently.
And chr### [at] maccom answered with:
> 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.



Offtopic:
=========
chr### [at] gmxde provide URL to papers describing adaptative tesselation methods
usable for tesselation of isofunction, blobs and/or parametrics. 
I dismissed the paper because my goal is to be able to tesselate ANY solid finite
bounded object (including CSG !), but the papers might be useful to people seeking to
play with isofunction, blobs or parametrics.

Dismissed:
==========
*UV-mapping, for two reasons:
 1. There is no generic way to correctly UV-map ANY closed mesh that I know of.
 2. I personally never liked UV-mapping. I can appreciate the texture_list in 3.5 for
triangle, and the interpolation it make, but UV-mapping is, for me, breaking one of
the great paradigm of Pov: the immersion of the 3D-object in the 3D procedural
texture, independently of the object.  The mapping of 2D texture depending on the 3D
object is still underdevelopped in Pov (slope pattern ?).

*Color-Inheritance because:
 1. How to get the texture ? only getting an intersection *might* return an object,
and this object may or not have a texture.
 2. The cited example was blob texture, and the computation is done in a special
functions in lighting.c, so sampling this kind of texture would be nearly impossible.
Better to use a texture which use the original blob as the pattern...

Well, may be, just getting the texture from the object returned in the intersection
should be done. There would lake some textures in some case of nexted CSG, but if one
really wants to inherit textures, one should provided a CSG textured at the deepest
level.
Not quite sure yet....

*Tesselate flag, with object specific method for tesselation, because:
 1. I do not want to turn Povray in a triangle rendering engine.
 2. It involves too much changes, including adding a method!
 3. it secretly would change the object. If user (scene writer) really want to use a
mesh instead of a real object, it should explicitely request it so. ( for instance,
the tesselated object can not be used any more in a CSG, and there is no way back, so
this is not a small change).
 4. some people think that rendering a mesh is quicker than the real object, but the
building of the mesh bounding tree is quite long in some case (even if it's part of
the parsing time, not the rendering time). Therefore, I believe that tesselation is
NOT the universal answer.


Added to the 'todo' list:
====================
1. All mesh-transformations (bend,screw,roll,smooth,displace,select...) should be
conservative in regard to the individual textures of the triangles, and inherit the
global texture as an option. Well, in fact, the conservatisme of individual textures
should also be another option.

2. A new mesh-transformation option which remove all individual textures from a mesh.
(using select with no restriction apply it to a whole mesh without further
transformation, so it's easily done).

3. Revise and unify the syntax, enforce checking (using a full-keyword oriented
syntax, without any positional information).

4. Allow, only for tesselation which are part of a mesh, to put a texture identifier
over all the new triangles which do not have a specific texture already. (thus
creating a mesh full of colour should be easier)

5. Re-incorporate the 'three texture' interpolation for triangles in mesh. (Just in
case color-inheritance be implemented, and because I like that)

6. Find and implement a mesh decimation such that for example a tesselated cube use
the minimal number of triangles. It will have a bad effect if the decimation is
applied before a transformation, but it should reduce the memory consumption. The
individual texture of the triangles must be taken into account. 

7. Find and implement a mesh sub-division such that all triangles have a size small
enough. (allowing to have smoother deformation from initially simpler mesh).

8. Find and implement a mesh Delaunay transformation such that all triangles are
'nice'. Beware of texture consistency.

9. Documents and illustrates!

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

Post a reply to this message