"Eriban" <pov### [at] spamgourmetcom> wrote in message 
news:web.4a42895f99a5bfb681475b100@news.povray.org...
> Iin the small sample scene I used it the fibers do not enhance the
> image as they are too small to show up. The main effect is that they 
> reduce the
> overall brightness of the rope a bit. Having said that, it's good to know 
> I can
> get the fibres to show up when needed. :-)

That's true. It only really shows up if the rope is close enough or if the 
image is large enough to show that level of details, which is why I 
incorporated the option to switch it off and save on render times. I think 
this is also true of real ropes though, you can't see the fibres till you 
get reasonably close.


> A small suggestion. Is it maybe worth adding another quick-rendering 
> option to
> the rope macros, alongside the Rope_ShowFibres=0 setting? In some 
> test-renders
> you may only want to see the path of the rope, without it having to 
> consist of
> multiple strands. For my rope-looping macro I am using a single 
> sphere_sweep
> during loop construction (to make sure that the loops do not overlap 
> anywhere).
> This sphere_sweep can also be used creating the image. It does not look 
> good of
> course (see the attached image), however, it may be handy when contructing 
> the
> path for the rope, as it takes less time to generate the image.
>

I think that's a very good idea.


> In my case (using a simple 1.42 GHz PowerPC MacMini) the rendering and 
> parse
> times for my simple "looped rope" image are as follows:
> Proper rope, with fibres: Total time 39m30s, of which 1m49s parsing
> Proper rope, w/o wibres: Total time 3m44s, of which 1m37s parsing
> Simple sphere_sweep: Total time 1m56s, of which 0s parsing

I have to admit that I invested in quite a fast machine last year, so most 
of the test renders I did took less than 5 seconds. The big coils of rope 
were the main exception to that and I was getting between 30 seconds and 1.5 
minutes. The example in the documentation containing 3 quite long coils of 
rope, with fibres did take it up to about 27 minutes.


> The macro to create the sphere_sweep from the array of points can be very 
> simple
> of course. Here's what I have been using:
>
> #macro BuildRope(RopePoints, StartIndex, EndIndex, Radius)
> sphere_sweep {
>  cubic_spline
>  EndIndex - StartIndex
>
>  #local I = StartIndex;
>  #while (I != EndIndex)
>   RopePoints[I], Radius
>   #local I = I + 1;
>  #end
> }
> #end
>

Thanks. I'll add that in.

Regards,
Chris B.

Post a reply to this message

"Alain" <aze### [at] qwertyorg> wrote in message 
news:4a41648a$1@news.povray.org...

>> I was surprised that I hadn't needed to increase the POV-Ray 
>> max_trace_level when I developed the outer 'fibre' layer,
>
> With version 3.7, when a transparent object don't have reflection nor an 
> interior with an ior, passing trough such an object don't count toward the 
> max_trace limits. That change happened over 10 versions ago, I think. Now, 
> a ray can pass trough over 500 transparent object, giving over 1000 
> surfaces intersections.

Well that's good. Quite nifty thinking by whoever had that idea. Should save 
quite a few questions on povray.newusers each year :-)

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> Now that I tried it on 3.6 it clearly needs the following line adding if
> fibres are used and I would imagine it's the same problem for MegaPOV:
> global_settings {max_trace_level 10}
>
> I'm still not really sure why it doesn't need this on the 3.7 beta 32.
> I also notice that the lighting levels are a lot darker on 3.6, but I guess
> you've already spotted that and set Rope_Brightness to 2 to compensate,
> because your scene looks bright enough (or maybe MegaPOV is different from
> 3.6 on lighting levels).

3.7 uses a new scheme of what is counted towards the "max_trace_level" limit:
While 3.6 *always* counts transitions through (semi-) transparent surfaces, 3.7
only counts such transitions if refraction occurs (i.e. if the "ior" values
differ).

Post a reply to this message