I have been playing with the two patches mentioned in the subject.

  I'll describe my ideas and I hope to get some suggestions about the syntax,
improvement ideas and so on.


  - The mesh data extraction patch
    ==============================

  This is an independent patch which can be used with any mesh. Although
it's useful in itself, it makes the tesselation patch to make sense
(the tesselation patch without this patch would be pretty useless).

  The idea is that you could get individual values (vertices, triangles,
normals...) from a mesh object.
  This can be used to, for example, export a mesh to an ascii file format
(such as PCM or other more popular mesh formats), use macros on the mesh
(such as the SSS or the PCM macros) and so on.

  Right now I have done these functions:

  * get_triangle_count(MESH)
      Returns the number of triangles in the mesh

  * get_vertex_count(MESH)
      Returns the number of vertices in the mesh

  * get_normal_count(MESH)
      Returns the number of normal vectors in the mesh

  * get_vertex(MESH, INDEX)
      Returns the vertex vector that corresponds to the given index
      value (starting from 0)

  * get_normal(MESH, INDEX)
      As get_vertex, but returns a normal vector

  * get_vertex_indices(MESH, INDEX)
      Returns a vector containing index values to vertices for the triangle
      number INDEX (starting from 0). This can be used to read the three
      vertices of the triangle calling get_vertex() with each vector component

  * get_normal_indices(MESH, INDEX)
      The same as get_vertex_indices(), but returns indices to the normal
      vectors of the triangle number INDEX

  * is_smooth_triangle(MESH, INDEX)
      Tells whether the triangle number INDEX is smooth or not (not yet
      implemented).

  As you can see, there are lots of functions.

  My first idea was to put everything into arrays so that you could just
do all that with one function, like for example:

  get_mesh_data(MESH, VERTICES, NORMALS, TRIANGLES)

(with the three last parameters being undefined identifiers).
  You could then get the count values by reading the size of the arrays and
the data would be inside the arrays.
  (Another option would be to create three functions, each one returning
one array.)

  This latter option certainly sounds better than having 8 functions to get
the triangle data.
  However, it has one drawback: It takes a lot of memory to create those
arrays. Studying the povray source I have deduced that the arrays would
take more than twice the memory than the mesh itself (which would mean
that it takes more than three times the memory required for the mesh
itself to be able to handle the mesh and the arrays).

  But I can add this kind of function as an option. It's not like it was
mutually exclusive with the 8 first functions. Both could exist.

  Here is an example macro that writes a mesh to PCM format:

#macro ExportToPCM(Mesh, FileName)
  #fopen OutFile FileName write
  #local vrt_cnt = get_vertex_count(Mesh);
  #local nrm_cnt = get_normal_count(Mesh);
  #write(OutFile, "\"PCM1\",\n", vrt_cnt+nrm_cnt, ",\n")
  #local VInd = 0;
  #while(VInd < vrt_cnt)
    #local V = get_vertex(Mesh, VInd);
    #write(OutFile, V.x, ",", V.y, ",", V.z, ",")
    #local VInd = VInd+1;
  #end
  #local NInd = 0;
  #while(NInd < nrm_cnt)
    #local N = get_normal(Mesh, NInd);
    #write(OutFile, N.x, ",", N.y, ",", N.z, ",")
    #local NInd = NInd+1;
  #end
  #local tr_cnt = get_triangle_count(Mesh);
  #write(OutFile, "\n0,", tr_cnt, ",\n")
  #local TInd = 0;
  #while(TInd < tr_cnt)
    #local Ind1 = get_vertex_indices(Mesh, TInd);
    #local Ind2 = vrt_cnt + get_normal_indices(Mesh, TInd);
    #write(OutFile,
      Ind1.x, ",", Ind2.x, ",",
      Ind1.y, ",", Ind2.y, ",",
      Ind1.z, ",", Ind2.z, ",")
    #local TInd = TInd+1;
  #end
  #fclose OutFile
#end


  - The tesselation patch
    =====================

  The tesselation patch defines a function called tesselate() which can
