Compare these two frames from an animation of a roller coaster I'm 
working on.  Notice that in the second frame, the track spine has 
disappeared.

Throughout the animation, the track spine disappears randomly for 1-3 
frames at a time.  What would cause this?

The spine is a sphere_sweep generated through SDL using bezier data. 
Sphere_sweeps are generated by using some macros from transform.inc to 
orient the components of the sphere_sweep to the current track heading 
and banking.

I don't understand why it would disappear in some frames though, 
considering that NONE of the SDL for the sphere_sweep looks at the clock 
variable at all.  Its generated on every frame and should be the same on 
every frame.

The only thing I can possibly think of is rounding errors.  But if that 
was the case, then the other two rails should be messing up as well.  I 
suppose I could post the code:

#declare xx = 0;
#while (xx < NUMBEZIERS -1 )
#declare yy = 0;
#while (yy < POINTSPERBEZIER)
GetBezier(bez[xx],c2[xx],c1[xx+1],bez[xx+1], yy/POINTSPERBEZIER, ret)
#declare point1 = ret;
GetBezier(bez[xx],c2[xx],c1[xx+1],bez[xx+1], yy/POINTSPERBEZIER + 0.001, 
ret)
#declare point2 = ret;
#declare point3 = point2 - point1;
#declare il = int(xx);
#declare b = -((bank[xx+1] - bank[xx]) * (yy/POINTSPERBEZIER) + bank[xx]);
#declare raxis = vaxis_rotate(y,point3,b);
#declare bpsl[xx*POINTSPERBEZIER + yy] = VPerp_To_Plane(raxis,point3) * 
0.5 + point1;
#declare bpsr[xx*POINTSPERBEZIER + yy] = VPerp_To_Plane(raxis,point3) * 
-0.5 + point1;
#declare bpsc[xx*POINTSPERBEZIER + yy] = -0.2*raxis + point1;
#declare yy = yy + 1;
#end
#declare xx = xx + 1;
#end

sphere_sweep { linear_spline (NUMBEZIERS-1)*POINTSPERBEZIER - 1
#declare xx =0;
#while (xx < (NUMBEZIERS-1)*POINTSPERBEZIER -1 )
bpsl[xx], 0.0725
#declare xx=xx+1;
#end
pigment { color rgb x+y }
}

sphere_sweep { linear_spline (NUMBEZIERS-1)*POINTSPERBEZIER - 1
#declare xx =0;
#while (xx < (NUMBEZIERS-1)*POINTSPERBEZIER -1 )
bpsr[xx], 0.0725
#declare xx=xx+1;
#end
pigment { color rgb x+y }
}

sphere_sweep { linear_spline (NUMBEZIERS-1)*POINTSPERBEZIER - 1
#declare xx =0;
#while (xx < (NUMBEZIERS-1)*POINTSPERBEZIER -1 )
bpsc[xx], 0.2023
#declare xx=xx+1;
#end
pigment { color rgb x+y }
}

(END OF CODE)

bez, c1, and c2 are bezier data.  GetBezier is a macro for getting the 
coordinates in space of a point on a bezier at T.  bpsl, bpsr, and bpsc 
are of the course the generated sphere_sweep points for the left, right, 
and center rails respectively.

Post a reply to this message

Attachments:
Download 'bezier0186.png' (26 KB) Download 'bezier0185.png' (29 KB)

Preview of image 'bezier0186.png'

Preview of image 'bezier0185.png'

> Compare these two frames from an animation of a roller coaster I'm
> working on.  Notice that in the second frame, the track spine has
> disappeared.
>
> Throughout the animation, the track spine disappears randomly for
> 1-3 frames at a time.  What would cause this?


Try MegaPOV if you haven't already, I found that with the original POV I get 
many bugs and sometimes parse errors when using splines and sphere sweeps. 
MegaPOV seemed to fix it. Also I found replacing the sphere sweeps with 
spheres connected by cylinders made render times much faster and without 
much loss to quality (you should choose a good spacing for the spheres). 
Just my 2 cents.

Post a reply to this message

scott wrote:
> Try MegaPOV if you haven't already, I found that with the original POV I get 
> many bugs and sometimes parse errors when using splines and sphere sweeps. 
> MegaPOV seemed to fix it. Also I found replacing the sphere sweeps with 
> spheres connected by cylinders made render times much faster and without 
> much loss to quality (you should choose a good spacing for the spheres). 
> Just my 2 cents.
> 
> 

I installed MegaPOV and it works.  No more disappearing sphere_sweeps!

