Christopher James Huff <chr### [at] maccom> wrote in
news:chr### [at] netplexaussieorg 

>> all variables are changed into literal values, like :
>> x *sin(y)*power + clock  into :
>> x*sin(y)*1.5+0.1333
> This can't be done. What "literal values" would you change objects
> into? What about data read from files? That's just two examples. It

Agree - in thoes case caching would NOT be supported, but as You pointed 
out - this are _very_ rerelly cases.

>> no. Very basic pattern that I used to create mountains, parses 15
>> sec. on 1500x1500
> Thanks for the example, it supports my statements, not yours.

Mine's statment - 15 sec *but* on 1,7 GHz where render time for 640x480 is 
5 sec - 75% is pares-time.

>> then writting scripts ? What if linux user want's to give it to
>> un-expirienced windows suer (with fast machine) or vice-versa ?
> He has to render some other scenes first, taking perhaps a few minutes
> a piece, big deal...

ok - I have few friends that can run some program for me on summary about 
10 GHz computers (with is enought to make i.e. long animation with very 
precission radiosity + focal-blur in resonable time) but even explaining 
them how to run "this strange program called POV-RAY" took me some time. In 
other words - asking them to change something in *.pov, or render several 
scenes first is complicated. Probably I'm not the only one that have 
friends that use computers only for games.

> Or use function images, no trouble at all, and minimal speed penalty.

speed - no, se above
 
> Yes. Doesn't take very long. Definitely not long enough to justify 
> adding a feature like this, which doesn't really fit in with the 
> existing features.

I realy must pust full source + image.
 
>> > into an extremely complex 
>> save .tga of 2d array of height_field - is this extremly complex for
>> You ? 
> You have an amazing ability to ignore simple logic...I don't believe
> you could really be that stupid. The saving to a file is the simplest
> part of your suggestion.

I don't belive that trimming pattern formula (yes, and changing variables 
into literals as described above) could be much harder for You ?
 
>> > unpredictable, unportable, 
>> why ? I agreee .tga is better then raw data.
> Image format is irrelevant

?

> that complex cache system would be nearly 
> impossible to write portably and efficiently. 

cache system is a problem for YOU ? 
Ok, I'll write it (in few days, focal-blur path first :)

> Unpredictable because at
> any render it might or might not use a cached version, you'd have to 
> avoid using it for benchmarks.

global_settings {allow_cache } with default - OFF

> Of disk space, mainly.

but cache is turned OFF by default. If someone has BIG disc and plays with 
hf's he would turn it on.

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message