 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
As it seems, POV can write *every* file format it can read (and more)... except
that one file format which was specifically *designed* for POV: DF3.
You just can't write that format with POV. No way. You need a 3rd party tool to
create such files.
That sucks.
I therefore propose to extend the #write mechanism to allow for writing binary
data.
Well, actually I did already implement a patch, so it's more like a request for
a "go/no-go" from the POV team to go ahead and integrate it into official POV.
The mechanism is simple: The statement
#write (fOut, someVal, int16 fooBar, otherVal)
will write fooBar in binary 16-bit unsigned integer format.
That means, if it is a float, the value is rounded to the nearest integer
(values outside the valid unsigned 16-bit integer range are "clipped" to 0 or
65535, respectively), and written to the file in 16-bit binary format
(big-endian, i.e. matching the df3 format byte ordering).
If fooBar is a vector, all components are written in this manner.
A sequence of values can be written in binary format using either of the
following syntax:
#write (fOut, int16 a, int16 b, int16 c, int16 d)
#write (fOut, int16 a b c d)
(Note the absence of commata in the second variant)
Well, that's it. Equipped with this tool, creating DF3 files still remains some
bit of work, but now at least it's possible, and actually not too complicated.
So far I have only implemented 16-bit because for now my main goal is creating
DF3 files, which have 16-bit values in the header and come in a 16-bit voxel
flavor (among other). However, adding support for 8-bit data isn't too
difficult either.
Anyone else who thinks this would be a neat idea?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> As it seems, POV can write *every* file format it can read (and more)... except
> that one file format which was specifically *designed* for POV: DF3.
>
> You just can't write that format with POV. No way. You need a 3rd party tool to
> create such files.
>
> That sucks.
>
> I therefore propose to extend the #write mechanism to allow for writing binary
> data.
>
> Well, actually I did already implement a patch, so it's more like a request for
> a "go/no-go" from the POV team to go ahead and integrate it into official POV.
>
> The mechanism is simple: The statement
>
> #write (fOut, someVal, int16 fooBar, otherVal)
>
> will write fooBar in binary 16-bit unsigned integer format.
>
> That means, if it is a float, the value is rounded to the nearest integer
> (values outside the valid unsigned 16-bit integer range are "clipped" to 0 or
> 65535, respectively), and written to the file in 16-bit binary format
> (big-endian, i.e. matching the df3 format byte ordering).
>
> If fooBar is a vector, all components are written in this manner.
>
> A sequence of values can be written in binary format using either of the
> following syntax:
>
> #write (fOut, int16 a, int16 b, int16 c, int16 d)
> #write (fOut, int16 a b c d)
>
> (Note the absence of commata in the second variant)
>
> Well, that's it. Equipped with this tool, creating DF3 files still remains some
> bit of work, but now at least it's possible, and actually not too complicated.
>
> So far I have only implemented 16-bit because for now my main goal is creating
> DF3 files, which have 16-bit values in the header and come in a 16-bit voxel
> flavor (among other). However, adding support for 8-bit data isn't too
> difficult either.
>
> Anyone else who thinks this would be a neat idea?
Absolutely - I'd love that feature. Raw 8 bit support is critical though.
Cheers,
Edouard.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> schreef in bericht
news:web.49c83b4b7972c2f3c7b40aac0@news.povray.org...
>
> Anyone else who thinks this would be a neat idea?
>
Absolutely. Without any question.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> "clipka" <nomail@nomail> schreef in bericht
> news:web.49c83b4b7972c2f3c7b40aac0@news.povray.org...
> >
> > Anyone else who thinks this would be a neat idea?
> >
>
> Absolutely. Without any question.
Agreed. I've played with df3 briefly in the past, and SDL access would make it
much easier.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
My! Sounds interesting!
These links may be useful?
- Using POVRay as a volume renderer:
http://local.wasp.uwa.edu.au/~pbourke/miscellaneous/df3/
- DF3 utility from Woody:
http://news.povray.org/web.4799e4c49ec55a3e94e61a50%40news.povray.org
- Request for *.df4 format (ASCII text based):
http://news.povray.org/web.47b586279e245a8f94e61a50%40news.povray.org
:-)
--
Carlo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 23 Mar 2009 21:45:47 EDT, "clipka" <nomail@nomail> wrote:
>
>Anyone else who thinks this would be a neat idea?
Me too.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sounds like another language feature better for POV-Ray 4 rather than
the current one.
In other words, rather hacking tons of tiny features on top of the old
SDL, it's better to design a new SDL which is so flexible that you can do
almost anything with it without the need to add core features.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tag povrayorg> wrote:
> Sounds like another language feature better for POV-Ray 4 rather than
> the current one.
>
> In other words, rather hacking tons of tiny features on top of the old
> SDL, it's better to design a new SDL which is so flexible that you can do
> almost anything with it without the need to add core features.
This is a bit different from various other SDL extension proposals, IMO.
SDL is so flexible that you can do virtually everything with it, so most
suggested SDL extensions would just eliminate the need of tons of macros.
Writing DF3 files, however, is something that as of now *cannot* be done with
macros, no matter how sophisticated they are. Not unless you're fine with file
sizes of 16 MB and over at less than 7 bit resolution.
So we have a real gap to be filled here, not just some nice polishing-up.
Plus, IMO there's nothing wrong with polishing up the 3.x SDL a bit either - if
it's easy enough to implement. Which is definitely the case here.
BTW, if we'd be talking about POV 4 SDL, I'd take a totally different approach.
For example, the ability to dump a whole 3D-array to DF3 with just a single
statement would come in handy. But with 3.x SDL being ripe for replacement,
*that* is something I decided to file under "too much effort for too little
gain - to be postponed until POV 4 SDL", as it can easily be done with quite a
simple macro once binary #write is available. Much easier than implementing
native SDL support for an "array dump", as a matter of fact:
#macro Write3DArrayToDf3(filename, a)
#local sizeX = dimension_size(a,1);
#local sizeY = dimension_size(a,2);
#local sizeZ = dimension_size(a,3);
#fopen WriteToDf3_File filename write
#write (WriteToDf3_File, int16 sizeX sizeY sizeZ)
#local iZ = 0;
#while (iZ < sizeZ)
#local iY = 0;
#while (iY < sizeY)
#local iX = 0;
#while (iX < sizeX)
#write (WriteToDf3_File, int16 a[iX][iY][iZ] * 65535)
#local iX = iX + 1;
#end
#local iY = iY + 1;
#end
#local iZ = iZ + 1;
#end
#fclose WriteToDf3_File
#end
There.
To instead add native support for this to POV, not only would something like the
above have to be implemented somewhere - there would also be extra work to do
thinking about a good syntax, implementing code to parse that syntax, taking
care of file handling, checking for unexpected pitfalls, and maybe changing
code to work around these pitfalls. Then checking that it didn't break
anything. That's why I'd agree that *this* isn't worth the pain for 3.x SDL.
Basic support for binary writes, however, is not much of a pain, and its gain
simply cannot be achieved otherwise without 3rd-party tools.
I hope this gives a clear picture of how I think about extending 3.x SDL. Of
course it's just my opinion - yours may differ.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Sounds like another language feature better for POV-Ray 4 rather than
> the current one.
>
> In other words, rather hacking tons of tiny features on top of the old
> SDL, it's better to design a new SDL which is so flexible that you can do
> almost anything with it without the need to add core features.
It would be easy enough to fit binary file access into the current SDL
framework.
FOPEN_DIRECTIVE:
#fopen IDENTIFIER "filename" OPEN_TYPE [FILE_MODE]
OPEN_TYPE:
read | write | append
FILE_MODE
standard | binary
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:
> It would be easy enough to fit binary file access into the current SDL
> framework.
>
> FOPEN_DIRECTIVE:
> #fopen IDENTIFIER "filename" OPEN_TYPE [FILE_MODE]
> OPEN_TYPE:
> read | write | append
> FILE_MODE
> standard | binary
That alone wouldn't quite do the job: How is POV to know whether to write a
particular value as a byte, 16-bit or 32-bit integer?
So when invoking #write, the parameters would have to be marked accordingly
anyway; and in that case the FILE_MODE isn't required at all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
