|
 |
Lukas Winter escreveu:
> Am Wed, 15 Apr 2009 13:32:07 +0200 schrieb C:
>
>> Large amounts of dynamically placed objects, such as grass or trees, can
>> take a long time to parse.
>> Usually you would write these objects to a file, and then just use an
>> include statement to place them.
>>
>> What if Pov Ray could handle this instead? You would write something
>> like this:
>>
>> cache "grass"{
>> #declare a=0;
>> #while(a<100000)
>> placeGrass(a)
>> ...
>> #end
>> }
>>
>> Pov Ray will automatically take the results and and save it to a file
>> named grass.
>> Anytime the scene is rendered it will check if the file exists, if it
>> doesn't the contents of the block will be parsed, otherwise the file
>> will just be slotted in in place of the block.
> Actually the code should check if the definition of the cache block and
> any functions/prototypes used in it have changed since the cache was
> written. Else people would start complaining that their changes to code
> in chache blocks don't take effect ;)
>
> I think there is a consensus that SDL 4 should be a bytecode-compiled
> language and as such it will execute much faster than SDL 3 did. Such a
> "cache" should be needed much less than now. But sometimes calculations
> are very time-consuming so I think there is some justification for that
> feature.
> Historically for POV-Ray, plain SDL has been the only way to save scene
> data to disk. I believe that serialization of scene data would be a
> useful feature, but perhaps instead of developing just another binary
> scene format, POV-Ray 4 could just save compiled bytecode to recreate the
> scene or parts of it. Executing it should be almost as fast as loading a
> binary format while supporting all the complexity behind POV-Ray scenes
> perfectly. Perhaps POV-Ray could even do this caching automatically
> without an extra "cache" block.
Now, I'm probably all wrong and messed up here so if anyone cares may
correct me. But I do feel JIT-compiled, bytecode compiled or even
native code compiled SDL would do nothing for performance except perhaps
make it worse should a more expressive and general language be used for
the next SDL.
I've recently been taking a look at Povray beta source, in particular
parse.hpp and associated. It is the purpose of parse to create a long
list of povray objects and it does that by analizing the SDL code,
breaking it down into tokens and calling as it goes the internal
functions which will create the objects, like Create_Sphere or Create_Plane.
Quite frankly, hardly any external general-purpose language would do
much better at pure speed than using this method. They'll still have to
parse and create the objects in the same manner, by binding some of its
particular calls to calls to povray object-creating functions and
methods. But there's also a compilation step. And I don't believe
parsing itself would be faster by going with a general purpose language,
even lightweight ones like Lua, Tcl or Scheme.
How can you be faster for a general purpose language that would allow
for creation of unrestricted user-level functions rather than pov's
textual macros and still bring possibly much more unecessary stuff to
the table? How can that be faster than the SDL's straightforward
parsing by directly calling the creation functions?
I was thinking even if I would use a native compiled language perhaps it
would not be worth it because I believe most users of povray SDL enjoy
an iteractive development style: write a little, parse with low quality
settings, go back, loop. Would the time taken on parsing and
compilation be worth it? Current SDL only takes time on parsing,
compilation merely means calling the internal creation functions.
I'm not against a better, more expressive SDL that would allow for far
better and convenient scripting and do away with many name clashes with
true scoping rules. Just pointing out that that kind of power may also
mean slower rather than higher performance.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
