"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Paul Bourke" <pau### [at] gmailcom> wrote:
> > Any ideas why this scene
> >    https://paulbourke.net/transient/povray/
> > crashes once "theradius" gets past a certain value, eg: 0.6. There are no
> > coincident points, running version 3.7 on MacOS. Tonnes of RAM (192GB) and only
> > a fraction is used.
> > And more importantly, how to fix or get around it?
>
> I would say that you're pushing up against certain hard-coded values in 3.7.
> Also, people have made a very good (and non-obvious) point about the disc object
> having an inside.
>
> Although you could use cylinders, I used spheres, but I put them all inside a
> blob {} statement to get a speed boost from the special bounding mechanism.
>
> It takes maybe 15 sec to parse that huge inc file, and then FOR-EVER to try and
> render it.
> That's coming from the transmit values in your pigment map.
> Setting all of those to 0 allows the scene to render in 45s on my machine.
>
> The only other things I can think of to perhaps make the scene render faster and
> with less memory usage, are to sort the disc/sphere/blobs by color (perhaps with
> some rounding) so that you can use a single texture statement for each group of
> similarly colored object, thereby saving memory.
> Also, you could sort by distance from the camera, and only give the nearest
> objects a transmit pigment, so you wouldn't have so many layers of transmit to
> deal with, though perhaps setting max_trace_level to a lower value would
> essentially accomplish the same task.
>
> Pretty cool idea - and I hope to see the final animation once it's all working!
>
> - BW

Thanks for the suggestions. I am now rendering in 3.8, only takes about 20s and
that's with an even bigger inc file. But speed isn't an issue for me, at least
with 3.7 since I can distribute it. The 3.8 I downloaded has the gui (MacOS), is
there a pure command line for 3.8? Can't efficiently do a distributed render
with the gui.

See previous message, tried cylinders and spheres (3.7), same problem.

There are also nasty defects in the 3.8 render (discs), see attached example
frame. Strange they are mostly on the right half, it's those narrow dark
slivers. Perhaps they are a cue to what's happening.

Post a reply to this message

Attachments:
Download 'scene120.png' (1797 KB)

Preview of image 'scene120.png'

I just changed the disks to plain spheres (no blob) and set max_trace_level to
2, and it rendered just fine in 20s.

I'm guessing maybe it's something in 3.7.

I'll keep bumping up the MTL and see what happens.

Post a reply to this message

Attachments:
Download 'scene.png' (1115 KB)

Preview of image 'scene.png'

"Paul Bourke" <pau### [at] gmailcom> wrote:

> Thanks for the suggestions. I am now rendering in 3.8, only takes about 20s and
> that's with an even bigger inc file. But speed isn't an issue for me, at least
> with 3.7 since I can distribute it.

Well, I was juggling making the kid dinner + other stuff + Bourke-level POV-Ray
creativity, so I wanted to get a finished render so that I could get a better
overall idea of what was going on.

> The 3.8 I downloaded has the gui (MacOS), is
> there a pure command line for 3.8? Can't efficiently do a distributed render
> with the gui.

Yes Sir.
I just ran [Path] pvengine64 /RENDER scene.pov, and that seemed to work fine
under M$ Win 7

> See previous message, tried cylinders and spheres (3.7), same problem.
>
> There are also nasty defects in the 3.8 render (discs), see attached example
> frame. Strange they are mostly on the right half, it's those narrow dark
> slivers. Perhaps they are a cue to what's happening.

Dunno.  If they're disks or something, maybe somehow they got oriented wrong,
and they're dark colors in front of light?

I just tried again with spheres that are scaled by 0.01 in x, so that they
resemble your original disc.  Can't tell if the lines are there.
What resolution are you rendering at?

- Bill

Post a reply to this message

Attachments:
Download 'scene.png' (1239 KB)