be used to convert any object with a finite bounding box into a triangle
mesh. The syntax is the following:

  tesselate(OBJECT, RESOLUTION, SMOOTH, BBOX_OFFSET)

  The two last parameters are optional.
  The function returns a regular mesh object.

  The parameters have to following meaning:

  OBJECT: Any object with a finite bounding box.

  RESOLUTION: An integer value which must be greater than 0 and which
    affects the accuracy of the tesselation. A larger value gives a higher
    accuracy.

  SMOOTH: Boolean value which tells the function whether it should calculate
    flat or smooth triangles. If smooth triangles are calculated, the normal
    vectors are taken from the object itself. The default value is false.

  BBOX_OFFSET: If this value is different from 0, then the dimensions taken
    from the bounding box are enlarged by this amount. Only very small
    values should be used if any (like 0.0001). The default value is 0.
      This operation is necessary to tesselate objects like box { -1,1 }.
    However, this is not usually necessary and using a value different
    from 0 can cause inaccuracies with some objects (if an edge of the
    object touches the bounding box).

  To do: To study whether it's possible to use some supersampling algorithm
to calculate more triangles at sharp edges of the object.
  Currently the tesselation is not very good with sharp edges.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <3a37dd81@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   - The mesh data extraction patch
>     ==============================

This definitely looks useful!


>   - The tesselation patch
>     =====================

This reminds me of something I have been thinking of but don't know 
enough about meshes to do...extending the mesh object so you can put 
other objects in it and have them be automatically tesselated. There 
would also be various mesh processes that could do things like remove 
internal triangles, auto-smooth normals, remove redundant triangles, 
replace groups of tiny triangles with larger ones, apply a warp to the 
points to displace the mesh(I actually tried this one, I never got it to 
work), and various subdivision features...these would be in a 
"process_mesh" block and would be done in the order they are found.
The syntax would be something like this:

mesh {
    ...triangles and/or smooth triangles...
    OBJECT {OBJECT_STUFF TESSELATION_OPTIONS}
    process_mesh {
        warp {WARP}
        smooth SMOOTH_METHOD
        strip_interior_triangles
        subdivide {...}
        round_edges {...}
        ...
    }
}

TESSELATION_OPTIONS would vary from object to object, but would contain 
things like method, uv resolution, a target triangle area, whatever...as 
well as commands for how to add the tesselated object to the mesh: union 
would just add the triangles, merge would strip the interior triangles, 
etc...it could also contain mesh processing commands applied to the mesh 
generated from that object, before it is added into the main mesh.
An example would be:

mesh {
    sphere {<-1, 0, 0>, 1
        method 1, 4// 0=usual sin/cos tesselation, 1=subdividing 
polyhedron with depth as second parameter, something like a geodesic 
sphere
    }
    sphere {< 2, 0, 0>, 2
        method 1, 4
        merge// tell it to automatically remove interior triangles and 
produce the proper "seams"
        process_mesh {
            warp {turbulence 0.3}
        }
    }
    process_mesh {
        smooth SMOOTH_METHOD
    }
}

This could be very useful for manipulating meshes by hand...I had 
visualized it as using an approximation of objects which it couldn't 
tesselate directly, the bounding box of a julia_fractal for instance, 
but your tesselation algorithm would be a much better choice for this.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Whoa... you did it*. Way to go! Our dreams are a reality! Now we can make
POV benefit from those nice video cards, and stuff. Can you make a patch for
reading directly from 3DS and other file formats directly? :)


* "it" being "the tesselation of POV objects".

Post a reply to this message

Would this alternative syntax be better?

tesselate
{ MyObject
  accuracy INTEGER
  [smooth]
  [inside_vector VECTOR]
}

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I modified the syntax of the tesselation to be more versatile and more
homogeneous with the syntax of other povray objects.

tesselate
{ OBJECT
  [accuracy INTEGER]
  [smooth]
  [inside_vector VECTOR]
  [distance FLOAT]

  OBJECT_MODIFIERS
}

  I reused old keywords in MegaPov so that I wouldn't have to create new
ones.
  The hardest keyword to find was for the bounding-box offset value. I thought
that 'distance' could be the best one for that.

  I still have to work a bit about the meaning of the accuracy value.
  Any suggestions?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 14 Dec 2000 09:35:54 -0500, Warp wrote:
>  I reused old keywords in MegaPov so that I wouldn't have to create new
>ones.
>  The hardest keyword to find was for the bounding-box offset value. I thought
>that 'distance' could be the best one for that.

Isn't "offset" a keyword in MegaPOV anymore?

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
:   [accuracy INTEGER]

  I have decided to change that to:

    [accuracy VECTOR]

  This way the user can specify the accuracy in each axis.
  Of course specifying a single value will have the same effect as before
(because it's converted to a vector with the three components being that
value).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Isn't "offset" a keyword in MegaPOV anymore?

  Oh... You are right. I changed it to "offset" :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Sounds fine now. Just one question: What's "inside_vector"?

Post a reply to this message

