 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly wrote:
(something)
It's because of the 256 map entries limitations....
Bouf.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly wrote:
>
> The following code fails in both pov and megapov (list too long) - but
> megapov crashes.
You are not allowed more than 256 entries in a color map which explains
the warning message in the official version. You are correct however in
assuming that MP should not crash as a result.
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christophe Bouffartigue <Chr### [at] nanterre marellifr> wrote:
: It's because of the 256 map entries limitations....
That's right, but crashing is still a bug.
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> You are not allowed more than 256 entries in a color map which explains
> the warning message in the official version. You are correct however in
> assuming that MP should not crash as a result.
>
I think Chris Huff was working on removing that limitation, or was it
someone else?
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
>
> Ken wrote:
> >
> > You are not allowed more than 256 entries in a color map which explains
> > the warning message in the official version. You are correct however in
> > assuming that MP should not crash as a result.
> >
>
> I think Chris Huff was working on removing that limitation, or was it
> someone else?
What would be gained by it ?
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > I think Chris Huff was working on removing that limitation, or was it
> > someone else?
>
> What would be gained by it ?
The delightful idea that no software should contain size limitations
of any kind. Especially since today's home computers may accept several Gbytes
of onboard memory. I personnaly don't think that (again nowadays) memory size,
as disk space, is a "good reason" compared to CPU time. But even the last becomes
smaller day after day for the same jobs. So why bother with limitations ?
[Well, sorry for that, but I'm currently enjoying supercomputers for
my research calculations, and once I ran a "small" job using 96 processors in
parallel. Was just for fun since 8 are much more efficient in my case... the
device has something like 256 R12000 MIPS processors though]
*** Nicolas Calimet
*** http://pov4grasp.free.fr
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A819B20.178355ED@gmx.de>, Christoph Hormann
<chr### [at] gmxde> wrote:
> I think Chris Huff was working on removing that limitation, or was it
> someone else?
I was, but haven't gotten it working right yet. If my code got stuck in
0.7, that might explain the crash...
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A819F31.8892A310@pacbell.net>, lin### [at] povrayorg
wrote:
> What would be gained by it ?
Simple: the ability to have more than 255 elements in blend maps.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The problem with dynamic data containers is that they usually take extra
memory (at least temporarily) and are sometimes slower than fixed-sized
data containers.
Of course this shouldn't matter in this case since the required size can
be calculated first, then a proper array allocated and initialized from the
input.
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a829438@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> The problem with dynamic data containers is that they usually take
> extra memory (at least temporarily) and are sometimes slower than
> fixed-sized data containers.
Well, the unlimited version will parse a little slower, since it will
have to resize the array every so often, but unless you have some really
huge blend maps it won't be noticeable, and it will only affect parse
time. I took the approach of resizing the array when needed for
simplicity.
I think color_maps will reallocate to an array of exactly the right size
after parsing, but I'm not certain about the other blend_map types...but
the memory waste for each bland_map won't be very bad even if there are
unused entries.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
