 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204 213191226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> Generaly I think that POV can be about 100-1000% (!) faster in some complex
> scenes when using some optimization tricks. I have some ideas, probably
> most of them are not so good, but maybe at lest few can be usefull.
I highly doubt it. Even more since you are the one saying so, judging
from the things you've said in the past.
> now when we i.e. give it to a friend, (OR - use it in some multi computers
> network addon) we must render first 4 scenes, correct pathes to output of
> them, and finaly run main secene.
You shouldn't have to correct the paths, just don't write scenes that
depend on the organization of a particular machine (a path should almost
always be a simple file name). Or just use function images as they are.
> In my idea there is no need to even set save_file or load_file - all is
> "auto-magic" ;)
That won't work. The user would have to delete the file every time they
changed something.
> at first pass - on "new" computer (or after deleting of temorary data)
> computer will take pattern formula and strip it from whitespaces/comments,
> to get "ID" of this pattern "x+y+z*sin(x*10)"
Not possible, the function could easily depend on things you couldn't
detect this way, and different functions could result in the same
"signature" (not very likely, but possible). The best you could get that
way is "the function might not have changed".
> + render time is not about 10:00 but about 0:10
Render time is not affected at all. Total time including parse might go
from 10 minutes to 9 minutes 30 seconds.
> + we can give .pov to any user without explaining him how to prepare all
> HF's, or without sending him ~30 MB data.
You don't have to now. This would shave a couple minutes rendering and
the time to read "render these first" once if they have to render
external files, or a few seconds per render if they use function images.
> + we can run .pov %100 automaticly
No improvement. You could automate it now, in fact several scenes do
this already, using the animation feature. Or you could use a (platform
dependant) shell script. There are lots of other possibilities, you are
trying to solve a non-problem.
> + HF's will be recalculated only if needed
Saving a tiny amount of time. A solution without a problem.
> + users HDD space will not wasted by outdated cache files
But it will.
> - We have to write a patch.
>
> What are other disadvantages ?
You have taken a simple idea for an unnecessary feature and bloated it
into an extremely complex, unpredictable, unportable, wasteful mess.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote in
news:chr### [at] netplexaussieorg
> That won't work. The user would have to delete the file every time
> they changed something.
no - read below,
>> whitespaces/comments, to get "ID" of this pattern "x+y+z*sin(x*10)"
> Not possible, the function could easily depend on things you couldn't
> detect this way, and different functions could result in the same
[...]
all variables are changed into literal values, like :
x *sin(y)*power + clock into :
x*sin(y)*1.5+0.1333
>> + render time is not about 10:00 but about 0:10
> Render time is not affected at all. Total time including parse might
> go from 10 minutes to 9 minutes 30 seconds.
no. Very basic pattern that I used to create mountains, parses 15 sec. on
1500x1500
>> + we can run .pov %100 automaticly
> No improvement. You could automate it now, in fact several scenes do
> this already, using the animation feature. Or you could use a
> (platform dependant) shell script. There are lots of other
> possibilities, you are trying to solve a non-problem.
wouldn't adding 1 keyword be easier/nicer/more comfortable for users then
writting scripts ? What if linux user want's to give it to un-expirienced
windows suer (with fast machine) or vice-versa ?
>> + HF's will be recalculated only if needed
> Saving a tiny amount of time. A solution without a problem.
no. Did You try any complex pattern function yet ? That would generate
realy nice mountains ? Or wait, I will post litte example soon.
>> + users HDD space will not wasted by outdated cache files
> But it will.
only if user wants to do so. I.e. I want to spare some of 60 GB HDD to
increase rendering/parsing speed.
> into an extremely complex
save .tga of 2d array of height_field - is this extremly complex for You ?
> unpredictable, unportable,
why ? I agreee .tga is better then raw data.
> wasteful
?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204213191226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> 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 would take
a huge amount of coding to cover the simplest situations. It is not
worth it.
> > Render time is not affected at all. Total time including parse might
> > go from 10 minutes to 9 minutes 30 seconds.
> 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.
> wouldn't adding 1 keyword be easier/nicer/more comfortable for users 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...
Or use function images, no trouble at all, and minimal speed penalty.
> > Saving a tiny amount of time. A solution without a problem.
> no. Did You try any complex pattern function yet ? That would generate
> realy nice mountains ? Or wait, I will post litte example soon.
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.
> >> + users HDD space will not wasted by outdated cache files
> > But it will.
> only if user wants to do so. I.e. I want to spare some of 60 GB HDD to
> increase rendering/parsing speed.
Then render image files with the desired pattern on a plane.
> > 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.
> > 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. Unpredictable because at
any render it might or might not use a cached version, you'd have to
avoid using it for benchmarks.
> > wasteful
> ?
Of disk space, mainly.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204213191226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> Agree - in thoes case caching would NOT be supported, but as You pointed
> out - this are _very_ rerelly cases.
I said cases where different functions had the same hash "signature"
would be rare, this would be quite a bit more common.
> Mine's statment - 15 sec *but* on 1,7 GHz where render time for 640x480 is
> 5 sec - 75% is pares-time.
Huh? As rendering speed increases, parse speed will also increase. And
in that range it is irrelevant unless you are doing an animation, where
you probably would want to use an image file. For less simplistic
images, it will take a much smaller percentage.
> > Or use function images, no trouble at all, and minimal speed penalty.
> speed - no, se above
Right, see above. Your numbers still support me.
> I don't belive that trimming pattern formula (yes, and changing variables
> into literals as described above) could be much harder for You ?
By "trimming pattern formula", I assume you mean the hash value
"signature" assigned to the function? Yes, it would be extremely complex
to do. You don't seem to have any idea how many things could change
functions, how many things would have to be taken into account, and how
messy that code would look. It would add an entirely new system to
POV-Ray, with very little benefit.
> > 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 :)
Haha, go ahead.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote in
news:chr### [at] netplexaussieorg
> I said cases where different functions had the same hash "signature"
> would be rare, this would be quite a bit more common.
below
>> Mine's statment - 15 sec *but* on 1,7 GHz where render time for
>> 640x480 is 5 sec - 75% is pares-time.
> Huh? As rendering speed increases, parse speed will also increase. And
> in that range it is irrelevant unless you are doing an animation,
> where you probably would want to use an image file. For less
> simplistic images, it will take a much smaller percentage.
but for realy-complex HF's againt it would be a big part of total
parse+render 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
Yes, I can go to another file, render HF-16 and go back to my scene but
this is just UNCOMFORTABLE, and for lame-users (that would i.e. like to
help me to render long aniamtions) - almost impossible.
> By "trimming pattern formula", I assume you mean the hash value
> "signature" assigned to the function? Yes, it would be extremely
> complex to do. You don't seem to have any idea how many things could
> change functions, how many things would have to be taken into account,
> and how messy that code would look. It would add an entirely new
> system to POV-Ray, with very little benefit.
1. sin(x)*power + clock + y+z+rand(seed1) // input
2. sin(x)*power+clock+y+z+rand(seed1) // no spaces
3. sin(x)*3.0+0.1+y+z+rand(777) // constants - ready
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)"
>> 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 ?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote in
news:Xns### [at] 204213191226
> 3. sin(x)*3.0+0.1+y+z+rand(777) // constants - ready
> 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)"
oook... problem is with
a) rand() stream state
b) variables used in functions used in expression
c) global settings, i.e. noise generator type
analysing all functions etc is possible but quite complex - maybe later...
but even now VERY EASY work around is possible - in small steps
1. POV will just ignore problem with variables - it will not 'detect'
change of pattern - yes then caching will work wrong, but this would be
just a beta-test version
2. inform POV with variables are used in expression (that are not obvious -
they are used in functions used in formula)
pattern 1000,1000 { x+y+function_basing_on_my_variable(x,y,z)
cache { depend(my_variable, another_var) }
}
cache implementation is simply - just write (in .id hash file)
variable-name variable-value
i.e.:
my_variable 10.0
another_var 0.33
this code (hash checking) I can write myself (but I will need some help
with merging it with POV).
3. maybe later POV will have some more complex code to egzaminate (and
maybe optimize) expressions ? Then, btw. we can add posibbility to auto-
detect depend variables (as they will be any way detect as it is needed to
create optmization of pattern formula)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204213191226>, "Rafal 'Raf256' Maj"
<raf### [at] raf256com> wrote:
> 1. sin(x)*power + clock + y+z+rand(seed1) // input
> 2. sin(x)*power+clock+y+z+rand(seed1) // no spaces
> 3. sin(x)*3.0+0.1+y+z+rand(777) // constants - ready
>
> 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)"
What you are asking for is the most trivial demonstration:
Assume you have a hash function which gives you 2^128 possible hash values.
Now try to create a hash over all 17 byte sequences. This would be 2^136
different bit pattern. The result is that you would have at least (2^136 -
2^128) duplicate hash value, and probably more depending on the quality of
your hash function. It is very simple and trivial to show that every hash
function has this problem as long as it has a finite range and is supposed
to hash something with an infinite range (functions can be very complex as
you pointed out yourself). Being able to find a duplicate is a matter of
time, not principle.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204213191226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> oook... problem is with
> a) rand() stream state
> b) variables used in functions used in expression
> c) global settings, i.e. noise generator type
Also, objects, image maps or patterns, anything that uses other forms of
data files...I'm not going to bother coming up with more.
> 1. POV will just ignore problem with variables - it will not 'detect'
> change of pattern - yes then caching will work wrong, but this would be
> just a beta-test version
That's not even close to a beta. That's early alpha at best. It just
doesn't work in the majority of cases.
> 2. inform POV with variables are used in expression (that are not obvious -
> they are used in functions used in formula)
> pattern 1000,1000 { x+y+function_basing_on_my_variable(x,y,z)
> cache { depend(my_variable, another_var) }
> }
> cache implementation is simply - just write (in .id hash file)
> variable-name variable-value
> i.e.:
> my_variable 10.0
> another_var 0.33
It's getting more and more bloated, clumsy, and ugly. By this point you
are spending more time making sure the cache system works right then you
are saving with the cache.
> this code (hash checking) I can write myself (but I will need some help
> with merging it with POV).
You've been told many times before, that is not how things are done. Get
a clue...the best advice I can give is to forget everything you think
you know about programming and start again from scratch. You don't just
write up something like this and then cram it into the POV code.
> 3. maybe later POV will have some more complex code to egzaminate (and
> maybe optimize) expressions ? Then, btw. we can add posibbility to auto-
> detect depend variables (as they will be any way detect as it is needed to
> create optmization of pattern formula)
"egzaminate"? That's no English word...
Again, getting more and more complex, and less and less maintainable.
You obviously have no idea what would be required for this.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
