"gilroy" <nomail@nomail> wrote:
> [description of a POV-Ray binary format]
>
> >
> >What would be the use of such file?
> >Among numerous ideas:
> >- To give a model without revealing some tricks used to make it. So it
still
> >can be rendered with different point of view, lighting, etc.
> >Of course, this format can be disassembled, but in "unrolled" format, ie.
> >with only the raw list of generated objects, without the coding wizardry
> >that could have been used to create it.
>
>     I might be in the minority, but I feel this is actually a good reason
> NOT to do it.  The POV-Ray community is the main reason for using POV-Ray,
> in my mind; and I _like_ the fact that people share code as well as ideas.
> I'm just an old-time coot, I suppose, but I liked the Net in 1994, when
> everyone used transparent, standard HTML and you could "view source" on a
> cool page and learn something.  And I've always liked that about POV-Ray,
> too.
>
>     I think the POVteam should avoid anything that encourages people to
wrap
> their coding in impenetrable layers.  I think they should avoid anything
> that allows one to "give a model without revealing some tricks used to
make
> it".

I agree, I am an open source guy :-) That's why I immediately gave a
workaround...
I just wanted to mention it because often users programming in a script
language (Visual Basic 3, JavaScript, AutoIt, etc.) want to protect their
work. But most of the time, the protection schemes are lame and are easily
broken.
Note that the easiest way to protect your source is not to publish it at
all. I am often frustated to see beautiful images on Internet, and not to
know how they are made :-)

Regards.

-- #=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=# --
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

"Gilles Tran" <tra### [at] inapginrafr> wrote:
> Actually, I tend to think that the use of a binary format to save on
parsing
> time is a non-issue with modern computers. In my experience, large parsing
> times are more often caused by insufficient RAM than by insufficient
> processing speed. A contemporary 1-2 Ghz PC can gobble very large meshes
and
> process long loops very quickly.

I still have a P-II 300 at home :-( Some recursive scenes are very time
consuming.
Now, it is one of the reasons, not the main one.

> This could be more interesting in animation, but then, since the purpose
of
> the animation is usually to change the scene geometry between frames, the
> gain would be minimal in many cases.  (perhaps the IMP people use such a
> binary format, I'm not sure).

Unless the animation is just to fly in a scene. Supposing, of course, that
we can mix binary data (the scene) and parsed one (the animation).

> A binary format could have its uses, but the absence of it is not
currently
> an actual limitation of Povray. I tend to believe that, given the nature
of
> Povray, implementing it in a useful way would be quite difficult.

I didn't said it would be easy... I didn't even said it should be done
immediately. I think the PoV-Ray team has higher priorities, and my "plea"
was more a dreaming on the possibility of this format.

Regards.

-- #=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=# --
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

3d4a3fc9$1@news.povray.org...
> I still have a P-II 300 at home :-( Some recursive scenes are very time
> consuming.

Well, with some luck you'll have a better one when the binary format is
developed ;-)

> Unless the animation is just to fly in a scene. Supposing, of course, that
> we can mix binary data (the scene) and parsed one (the animation).

The possibility of mixing binary data and text data could be the most
interesting possibility, and not just for animation in fact. Like with
radiosity and photons, we could commit an object to a binary format to be
able to reuse it at a later stage.
#if (ExportObject) // first run
    #declare MyObject=object{...}
    #export (MyObject,"myobject.dat")
#else // second run
    #import (MyObject,"myobject.dat"}
#end
object{MyObject ...}
I can imagine a real nightmare of conflicting #declares but this could be
useful

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> You could just standardize on one floating point format for the POV data 
> files, and write platform indpendant code that reads it byte by byte and 
> converts it to a float or takes a float and writes it in the correct 
> format, but the format might have different precision from what is 
> native on some platforms.

  You know what? That's exactly what POV-Ray does currently. :)

-- 
#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 <3d4a9a10@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> > You could just standardize on one floating point format for the POV data 
> > files, and write platform indpendant code that reads it byte by byte and 
> > converts it to a float or takes a float and writes it in the correct 
> > format, but the format might have different precision from what is 
> > native on some platforms.
> 
>   You know what? That's exactly what POV-Ray does currently. :)

Where does POV currently read and write floating-point data? The only 
cases I can think of are the radiosity and photon data files, and I 
never tried transferring them to a different platform...wouldn't think 
they would be worth the effort.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Philippe Lhoste wrote:
> 
> [...]
> Among numerous ideas:
> - To give a model without revealing some tricks used to make it. [...]
> - To ease the creation of PoV-Ray to other 3D formats converters. [...]
> - In the same spirit, to ease the creation of PoV-Ray pre-viewers, [...]

To give my 2 cents concerning this:

Neither of the arguments cited above is really a good argument for a
binary file format:

- You can easily add file writing routines to your sophisticated
build-whatever-macro and thereby avoid revealing your algorithms.  In fact
quite a few include files available (like the HF macros in 'shapes.inc')
have such functions already built in.

- The binary format would be really complicated (not comparable to png,
tiff, etc. at all) so writing converters would not be much easier than
writing them for the text format.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 15 Jul. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Fri, 02 Aug 2002 20:08:36 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> To give my 2 cents concerning this:

I think also binary format should be still somehow 'parsed' for validation
whatever it could mean in that case. And objects have to be allocated in
memory but it takes a lot of time as we know.

ABX

Post a reply to this message

On Fri, 02 Aug 2002 12:37:28 -0500, Christopher James Huff
<chr### [at] maccom> wrote:

>Where does POV currently read and write floating-point data? The only 
>cases I can think of are the radiosity and photon data files, and I 
>never tried transferring them to a different platform...wouldn't think 
>they would be worth the effort.

Ahem... Chris, every thought about the parser itself? <ducks>


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

In article <jejlkusg7tnpnh4qajkpfdrsc5eu6phngk@4ax.com>,
 Peter Popov <pet### [at] vipbg> wrote:

> >Where does POV currently read and write floating-point data? The only 
> >cases I can think of are the radiosity and photon data files, and I 
> >never tried transferring them to a different platform...wouldn't think 
> >they would be worth the effort.
> 
> Ahem... Chris, every thought about the parser itself? <ducks>

I don't get it...the parser doesn't do any binary I/O of floating-point 
values. The closest thing it does is read or write values in plain text 
files. I'm ignoring the possibility of an image file format storing 
floating point values...to my knowledge, none of the formats POV 
supports store floating point values for anything, and if they did I 
wouldn't consider it something POV does, but something from the library 
supporting that format. The parser definitely doesn't do it, though it 
is done at parse time.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On Fri, 02 Aug 2002 14:54:02 -0500, Christopher James Huff wrote:
> In article <jejlkusg7tnpnh4qajkpfdrsc5eu6phngk@4ax.com>,
>  Peter Popov <pet### [at] vipbg> wrote:
> 
>> >Where does POV currently read and write floating-point data? The only 
>> >cases I can think of are the radiosity and photon data files, and I 
>> >never tried transferring them to a different platform...wouldn't think 
>> >they would be worth the effort.
>> 
>> Ahem... Chris, every thought about the parser itself? <ducks>
> 
> I don't get it...the parser doesn't do any binary I/O of floating-point 
> values. The closest thing it does is read or write values in plain text 
> files. 

You're missing his point.  He's saying that the plain-text representation IS
a platform-independent floating-point representation that we convert to and
from on the fly.


-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message