On 3/24/21 6:20 AM, William F Pokorny wrote:
> On 3/23/21 2:06 PM, Bald Eagle wrote:
>> On 3/22/21 7:27 AM, William F Pokorny wrote:
>>
>>> The short answer if you are using v3.7 or v3.8 more or less stock, is 
>>> you can use the 0-1 map range only(1).
>>
>> That's what I thought.
>> Any chances on future alternate mechanism for color/pattern/texture 
>> mapping in POV-Ray or povr?
> 
> In my povr branch, extensions, yes.
> 
> Therein I've as much been clearing issues as adding function. The core 
> map mechanism itself doesn't care what the map range is. It's the wave 
> modifier functionality and the "bridge code" between pattern(s) / 
> function(s) and the map mechanism which have limits <= v3.8 today. Some 
> of these bridge limitations enabling real issues in current patterns to 
> go 'mostly' unnoticed.

Ah, ok.  That's the part I was missing.  I thought maybe it was a

#if (PointE > 1)
#declare PointE = 0
#end

Sort of thing.

I just did a bunch of function/pattern work, and I think I know what 
you're talking about.  Which patterns have the hidden problems?  Part of 
what I'm doing is discussing how POV-Ray generates and uses its 
patterns, so I could weave that into what I already have, and maybe 
knowing what the underlying problems are, the ole' brain might come up 
with something - - - when I'm _trying_ to sleep.   ;)



> ./source/base/image/colourspace.* ./source/base/colour.* has a lot of 
> it. I have no complete list.


Ah, right.  Thanks for the reminder.

>> And how do HDRI ... things ... get encoded?

Have you looked at .raw?  I know next to nothing about it except that it 
seemed flexible, was used for ultra high-end digital cameras, and you 
can jam a whole lot of information into it besides the image data.

> Anyway... Onward! :-)
> 
> Bill P.


Indeed.   Ever onward.

- and -

If you ever have ramblings on the C / C++ code you're writing, I'd be 
interested in reading that - maybe in the programming section.


Thanks for the info as always

Post a reply to this message