 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
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>
|
|
|
| |
| |
|
|
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] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> 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
|
|
| |
| |
|
|
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>
|
|
|
| |
| |
|
|
In article <3d5426ce@news.povray.org> , Warp <war### [at] tagpovrayorg> 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] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
