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