Has anyone else seen the article in Linux Journal about using POV-Ray for 
visualizing large data sets? The patch stuff is here:

http://staff.aist.go.jp/r-suzuki/e/povray/iso/df_body.htm

I seem to remember people talking about something similar on some posts, 
but not actually implementing anything directly in POV-Ray. Apparently, 
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 
interesting for anyone that has data they can use with it, not to mention 
complex isosurfaces from data you could generate programmatically to take 
advantage of it.

If someone on here did create this and already mentioned it, then 
"Ooops!". ;) All I can say is - too many dang posts to keep track of and 
'search' only works if they know for sure what to look for.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

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?

    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 <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

Patrick Elliott <sha### [at] hotmailcom> wrote:
> Why not also limit color output to 8-bit?

  So you did not read the 3.6 documentation?

  Besides, the patches over patches over patches technology of the
current POV-Ray has more or less come to an end. A patch is seldom
a good solution to anything (except features which can't be done
in any other way, but this is not such a feature), and adding more
and more patches to POV-Ray is only making worse the problem which
is currently overwhelming it.

  When suggesting a new feature, think first if it's *really* necessary
to implement as a patch (eg. because of speed and/or memory issues),
or if it could be done as a script (assuming POV-Ray had a powerful
scripting language). Most patches written in C++ will probably die
with POV-Ray 4 because they will then be possible to be implemented
with the scripting language instead.

  Patches are only good for one thing: Speed. Basically everything else
in a patch is a burden: Patches are rigid (their feature set is usually
limited and fixed), not easily modifiable and they add potential bugs
and maintenance nightmares to the source code.
  "Plugins" made with a powerful scripting language have many advantages:
They can be made versatile and easily modifiable (without having to
recompile anything) and they do not introduce bugs nor maintenance
problems to the POV-Ray source code. In fact, quite many of the current
features in POV-Ray could be removed from the source code and implemented
as scripts.

  Of course POV-Ray 4 is in the very distant future and for now patches
are usually the only way to go. However, you have to be aware that
patches are usually not the answer in the long run.

-- 
#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 <MPG.1bea10575f2e0627989bfb@news.povray.org> , Patrick Elliott 
<sha### [at] hotmailcom>  wrote:
> Has anyone else seen the article in Linux Journal about using POV-Ray for
> visualizing large data sets? The patch stuff is here:
>
> http://staff.aist.go.jp/r-suzuki/e/povray/iso/df_body.htm

In article <MPG.1beb1350c94266cd989c01@news.povray.org> , Patrick Elliott
<sha### [at] hotmailcom>  wrote:
> "...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.

I think you posted the wrong link then.  The link you posted does not point
to a page containing that statement nor does that website mention the word
"hdf" anywhere.  So I am rather confused now.  Is that Linux Journal article
available online somewhere, or could you at least provide the issue
number/month/year?

    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 <4182b551@news.povray.org>, tho### [at] trfde says...
> In article <MPG.1bea10575f2e0627989bfb@news.povray.org> , Patrick Elliott 
> <sha### [at] hotmailcom>  wrote:
> > Has anyone else seen the article in Linux Journal about using POV-Ray for
> > visualizing large data sets? The patch stuff is here:
> >
> > http://staff.aist.go.jp/r-suzuki/e/povray/iso/df_body.htm
> 
> In article <MPG.1beb1350c94266cd989c01@news.povray.org> , Patrick Elliott
> <sha### [at] hotmailcom>  wrote:
> > "...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.
> 
> I think you posted the wrong link then.  The link you posted does not point
> to a page containing that statement nor does that website mention the word
> "hdf" anywhere.  So I am rather confused now.  Is that Linux Journal article
> available online somewhere, or could you at least provide the issue
> number/month/year?
> 
>     Thorsten
> 
Sorry.. Not sure if the article is online anyplace. The only link I 
know of is the one for the resources used to make the patch:

http://www.linuxjournal.com/article.php?sid=7754

It is November 2004, issue #127, pp. 66

Hmm. I did screw up. I copied the link to someone else's patch. The one 
for the articles author, Leigh Orf, is here:

http://research.orf.cx/

Oops! I shouldn't have been quite so enthusiastic about posting and 
double checked which link I was posting. Many, many apologies.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <4182b4b1@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sha### [at] hotmailcom> wrote:
> > Why not also limit color output to 8-bit?
> 
>   So you did not read the 3.6 documentation?
> 
I barely use it, though I keep fiddling now and then. The last time I 
read the docs cover to cover was 3.1. But I got the wrong link anyway, so 
trying to tell me I missed something that already exists is my fault for 
confusing the issue. The correct link is:

http://research.orf.cx/

>   Besides, the patches over patches over patches technology of the
> current POV-Ray has more or less come to an end. A patch is seldom
> a good solution to anything (except features which can't be done
> in any other way, but this is not such a feature), and adding more
> and more patches to POV-Ray is only making worse the problem which
> is currently overwhelming it.
> 
True, but we are more or less stuck with it for now.

>   When suggesting a new feature, think first if it's *really* necessary
> to implement as a patch (eg. because of speed and/or memory issues),
> or if it could be done as a script (assuming POV-Ray had a powerful
> scripting language). Most patches written in C++ will probably die
> with POV-Ray 4 because they will then be possible to be implemented
> with the scripting language instead.
> 
How am I suggesting a new feature? Someone else already did, I just 
tried, and do to excessive enthusiasm, screwed up point people to it.

>   "Plugins" made with a powerful scripting language have many advantages:
> They can be made versatile and easily modifiable (without having to
> recompile anything) and they do not introduce bugs nor maintenance
> problems to the POV-Ray source code. In fact, quite many of the current
> features in POV-Ray could be removed from the source code and implemented
> as scripts.
Oh I agree, I use a plugin system with my telnet client that supports 
pretty much any language that has an ActiveScript component, in theory 
anyway. Some script engines don't seem to want to start correctly using 
the same standard code... Having that later would be very nice. Not 
having it now, I wouldn't mind seeing some attempt to unmuddle some of 
the frustration with 3D formats anyway. The interface would change when a 
plugin system became available and inclusion in an official version would 
become irrelevant, but it would be nice to see some of the more common 
formats we deal with dealt with more easily. It might even encourage me 
to actually read the 3.6 docs and make something with POV-Ray... The 
overall lack of money, talent and software I have discourages me to even 
attempt most of the time.

>   Of course POV-Ray 4 is in the very distant future and for now patches
> are usually the only way to go. However, you have to be aware that
> patches are usually not the answer in the long run.

Yes. As I said, it is nice that it will be possible in the future, but 
for now we are stuck with an insane hodgepodge of stuff that only half 
works. It might be nice to see a few basic file types handled a bit more 
directly, not to mention gracefully in the mean time.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Ok, so now that I have the correct link, no one wants to comment? Sigh...

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message