POV-Ray : Newsgroups : povray.unofficial.patches : MegaPOV 0.6a 'transform id' bug Server Time
1 Sep 2024 18:12:42 EDT (-0400)
  MegaPOV 0.6a 'transform id' bug (Message 1 to 6 of 6)  
From: Nicolas Calimet
Subject: MegaPOV 0.6a 'transform id' bug
Date: 29 Nov 2000 06:09:26
Message: <3A24F503.5EF569B1@free.fr>
Hi,

	I previously [2000-06-26] reported the same bug for version 0.5a
that was crashing MegaPOV on some architectures under UNIX, but not others.
The same thing is still here in version 0.6a - actually I'm using the linux

	Try rendering the simple scene below, alternatively commenting one
of the two boxes. The problem arrises from the 'transform cube_t' which
seems to be still buggy due to the Compose_Transforms() function under
CASE(TRANSFORM_TOKEN) in parse.c; may use an unassigned pointer.


//-----------------------------------------------------------------
#version unofficial MegaPOV 0.5;

camera{ right x*4/3  up y  angle 40  location -z*50  look_at  0 }
light_source{ -z*50  rgb 0.66 }
light_source{ -z*50  rgb 1.0  rotate<45,-25,0> }
plane{ y, -5  pigment{checker rgb 1,rgb 0.7  scale 5} }
fog{ rgb 1  distance 200  fog_type 2  fog_offset -2  fog_alt 10 }

#declare cube_t = transform{
  translate<-5,-5,-5>
  rotate x*20
  rotate y*20
}

box{
  <0,0,0><10,10,10>  pigment{ rgb<1,0,0> }
  transform cube_t
}

box{
  <0,0,0><10,10,10>  pigment{ rgb<0,1,0> }
  transform cube_t
  translate x*5
}
//------------------------------------------------------------------


*** Nicolas Calimet
*** http://pov4grasp.free.fr


Post a reply to this message

From: Nicolas Calimet
Subject: Re: MegaPOV 0.6a 'transform id' bug
Date: 29 Nov 2000 06:13:54
Message: <3A24F611.9C539220@free.fr>
> #version unofficial MegaPOV 0.5;

	Well it should be 'MegaPOV 0.6' but there's no difference...
	Can anyone tells if this also append under Win/MacOS/others ?


*** Nicolas Calimet
*** http://pov4grasp.free.fr


Post a reply to this message

From: Jérôme M  Berger
Subject: Re: MegaPOV 0.6a 'transform id' bug
Date: 29 Nov 2000 06:29:28
Message: <3A24E897.8AF9FBA@enst.fr>
Nicolas Calimet wrote:
> 
>         Hi,
> 
>         I previously [2000-06-26] reported the same bug for version 0.5a
> that was crashing MegaPOV on some architectures under UNIX, but not others.
> The same thing is still here in version 0.6a - actually I'm using the linux

	mpov-0.6.1 is based on megapov 0.6. I just tried with mpov-0.6.2 which
is based on 0.6a and didn't see any problem (linux mandrake 7.1 using
the binary that's available from my site)


-- 

* Abandon the search for truth, * mailto:ber### [at] inamecom
* Settle for a good fantasy.    * http://www.enst.fr/~jberger
*********************************


Post a reply to this message

From: Nicolas Calimet
Subject: Re: MegaPOV 0.6a 'transform id' bug
Date: 29 Nov 2000 07:07:51
Message: <3A2502B8.46C0348B@free.fr>
>         mpov-0.6.1 is based on megapov 0.6. I just tried with mpov-0.6.2 which
> is based on 0.6a

	Gosh ! The hell with me !! ;-)
	I don't know why I didn't downloaded your mpov update just after Nathan
announced version 0.6a... I unfortunately assumed that mpov-0.6.1 was already
based on the 0.6a sources ('m completely blind man).
	Okay, so there's actually no bug anymore...
	Sorry for bothering with good-old-damn-buggy code, and forget my posts !


*** Nicolas Calimet
*** http://pov4grasp.free.fr


Post a reply to this message

From: Nicolas Calimet
Subject: It's unfortunately still there...
Date: 29 Nov 2000 10:36:16
Message: <3A25338B.1D334A06@free.fr>
Sorry, but when again trying on a Digital Alpha architecture,
my cube example above crashes with floating exception. This is for
mpov-0.6.2 which is based on MegaPOV 0.6a.

        Looking back into the source, the infamous Compose_Transform()
with an unassigned &Local_Trans is still there. It does not crash
Linux and SGI, but does for DEC. I cannot test other architectures,
including, in particular, Win or MacOS (maybe could with SunOS).

        The weird image I obtained previously with the mpov-0.6.1 code
has been solved by another portion of code in parse.c; using a 'diff'
on files of the two distro, mpov-0.6.2/parse.c has some change from
the lines 9004 to 9007 in Parse_Transform() function. The problem I'm
talking about is at line 1081 in Parse_Object_Mods().

        I hope this will be fixed in the next MegaPOV release, or I
will have to report it again ;-)


*** Nicolas Calimet
*** http://pov4grasp.free.fr


Post a reply to this message

From: Yvo Smellenbergh
Subject: Now it has gone away :-) [Re: It's unfortunately still there...]
Date: 29 Nov 2000 13:11:46
Message: <1ekvggb.r6n03hga00nmN%smellenbergh@skynet.be>
Nicolas Calimet <pov### [at] freefr> wrote:

>         Sorry, but when again trying on a Digital Alpha architecture,
> my cube example above crashes with floating exception. This is for
> mpov-0.6.2 which is based on MegaPOV 0.6a.
> 
>         Looking back into the source, the infamous Compose_Transform()
> with an unassigned &Local_Trans is still there. It does not crash
> Linux and SGI, but does for DEC. I cannot test other architectures,
> including, in particular, Win or MacOS (maybe could with SunOS).


> 
>         The weird image I obtained previously with the mpov-0.6.1 code
> has been solved by another portion of code in parse.c; using a 'diff'
> on files of the two distro, mpov-0.6.2/parse.c has some change from
> the lines 9004 to 9007 in Parse_Transform() function. The problem I'm
> talking about is at line 1081 in Parse_Object_Mods().

This is indeed wrong and a bug. However, it doesn't crash the Mac
either.
 
Anyway, looking at the source, it seems to me that it has been a bug
even before the TransformPatch.

>         I hope this will be fixed in the next MegaPOV release, or I
> will have to report it again ;-)
Well, I have fixed that now so if there is ever going to be a next MP it
will be fixed.
I guess I overlooked that specific problem, sorry for that!

Smellenbergh
-- 
e-mail:sme### [at] skynetbe

http://users.skynet.be/smellenbergh


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.