> 
> [...]
> Having a 'tesselation' block would mean to provide a view to the user which
> would really be very different from the internal: because the user would see
> it as an extension of any object, whereas in real code, the object would
> have been completely replaced by something else.

I second that.

Although Chris Huff is right that there are objects internally represented
as a mesh (like heightfield and patch) this is something different IMO.  A
method for combining different meshes into one would be good of course.

I think a syntax like ABX suggested in p.b.i would be best:

tesselate{
  OBJECT_ID | OBJECT
  METHOD {  METHOD_PARAMS }
  WARP { WARP_STATEMENT } | DISPLACEMENT{ PIGMENT |
f_x(x,y,z),f_y(x,y,z),f_z(x,y,z) }
  OBJECT_MODS
}

Although i think the 'DISPLACEMENT' is unnecessary if we have displace
warps or function warps (which would be based on a vector function)

No matter what syntax is chosen there should be a save_file/load_file
possibility, maybe with different possible file formats (mesh, mesh2, pcm)

Christoph

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

Post a reply to this message

Christoph Hormann wrote:

> A method for combining different meshes into one would be good of course.

As I'm overusing the foundation made by Warp in his tesselation patch, 
the good news is that there is already such things:

 mesh { tesselate {.... } tesselate {...} triangle.... }

> No matter what syntax is chosen there should be a save_file/load_file
> possibility, maybe with different possible file formats (mesh, mesh2, pcm)

that's a mesh level problem, not particular to the tesselation patch.
You want file I/O for mesh, and there was already a macro/include file
to do that (based on Warp extension to access the mesh structure from SDL).

And soon, you will want a full dump of all Pov-scene...
-- 
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,

Post a reply to this message

> 
> [...]
> 
> As I'm overusing the foundation made by Warp in his tesselation patch,
> the good news is that there is already such things:
> 

All right, that's fine.

> 
> > No matter what syntax is chosen there should be a save_file/load_file
> > possibility, maybe with different possible file formats (mesh, mesh2, pcm)
> 
> that's a mesh level problem, not particular to the tesselation patch.
> You want file I/O for mesh, and there was already a macro/include file
> to do that (based on Warp extension to access the mesh structure from SDL).

I forgot there were already hooks for that in Warp's patch, it will be
slower of course, but it would fulfill the purpose.  

Christoph

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

Post a reply to this message

<jer### [at] atosorigincom> wrote:
> And soon, you will want a full dump of all Pov-scene...

Fortunatelly it's not a problem, File->Save works fine ;-)

ABX

Post a reply to this message

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