Tony[B] <ben### [at] panamac-comnet> wrote:
: Sounds fine now. Just one question: What's "inside_vector"?

  See the section 5.3 (Solid Triangle mesh) of the MegaPov documentation.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

What tessellation method did you use?

Jim

Post a reply to this message

In article <3a38ca62@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Would this alternative syntax be better?
> 
> tesselate
> { MyObject
>   accuracy INTEGER
>   [smooth]
>   [inside_vector VECTOR]
> }

I think so...for one thing, there currently aren't any functions that 
return objects, so you should probably stick to the object syntax for 
creating objects. Also, this syntax could be applied to the idea I was 
talking about earlier while keeping a fairly consistant syntax:
mesh {
    tesselate {OBJECT, etc...}
    tesselate {OBJECT2, etc...}
}

BTW, do you think there is a need for more insideness-testing methods? 
Not all meshes will work perfectly with a single test, sending 3 rays at 
right angles(or more rays in various directions) would work better in 
some cases. However, it would be slower, and in some cases the 1 ray 
method would be perfectly adequate or even more useful than the "more 
reliable" method. For example, if you have a sheet-like mesh that you 
want everything "under" to be "inside", something like a height field.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <3a382eaf@news.povray.org>, "Tony[B]" 
<ben### [at] panamac-comnet> wrote:

> Can you make a patch for reading directly from 3DS and other file 
> formats directly? :)

That's a bit different from tesselating an object... :-)
A similar syntax could be used, though...especially if you ignore 
texturing information and only read geometry:
model_file {
    FORMAT "filename.FORMAT"
    ...maybe stuff for resizing to fit in a specified bounding box(which 
could save much guesswork with scaling), converting from different 
"handedness"(though that could be done just as well with a 
transformation), etc...also maybe a way to extract specific parts of 
files containing multiple models...
    ...usual modifiers and options...
}

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Reading all this with interest, don't understand all of it, so if I write 
nonsense, say so and I'll shut up.

Chris Huff wrote:
>BTW, do you think there is a need for more insideness-testing methods? 
>Not all meshes will work perfectly with a single test, sending 3 rays at 
>right angles(or more rays in various directions) would work better in 
>some cases.

When you tesselate a mesh from a declared object, can't you use this 
object to get the insideness information (all intersections?) from and 
apply it to the mesh?

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

In article <Xns### [at] povrayorg>, ing### [at] homenl (ingo) 
wrote:

> When you tesselate a mesh from a declared object, can't you use this 
> object to get the insideness information (all intersections?) from and 
> apply it to the mesh?

I vaguely remember this coming up in some earlier discussions about 
tesselating objects, but it apparently was forgotten, since nobody until 
now has actually done any work on a tesselation patch. You are right, it 
should work perfectly well for most purposes.
That could be a third insideness testing method...
Maybe an "insideness_method" keyword...

type 0:
insideness_method 0, DIRECTION
Fire a ray in DIRECTION, count intersections to determine insideness.

type 1:
insideness_method 1, DIRECTION_A, DIRECTION_B, DIRECTION_C, 
bidirectional BOOLEAN
Same as type 0, but performs three tests and returns the result of 2 or 
more. Avoids some problems with the first method, but slower and method 
0 would be useful for some things, like meshes that have "interiors" 
extending infinitely in one direction.
The sample directions would default to x, y, and z. If you specify only 
DIRECTION_A, the others are automatically calculated to be perpendicular 
to the given vector. If you only specify DIRECTION_A and DIRECTION_B, 
DIRECTION_C is automatically calculated to be perpendicular to those two.
The "bidirectional" keyword takes a boolean value that tells POV whether 
or not to sample in the opposite directions as well as the given 
directions. If it is true, yes, on, or 1, and you specify x, y, and z, 
it will send sample rays in x, y, z, -x, -y, and -z. It would default to 
"off", of course.

type 2:
insideness_method 2, OBJECT
Takes an object to use for insideness checks, the object could be 
declared or specified directly. Meshes generated with the "tesselate" 
feature could use this by default, unless something else is specified.


BTW, another thing about the tesselation patch: it could be very useful 
for the proximity patch, because it could use a proximity calculation 
optimized for meshes on any kind of object. Most objects wouldn't even 
need a high-res mesh, just something to give the general shape.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: BTW, do you think there is a need for more insideness-testing methods? 

  You'll have to ask Nathan. I don't know anything about the inside_vector
thing. I just copied the inside_vector reading code from his patch.

  Thinking about it, perhaps it could be better to put the tesselation
inside the mesh block as you suggest. The tesselation routine would just
add the triangles to the mesh.
  This way it would be possible to make everything you can make to a mesh
