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.
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
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
Anyhow, I'll stop rambling.
I'm interested in what your trying for possible use/adaptation with
stuff I'm trying. :-)
Post a reply to this message