"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> 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.

Question:  Would it be appropriate for, say, "tesselation" to have it's own
block of code inside the object declaration (the same way as texture, media,
interior, etc)?  This way, all tessellation-only transformations /
deformations whatever get grouped together for easy reference.

...Chambers


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.323 / Virus Database: 180 - Release Date: 2/8/2002

Post a reply to this message

Ben Chambers wrote:
> 
> "Christopher James Huff" <chr### [at] maccom> wrote in message

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

I do not like that idea of flag.

> 
> Question:  Would it be appropriate for, say, "tesselation" to have it's own
> block of code inside the object declaration (the same way as texture, media,
> interior, etc)?  This way, all tessellation-only transformations /
> deformations whatever get grouped together for easy reference.

I still think that a tesselated object is just an object, and that deformation
of mesh are still another object whose parameter is an input mesh and some
additional parameters.

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.

Moreover, some object won't be able to support this block, which is really
annoying because it breaks the homogeneity of the 'object' in Pov.

Last, I do not believe that transformation of mesh are similar to blob component:
 the order in which the transformation are made usually is important.
 So adding a 'tesselation block' would means to have something similar to
layered texture, which would just prouve to be counter-productive for mesh
transformation in the current state of the code.

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

Post a reply to this message

In article <3c7498ae@news.povray.org>,
 "Ben Chambers" <bdc### [at] yahoocom> wrote:

> Question:  Would it be appropriate for, say, "tesselation" to have it's own
> block of code inside the object declaration (the same way as texture, media,
> interior, etc)?  This way, all tessellation-only transformations /
> deformations whatever get grouped together for easy reference.

I don't see why this would be useful, and it would be very inconsistent. 
All it would do is complicate the programming, it wouldn't add any 
flexibility.

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

In article <3C74BB1F.D2267C56@atosorigin.com>,


> I still think that a tesselated object is just an object,

Agreed.


> and that deformation of mesh are still another object whose parameter 
> is an input mesh and some additional parameters.

Hmm? Are you talking about some sort of "deform" object that takes a 
mesh as input? That might be what was wrong with my approach, I was 
attempting to deform a mesh, with a syntax more like transformations.


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

This sort of thing is done already: bicubic patches and height fields 
are reduced to triangles internally, and some objects have a "sturm" 
option to change the intersection solver. The tesselate flag wouldn't 
replace the object, it would just tell it to use a mesh for the 
intersection calculations. It could even use the object's own normal and 
insideness calculations. The flag wouldn't be used for deformation or 
anything, just for intersection. Some other method would be used to 
generate a mesh, I'd suggest something like: mesh {OBJECT} or tesselate 
{OBJECT}.


> Moreover, some object won't be able to support this block, which is really
> annoying because it breaks the homogeneity of the 'object' in Pov.

Which objects? The only ones I can think of are the infinite ones, and a 
stand-in could be generated for those...two very big triangles for the 
plane, for example. And these objects have to be dealt with anyway, what 
does your patch currently do?


> Last, I do not believe that transformation of mesh are similar to blob 
> component:
>  the order in which the transformation are made usually is important.
>  So adding a 'tesselation block' would means to have something similar to
> layered texture, which would just prouve to be counter-productive for mesh
> transformation in the current state of the code.

I don't understand...what do blobs have to do with this? Did I miss 
something?

-- 
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 <3C74BB1F.D2267C56@atosorigin.com>,

> 
> > I still think that a tesselated object is just an object,
> 
> Agreed.
> 
> > and that deformation of mesh are still another object whose parameter
> > is an input mesh and some additional parameters.
> 
> Hmm? Are you talking about some sort of "deform" object that takes a
> mesh as input? That might be what was wrong with my approach, I was
> attempting to deform a mesh, with a syntax more like transformations.
> 

Yes.
 
> > Last, I do not believe that transformation of mesh are similar to blob
> > component:
> >  the order in which the transformation are made usually is important.
> >  So adding a 'tesselation block' would means to have something similar to
> > layered texture, which would just prouve to be counter-productive for mesh
> > transformation in the current state of the code.
> 
> I don't understand...what do blobs have to do with this? Did I miss
> something?

Just my mind wandering about the possible 'tesselation' block 
(which is a bad idea, IMNSHO, at least with my current code).
Order in blob is irrelevant, whereas order of transformation is important,
even if the rotate/scale/translate can all be summarized in one single
matrix, but for transformation of mesh there is no possible summarisation, and
order is still important.

I should probably not have mentionned the blob.


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

Post a reply to this message

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