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.
>> (1) - And even with this there are some general issues/bugs.
> I hadn't known. :O
>> For more information look at the series of postings working backward
>> from to the first few starting here:
> No idea what you're directing me to. But I will make do with 0-1.
A collection of posts with my ramblings on some of the issues and
proposed changes/fixes - raw_wave, function_interval, etc. - which I'm
giving a go in my povr branch.
Partly, these some answer to your last offline question regarding links
related to working with functions.
> Could I fake/simulate a wider range using an attenuated function output
> coupled with a color map ranging from negative color values to color
> values above 1?
Yep, probably so... We have functions v3.5 on. You 'can' do a lot from
that point onward working around the 'gotchas'. Whether easy or
efficient to do is another question - as you know. :-)
> Do you know where the "color math" happens in source? I'm wondering if
> it's as simple as summing the rgb values.
> Does <-n, 1, 1> = <0, 1-n, 1-n>?
./source/base/image/colourspace.* ./source/base/colour.* has a lot of
it. I have no complete list.
> And how do HDRI ... things ... get encoded?
Posted very recently some details on this elsewhere. :-) I only just
figured this question out myself while otherwise chasing a ghost-bug
really my own doing...
The hdr format uses rgbe and exr uses half floats (16 bits) making both
useful ONLY for dynamic range images and light / environment maps.
I've tossed a good chunk of time in the bit bucket trying to use our exr
implementation as a deep bit per channel format due not really
understanding POV-Ray's implementations... :-(
I've started to look at adding the .pfm/pfm(extended) format (32 bit
floats per channel) as another image file type in my povr branch. It's
supported by quite a few tools (like gimp). It's simple. It's been
around a long time. However, it's not all that far up on my to-do list
at the moment due having new inbuilt functions in povr which can do deep
bit in existing formats using multiple channels.
There, though, I've since found some issues in the ppm/png formats (of
v3.8) if using other than linear encoding/decoding of those images.
Still not sorted everything with png and it's the format I'd most want
to use due the non-lossy compression.
Anyway... Onward! :-)
Post a reply to this message