Preview of image 'scene.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I just tried again with spheres that are scaled by 0.01 in x, so that they
> resemble your original disc.  Can't tell if the lines are there.
> What resolution are you rendering at?

"Just download the render at look at the image size, Bill."
<eyeroll>

Take a look at this and see what you think.

Post a reply to this message

Attachments:
Download 'scene.png' (976 KB)

Preview of image 'scene.png'

Never mind that last one.

I flattened the spheres and then rotated them so that they were perpendicular to
the camera.
Try this and see if this gets you anywhere better.


#macro Reorient_Trans(Axis1, Axis2)
   #local vX1 = vnormalize(Axis1);
   #local vX2 = vnormalize(Axis2);
   #local Y = vcross(vX1, vX2);
   #if(vlength(Y) > 0)
      #local vY = vnormalize(Y);
      #local vZ1 = vnormalize(vcross(vX1, vY));
      #local vZ2 = vnormalize(vcross(vX2, vY));
      transform {
         matrix < vX1.x, vY.x,vZ1.x, vX1.y,vY.y,vZ1.y, vX1.z,vY.z, vZ1.z, 0,0,0
>
         matrix < vX2.x,vX2.y,vX2.z,  vY.x,vY.y, vY.z, vZ2.x,vZ2.y,vZ2.z, 0,0,0
>
      }
   #else
      #if (vlength(vX1-vX2)=0)
         transform {}
      #else
         #local vZ = VPerp_To_Vector(vX2);
         transform { Axis_Rotate_Trans(vZ,180) }
      #end
   #end
#end

#macro DoPoint(theposition,thecolour)

 #local theradius = 0.2;

   sphere{<0,0,0>, 0.2 //, 0.05
    //disc{<0,0,0>, VP-theposition, 1

      texture {
         pigment {
            onion
            colour_map {
               [0.00, rgb thecolour transmit 0]
               [0.20, rgb thecolour transmit 0.95]
               [1.00, rgb thecolour transmit 1]
            }
         }
         finish { emission 1 diffuse 0 specular 0 }
      }
      scale <0.01, 1, 1>
      Reorient_Trans(x, vnormalize(VP-theposition))
      scale theradius
      translate theposition
   }

#end

Post a reply to this message

Attachments:
Download 'scene.png' (678 KB)

Preview of image 'scene.png'

Even if I abandon solids and just create a polygon at each position, Povray
crashes as soon as I scale the polygon up past a certain amount. Is there
possibly an issue if too many objects overlap?

Post a reply to this message

"Paul Bourke" <pau### [at] gmailcom> wrote:
> Even if I abandon solids and just create a polygon at each position, Povray
> crashes as soon as I scale the polygon up past a certain amount. Is there
> possibly an issue if too many objects overlap?

I personally am not having that issue.
I have #local theradius = 1;
and it's still just chugging along fine.
It's just a cheap HP EliteDesk i5 with 16GB RAM

Of course, I'm using an edited version of the original...

Maybe it's the Apple version?

Post your current scene and I'll run it unedited.

-BW

Post a reply to this message

On 16/03/2025 01:37, Paul Bourke wrote:
> .... and you increased theradius to 0.1?
>

This is what I got with theradius = 0.1 and no crash.
--
YB

Post a reply to this message

Attachments:
Download 'scene0000.png' (2021 KB)

Preview of image 'scene0000.png'

On 3/15/25 19:12, Paul Bourke wrote:
> There are also nasty defects in the 3.8 render (discs), see attached example
> frame. Strange they are mostly on the right half, it's those narrow dark
> slivers. Perhaps they are a cue to what's happening.

Got up to go to the bathroom(*) and, wow, a lot of posts in this thread.

One of the things I wanted to mention - and didn't as I rushed off to an 
appointment yesterday - is that recent versions of POV-Ray do not 
increment the trace depth on just transparency. This was a significant 
change made to less often get black pixels on hitting the
max_trace_level limit. In other words, it means for your successful 
renders, the end of frame output should have text which always reads:

   Max Level: 1/6

