In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> but for realy-complex HF's againt it would be a big part of total 
> parse+render time.

For most images, it is a tiny percentage of total time.


> > Right, see above. Your numbers still support me.
> 
> (parse + render times with and without caching)
> write new HF formula -       15 + 5   15 + 5
> change HF formula            15 + 5   15 + 5
> go back to previous  form.    1 + 5   15 + 5
> change other things in scene  1 + 5   15 + 5

Great, you saved a whopping 14 seconds! Out of renders that can easily 
go several hours! The numbers still support my argument.
Guess what: I don't care. Most people don't care. The only case where it 
makes any significant difference is in an animation, and it is so easy 
to just render a height field image for those cases that there is no 
reason to bother with this addition.


> 3. sin(x)*3.0+0.1+y+z+rand(777)            // constants - ready

Bzzt. Wrong answer. Aside from the fact that you have tokens, not a 
string, the rand() function takes a stream ID, you would need to grab 
the state of the random stream as well, because it could change because 
of previous rand() calls or a different value given to seed().
Similar for a function which uses f_noise3d() or *any* pattern based on 
noise or using turbulence, you would have to take the global noise 
generator into account as well as per-pattern generators, possibly 
including any parameters for it. I'm sure there are even more that I 
haven't thought of. It would basically depend on all the rest of the 
code, it'd be a real headache to keep up to date.


> now show me formula that will result in _differnet_ pattern and that will 
> give _same_ hash as "sin(x)*3.0+0.1+y+z+rand(777)"> 

Show me a hash that is guaranteed to give a unique result for every 
different input. You would pretty much have to store the entire data you 
would use as input to a hash.


> >> cache system is a problem for YOU ? 
> >> Ok, I'll write it (in few days, focal-blur path first :)
> > Haha, go ahead.
> ok. but if I do - You will help me to nicely merge it POV code, right ?

Nope. Not a chance.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message