On 7/6/22 21:32, jceddy wrote:
> I actually changed the povray source code to add a new built-in function type,
> and patter type to call directly. The implementation is in the C++ source and
> just exposed to SDL via a couple of new parser directives.
> 
> On my phone ATM, so will probably put something over in programming later
> (unless there is a way for a forum admin to just move this thread or something).

So... I think you are saying you've added a new f_mindist() function 
with the appropriate hook in functions.inc - or a stand alone hook in 
the SDL? And also a new pattern calling the same mindist code?

I have an interest in the former work more than the latter as have on my 
wish list to expose an f_trace() capability in my povr branch play which 
is roughly equivalent to the SDL's trace() function. I'd like to see how 
you handled the internal code hooks for tracing, inside tests (surface 
handling?) and pointers to the objects to trace.

Official development is stalled again since mid 2021, so while a pull 
request would be one handy way I could look at your code, it's unlikely 
to be acted on any time soon - in any 'official' capacity.

---

Random thoughts
---------------

Over the years there has been a fair bit of play with "proximity 
patterns." The work breaking into two approaches. One sampling by 
tracing rays and the other by sampling density via inside/out shape 
sampling(a) at various distances.

(a) - Inside testing gets slow for complex SDL built shapes because the 
inside test bypasses all the bounding search mechanisms used while 
tracing. I have an open question in my head as to whether trace() 
bypasses the bounding mechanisms too?

There is a proximity pattern in Jerome's hgpovray38 branch IIRC. Long on 
my list to look over his implementation, but, I've never gotten to it...

There is in all v3.8 branches a potential pattern hook for all shapes. 
Today it's implemented only for blobs(b) and the isosurface(b1) itself. 
Extending it to other simple shapes like spheres would be easy, but it's 
not been done. I think because it's hard to see the benefit when you can 
represent simpler shapes directly with functions for isosurfaces and 
these simpler functions can be used as patterns already. Using 
'patterns' in isosurface functions comes with significant overhead - and 
in the official POV-Ray releases there are bugs and usage issues too.

(b) - There are continuity issues with the blob implementation itself 
which handicaps blob potential pattern use (blob use itself in fact).

(b1) I removed the capability to use this potential pattern with 
isosurfaces in my povr branch because working with the incoming 
isosurface functions directly will always be better. Further, supporting 
the isosurface potential pattern introduced new keywords and overhead 
for all isosurfaces. I felt it not worth the added complexity or run 
time cost.

Truly knowing 'the' mindist for all 3D shapes is likely impossible to 
any reasonable cost(c). This of course says nothing about whether a 
mindist functionality is useful - a somewhat fuzzy one would be.

(c) - So long as 2D the internal point list representations are 
standardized/cleaned this can be done by various direct algorithms - as 
happens in VLSI design rule checking tooling. New distance functions to 
linear segments represented by point lists could be useful - especially 
if the point list can be pre-processed for fast mindist determinations 
after parsing. For small numbers of segments this can be done in any 
recent POV-Ray release. I've played too with DF3 based methods for large 
numbers of 'walls' (maze images from some years back) but it's a clunky 
approach.

Anyhow, I'll stop rambling.

I'm interested in what your trying for possible use/adaptation with 
stuff I'm trying. :-)

Bill P.

Post a reply to this message