 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
anybody else get a seg-fault running this code?
Not sure what the problem is, but if I had to guess, it's too many objects in a
union...
Regards,
A.D.B.
#include "kolors.inc"
#include "rand.inc"
#include "math.inc"
#include "woods.inc"
#version 3.7;
global_settings {
assumed_gamma 1.0
}
light_source {
0*x
rgb 1
translate <100, 500, -300>
}
camera {
perspective
location <0.75, 4.5, -3.75>
up y
right x*(image_width/image_height)
look_at <0.0, 4.0, 0.0>
}
#declare ft = 12;
#declare dP =
pigment {
image_map {
jpeg "aperture_science_logo_800.jpg"
map_type 0
interpolate 4
once
}
translate <-0.5, -0.5, 0.0>
scale 1.0
translate 4.0*y
}
#declare P_OldWood =
pigment {
wood
turbulence <0.3, 0.1, 0.5>
color_map { M_Wood1A }
scale <0.125*ft, 1.0, 1.0*ft>
}
#declare F_OldWood =
function {
pattern {
wood
turbulence <0.3, 0.1, 0.5>
scale <0.125*ft, 1.0, 1.0*ft>
}
}
#macro Board(W, T, L)
#local grain_seed = 15643544181;
#local _X = Rand_Normal(0.0, 1.0, RdmA)*2e5;
#local _Y = Rand_Normal(0.0, 1.0, RdmB)*2e5;
#local _Z = Rand_Normal(0.0, 1.0, RdmC)*2e5;
isosurface {
function {
f_rounded_box(x,y,z,0.125,
W/2-0.03125*F_OldWood(x-_X,y-_Y,z-_Z),
T/2-0.078125*F_OldWood(x-_X,y-_Y,z-_Z),
L/2+0.25)
}
threshold 0
max_gradient 2
contained_by { box { <-W/2, -T/2, -L/2> <W/2, T/2, L/2> } }
all_intersections
pigment { P_OldWood translate <_X,_Y,_Z> }
finish { ambient 0 diffuse 0.38 specular 0.07 roughness 0.3 }
}
#end
plane {
y, 0
pigment {
checker
color White,
color rgb <0.078125, 0.375, 0.75>
}
}
#declare Env =
object { Board(12, 2, 30) scale 1/12 rotate <-90, 0.0, -90> translate 4.0*y }
/*
plane {
-z, 0
pigment {
checker
color White,
color White*0.3
}
}
*/
#declare Pattern = union {}
//#declare pSubT = -1.0;
//#while(PSubT <= 1.0)
#local a = 0;
#while(a < 60000)
#local PHI = Rand_Normal(0.0, 1.0, RdmA)*10;
#local THETA = Rand_Normal(0.0, 1.0, RdmB)*180;
#local Trajectory = <sind(PHI)*cosd(THETA), sind(PHI)*sind(THETA),
cosd(PHI)>;
// Begin trace
#local Norm = <0, 0, 0> ; // degenerate Normal vector.
#local Start = <0.0, 4.0, -3.0> ; // The object starts here.
#local Pos = trace (Env, Start, Trajectory, Norm) ; // And comes to rest
here.
// End trace
/* #if(
vlength(
<eval_pigment(dP, Pos).red,
eval_pigment(dP, Pos).green,
eval_pigment(dP, Pos).blue>
) = 0
)*/
#declare Pattern =
union {
object { Pattern }
sphere { Pos, 0.001 }
}
// #end
#local a = a + 1;
#end
//#declare pSubT = pSubT + 0.
union {
object { Env }
object { Pattern pigment { Black } }
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anthony D. Baye" <Sha### [at] spamnomore hotmailcom> wrote:
> anybody else get a seg-fault running this code?
>
snip...
Probably should mention that I'm running RC5 in Linux Mint 11 (Katya) on an AMD
Phenom II X6
my command line is: povray +a0.03 +H768 +W1024 +T8 +P filename.pov
currently compiling RC6 sources, but they configured saying that it was RC5.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/10/2012 03:34, Anthony D. Baye nous fit lire :
> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
>> anybody else get a seg-fault running this code?
>>
> snip...
>
> Probably should mention that I'm running RC5 in Linux Mint 11 (Katya) on an AMD
> Phenom II X6
>
> my command line is: povray +a0.03 +H768 +W1024 +T8 +P filename.pov
>
> currently compiling RC6 sources, but they configured saying that it was RC5.
>
> Regards,
> A.D.B.
>
>
>
Segfault occurs at parsing time (or seems so)
Missing so far:
* kolors.inc (I guess colors.inc is ok ?)
* aperture_science_logo_800.jpg
* line 98 (Parse Warning: Should have at least 2 objects in csg.)
Notice that you are stacking CSG inside the loop, and starting with an
empty union.
Unless union is to be replaced with intersection or difference, such
construct has no interest when compared to something like
union{
#while ...
sphere ..
#end
}
Broader union, depth 1
(as opposed to your cascaded union of 60000 levels, with 1 extra sphere
per level)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/10/2012 09:26, Le_Forgeron nous fit lire :
> Le 13/10/2012 03:34, Anthony D. Baye nous fit lire :
>> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
>>> anybody else get a seg-fault running this code?
>>>
>> snip...
>>
>> Probably should mention that I'm running RC5 in Linux Mint 11 (Katya) on an AMD
>> Phenom II X6
>>
>> my command line is: povray +a0.03 +H768 +W1024 +T8 +P filename.pov
>>
>> currently compiling RC6 sources, but they configured saying that it was RC5.
>>
>> Regards,
>> A.D.B.
>>
>>
>>
>
> Segfault occurs at parsing time (or seems so)
> Broader union, depth 1
> (as opposed to your cascaded union of 60000 levels, with 1 extra sphere
> per level)
>
And it parses faster too.
The segfault is due to the depth of CSG: each level will stack a few
calls... the provisionned stack is not big enough for diving in that data.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] freefr> wrote:
> Le 13/10/2012 09:26, Le_Forgeron nous fit lire :
> > Le 13/10/2012 03:34, Anthony D. Baye nous fit lire :
> >> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> >>> anybody else get a seg-fault running this code?
> >>>
> >> snip...
> >>
> >> Probably should mention that I'm running RC5 in Linux Mint 11 (Katya) on an AMD
> >> Phenom II X6
> >>
> >> my command line is: povray +a0.03 +H768 +W1024 +T8 +P filename.pov
> >>
> >> currently compiling RC6 sources, but they configured saying that it was RC5.
> >>
> >> Regards,
> >> A.D.B.
> >>
> >>
> >>
> >
> > Segfault occurs at parsing time (or seems so)
>
> > Broader union, depth 1
> > (as opposed to your cascaded union of 60000 levels, with 1 extra sphere
> > per level)
> >
>
> And it parses faster too.
>
> The segfault is due to the depth of CSG: each level will stack a few
> calls... the provisionned stack is not big enough for diving in that data.
Thanks for responding.
It's pretty much what I figured, although I had thought it was a signed 16-bit
overflow somewhere, but 32768 works just fine.
my solution was to create another container to hold unions of a safe size, but
it seems that there's a better solution.
at any rate, it would probably be a good idea to do some error checking on the
stack size before it overflows and causes a segfault.
Regards,
A.D.B
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> > The segfault is due to the depth of CSG: each level will stack a few
> > calls... the provisionned stack is not big enough for diving in that data.
> Thanks for responding.
> It's pretty much what I figured, although I had thought it was a signed 16-bit
> overflow somewhere, but 32768 works just fine.
> my solution was to create another container to hold unions of a safe size, but
> it seems that there's a better solution.
> at any rate, it would probably be a good idea to do some error checking on the
> stack size before it overflows and causes a segfault.
In any case, a segmentation fault is not something that a program should do,
so a bug report is in place.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.10.2012 17:44, schrieb Anthony D. Baye:
> at any rate, it would probably be a good idea to do some error checking on the
> stack size before it overflows and causes a segfault.
We'll implement such a check as soon as we've figured a way to solve the
halting problem :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 13.10.2012 17:44, schrieb Anthony D. Baye:
>
> > at any rate, it would probably be a good idea to do some error checking on the
> > stack size before it overflows and causes a segfault.
>
> We'll implement such a check as soon as we've figured a way to solve the
> halting problem :-P
Funny. Really.
I had assumed that the stack in question was not the system stack. i.e. part of
the code... And that it had a known max size.
Even if this is not the case, it should still be possible to implement some kind
of check to prevent a segfault.
But, again, I am not familiar with the code.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> clipka <ano### [at] anonymousorg> wrote:
>> Am 13.10.2012 17:44, schrieb Anthony D. Baye:
>>
>>> at any rate, it would probably be a good idea to do some error checking on the
>>> stack size before it overflows and causes a segfault.
>>
>> We'll implement such a check as soon as we've figured a way to solve the
>> halting problem :-P
>
> Funny. Really.
>
> I had assumed that the stack in question was not the system stack. i.e. part of
> the code... And that it had a known max size.
>
> Even if this is not the case, it should still be possible to implement some kind
> of check to prevent a segfault.
>
> But, again, I am not familiar with the code.
>
> Regards,
> A.D.B.
>
>
Checking for an impeding stack overflow is always tricky, whatever the
stack implementation. Having a static stack size don't mean that you can
acurately detect when an overflow could appen.
Also, such a check will slow down ALL accesses to the stack, possibly
severly.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
