|
 |
On 11/1/19 1:53 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymous org> wrote:
>
>> What's missing is a way to access the x,y,z vector result of all the
>> modifiers a pigment / pattern might employ.
>
>> Then pattern_modifier {} grabs just the result of those
>> operations for a given point returning the function/pattern space
>> adjusted x,y,z values. The usage is something like:
>
> Yes, this will be very nice indeed.
>
> Just curious:
> Being eyeballs-deep in the function code, what do you think the odds are that
> there will be functions that can return <x, y, z> vectors for user use, say in
> the next year or so?
>
If talking about a branch someone could compile themselves, good. I plan
to assemble publish such a branch(1).
If talking about in POV-Ray proper, I have no idea. The only person
actually updating POV-Ray in the past years has been quiet since April
or so. My pull requests, no matter how trivial, had not been getting
merged in any form since a minor build related one in November 2017.
Nothing substantially picked up and merged of mine since early 2017. I
think that reality unlikely to change no matter core development
starting up again.
Bill P.
(1) - Thinking that branch will include additional new functions /
function / pattern updates. I have a list of potential new functions and
am playing with several not yet posted about now. I'll probably pick up
Jerome's rotate warp too in some form. Might merge in / refine my
additional black hole warps as part of this branch too as they are
really part of the same idea push. I'd like to work out an efficient
back_hole encapsulated turbulence capability so it can more easily be
applied locally in a feathered-in-strength way.
I'm likely to hack at the current implementation of the new potential
pattern too... I find myself not sure how to really make use of the
potential pattern capability with most shapes. It works well only with
blobs today(1a). I've thought a fair bit about how to extend the
potential pattern to other shapes, but I've got no idea how to normalize
the values in the ray-surface equation values space. These equations
vary wildly in absolute magnitude and polarity - neither of which matter
to a first order to the majority of the root solvers. This means the
potential pattern extended to all inbuilt shapes amounts to implementing
it as some inside/outside switching - and we already have that
capability with the object (inside test based) pattern.
(1a) - Our blob has always had continuity issues at the boundaries of an
individual blob element's influence. Others have suggested updates over
the years to address this - and down somewhere on my list I want to look
at it given my solver branch addressed many base accuracy issues with
the blob shape. The point here, even with blobs where the value domain
is somewhat normalized, their usefulness as complicated multi-blob
potential patterns is constrained due the long-standing continuity
issues with the blob shape itself. I see the blob-potential pattern as
useful for noisy results with complicated structures - like how blobs
get used for snow and the like today - but not for real detail. The
surface continuity necessary just isn't there for the latter use except
with stand alone blob elements. In other words - except with non-blobbed
blobs... ;-)
Post a reply to this message
|
|