without having to copy any code.
  It would also allow tesselating several objects into one mesh and even
add individual triangles to it.

  I'm liking your idea. It shouldn't be extremely difficult to implement
either.

  Perhaps something like:

mesh
{ triangle { ... }
  smooth_triangle { ... }
  tesselate
  { OBJECT
    [accuracy VECTOR]
    [smooth]
    [offset FLOAT]
  }
  OBJECT_MODIFIERS
}

  Thinking about it, it wouldn't be difficult at all to implement that.
Instead of expecting a 'tesselate' keyword at general level it's enough
to expect it inside Parse_Mesh().

  Btw, the tesselation code has some strange bug right now which I'm unable
to find. Damn it.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Jim Kress <kre### [at] kressworkscom> wrote:
: What tessellation method did you use?

  I'm sampling tetrahedrons thorough the entire bounding box volume.

  Perhaps I'll look at the marching triangles algorithm (if it's different
from that, I don't know) to see if it may give a better result.
  Any URLs?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Didn't remember that I would have to implement it in both the mesh and
the mesh2 blocks...
  The mesh2 may be a more difficult beast...

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 15 Dec 2000 06:41:00 -0500, Warp <war### [at] tagpovrayorg> wrote:


>  I'm sampling tetrahedrons thorough the entire bounding box volume.
>
>  Perhaps I'll look at the marching triangles algorithm (if it's different
>from that, I don't know) to see if it may give a better result.
>  Any URLs?

http://www.ee/surrey.ac.uk/Research/VSSP/3DVision/mt.html

Post a reply to this message

In article <3a3a03c0@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Didn't remember that I would have to implement it in both the mesh and
> the mesh2 blocks...
>   The mesh2 may be a more difficult beast...

I don't think it would be necessary for the mesh2 object...as I 
understand it, mesh2 is designed to make it easier for programs to 
output in POV-readable format, not for hand coding, which is what 
tesselation of primitives will be used for. So "mesh" will be the 
hand-coding type, and "mesh2" will be the computer-generated type.
If you want to use the two together, something like this should be 
allowed, allowing meshes, mesh2s, and maybe other shapes(height fields, 
bicubic_patches...) and their identifiers to be added to mesh objects:

#declare Mesh2Ident = mesh2 {...}

mesh {
    Mesh2Ident
    mesh2 {...}
    mesh {...}
}

You won't even have to use a special syntax for this if your tesselation 
patch automatically detects whether an object is already tesselated, and 
copies that data (or a reference to it) instead of using your own 
tesselation algorithm.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Jerry Anning wrote:

> http://www.ee/surrey.ac.uk/Research/VSSP/3DVision/mt.html

404?

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

Try this one:

http://graphics.cs.uiuc.edu/~garland/software/qslim.html

I've used his method.  It is quite fast and works quite well.

Jim


"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a3a034c@news.povray.org...
> Jim Kress <kre### [at] kressworkscom> wrote:
> : What tessellation method did you use?
>
>   I'm sampling tetrahedrons thorough the entire bounding box volume.
>
>   Perhaps I'll look at the marching triangles algorithm (if it's different
> from that, I don't know) to see if it may give a better result.
>   Any URLs?
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On Fri, 15 Dec 2000 16:16:04 -0600, David Fontaine <dav### [at] faricynet>
wrote:

>Jerry Anning wrote:
>
>> http://www.ee/surrey.ac.uk/Research/VSSP/3DVision/mt.html
>
>404?

http://www.ee.surrey.ac.uk/Research/VSSP/3DVision/mt.html

typos are irritating.

Post a reply to this message

Chris Huff wrote:

>Takes an object to use for insideness checks, the object could be 
>declared or specified directly. Meshes generated with the "tesselate" 
>feature could use this by default, unless something else is specified.
>

To prevent confusion, the default should be the same as the current mesh. 
Also you do not always want a mesh to be solid.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

> That's a bit different from tesselating an object... :-)

Duh... :)

> A similar syntax could be used, though...especially if you ignore
> texturing information and only read geometry:

<snip> Yes, geometry is the only thing I really care about. That syntax
sounds OK. I would love to be able to use these files directly without
worrying about translating them to POV meshes. With the ability to read in
the files we could write macros to export to PCM all within POV... anyway, I
can dream, can't I? :)

Post a reply to this message

Warp wrote:

> Jim Kress <kre### [at] kressworkscom> wrote:
> : What tessellation method did you use?
> I'm sampling tetrahedrons thorough the entire bounding box volume.

