 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 28 Feb 2002 13:57:06 -0000, "Gleb" <gk1### [at] soton acuk> wrote:
> > As you might know, you are not supposed to be able to write binary files...
>
> By the way, why there is such a limitation? It should be useful.
You know, POV-Ray is a raytracer not... everything.
It is supposed to take script as input with SDL and produce image as output.
Writing binary files with SDL is like writing viruses with it - erhaps
possible but more efficient with external, specialized tool.
For example in my case I can export all values as text and produce proper df3
file with external tool written in any free compiler. The problem is my
laziness :-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gleb wrote:
>
> > As you might know, you are not supposed to be able to write binary
> files...
>
> By the way, why there is such a limitation? It should be useful.
>
Portability is the main concern. As soon as writing binaries includes
more than just writing single bytes the behaviour will be strongly
platform dependant.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"W?odzimierz ABX Skiba" <abx### [at] babilonorg> wrote in message
news:ctds7u8u46hhf0crd5uaond5jsb9so71l9@4ax.com...
> You know, POV-Ray is a raytracer not... everything.
> It is supposed to take script as input with SDL and produce image as
output.
Well, I agree, maybe it was before, but now it is almost... everything.
Now it takes not only a script as input, but also some binary files
(images, dencity) and possibility to interact with them (trace).
Moreover, POV SDL has almost unlimited abilities for creation such a files
with unique effects.
> Writing binary files with SDL is like writing viruses with it - erhaps
> possible but more efficient with external, specialized tool.
The danger of viruses is not a point at all, you know, there are pure
text-looking ones.
From the other point, for example, possibility of reading
binary data into array and loading a "binary image" of
once parsed huge complex object would save a lot of time and/or space.
> For example in my case I can export all values as text and produce proper
df3
> file with external tool written in any free compiler. The problem is my
> laziness :-)
I do appreciate this, but again, to create some files one need POV or
similar
engine. By the way, a binary file produced with your recent beta-test code
looks very interesting when interpreting as an image.
I like POV as it is, but imho tendency of the development itself
will take it's own anyway.
Regards,
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3C7E4A40.365ADF05@gmx.de...
> Portability is the main concern. As soon as writing binaries includes
> more than just writing single bytes the behaviour will be strongly
> platform dependant.
Do you really mean that storage device drivers are more complex in access
than display ones?
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gleb wrote:
>
> Do you really mean that storage device drivers are more complex in access
> than display ones?
>
This does not have anything to do with device drivers.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> Portability is the main concern. As soon as writing binaries includes
> more than just writing single bytes the behaviour will be strongly
> platform dependant.
But writing bytes is all one needs.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3C7E50DA.A9B7F6F4@gmx.de...
>
>
> Gleb wrote:
> >
> > Do you really mean that storage device drivers are more complex in
access
> > than display ones?
> >
>
> This does not have anything to do with device drivers.
Same question: :is graphic portability more complex thing? Sorry, if the
question looks stupid and/or has well-known
answer. I just want to get the real reason.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gleb wrote:
>
> > This does not have anything to do with device drivers.
>
> Same question: :is graphic portability more complex thing? Sorry, if the
> question looks stupid and/or has well-known
>
> answer. I just want to get the real reason.
There is no graphics output in Povray, only some versions call API
functions of the OS to display the render in the platform specific code.
This has nothing to do with the rendering program itself.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3C7E58B5.F6B0933C@gmx.de...
> There is no graphics output in Povray, only some versions call API
> functions of the OS to display the render in the platform specific code.
> This has nothing to do with the rendering program itself.
>
This is exactly what I mean: there is no graphics in Povray, but there is
somehow binary images output
and and input, isn't it?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gleb wrote:
>
> > There is no graphics output in Povray, only some versions call API
> > functions of the OS to display the render in the platform specific code.
> > This has nothing to do with the rendering program itself.
> >
> This is exactly what I mean: there is no graphics in Povray, but there is
> somehow binary images output
> and and input, isn't it?
Yes, but this is platform independant due to precautions in the image file
format definitions. Simply writing your floats and vectors to a file as
binary with some IO functions would be different.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
