 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The following code fails in both pov and megapov (list too long) - but
megapov crashes. Sometimes (well, with varients of this - this version
always seems to crash immediately), the crash occurs straight away,
sometimes I get the standard error message, but them mp crashes on the next
attempt to render (even when I have corrected the fault by increasing the
increment of n to 0.1)
I'm using mp 6a
#declare n = 0;
#declare TestPigment =
pigment{
bozo
pigment_map{
#while(n<=1)
[n rgb 1]
#declare n = n + 0.000001;
#end
}
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
