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'

On 3/16/25 03:21, William F Pokorny wrote:
> 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.

It just came to me what is likely going on.

The disc has an infinite inside so the 'interior ior' only kicks in on 
the fist disc intersection. All the disc surfaces seen after that first 
are inside other discs and also have the same ior - so there is no 
further refraction, but rather we get again transmitted rays. In other 
words, the trick doesn't limit the recursive depth on ray surface 
traversals in this case because it only bumps the max trace level by 
one. We get Max Level: 2/6 rather than 1/6 - and we were after 6/6.

Bill P.

Post a reply to this message

On 3/16/25 08:36, Bald Eagle wrote:
> I would think the lines would be curved in that instance?

I guess what I was thinking is that off to the left and right the disc 
intersections would become perpendicular where one of the two discs has 
passed behind the forward directional plane - and both discs are 
somewhat near the camera location. But, I admit I'm not sure I've 
imagined the situation correctly.

> 
> 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)

Cool. :-)

Bill P.

Post a reply to this message

On 16/03/2025 04:27, yesbird wrote:
> This is what I got with theradius = 0.1 and no crash.
> -- 
> YB

The charm of these mystical cyberpunk-like images forced me to start
rendering complete animation and this is the first 11 seconds
(334 frames of 3204x512 resolution) with cylindrical projection and
forward-backward loop:
https://povlab.yesbird.online/pb/

Rendering in progress ...
--YB

Post a reply to this message

yesbird <sya### [at] gmailcom> wrote:


> rendering complete animation and this is the first 11 seconds

> forward-backward loop:
> https://povlab.yesbird.online/pb/
>

> --YB

Super nice job, Sergey.  :)

This is pretty much what I envisioned Paul was shooting for when I saw that all
of the points were a sort of firefly glow.

I just did a quick render using "puffs" that I used in place of spheres.

It adds a peaceful, ethereal, Christmassy feel.

So now I'm thinking that if there was a way to use a collection of actual
snowflake shapes and have them appear, fall a sort way, then fade out - in a
cycle centered on their locations, that might make a cool "animated animation".
Or it might look like a total nightmare of a mess  ;)

- BW

Post a reply to this message

Attachments:
Download 'scenewithpuffs.png' (625 KB)

Preview of image 'scenewithpuffs.png'

Also:

Since we have trace (), we can do a synthetic / virtual LIDAR to take any
geomtric scene and place similar points.

What we DON'T have, is a combination of trace () and eval_pigment () to return a
color.

I suppose there are a number of workarounds that we could do there...

3D to 2D reverse projection (screen location macro)

Scan all of the objects in the scene sequentially with trace, and assign color
based on which object gets hit. (ugh)

Render the geometric scene and use that as an image_map for eval_pigment, and
use trace () in a sort of orthographic scanning mode.

I think the last has the most merit.

- BE

Post a reply to this message

On 16/03/2025 21:44, Bald Eagle wrote:
> Super nice job, Sergey.  :)
> 
> This is pretty much what I envisioned Paul was shooting for when I saw that all
> of the points were a sort of firefly glow.
> 
> I just did a quick render using "puffs" that I used in place of spheres.
> 
> It adds a peaceful, ethereal, Christmassy feel.
> 
> So now I'm thinking that if there was a way to use a collection of actual
> snowflake shapes and have them appear, fall a sort way, then fade out - in a
> cycle centered on their locations, that might make a cool "animated animation".
> Or it might look like a total nightmare of a mess  ;)
> 
> - BW

Thanks, Bill, it was not a "rocket science" task, having Three.js, a
powerful server and such rich data in hands.

I like your idea about snowflakes - winter in HK looks excellent !
Animated animation sounds intriguing, and looks like a lot of space for
experiments. If you will send me a scene, I'll do the rendering.

Now I am working on a stereo version with VR support, for those who have
a headset (static images at first). Btw, this is the reason why I am
prefer HGPovray - it has a stereo camera.
--
YB

Post a reply to this message

On 16/03/2025 21:51, Bald Eagle wrote:
> Also:
> 
> Since we have trace (), we can do a synthetic / virtual LIDAR to take any
> geomtric scene and place similar points.
> ...

Really, and by applying different objects to points we can produce
fantastic effects ! I like this idea very much and can assist as I can.

Quick googling shows that colorization of point clouds is not a trivial
task, but there are different approaches and solutions to choose from.
Interesting, how did PB solve it in his scene ?

Let's try ?
--
YB

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "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

No problems with spheres.
There is only one light source, it's at the camera.
I can't imagine misorientated discs, the normal is the vector from camera to
point position.

Post a reply to this message