About the use of spheres and cylinders...In theory, shouldn't a 
sphere_sweep using linear_sweep look exactly the same as spheres 
connected by cylinders?  If so, why doesn't POV-Ray break it up like 
that?  I'm finding that POV-Ray is shooting way more rays to test the 
sphere_sweep than is probably necessary...only 1-2% of the rays tested 
result in a success.  That certainly can't be efficient.

-DJ

Post a reply to this message

scott wrote:
> Try MegaPOV if you haven't already, I found that with the original POV I get 
> many bugs and sometimes parse errors when using splines and sphere sweeps. 
> MegaPOV seemed to fix it. Also I found replacing the sphere sweeps with 
> spheres connected by cylinders made render times much faster and without 
> much loss to quality (you should choose a good spacing for the spheres). 
> Just my 2 cents.
> 
> 

I replaced the sphere sweeps with spheres/cylinders..

@#$%$!#$ WHY DIDN'T I DO THIS SOONER!?  My rendering time for my current 
set of tests has dropped from 4 minutes per frame to 4 SECONDS.

Now if only I could figure out why the track ties appear wrong at the 
beginning and end of the track...

-DJ

Post a reply to this message

Wasn't it DJ Wiza who wrote:
>
>Now if only I could figure out why the track ties appear wrong at the 
>beginning and end of the track...

Could you perhaps be placing them before the second point and after the
penultimate point of a cubic spline?

Note: Because of the way cubic_splines are defined: the first and last
points are tangents rather than points on the spline, cubic_spline
interpolation is only valid between the second and next-to-last points.
For all other spline types, interpolation is valid from the first point
to the last point. For t-values outside the valid range, POV-Ray returns
the value of the nearest valid point. 

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams wrote:

> Wasn't it DJ Wiza who wrote:
> 
>>Now if only I could figure out why the track ties appear wrong at the 
>>beginning and end of the track...
> 
> 
> Could you perhaps be placing them before the second point and after the
> penultimate point of a cubic spline?
> 

Actually, I figured it out.  I had misunderstood how Reorient_Trans() 
works.  I fixed it and will be uploading a new version soon.

-DJ

Post a reply to this message

DJ Wiza nous apporta ses lumieres en ce 25/04/2006 06:07:
> scott wrote:
> 
>> Try MegaPOV if you haven't already, I found that with the original POV 
>> I get many bugs and sometimes parse errors when using splines and 
>> sphere sweeps. MegaPOV seemed to fix it. Also I found replacing the 
>> sphere sweeps with spheres connected by cylinders made render times 
>> much faster and without much loss to quality (you should choose a good 
>> spacing for the spheres). Just my 2 cents.
>>
>>
> 
> I installed MegaPOV and it works.  No more disappearing sphere_sweeps!
> 
> About the use of spheres and cylinders...In theory, shouldn't a 
> sphere_sweep using linear_sweep look exactly the same as spheres 
> connected by cylinders?  If so, why doesn't POV-Ray break it up like 
> that?  I'm finding that POV-Ray is shooting way more rays to test the 
> sphere_sweep than is probably necessary...only 1-2% of the rays tested 
> result in a success.  That certainly can't be efficient.
> 
> -DJ
When you shoot rays at a sphere_sweep, you need to cover the whole bounding box, witch
in turn, must 
completely enclose the whole extent of the sweep. In most cases of large sweeps, the
bounding box is 
almost empty, leading to very poor success percentages, and extended trace times.
Breaking the sweep 
in smaller sections and puting those in an union can realy improve the effeciency.
In practice, a sphere_sweep using linear_sweep DOES looks exactly the same as spheres
connected by 
cones as the radius can vary. As a bonus, you get rid of those pesky artefacts by
using spheres and 
cones.

-- 
Alain
-------------------------------------------------
WARNING: The consumption of alcohol may make you think you can logically converse with
members of 
the opposite sex without spitting.

Post a reply to this message

Alain wrote:
> When you shoot rays at a sphere_sweep, you need to cover the whole 
> bounding box, witch in turn, must completely enclose the whole extent of 
> the sweep. In most cases of large sweeps, the bounding box is almost 
> empty, leading to very poor success percentages, and extended trace 
> times. Breaking the sweep in smaller sections and puting those in an 
> union can realy improve the effeciency.
> In practice, a sphere_sweep using linear_sweep DOES looks exactly the 
> same as spheres connected by cones as the radius can vary. As a bonus, 
> you get rid of those pesky artefacts by using spheres and cones.
> 

So then why not program POV-Ray to automatically break up linear_sweep 
sphere_sweeps into spheres and cylinders/cones?  If the end result is 
the same, why do it any differently?

Post a reply to this message