![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
The pigment object causes a crash when the object is a CSG construction.
Below are two scenes that allmost always crashes with type 1, 2 or 11
error (Macintosh)
Anyone having the same problems? Any fixes?
//First scene
camera {
location <0.0, 0.0, -6>
angle 60
look_at <0.0, 0.0, 0.0>
}
light_source {
<0.0, 20, -100>
rgb <1.0, 1.0, 1.0>
}
#declare TexObj =
// Point connector macro
#macro P_C_P ( Center, Radius, R, G, B, F, T, Center2, Radius2,
R2, G2, B2, F2, T2)
#local dx = Center2.x - Center.x ; #if (dx=0) #declare dx=
0.000001; #end
#local dy = Center2.y - Center.y ;
#local dz = Center2.z - Center.z ;
#local len = sqrt (dx*dx+dy*dy+dz*dz);
#local xylen = sqrt (dx*dx+dy*dy);
#local D = acos( (Radius-Radius2)/len);
< cos(D)*Radius, 0, 0>, sin(D)*Radius ,
< len + (cos(D)*Radius2), 0, 0>, sin(D)*Radius2
texture {
pigment {
gradient x
color_map { [ 0.0 1.0 rgbft < R, G, B, F, T > color
rgbft < R2, G2, B2, F2, T2 > ] }
scale <( len + (cos(D)*Radius2))-(cos(D)*Radius), 1, 1>
translate < cos(D)*Radius, 0, 0>
}
}
rotate <0, degrees(-atan2(dz, xylen)), degrees(atan2 (dy, dx))>
translate <Center.x, Center.y, Center.z>
#end
#declare C = 0;
#declare Copies = 500;
#declare S1 = -1;
union {
#while ( C < Copies)
#declare Center = <0, 0, 0>; #declare Radius = 1.0;
#declare Center2 = <0, 0, 0>; #declare Radius2 = 1.0;
sphere {
#if (((C/(250)) - floor (C/(250))) = 0) #declare
SubC1 = 0; #declare S1 = S1 * -1;#end //reverse
#declare Radius = Radius * (0.01 #if (S1<0) + ((0.1
-(0.01))/(250) * (250)) #end + (((SubC1 * (0.1 -(0.01))/(250 -1))) * S1
));
#if (((C +1)/(250) - floor ((C +1)/(250))) = 0)
#declare Radius2 = Radius;
#else
#declare Radius2 = Radius2 * (0.01 #if (S1<0) +
((0.1 -(0.01))/(250) *250) #end + ((((SubC1+1) * (0.1 -(0.01))/(250
-1))) * S1));
#end
#declare Tx = (1);
#declare Center = Center + <Tx, 0, 0>;
#declare Tx2 = (1);
#declare Center2 = Center2 + <Tx2, 0, 0>;
#declare Ty = (-5 + (C * (5 - (-5))/(Copies -1)));
#declare Center = Center + <0, Ty, 0>;
#declare Ty2 = (-5 + ((C+1) * (5 -(-5))/(Copies -1)));
#declare Center2 = Center2 + <0, Ty2, 0>;
#declare Roty = (0 + (C * (360*10 - (0))/(Copies -1)));
#declare Center = vaxis_rotate (Center, y, Roty);
#declare Roty2 = (0 + ((C+1) * (360*10 -(0))/(Copies
-1)));
#declare Center2 = vaxis_rotate (Center2, y, Roty2);
Center, Radius
#declare R = (0.000000 + (C * (0.694820
-(0.000000))/(Copies -1)));
#declare G = (0.000000 + (C * (0.694820
-(0.000000))/(Copies -1)));
#declare B = (1.000000 + (C * (0.152590
-(1.000000))/(Copies -1)));
#declare F = (0 + (C * (0 -(0))/(Copies -1)));
#declare T = (0 + (C * (0 -(0))/(Copies -1)));
texture { pigment { rgbft <R, G, B, F, T> } }
#declare R2 = (0.000000 + ((C+1) * (0.694820
-(0.000000))/(Copies -1)));
#declare G2 = (0.000000 + ((C+1) * (0.694820
-(0.000000))/(Copies -1)));
#declare B2 = (1.000000 + ((C+1) * (0.152590
-(1.000000))/(Copies -1)));
#declare F2 = (0 + ((C+1) * (0 -(0))/(Copies -1)));
#declare T2 = (0 + ((C+1) * (0 -(0))/(Copies -1)));
}
#if ((C+1) < Copies)
cone {P_C_P ( Center, Radius, R, G, B, F, T, Center2,
Radius2, R2, G2, B2, F2, T2 ) }
#declare SubC1 = SubC1+1;
#end //#if ((C+1) < Copies)
#declare C = C +1;
#end //while (C < Copies)
} //union
cylinder {
<0, -5, 0>, <0, 5, 0>, 1
pigment { object { TexObj color rgb <1, 0, 0> color <0, 1, 0> }}
}
//second scene
camera {
location <0.0, 0.0, -6>
angle 60
look_at <0.0, 0.0, 0.0>
}
light_source {
<0.0, 20, -100>
rgb <1.0, 1.0, 1.0>
}
#declare StarObj =
union {
#declare C = 0;
#declare Copies =20;
#while ( C < Copies)
prism {
linear_spline
linear_sweep
0, //Base height
2.1, //Top height
13,
<0.25419, 0.00000>,
<0.86603, 0.50000>,
<0.14121, 0.24459>,
<-0.00000, 1.00000>,
<-0.14121, 0.24459>,
<-0.86603, 0.50000>,
<-0.28243, -0.00000>,
<-0.86603, -0.50000>,
<-0.14121, -0.24459>,
<0.00000, -1.00000>,
<0.14121, -0.24459>,
<0.86603, -0.50000>,
<0.25419, 0.00000>
sturm
scale <0.3, 1, 0.3>
rotate x * (-89.5)
rotate y * (0 + (C * (360)/(Copies -1)))
} //object
#declare C = C +1;
#end //while (C < Copies)
}
sphere {
<0.0, 0.0, 0.0>, 2
pigment { object { StarObj color rgb <1, 0, 0> color <0, 1, 0> }}
}
--
e-mail:sme### [at] skynet be
http://users.skynet.be/smellenbergh
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <1e2gl0e.1hrykd4wgajkkN%smellenbergh@skynet.be>,
sme### [at] skynet be (smellenbergh) wrote:
> The pigment object causes a crash when the object is a CSG construction.
There is a bug in the object pattern, it assumes a declared object will
stay allocated through the render. The solution is to copy the object,
and set the pointer in the pattern data structure(proxObj, as I
remember)to point at that copy. Of course, the object then needs to be
destroyed when the pattern is destroyed.
The same problem should exist in the proximity pattern, I will upload
some fixed source soon.
--
Chris Huff
e-mail: chr### [at] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I posted my latest source, containing just about everything I have done,
to povray.binaries.programming. This includes slightly tested fixes for
the object and proximity pattern.(Maybe the proximity pattern will work
with height fields now, time for some more testing.)
--
Chris Huff
e-mail: chr### [at] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] yahoo com> wrote:
> I posted my latest source, containing just about everything I have done,
> to povray.binaries.programming. This includes slightly tested fixes for
> the object and proximity pattern.(Maybe the proximity pattern will work
> with height fields now, time for some more testing.)
Hi Chris,
We tested the two scenes with your updated sources.
There is improvement. It doesn't crash as often. Rendering one of the
scenes over and over seems ok now. But rendering the two scenes
alternating freezes the computer.
Could you have another look at it? This patch has potential!
BTW, do you have any recent example scenes (complete ) for the proximity
patch?
Smellenbergh
--
e-mail:sme### [at] skynet be
http://users.skynet.be/smellenbergh
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <1e2if1h.153on6f1bsrqniN%smellenbergh@skynet.be>,
sme### [at] skynet be (smellenbergh) wrote:
> We tested the two scenes with your updated sources.
> There is improvement. It doesn't crash as often. Rendering one of the
> scenes over and over seems ok now. But rendering the two scenes
> alternating freezes the computer.
>
> Could you have another look at it? This patch has potential!
Strange, very strange...those patches only affected the pattern data
structure, there isn't anything going across renders. The only thing I
did that might need to be reinitialized for each render would be the
z-buffer patch, but that definitely shouldn't cause a crash.
I added code to copy the object to proxObject, and code to copy the
object when a pattern was copied, and code to destroy the object. I
probably goofed in one of the last two, I will try to reproduce the
crash.
BTW, are you using media with these patterns? Although media probably
isn't the culprit...
> BTW, do you have any recent example scenes (complete ) for the proximity
> patch?
No, but I can make a few quick ones.
--
Chris Huff
e-mail: chr### [at] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <1e2if1h.153on6f1bsrqniN%smellenbergh@skynet.be>,
sme### [at] skynet be (smellenbergh) wrote:
> We tested the two scenes with your updated sources.
> There is improvement. It doesn't crash as often. Rendering one of the
> scenes over and over seems ok now. But rendering the two scenes
> alternating freezes the computer.
I was unable to reproduce this. I rendered the first one(320*240, no AA)
then rendered the second, and repeated this, but nothing goes wrong.
Are you using just the sources I uploaded, or are you adding them to
your version? If you are adding them to your version, make sure add the
code which copies and destroys proxObj.
Hmn, I don't think this should be a problem, but to destroy the object,
I used this:
if(Tpat->proxObject != NULL)
{
Destroy_Object((OBJECT *)Tpat->proxObject);
POV_FREE ((OBJECT *)Tpat->proxObject);
}
Is the call to POV_FREE necessary? I don't think it is.
I had copied it from Destroy_CSG, and interpreted it as destroying the
pieces of the object, but not freeing the actual object. Now that I look
at it more closely, this seems likely to be the problem. Try deleting
the line
POV_FREE ((OBJECT *)Tpat->proxObject);
and see if that fixes it.
--
Chris Huff
e-mail: chr### [at] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Thorsten Froehlich
Subject: Re: Bug in pigment object (Chris Huff's patch)
Date: 9 Dec 1999 10:50:09
Message: <384fcfb1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <chrishuff_99-5D09DB.16383508121999@news.povray.org> , Chris Huff
<chr### [at] yahoo com> wrote:
> Strange, very strange...those patches only affected the pattern data
> structure, there isn't anything going across renders. The only thing I
> did that might need to be reinitialized for each render would be the
> z-buffer patch, but that definitely shouldn't cause a crash.
Chris, maybe these tips help :-)
Not reproducible crashes, especially on the Mac are most likely caused by
invalid pointers or other out of range addressing. As the Mac OS does not
have full memory protection (yet) these bugs are hard to catch. However,
there are several (free) tricks you can use:
- Use the MacsBug "hs" command to turn on/off heap scrambling.
- When you free memory a pointer points to, set the pointer to NULL.
- Init all pointers and data structures you use to NULL before using them
(even if it looks stupid, i.e. code _should_ always put something into a
pointer).
In general, you should then see either hard crashes (mostly with "hs" on) or
memory access faults when your program tries to write to memory locations
around 0 which are protected by the system. You will also see failing free
calls if the pointers are set to NULL and somewhere code tries to free that
memory again.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <384fcfb1@news.povray.org>, "Thorsten Froehlich"
<tho### [at] trf de> wrote:
> Not reproducible crashes, especially on the Mac are most likely caused by
> invalid pointers or other out of range addressing. As the Mac OS does not
> have full memory protection (yet) these bugs are hard to catch.
Yes, I understand that.
> - Use the MacsBug "hs" command to turn on/off heap scrambling.
What exactly is heap scrambling? I know of this command, but I don't
know what it does.
Also, do you know of a good reference to MacsBug which is available
online?
> - When you free memory a pointer points to, set the pointer to NULL.
> - Init all pointers and data structures you use to NULL before using them
> (even if it looks stupid, i.e. code _should_ always put something into a
> pointer).
Well, I normally do this, but this is happening just before the data
structure containing those pointers is destroyed, and those pointers are
not used after their targets are destroyed. That was the first thing I
looked at, though.
> In general, you should then see either hard crashes (mostly with "hs" on)
> or memory access faults when your program tries to write to memory locations
> around 0 which are protected by the system. You will also see failing
> free calls if the pointers are set to NULL and somewhere code tries to free
> that memory again.
Well, I think the problem was basically that a function was destroying a
data structure which I thought I had to destroy separately. Setting the
pointer to NULL after the call to the first one wouldn't have made sense
had that been the case, because the first thing I did after that call
was use POV_FREE on that pointer.
Thanks for the advice, I will be more careful about pointers in the
future.
--
Chris Huff
e-mail: chr### [at] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] yahoo com> wrote:
[...]
>
> I was unable to reproduce this. I rendered the first one(320*240, no AA)
> then rendered the second, and repeated this, but nothing goes wrong.
> Are you using just the sources I uploaded, or are you adding them to
> your version? If you are adding them to your version, make sure add the
> code which copies and destroys proxObj.
We use our GUI but we start with clean sources 3.1g without any
modifications. We throw your sources in the source folder and then
compile.
There is no media, we use the two sources at the start of this chain.
> Hmn, I don't think this should be a problem, but to destroy the object,
> I used this:
> if(Tpat->proxObject != NULL)
> {
> Destroy_Object((OBJECT *)Tpat->proxObject);
> POV_FREE ((OBJECT *)Tpat->proxObject);
> }
> Is the call to POV_FREE necessary? I don't think it is.
> I had copied it from Destroy_CSG, and interpreted it as destroying the
> pieces of the object, but not freeing the actual object. Now that I look
> at it more closely, this seems likely to be the problem. Try deleting
> the line
> POV_FREE ((OBJECT *)Tpat->proxObject);
> and see if that fixes it.
Well, we commented that line out and guess what: no more freezes!
It seems logic too! :-) (easy to say afterwards, isn't it?)
Smellenbergh
--
e-mail:sme### [at] skynet be
http://users.skynet.be/smellenbergh
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Mark Wagner
Subject: Re: Bug in pigment object (Chris Huff's patch)
Date: 12 Dec 1999 00:30:56
Message: <38533310@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich wrote in message <384fcfb1@news.povray.org>...
>Chris, maybe these tips help :-)
>
>Not reproducible crashes, especially on the Mac are most likely caused by
>invalid pointers or other out of range addressing. As the Mac OS does not
>have full memory protection (yet) these bugs are hard to catch. However,
>there are several (free) tricks you can use:
>- Use the MacsBug "hs" command to turn on/off heap scrambling.
>- When you free memory a pointer points to, set the pointer to NULL.
>- Init all pointers and data structures you use to NULL before using them
>(even if it looks stupid, i.e. code _should_ always put something into a
>pointer).
>
>In general, you should then see either hard crashes (mostly with "hs" on)
or
>memory access faults when your program tries to write to memory locations
>around 0 which are protected by the system. You will also see failing free
>calls if the pointers are set to NULL and somewhere code tries to free that
>memory again.
Another thing you can do is in config.h uncomment the lines:
#define MEM_TAG // Enables memory tag debugging
#define MEM_TRACE // Enables garbage collection and memory tracing
This will cause the program to alert you to such things as memory leaks and
attempts to free memory twice or free invalid memory locations.
Mark
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |