POV-Ray : Newsgroups : povray.beta-test : POV-Ray v3.8.0-x.freetype.1 : Re: POV-Ray v3.8.0-x.freetype.1 Server Time
3 May 2024 00:24:27 EDT (-0400)
  Re: POV-Ray v3.8.0-x.freetype.1  
From: clipka
Date: 7 Feb 2019 16:34:28
Message: <5c5ca464$1@news.povray.org>
Am 07.02.2019 um 17:31 schrieb William F Pokorny:

> Trying to avoid sliding too much sideways into work I did almost two 
> years ago given I've already got more going than I'll ever finish.

Welcome to the world of POV-Ray development ;)

> - Remembered a decade ago with the objectAsIso experiments how I looked 
> hard at converting other than the simplest csg to a mesh because the 
> inside test performance got so slow with larger/complex csg.
> 
> - Remembered Lanuhum's Blender hair scene and thinking it shouldn't 
> really be that slow, even with super slow sphere_sweeps.

Let's play a game of "shapes that could benefit from internal bounding 
but don't have any" ;)

> - Remembered learning early last year while finding the cause of a 
> particular speckling bug, that POV-Ray does inside tests when it creates 
> original rays.

Just a spontaneous thought here: Would it be worth it to cache the 
result of the camera ray origin inside test, and only re-do it if the 
origin changes (due to special camera or focal blur)?


> Results were not similar. This leads me to a new suspicion / unproven 
> theory we are sitting on a csg inside test performance issue. One 
> perhaps affecting things generally. My code changes to the text object 
> only treated another problem.

I'm not so sure it's a CSG thing you're seeing. By default, POV-Ray 
"flattens" CSG unions wherever possible, promoting all children to 
top-level objects - presumably this is also the case with implicit 
unions like the text primitive. So unless you took some measure to 
specifically prevent this, you're not actually testing a CSG object.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.