On 7/7/22 17:57, jceddy wrote:
> 
>> I'll work on this more today, and be back later with a link to my github fork.
> 
> My fork is over here: https://github.com/jceddy/povray
> 
> If you search for "minimum" you are going to find most of my changes.
> 
> You can create a minimum distance function with:
> 
> #declare fn = function { minimum_distance { object } };
> 
> The minimum distance pattern allows a little more control over the simulated
> annealing step, but I am currently working on additional changes to expose all
> of the relevant tweakable parameters.
> 
> At any rate, if you take a look at how I ma using Find_Intersection in the
> MinimumDistanceSolver class, that is basically the core trace() functionality
> that you had mentioned you are interested in exposing via a function.
> 
> 

Thanks. Is this minimum_distance work the only thing changed in that 
fork - or is there (or will there be) other stuff changed in it too?

I implemented my own special function / new parser keyword in 
'pattern_modifiers' a couple years back in povr. I wasn't thinking about 
that approach for an f_trace(), but maybe it's a way to go...

In a post following this one you were talking about recognizing the mesh 
object for special handling. It's a shape with its own internal 
bounding. Tracing of rays(a) should be relatively fast with meshes - FWIW.

Bill P.

(a) - A thought that popped into my head yesterday is that if your ray 
origin point for is very close to an object's surface you can get fooled 
for mindist due the closest root/intersection being inside the minimum 
intersection depth for the particular shape/surface - those 
intersections are typically thrown out (or are never found depending 
upon the solver used). In practice this issue might not come up that 
much. The issue is tangled in the isosurface (~parametric~) accuracy 
setting which is already useless beyond about 1e-6 as a soft rule. Most 
folks run with an accuracy of something more like 1e-3 or a little less 
and most shapes support smaller depths than that (blobs in official 
POV-Ray versions are at a quite large 1e-2). An advantage of 
"proximity/density" approaches based upon inside tests only is they 
don't have this exposure to unstable ray traced results near surfaces. 
Anyhow. Maybe this a worry for later should you see near surface 
noise/issues with your ray traced approach.

Post a reply to this message