![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3d4a9a10@news.povray.org>, Warp <war### [at] tag povray org>
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] mac com>
POV-Ray TAG e-mail: chr### [at] tag povray org
TAG web site: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Christoph Hormann
Subject: Re: Plea for a PoV-Ray binary scene format
Date: 2 Aug 2002 14:08:36
Message: <3D4ACAA4.9A54F44@gmx.de>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 02 Aug 2002 20:08:36 +0200, Christoph Hormann <chr### [at] gmx de>
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 02 Aug 2002 12:37:28 -0500, Christopher James Huff
<chr### [at] mac com> 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] vip bg
TAG e-mail : pet### [at] tag povray org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <jejlkusg7tnpnh4qajkpfdrsc5eu6phngk@4ax.com>,
Peter Popov <pet### [at] vip bg> 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] mac com>
POV-Ray TAG e-mail: chr### [at] tag povray org
TAG web site: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 02 Aug 2002 14:54:02 -0500, Christopher James Huff wrote:
> In article <jejlkusg7tnpnh4qajkpfdrsc5eu6phngk@4ax.com>,
> Peter Popov <pet### [at] vip bg> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"we should not kill a fly with an newspaper. we should use a pumpgun. it
has the advantage that everybody can use it." (selfquotation)
sorry to all pacifists...
[..]
>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.
[..]
if you do not want to see anybody your excellent code just give away your
file in a binary "scene" format like this:
.jpeg, tga.gz, .ppm
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Thorsten Froehlich
Subject: Re: Plea for a PoV-Ray binary scene format
Date: 9 Aug 2002 14:18:23
Message: <3d54076f@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3d4961d7@news.povray.org> , "Philippe Lhoste" <Phi### [at] GMX net>
wrote:
> In my idea, this data would have been already parsed, saving a lot of time,
> and a bit of memory.
You are falling into the old trap that POV-Ray parsing is slow because the
parser is slow. This is not the reason. The slowdown occurs when building
the scene in memory via dynamically allocated memory. Dynamic allocation of
lots and lots of (rather small) objects is simply slow with default
allocators. The parser is fairly fast.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich <tho### [at] trf de> wrote:
> The slowdown occurs when building
> the scene in memory via dynamically allocated memory. Dynamic allocation of
> lots and lots of (rather small) objects is simply slow with default
> allocators.
Which means that creating optimized allocators for those things which
povray creates could drastically increase parsing speed?
Patch makers, where are you? ;)
> The parser is fairly fast.
Of course this doesn't mean it couldn't be faster. If calling a macro which
resides in another file is noticeably slower (eg. inside a loop) than calling
the same macro residing in the current file, it means that parsing itself
could be faster.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Thorsten Froehlich
Subject: Re: Plea for a PoV-Ray binary scene format
Date: 10 Aug 2002 04:11:12
Message: <3d54caa0@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3d5426ce@news.povray.org> , Warp <war### [at] tag povray org> wrote:
> Of course this doesn't mean it couldn't be faster. If calling a macro which
> resides in another file is noticeably slower (eg. inside a loop) than calling
> the same macro residing in the current file, it means that parsing itself
> could be faster.
No, it means that operating systems should supply faster "seek" function ;-)
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |