In article <4180a39d$1@news.povray.org>, tho### [at] trfde says...
> In article <MPG.1bea10575f2e0627989bfb@news.povray.org> , Patrick Elliott 
> <sha### [at] hotmailcom>  wrote:
> 
> > one thing this does is extend the file parser for density files to deal
> > with some stuff it couldn't, including supporting decimal data, instead
> > of requiring it be imported as ranges between 0 and 255. Looks
> 
> Apart from intentionally not supporting decimal data, did you look at
> POV-Ray 3.6 lately?
> 
At that specific feature? No. I just thought it was an interesting 
article and wondered if anyone had seen the patch.

I tend to agree with the author of the patch though. We have enough 
situations where we have to convert real world data into the artificial 
limits POV-Ray often imposes for data. It doesn't make a lot of sense to 
'intentionally' introduce yet another situation where the data has to be 
converted from decimal to integer. How exactly does placing such 
artificial limits on the data help anyone use POV-Ray for visualizing 
data that *cannot* be collapsed into such a limited and rigid set of 
values? Why not also limit color output to 8-bit? After all, producing 
the image is so much more important than making sure it is accurate...

Yeah, I understand why, but this is an extension specifically for HDF. It 
doesn't supercede or change the existing limited system, it is 
specifically designed for the specialized import and use of data that 
cannot and does not conform to the limits imposed by the existing density 
file format. This includes the amount of data available:

"...each HDF file is a snapshot of the model state at a given time and 
contains 12 3-D variables per file. It often is illustrative to look at 
multiple variables, such as cloud, rain, hail and snow."

Basically, his format lets you retrieve individual surfaces in a single 
file to by name, like this:

density_file hdf "blah.hdf", "foo"

This would read in only the data for the 'foo' section of the hdf file. 
Not only can you use raw data from a simulation source that isn't 
artificially scaled to an integer range, which would make his simulation 
of complex supercell thunderstorms impossible, but the data for all 
aspects of it, including rain and the rest, can be rendered from a single 
source. A similar patch could be made for say DXF, so allow each sub 
object to be read in as its own object, without the currently insane 
method of relying on some third party application to misconvert the data 
or collapse the entire thing into one object you then can't bloody do 
anything with. Forgive me for thinking that this 'might' be a better idea 
that forcing artificial and questionable limits on the data, while 
requiring everyone to rely on the often incomplete support for POV-Ray 
exporting in the applications to use other 3D formats. I personally think 
it is a brilliant solution.

Maybe you where trying to make some other point though? For that matter, 
if it does include something for HDF, what would I look for and how 
versatile is the feature? I suspect already, from your statement about 
intentionally limiting it to integer, that the answer is 'not very'.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message