On 4/13/20 2:03 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
...
> 
>> Reminds me, our .grey and general color to grey conversion also has
>> issues with being - off standard, I guess. A question on my - think more
>> deeply about it someday - list, is whether on the fly color to grey
>> conversion should get pulled from povr. I have this feeling it isn't
>> 'really' necessary today.
> 
> I suppose - though I see no harm either.
> Now, having brought that up, it reminds me that all 3 channels get combined into
> a single scalar output.

That, today, only happens when you somehow invoke the rgb to grey 
functionality as with .grey, output to grey, etc. If you code
function { pattern brick } what that function returns is the single 
pattern value that would normally be used to drive the *map.

I got tangled up because I was using .<channel> to grab particular 
colors and some patterns had default maps while others did not.

> If that could be done in a deterministic manner such that the channels could be
> extracted back out (albeit with lower, but usable precision) then it would be a
> nice way to cheat / work-around vector function output.
> "Pairing functions" could be used, and maybe there are other better ways...
>
https://stackoverflow.com/questions/919612/mapping-two-integers-to-one-in-a-unique-and-deterministic-way
> 

Thanks for links.

Today I have the vector support sitting in the job pile with some sort 
of more general just in time compiling which would be used for all the 
language elements of the 'SDL' scene input. However, I'm unlikely to do 
such support as today's SDL, but rather by moving to tcl, lua - or maybe 
python. That work is way down the list though now and again I spend some 
days looking at the how of using chunks of POV-Ray as callable functions 
with bindings to whatever language.

Aside: IIRC lua has moved to llvm, but it's first vm in structure looked 
to me to be pretty similar to the vm and function handling in POV-Ray 
today. Which by the way I'm finding pretty efficient performance wise. I 
plan to post about some new povr inbuilt functions later today, two of 
which are 1 to 8 pairwise min/max implementations. In my performance 
comparisons these, at 8 pairs, with a min or max of those results on the 
back end, were only a little over 20% faster than using 15 min()s/max()s 
in a de-nested/flat way to do the same thing. This is in line with 
results from work I did more a decade ago where I created C++ versions 
of some complex SDL function/vm stuff hoping for big performance gains 
that did not materialize.

So, I see 'ease' of coding up what you want as the primary reason for 
something better - which gets back to your request to better vector 
support.

The v.zyx syntax has a name - like twizzling or something - and it's 
offered in some C++ vector template classes at significant complexity to 
those and with hits to compile time and compile memory requirements. We 
too have some issue internal to our current code with single value 
references being awkward - and somewhat inefficient - with our current 
vector template implementation (mostly for reasons of the more limited 
C++ version for which it was coded). Inside the code you'll see v.[X] 
and v.x() everywhere which are both ugly in C++. The former requires an 
overload on the [] - which inhibits optimizations all too often for one 
and sometimes doesn't get optimized away at all. The latter is a 
function/method call hard coded to the position in the vector which is 
often more efficient, but yep, still uglier than being able to code v.x. 


Anyway... Off to other efforts.

Bill P.

Post a reply to this message