On 3/15/25 12:26, ingo wrote:
> I rendered frame 100 (+SF100 +SF101). It crashes during the rendering of the
> first block in the image.

I took you to mean +sf100 +ef100. Both v3.8 beta 2 and my current 
working yuqk fork had no trouble.

In the attached image the top two rows are at frame 0. Thereafter the 
rows are for frame 100, 200, 300 and 400.

The more blurry images are using a radius of 0.85 and the clearer ones 
0.24. With the latter radius being ~20x faster.

Ah, though I'm not motivated to drop back and look at v3.7, let me 
quickly try my current v3.7 compile to see if it dies fast at 0.85. It 
does indeed crash... I know that one of the improvements clipka worked 
hard on for v3.8 was to remove all the hard limits for size he could - 
so I am not too surprised v3.7 dies for Paul's scene.  As you noted it
dies just as it starts to render.

Anyhow. Out of time. Real life has me tied up for a while now so... yep.

Bill P.

Post a reply to this message

Attachments:
Download 'pbtest_01.jpg' (200 KB)

Preview of image 'pbtest_01.jpg'

"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

Post a reply to this message

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

Preview of image 'scene.png'

> Does it crash during parsing? Rendering the first frame? Or sometime
> during the animation of the frames?

During rendering.

> Only ideas I had on reading through your scene initially were:
> 1) Normalize the disc normal vector: vnormalize(VP-theposition).
> Shouldn't matter, but...

I originally did that, will try again.

> 2) The disc is a funny 2d object in that it has a defined inside. So
> adding hollow a good idea, if perhaps during your animation, the camera
> happens to end up inside one or more disc shapes.

Hmmm.

> I assume this a real market somewhere. How did you get these samples?

Lidar on the streets of HK. This is every 100th sample, with any points really
close removed.

Post a reply to this message

yesbird <sya### [at] gmailcom> wrote:
> On 15/03/2025 12:18, yesbird wrote:
> > POV-Ray version:
> > https://github.com/LeForgeron/povray
> >
> > System:


>
> Just tested the same version, but build on Linux - works fine.
> --
> YB

.... and you increased theradius to 0.1?

Post a reply to this message

yesbird <sya### [at] gmailcom> wrote:
> On 15/03/2025 11:00, Paul Bourke wrote:
> > And more importantly, how to fix or get around it?
> >
>
> Successfully rendered this scene (see attached image), but have a lot of
> warnings:
> ------------------------------------------------------------------------
> "C:\temp\pb\scene.pov" line 33: Possible Parse Error: Suspiciously high
> 'ambient' value found. Are you trying to model a glowing material? As of
> POV-Ray v3.7, 'ambient' is disabled when using radiosity, and its use to
> model glowing materials is generally deprecated;
> use 'emission' for this purpose instead. If your intention is to model
> unusually high ambient illumination in a non-radiosity scene, you can
> avoid this warning by explicitly specifying 'emission 0'.
> ------------------------------------------------------------------------
>
> POV-Ray version:
> https://github.com/LeForgeron/povray
>
> System:
> OS Name Microsoft Windows 7
> Version 6.1.7601 Service Pack 1 Build 7601
> Total Physical Memory 24.0 GB
>
> Log in attachment.
> --
> YB

But did you increase theradius to 0.1?

Post a reply to this message

kurtz le pirate <kur### [at] freefr> wrote:
> On 15/03/2025 11:14, Paul Bourke 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?
> >
> > Also happens for beta 3.8, but at different values of "the radius".
> >
>
> IMHO, this comes from using the <disk> object.
>
> Have you tried using the <cylinder> object instead ?

I just tried it, didn't make any difference, still crashes, in fact crashes more
reliably now. Here's the new DoPoint macro.

#macro DoPoint(theposition,thecolour)
   #local thenormal = vnormalize(VP-theposition);
   #local thedistance = vlength(VP-theposition);
   #if (thedistance > 0.2)    // Filter any points close to the camera
      #if (thedistance < 30)  // Filter any distant outliers
         #local theradius = 0.05;
         cylinder {
            <0,0,0>, thenormal/100, 0.95
            //hollow
            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 0 ambient 1 diffuse 0 specular 0 }
            }
            scale theradius
            translate theposition
         }
      #end
   #end
#end

Post a reply to this message

"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'