|
|
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
|
|