 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
playing with media and clouds, I tried to write a macro to create binary
df3 files from within SDL.
Of cause I failed 'cause it seems to be unpossible to write a binary
zero to a file (will allways be interpreted as end of string).
I renembered a macro created by Gilles Tran (makeclouds) which included
to render a series of images corresponding to slices of the density
volume and merging these images with an external program together.
In order to simplify this approach I wrote my own macro, which writes a
density file in ASCII format and convert it with a tiny PERL script into
the binary df3 format.
Eventhough it still needs an external script, I think it's a more
versatile approach adressing the same problem. There is no more need to
render slices anymore; instead of this you get only one file which have
to be converted. As this file is pure ASCII it can be converted easely
without writing a program which have to handle image formats and data.
OUTLINE:
The macro itself takes a pre-declared pigment as input. Together with
the file name to write to and the voxel resolution, the corners of
density extents are specified.
The pigment is turned into a vector function which is evaluated for the
midpoint of every voxel. The resulting color value will then be
interpreted as density by means of the .gray operator and written to the
ascii file.
I post the macro together with the PERL script in p.b.s
the image shows just a simple test:
generation of the ascii density file (90x30x60 = 162000 voxels) : 10s
conversion to binary df3 : < 1s
comments, critics and suggestions for improvment are welcome (as ever)
... dave
Post a reply to this message
Attachments:
Download 'df3_cloud.jpg' (15 KB)
Preview of image 'df3_cloud.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David El Tom wrote...
> generation of the ascii density file (90x30x60 = 162000 voxels) : 10s
> conversion to binary df3 : < 1s
>
> comments, critics and suggestions for improvment are welcome (as ever)
>
> ... dave
Really nice, but what about rendering time ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
LightBeam schrieb:
> David El Tom wrote...
> > generation of the ascii density file (90x30x60 = 162000 voxels) : 10s
>> conversion to binary df3 : < 1s
>>
>> comments, critics and suggestions for improvment are welcome (as ever)
>>
>> ... dave
>
> Really nice, but what about rendering time ?
Gilles Tran gives a very good comparision between diffrent methods when
it comes to render clouds.
http://www.oyonale.com/ressources/english/sources13.htm
for this one it was appr. 10min with AA and high media-sample settings
(30,100)
... dave
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David El Tom <dav### [at] t-online de> wrote:
> Gilles Tran gives a very good comparision between diffrent methods when
> it comes to render clouds.
> http://www.oyonale.com/ressources/english/sources13.htm
yes very good. I even sucessfully used it in animations.
But the real problem with this method is that you reach the 255 raytrace
limit very soon when one cloud is in front of another.
Would it be possible to hack povray to accept trace levels of >255 ? or at
least not make the pixel black when it reaches the maximum trace level?
Post a reply to this message
Attachments:
Download 'sky_red_cloud.png' (374 KB)
Preview of image 'sky_red_cloud.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaap schrieb:
>
> yes very good. I even sucessfully used it in animations.
>
> But the real problem with this method is that you reach the 255 raytrace
> limit very soon when one cloud is in front of another.
> Would it be possible to hack povray to accept trace levels of >255 ? or at
> least not make the pixel black when it reaches the maximum trace level?
>
>
> ------------------------------------------------------------------------
>
if you want to use this approach to get a dense cloud cover there are
some drawbacks. You have to make sure that the containers of the cloud
do not overlap -> this will probably give some strange artefacts.
concerning your questions:
it would be quite tedious to modify the source code and tracing all the
dependencies throughout all the files.
Is there an example of a scene showing those black dots?
And which media settings do you use?
Are you aware, that the docs contain an error in the media section?
DEFAULTS
docs correct
---- -------
intervals 10 intervals 1
samples 1,1 samples 10,10
I'm not really sure but I always thought intervals spwans a new trace
for each interval.
So try keeping the intervals low and instead raise the samples.
....dave
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David El Tom <dav### [at] t-onlinede> wrote:
> concerning your questions:
> it would be quite tedious to modify the source code and tracing all the
> dependencies throughout all the files.
ok.
> Is there an example of a scene showing those black dots?
found one. (attached)
> And which media settings do you use?
> Are you aware, that the docs contain an error in the media section?
I used:
media{
scattering{1,GammaColor(C_Sun,0.3)*0.0003*0.75}
absorption (1-C_SkyBlue_05)*0.001*0.6
intervals 1 // (or 2)
density{
density_file df3 "include/cloud1.df3"
interpolate 1
}
}
I think the problem is with the ~90 layers in the cloud. If you look at the
cloud at an angle it will be 180 layers? I can overlap a small corner of
clouds without running into problems, but it will if two clouds overlap
more than that.
by the way, the clouds look really nice if you fly along them in an
animation!
Post a reply to this message
Attachments:
Download 'water_test_1.png' (403 KB)
Preview of image 'water_test_1.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
also, viewing the clouds exactly along the x,y or z axes does not work.
(I renders them like this to manually adjust the bounding box of the media)
Post a reply to this message
Attachments:
Download 'showcloud_1.png' (80 KB)
Preview of image 'showcloud_1.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jaap" <jws### [at] yahoocom> wrote:
> David El Tom <dav### [at] t-onlinede> wrote:
> > Is there an example of a scene showing those black dots?
> found one. (attached)
It's the first few frames of this animation: (8MB on a slow server)
http://jwstolk.xs4all.nl/wisse/f4animation_test10.mpg
For the reaming frames I disabled most of the clouds.
Note that the problem is not caused by overlapping cloud bounding boxes in
3D, that would be easy to avoid. The problem is when two clouds overlap in
the rendered (2D) image.
of course using less layers for each cloud would allow for some clouds to
overlap, but that makes the clouds look less good.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaap schrieb:
> also, viewing the clouds exactly along the x,y or z axes does not work.
> (I renders them like this to manually adjust the bounding box of the media)
>
>
> ------------------------------------------------------------------------
>
the rectangular shapes looks more like an coincident surface problem
then a max_trace_level problem.
I will check the problem concerning the viewing angle.
Have to check if it's a inherent problem of the density file or it is a
problem of the macro or the script.
I wonder what you mean with layers as the density file compared to a
desity function is like an image_map compared to a procedural texture.
b.t.w really nice animation
... dave
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David El Tom <dav### [at] t-onlinede> wrote:
> the rectangular shapes looks more like an coincident surface problem
> then a max_trace_level problem.
I made sure that the clouds do not overlap in 3D, so unless it's within a
cloud it can't be a coincident surface problem. I think rectangular shapes
make sence if you run out of trace levels becouse another "patch" of cloud
is added.
Gilles decribes them as "vertical lines"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
