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