I wrote a simple script to convert fractint color maps to povray 
color_maps so I could use ApoMap to make nice fractal colors for pov, 
but I ran into
"Parse Error: Blend_Map too long."
The map has entries from 0/255 up to 255/255 (inclusive). I looked up 
the documentation which says that color_maps can have from 2 to 256 
entries, and this is exactly 256 entries.
I'm posting this in beta-test because I assume that the documentation is 
correct for v3.6, and that a previous version can handle 256 entries.

I won't include the entire map here for space reasons, but the format of 
the inc file is as follows:
-----------------
/* POV-Ray Color map converted from FractInt format */
#declare colormap_random1 =
color_map{
	[0/255 rgb <166,165,164>/255]
	[1/255 rgb <160,147,160>/255]
...
	[252/255 rgb <45,67,45>/255]
	[253/255 rgb <53,83,51>/255]
	[254/255 rgb <61,99,57>/255]
	[255/255 rgb <69,115,63>/255]
}
-----------------

The file is terminated with a newline, as is standard for text files.
Considering that povray's parser is considerably slower than php or c++ 
I will probably pre-calculate the float values for each of the fractions 
when I finish the script, this was just for testing purposes.

Post a reply to this message

Le 14/12/2009 03:40, CShake nous fit lire :
> I wrote a simple script to convert fractint color maps to povray
> color_maps so I could use ApoMap to make nice fractal colors for pov,
> but I ran into
> "Parse Error: Blend_Map too long."
> The map has entries from 0/255 up to 255/255 (inclusive). I looked up
> the documentation which says that color_maps can have from 2 to 256
> entries, and this is exactly 256 entries.

Confirmed, beta34/Unix sources/amd64

In express.cpp (backend/parser), circa line 2936, in
Parser::Parse_Colour_Map()

The number of entry in the map is strangely managed.
variable j starts at 1, i at 0.
both evolve in parallel (nearly all the time, j==i+1)

For a single point of colour, entry i is filled and then incremented.
For a range (e.g. : [ 0.5, 0.6 colour ... colour ...] ), it's an old
syntax, and i and i+1 entries are used (as they should) and both
counters get +2.

So, with 2 entries used, i=2, j=3.
With 255 entries used, i=255, j=256.

But to cover the bad case of ending a map with an old syntax, the test
for the limit is j > MAX_BLEND_MAP_ENTRIES (whereas it should be
normally i > MAX_... and ONLY if the current entry is an old syntax
should j be used... and as the current test is performed after the
addition of an entry (instead of doing it AT the time of adding one
new), the test is wrongly ending a valid map.

---> after the 255th entry, i=255, j=256, test is failed,
whereas if the test was duplicated for each case (in their beginnings),
it might be easier to protect correctly for 1 entry & 2 entries.


Side note: the number of entries is limited to a parsing of 256
(MAX_BLEND_MAP_ENTRIES), but there a removal of duplicates (sequentially
identical entries) so a map might end shorter afterwards.
From a strict C++ point of view, the colour blend map could be made of
infinite number of entries, with a vector object as container of
BLEND_MAP_ENTRY (itself an object ?) and a proper function to add one or
two new entries, filtering duplicate on the fly (do not add if new entry
is identical to last one). As the map is not ordered, there is no point
in performing that reduction at the closing of the map.
(cost would be identical in worst case)

P.S. : MAX_BLEND_MAP_ENTRIES is also used for another map, but that
other case is simpler, no old syntax, only +1 operation at a time.

P.S.2 : would it make sense to force some ordering of the map ?

Post a reply to this message