The only thing stopping the actual internal recursion depth as you move 
through multiple discs is the adc_bailout value. This sometimes causes 
trouble because depending on any particular ray's path the recursion 
depth due the number of surfaces traversed can get very deep. A trick 
Alain taught me is that we can restore the old behavior by adding an 
interior with an ior of say 1.00001.

Unfortunately, trying this trick didn't fix my v3.7 render even when I 
reduced the radius to 0.24 (though at that radius the first blocks now 
do render for a while before crashing).

With lidar data, it should be the case that where the radius is small 
you traverse through very few - maybe always one - disc. As the radius 
increases rays will need to traverse more and more surfaces and the 
recursion depth will increase.

One thing which does work for my v3.7 render is changing the color_map 
so everything is opaque. Offers a much clearer view of what is happening 
with the discs too.

I next tried setting the maximum color_map transparency to 90% and now 
my v3.7 renders are rendering fine. As does setting last color_map 
transparency to 99%. Image attached (no AA).

So the issue has to do with overlapping regions of complete transparency 
I guess. Wonder, does the ior 1+epsilon trick not work in v3.7? Hmm, 
maybe with the spherical camera more rays hit the surface parallel to 
surface normal? Don't know.

Lastly, you could play with higher adc_bailout values too as a solution 
to the v3.7 rendering.

---

On your particular question about artifacts. The discs at larger radius 
values will start to cross each other. Where they do there will be a 
seam of numerical instability somewhat like coincident surfaces. Some 
likelihood this is the cause of the artefacts, but unsure how to be sure 
at moment. Can you filter out some range of discs closer to the camera 
location?

Bill P.

(*) TMI.

Post a reply to this message

Attachments:
Download 'scene_v3.7_opaque0_990400.png' (194 KB)

Preview of image 'scene_v3.7_opaque0_990400.png'

William F Pokorny <ano### [at] anonymousorg> wrote:

> Got up to go to the bathroom(*) and, wow, a lot of posts in this thread.

> Lastly, you could play with higher adc_bailout values too as a solution
> to the v3.7 rendering.

I thought this was just straight rendering - no radiosity.

Also, I replaced all of the ambient statements with emission.

> On your particular question about artifacts. The discs at larger radius
> values will start to cross each other. Where they do there will be a
> seam of numerical instability somewhat like coincident surfaces. Some
> likelihood this is the cause of the artefacts, but unsure how to be sure
> at moment. Can you filter out some range of discs closer to the camera
> location?

I would think the lines would be curved in that instance?

Just out of curiosity, I was wondering what the actual overall scene looked
like, so once I wrapped my head around the coordinate system and
camera-to-look_at orientation, I was able to pull the camera back and look down
over the entire undistorted market.
(see attached)

There are places where there are significant holes / spaces.
I'm wondering if perhaps part of the problem may be that the lines are places
where the rays are making it through to the black background.

Perhaps a non-zero (1/255) sky_sphere or background may help, or something like
a fog effect where the foreground is crystal clear, but the far-away spaces get
filled in with a lighter color.  Maybe some sort of large box with a gradient
that's the 4th root of the normalized total distance... that sort of thing.

Due to the time difference, I'm _just_ getting up and having First Coffee - so,
you're getting what you're paying for.  ;)

- BW

A huge point set like this is a real treat to play with, since it is large,
asymmetric, offers human-recognizable structure, and has color data built in.
I've been wanting to do a 3D convex hull algorithm, and this would be a great
final test for that.
Wondering what would happen if instead of discs or cylinders or spheres, _cones_
were used instead, oriented looking straight at the smaller face and the larger
end being just large enough to protrude: maybe that might fix the dark artifact
lines if it's a see-through effect.

Post a reply to this message

Attachments:
Download 'scene.png' (756 KB)

Preview of image 'scene.png'