I recall trying to tesselate BlobMan objects and the bug showing up there.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Warp wrote:
> 
>   I recall trying to tesselate BlobMan objects and the bug showing up there.
> 

Any specific scene ?
I cannot try every values for the blobman parameters...,
I'm not immortal yet...

Post a reply to this message

Oo - can't wait!

BTW which version does it run on? 3.1, 3.5, Megapov .6, .7 ?

- Nekar


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.282 / Virus Database: 150 - Release Date: 2001/09/25

Post a reply to this message

Christoph Hormann wrote:
> 

> >
> > So, does anyone have some bogus generated mesh that I could try ?
> > (Possibly only with object from 3.1, because I have not Megapov installed,
> > so no isosurface, please).

> I don't have any specific object here you should try, but i think some
> CSG's,  blobs and text objects would be good examples to test.

I have done some tests with blobs already, but maybe not the Bogus blobs...
I have also my own set of test objects... BUT...
Given the fact that the initial bogus (sphere) only appeared when 
moving the sphere, I may very well miss a bogus case that someone
already know about. So, I would like to perform a kind of private beta
(with scene from other people, even if I'm not yet ready to publish
the correction
[before that, I need to gain confidence with my analysis 
of the cause of the problem {I'm nearly OK for the theory, and so far the 
scenes I tested where fine, but know problem scenes are the better}]

Thanks for the suggestion of ttf ! I missed that basic one, as well as CSG
(I played with torus, superellipsoid, cylinder and so on, but still missed the
basic CSG and ttf one! I would better reopen the pov manual and check with 
each finite solid primitive...

Post a reply to this message

Nekar Xenos wrote:
> 
> Oo - can't wait!

You will have to. At least a little.
(Anyway, for this weekend, you should have the next 3.5 beta to install,
 or otherwise it will be expired for everybody, 
so you will have something to do.)

> 
> BTW which version does it run on? 3.1, 3.5, Megapov .6, .7 ?
>

Currently, only MY personnal 3.1 derivative... on Linux. The patch code is 
not in a publishable state. But you will have the explanation sooner than the
code IF it is really the cause that I have isolated.

Maybe someone incorporated the initial patch of Warp (which was for
Megapov [UV mapping was required]) in a variant of Megapov ?

Post a reply to this message

news:3BBDD3B6.E11BF559@atosorigin.com...
> Nekar Xenos wrote:
> >
> > Oo - can't wait!
>
> You will have to. At least a little.
> (Anyway, for this weekend, you should have the next 3.5 beta to install,
>  or otherwise it will be expired for everybody,
> so you will have something to do.)
>
> >
> > BTW which version does it run on? 3.1, 3.5, Megapov .6, .7 ?
> >
>
> Currently, only MY personnal 3.1 derivative... on Linux. The patch code is
> not in a publishable state. But you will have the explanation sooner than the
> code IF it is really the cause that I have isolated.
>
Will it work on Windoze?

- Nekar


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.282 / Virus Database: 150 - Release Date: 2001/09/25

Post a reply to this message

Nekar Xenos wrote:
> Will it work on Windoze?
> 
Of course, when someone with the ZinZin compilation system will have
 incorporated it in whatever (Mega)Pov version.
There is no Linux dependancy, It's just that I only have the compiler for Linux.

Pov is portable. Pov is great.

Post a reply to this message

I look forward to seeing this patch working and integrated into the next
incarnation of megapov based on the 3.5 code as I belive it to be
potentially one of the most useful additions to Pov. So good luck, fingers
crossed.

Mick

Post a reply to this message

What Mick said... I'm dying to know if it was some little oversight, or some
bigger problem causing the buggy meshes.

Post a reply to this message

"Tony[B]" wrote:
> 
> What Mick said... I'm dying to know if it was some little oversight, or some
> bigger problem causing the buggy meshes.

Ok, Take a deep breath now and everybody try to relax.

Here come the reason for the bug of the moving sphere... 

I would say it's a design assumption which turns out to be wrong, sometimes:
The Inside test and the trace test may disagree; 
They should not, but they do in some occurences.

The decision to add a triangle is determined by the value of Inside
at each vertex of the Tetrahedron. 
The triangle vertices are determined by the trace test between an outside/inside pair
of vertices. 
Alas, the code assumes that if one vertex is outside, and the other one is inside,
then Intersection() will always gives a valid result. 

If you really want to have fun (NOT), Try YOffs=3.5 in the sphere scene.
(Expect a Segmentation Fault, at render time, at least on my system!).


I successfully removed that bug by testing the Intersection() return 
in CalcIntersection().
I had to choose a "good" answer when Intersect failed. I choose the middle
of the segment, but there is maybe a better values ?

Here some code, for those that want to try it: 

        if (Intersection(&tess_intersect, info->Object, &tess_Ray))
        {
        Assign_Vector(info->Intersection[outs][ins][0], tess_intersect.IPoint);
        if(Smooth)
            Normal(info->Intersection[outs][ins][1],
                   tess_intersect.Object, &tess_intersect);
       }
       else
       { /* Cheating */
       Assign_Vector(info->Intersection[outs][ins][0], info->Coord[ins]);
       VScaleEq(Dir,-1/2);
       VAddEq(info->Intersection[outs][ins][0],Dir);
         if (Smooth)
           {
              VNormalizeEq(Dir);
              Assign_Vector(info->Intersection[outs][ins][1],Dir);
           }
       
       }

If you do not believe me, the demonstration of the bug is left as an exercice
to the reader.

Last point, Because good news always comes with bad news, my test with the torus
gives strange results... Still another bug, but maybe not at the same place.
Other objects seems to have survived the tesselation.

Post a reply to this message