 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
I have height field with
function 2000,2000 { ...
how can I save / load data (as in radiosity/photons).
Ofcourse instead standart metod to render a separate 16 bit .tga ?
This would very usefull i.e. in animations with big terrain
--
#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] 204 213191226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> I have height field with
> function 2000,2000 { ...
>
> how can I save / load data (as in radiosity/photons).
>
> Ofcourse instead standart metod to render a separate 16 bit .tga ?
>
> This would very usefull i.e. in animations with big terrain
You can't. You could render an image with an orthographic camera pointed
at a plane with that pattern instead though...this was the common
technique before the function image was added.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > I have height field with
> > function 2000,2000 { ...
> >
> > how can I save / load data (as in radiosity/photons).
> >
> > Ofcourse instead standart metod to render a separate 16 bit .tga ?
> >
> > This would very usefull i.e. in animations with big terrain
>
> You can't. You could render an image with an orthographic camera pointed
> at a plane with that pattern instead though...this was the common
> technique before the function image was added.
Be careful with this method as I have found that there is a slight
difference in how the images are used. In the function heightfield,
(essentially) the 'vertices' of the pixels are used, whereas for an
image_map type, the centres of the pixels are used. So, essentially, a
2000x2000 function HF is equal to a 2001x2001 image_map HF. In most
applications of HFs this isn't a problem or concern though, it is really
only neccessary to pay attention when splicing HFs together.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
6D4### [at] netplexaussieorg
> You can't. You could render an image with an orthographic camera pointed
> at a plane with that pattern instead though...this was the common
> technique before the function image was added.
Yes I know, but how about a patch like
height_field { // ...
pattern 2000,2000 { // ...
save_data "" load_data "" // #1
}
save_data "" load_data "" // #2
}
simmilar to photons/radiosity ? This is another thing that might strongly
seed up rendering, and probably is easy to implement.
#1 is for every pattern (not only in HF) - just saves array of 2000x2000
colors
#2 is for every HF (even for tga "texture.tga" etc) that is usefull for
smooth HFs - it saves normal informations. Informations are stored before
appling transforms so it is easy to transform HF and load data.
Any comments ? Is it worth coding ?
I.e. simple scene with 3000x3000 HF with complex pattern function (for
generating interesting moutains) in 640x480 took about 60 s to parse and
only 10 to render (on Athlon 1,7)
--
#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:
> Any comments ? Is it worth coding ?
IMO no.
It will be easier and better to just make a small macro which you can
use to create an image file with the given pattern (and the resolution is
given as rendering parameter). This way you can "save" to any format
supported by povray (png is best for compression).
The macro would simply create a plane using the given pattern as pigment
and create a camera for rendering it.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:3d951333@news.povray.org
> The macro would simply create a plane using the given pattern as pigment
> and create a camera for rendering it.
1. alsow path is very easy, just open file and flush there texture memory
2. it is impossible - as macro sholud create _new_ scene (discard all
previous objects, lights, set new camera and render it).
3. only way is to prepare a little scene for rendering HF purposes, but
imho it is little uncomfortable.
Assume that I want to implement it - where should I start - to dump
pattern aaa,bbb { ... } array into text file after reaching keyword
save_data ?
--
#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:
> 1. alsow path is very easy, just open file and flush there texture memory
No, it's not as easy. You have to write the patch and it has to be included
eg. in megapov, and this happens sometime in the future.
And as always, hardcoded internal features are usually a lot less
versatile than a macro and the often needlessly clutter povray.
> 2. it is impossible - as macro sholud create _new_ scene (discard all
> previous objects, lights, set new camera and render it).
Why would you want to create a file with a scene which simply
needs to *use* the file?
> 3. only way is to prepare a little scene for rendering HF purposes, but
> imho it is little uncomfortable.
That's what the macro would be for.
This is not unprecedent at all. For example, look at the tiled texture
creation macro by Chris Colefax.
Besides, why would you want the raw texture data dumped to disk when you
can have it in compressed png format? And without patching anything.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204213191226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> Any comments ? Is it worth coding ?
Not in my opinion. Just use a small scene with the pigment on a plane,
or a macro. More flexible, and doesn't require a patch. And it isn't so
easy, you could hack up an ugly little patch that dumps raw data to a
file, but the result would be that odd little POV-only image.
#2, saving the normals, just sounds useless: it doesn't take that long
to compute.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27 Sep 2002 15:54:27 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> height_field { // ...
> pattern 2000,2000 { // ...
> save_data "" load_data "" // #1
> }
> save_data "" load_data "" // #2
> }
It could be rather more interesting output as df3. Then you could use df3
cross section as your pattern and whole df3 as faster isosurface. But I agree
with other it is more effective to use two pass rendering. It is becouse it
could save memory, virtual machine resources and time for parsing.
> simmilar to photons/radiosity ?
It is becouse photons/radiosity have no chance to be outputed as raytraced
image.
> This is another thing that might strongly
> seed up rendering, and probably is easy to implement.
Writing it as another raytracing is the same speed. Note you have all
necessary macros already written in screen.inc include file.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX <abx### [at] abxartpl> wrote in
news:lbufpugbe3cien2isqkvbvi7gkudscq99c@4ax.com
[...]
Maybe I didnt pointed where IMHO it could be usefull.
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 know it would be best to implement them myself. Currently I'm
implementing a path to speed up focal blur calculations :) It will have
some limiationts but in some cases it should work about x2..x5 times faster
with almost identical quality.
But this HF is someting too hard for me (currently).
Back to HF (sorry for long post)
We have scene like :
// file - testscene.pov
[...]
height_field { ... }
height_field { ... }
height_field { ... }
height_field { ... }
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.
In my idea there is no need to even set save_file or load_file - all is
"auto-magic" ;)
height_field { pattern 1000,1000 { x+y+z * sin(x *10) } cache_data }
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)"
Computer counts this pattern in 1000x1000 resolution, and saves it (as
suggested) as .png / .tga file.
File name is "testscene_cache0.tga"
Formula ID is saved in testscene_cache0.id - "x+y+z*sin(x*10)"
Same with other HF's creating testscene_cacheN.tga and .txt N=1..3
-------------
In next pass, if change is done onlyt to 3-rd HF formula,
1-st HF - computer searches all testscene_cache*.id
at whe found that formula "x+y+z*sin(x*10)" is already saved on HDD - so
computer just load's it. Same for other HF's except 3-rd.
Copmuter see that one of HF is not cached, so he recalucalets it (as in
first-pass).
In addition computer may notice that one of files
cache_scene*.tga what NOT used, and computer may delay it (to save users
HDD space) or better - this file can be deleteed i.e. after some time (like
3 days) - something simmilar to i.e. WWW browsers cache.
-------------
In result, if we have 4 HF's each 3000x3000 with COMPLEX formulas and scene
is simple in 640x480 then :
+ render time is not about 10:00 but about 0:10
+ we can give .pov to any user without explaining him how to prepare all
HF's, or without sending him ~30 MB data.
+ we can run .pov %100 automaticly
+ HF's will be recalculated only if needed
+ users HDD space will not wasted by outdated cache files
- We have to write a patch.
What are other disadvantages ?
--
#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
|
|
| |
| |
|
|
|
|
| |
|
|
