 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmx de> wrote:
: error: Can't tesselate object. (Perhaps too low accuracy?)
: *after* running tesselation.
Well, it can't report that before trying, can it?-)
It first tries to tesselate and after that, if no triangles has been
created, it reports that it couldn't do it.
Sometimes this is due to a too low accuracy (there are too few
tetrahedrons and no vertex points hit the inside of the object). This
is, I think, so rare, however, than perhaps I should just modify the
error message (I think that usually the reason is something else, like
the object not being solid).
Btw, is it possible to check whether an object is solid and it has a
finite bounding box? (It would be good to check these things before trying
to tesselate anything.)
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Well, it can't report that before trying, can it?-)
>
> It first tries to tesselate and after that, if no triangles has been
> created, it reports that it couldn't do it.
> Sometimes this is due to a too low accuracy (there are too few
> tetrahedrons and no vertex points hit the inside of the object). This
> is, I think, so rare, however, than perhaps I should just modify the
> error message (I think that usually the reason is something else, like
> the object not being solid).
>
Sound reasonable,
I also found that the object pattern functions with method 2 so
Inside_Object() seems to work - There is also probably no difference
beween method 1 and method 2 concerning this function, because it is just
evaluating the isosurface function at that point.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
[posted & emailed]
Warp wrote:
>
> http://www.cs.tut.fi/~warp/TesselationPatch/
>
I get it working with a 3.1g like. (Just had to remove the Uv_mapping code,
and correctly set the Number_Of_Textures in the Data structure when
used as an object {in tesselat.c} so as to avoid a Segmentation Fault
when freeing the scene, after the render).
While I was at it, I look for the bug...
I have a good news and a bad news (IMO):
Good news: I made the bug disappeared by modifying the
Tesselate_Object function so that :
DBL CoordZ1 = Min[Z] + IndZ*Size[Z]/ZAccuracy;
DBL CoordZ2 = Min[Z] + (IndZ+1)*Size[Z]/ZAccuracy;
is now
DBL CoordZ1 = Min[Z] + (IndZ-0.001)*Size[Z]/ZAccuracy;
DBL CoordZ2 = Min[Z] + (IndZ+1.001)*Size[Z]/ZAccuracy;
(And so on for the other coordinates over X and Y).
Bad news: this modification request that you remove the
optimisation that reused the intersection from the previous
round... because now the cubes are not contiguous, but slightly
overlapping.
As a side effect, the joint between triangles is now less visible.
Personnal comment : I do not understand why Warp decided to
split the cube in 6 tetrahedrons (Ok, I know that this
scheme make them to have the same volume, but the original
splitting seems to have a bias toward one diagonal of the cube,
which has a visual effect)
So I tried to use a split into five tetrahedrons
(four corner and one central (twice the volume of the corner))
and I found it to work quicker and yet to provide a better
visual (well, personnal opinion anyway (moreover, I'm biased...))
P.S.: When I said that I made the bug disappears, It was at least
for the provided bug demonstration scene. More testing is
probably needed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
: Good news: I made the bug disappeared by modifying the
: Tesselate_Object function so that :
: DBL CoordZ1 = Min[Z] + IndZ*Size[Z]/ZAccuracy;
: DBL CoordZ2 = Min[Z] + (IndZ+1)*Size[Z]/ZAccuracy;
: is now
: DBL CoordZ1 = Min[Z] + (IndZ-0.001)*Size[Z]/ZAccuracy;
: DBL CoordZ2 = Min[Z] + (IndZ+1.001)*Size[Z]/ZAccuracy;
: (And so on for the other coordinates over X and Y).
I'm not happy with this kind of "kludge". I want to know why the problem
happens and why that "solution" seems to correct it, and when I know it,
I want to apply the correct solution at the correct place.
I don't think that those modifications are answer.
: Bad news: this modification request that you remove the
: optimisation that reused the intersection from the previous
: round... because now the cubes are not contiguous, but slightly
: overlapping.
That's exactly why I don't like that solution at all. Slightly overlapping
boxes mean slightly overlapping triangles, which don't share vertices
(but probably cut each other or can even leave tiny gaps).
I suppose that the solution may have to be implemented in the intersection
calculation part and/or the insideness test.
The most important thing, however, is to understand why the problem happens.
: So I tried to use a split into five tetrahedrons
: (four corner and one central (twice the volume of the corner))
: and I found it to work quicker and yet to provide a better
: visual (well, personnal opinion anyway (moreover, I'm biased...))
This might be a good idea. Thanks.
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
>> I'm not happy with this kind of "kludge". I want to know why the problem
> happens and why that "solution" seems to correct it, and when I know it,
> I want to apply the correct solution at the correct place.
> I don't think that those modifications are answer.
>
Well, I'm not happy with it either.
The more I play with the original code, the more it looks like
a design problem related to the well-known coincident surface
trouble: bogus happen when one vertex is ON the object.
Let me explain: the code use the Inside_ functions to know if a
point of a cubic net is either inside or outside the object.
The fact is that it miss a subtlety : a point can be outside, inside
or on the surface.
As later an intersection is only searched between an outside and an inside
vertex, It happens that a point which is EXACTLY ON the surface
is tagged as OUTSIDE (at least for spheres.c, and we do not want to
change this, do we ?).
May be a change in the search for intersection can help:
remove outside/insde optimisation, always search for the intersection
and keep it only if it is between the two vertex.
If this solution works, it provides a bonus: you could tesselate ALL
objects (even the flat disk!).
You would then keep the external optimisation (but loose the
inside/outside one, thus casting far more rays).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> May be a change in the search for intersection can help:
> remove outside/insde optimisation, always search for the intersection
> and keep it only if it is between the two vertex.
> If this solution works, it provides a bonus: you could tesselate ALL
> objects (even the flat disk!).
> You would then keep the external optimisation (but loose the
> inside/outside one, thus casting far more rays).
Been there, done that, seems to work, code currently submitted back to Warp
for comments and whatever he wants...
I need to do more tests too...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
: bogus happen when one vertex is ON the object.
I really don't understand why this would be any problem.
If a vertex is exactly on the surface of the object, it will be considered
either inside or outside (depending on the inside testing function for that
specific object). This shouldn't be a problem. There isn't any third mode
which isn't either inside or outside. The point is either inside or it is
outside.
An adjacent tetrahedron shares the same point and the same insideness of
that point. It's not like that point was inside for one tetrahedron and
outside for the adjacent tetrahedron sharing the same point. I can't believe
that the insideness test for any object would give different results for
the _exact_ same point in different calls.
: Let me explain: the code use the Inside_ functions to know if a
: point of a cubic net is either inside or outside the object.
: The fact is that it miss a subtlety : a point can be outside, inside
: or on the surface.
No, there aren't three modes, just two. A point is either inside or outside.
The function doesn't return three values, just two. A point that is exactly
on the surface of the object will be considered one of the two, so I don't
understand why it should matter.
: As later an intersection is only searched between an outside and an inside
: vertex, It happens that a point which is EXACTLY ON the surface
: is tagged as OUTSIDE (at least for spheres.c, and we do not want to
: change this, do we ?).
Yes, but for an adjacent tetrahedron the same vertex will give also "outside"
while another vertex will give "inside" and the trace will be performed.
I don't understand how a part of the surface can be missed even if a vertex
of a tetrahedron is exactly on the surface of the object.
This would make sense if the insideness test function would return different
values for the exact same point in different calls. However, I can't understand
why it would do that. That would require some really, really odd implementation
(like using rand() or something).
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> http://www.cs.tut.fi/~warp/TesselationPatch/
This may be the solution I'm looking for. Has anyone compiled this for Win
platforms that I can get it? I could go and compile Megapov myself, but I'm
lazy.
Right now, I'm trying to create a mesh of an object's surface, but only when
viewed from a certain angle (the triangles that would be visible using an
orthographic camera). I figure I can use the tesselation patch and
only keep those triangles that have normals pointing in that direction (or
partially in that direction). Is there a better way than that?
Anyway, does anyone have the binary files available for me to play with?
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Geoff Wedig wrote:
>
> This may be the solution I'm looking for. Has anyone compiled this for Win
> platforms that I can get it? I could go and compile Megapov myself, but I'm
> lazy.
>
> Right now, I'm trying to create a mesh of an object's surface, but only when
> viewed from a certain angle (the triangles that would be visible using an
> orthographic camera). I figure I can use the tesselation patch and
> only keep those triangles that have normals pointing in that direction (or
> partially in that direction). Is there a better way than that?
Yes, use the megapov 'depth' post processing function and use the
resulting file as a heightfield.
> Anyway, does anyone have the binary files available for me to play with?
>
I compiled it with cygwin, but i did not put it on my website, if you
really want it i can send it.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> Geoff Wedig wrote:
>>
>> This may be the solution I'm looking for. Has anyone compiled this for Win
>> platforms that I can get it? I could go and compile Megapov myself, but I'm
>> lazy.
>>
>> Right now, I'm trying to create a mesh of an object's surface, but only when
>> viewed from a certain angle (the triangles that would be visible using an
>> orthographic camera). I figure I can use the tesselation patch and
>> only keep those triangles that have normals pointing in that direction (or
>> partially in that direction). Is there a better way than that?
> Yes, use the megapov 'depth' post processing function and use the
> resulting file as a heightfield.
Since I'm doing this for *lots* of objects, in a single scene, that's not a
viable solution. Far too many height fields, and too much work to generate
lots of images and trying to get them all back where they're supposed to in
the final image.
I currently have a macro that drops points into the object in a grid and
produces a mesh that way, but for a variety of reasons, I find it to be
inadequate (not the least of which it's *very* slow)
>> Anyway, does anyone have the binary files available for me to play with?
> I compiled it with cygwin, but i did not put it on my website, if you
> really want it i can send it.
Yes, I'd like that. Be very useful to compare, even if it does drop the
occasional triangle.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