What about specific methods for different types of objects?
--
Bye
Pabs

Post a reply to this message

In article <3A3D7A81.62AE0E08@nospamthanx.hotmail.com>, Pabs 
<pab### [at] nospamthanxhotmailcom> wrote:

> What about specific methods for different types of objects?

I agree, it would be nice if a sphere could use a geodesic tesselation, 
a cube could be done with 12 triangles, etc...the sampling method could 
be used for each object until a method specific to it is implemented.
This is the approach I have been planning with the proximity 
pattern...however, I might make a slight adjustment to my plans: 
tesselate the object and measure proximity to the resulting mesh instead 
of sending dozens of rays. The tesselation patch could also be useful in 
the glow patch, which will require information about the proximity of a 
ray to the object...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> I agree, it would be nice if a sphere could use a geodesic tesselation,
> a cube could be done with 12 triangles, etc...

But that would not work for CSG.  You would either have to calculate the
boundary lines between the different parts or calculate the CSG of
different solid meshes separately.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3A3E49C1.2B818210@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> Chris Huff wrote:
> > 
> > I agree, it would be nice if a sphere could use a geodesic tesselation,
> > a cube could be done with 12 triangles, etc...
> 
> But that would not work for CSG.  You would either have to calculate the
> boundary lines between the different parts or calculate the CSG of
> different solid meshes separately.

It would work perfectly fine for CSG...because they are a separate type 
of object, they will just use the marching tetrahedrons method (or some 
other sampling method) until someone implements something better 
specifically for them. The whole idea is that you don't have to write a 
specialized method for every object at once, you can do it for a few 
objects at a time.

Someone could eventually go through the trouble to implement the code 
for CSG on meshes, and tesselate the objects individually and combine 
them together. Unions, for example, would be very easy, just put the 
meshes of each object together into one big mesh, you don't have to 
worry about boundary lines.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
:> What about specific methods for different types of objects?

: I agree, it would be nice if a sphere could use a geodesic tesselation, 
: a cube could be done with 12 triangles, etc...

  I can do that, but I want to get the basic tesselation to work first.
I still can't find the bug. It's making me crazy. I really don't know what
is causing it.
  I'm tempted to just give up.

  This is a very simple test scene where the bug shows up:

--------8<--------8<--------8<--------8<--------8<--------8<--------8<------
#declare YOffs = 0;

background { rgb z*.5 }
#default { pigment { rgb <1,.8,.6> } finish { specular .5 } }

#declare Obj = sphere { -y*YOffs,1 }
tesselate
{ Obj
  accuracy 10
  translate y*YOffs
}

camera { location <0,4,-13>*1.1 look_at y*.6 angle 35/10 }
light_source { <200,100,-150>, 1 }
light_source { <-200,100,-100>, x*.5 }
--------8<--------8<--------8<--------8<--------8<--------8<--------8<------

  With YOffs 0 there's no bug:
http://www.cs.tut.fi/~warp/tess/tessbug1.jpg

  With YOffs 4 the bug shows up:
http://www.cs.tut.fi/~warp/tess/tessbug2.jpg

  With YOffs 8 more bugs show up:
http://www.cs.tut.fi/~warp/tess/tessbug3.jpg


  The odd thing is that the location of the sphere shouldn't matter. Only
the size of the bounding box should have any effect on the algorithm, not
the location, and it's only the location which changes in the examples
above.
  I just don't know what to do anymore.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <3a3f270f@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   I can do that, but I want to get the basic tesselation to work first.
> I still can't find the bug. It's making me crazy. I really don't know 
> what is causing it.

Send me the code and I will look at it...though I'm not too hopeful, 
since I have never done anything with this sort of tesselation...


>   I'm tempted to just give up.

Noooo! Don't even talk like that... ;-)


>   The odd thing is that the location of the sphere shouldn't matter. Only
> the size of the bounding box should have any effect on the algorithm, not
> the location, and it's only the location which changes in the examples
> above.
>   I just don't know what to do anymore.

Does it show up if you don't translate the tesselated sphere back in 
position? Are all your calculations relative to the bounding box and not 
to the origin?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Send me the code and I will look at it...though I'm not too hopeful, 
: since I have never done anything with this sort of tesselation...

  Let me look at the code just once again. If I can't figure out anything,
I'll send it to you.

: Does it show up if you don't translate the tesselated sphere back in 
: position?

  Yes.

: Are all your calculations relative to the bounding box and not 
: to the origin?

  The calculations always take the geometry of the bounding box. It
shouldn't matter what is the location of the bounding box.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message