|
 |
On Fri, 9 Nov 2001 00:09:05 -0800, "Ben Chambers" <bdc### [at] hotmail com>
wrote:
>
>"Warp" <war### [at] tagpovrayorg> wrote in message
>news:3be69fc4@news.povray.org...
>> Firstly, the main reason is that the POV-Ray scripting language is an
>> _interpreted_ language. This makes comparison with _compiled_ languages
>> (eg. C++) very unfair.
>
>Hmm... I wonder if we could make a POV-Ray "compiler"? As in, it would
>parse your scene, and then create an executable which would render that
>scene (and that scene only) at a resolution specified on the command line?
Hmm, IIRC OORT did something like that. It's fairly straightforward to
call POV-Ray code directly for a hard-coded scene thus by-passing the
parser. OTOH the render speed would be identical and you would have to
add time for compile & link, thus no net gain.
/Erkki
Post a reply to this message
|
|
|
|
news:3beda714.170951229@news.povray.org...
> >Hmm... I wonder if we could make a POV-Ray "compiler"? As in, it would
> >parse your scene, and then create an executable which would render that
> >scene (and that scene only) at a resolution specified on the command
line?
>
> Hmm, IIRC OORT did something like that. It's fairly straightforward to
> call POV-Ray code directly for a hard-coded scene thus by-passing the
> parser. OTOH the render speed would be identical and you would have to
> add time for compile & link, thus no net gain.
>
> /Erkki
Well, probably not very practical, but you could probably throw in some
scene specific optimizations in there. For instance, if you don't use
radiosity, you could just drop all of that code from the end compile. You
could check reflections, and hardcode which objects will (and won't)
reflect. Things like this. Like I said, probably not worth it, and more
tongue in cheek than anything :)
...Chambers
Post a reply to this message
|
|
