POV-Ray : Newsgroups : povray.advanced-users : POVRay and XML : Re: POVRay and XML Server Time
29 Jul 2024 02:25:31 EDT (-0400)
  Re: POVRay and XML  
From: Patrick Elliott
Date: 2 Jan 2005 15:08:18
Message: <MPG.1c4202478fd89ae7989ca0@news.povray.org>
In article <41d7e026$1@news.povray.org>, Sil### [at] gmxde says...
> Besides: Parsing is just transforming the program to a treelike internal 
> representation form. It's not executing or evaluating the program except 
> you do everything with the preprocessor. So does it really take that 
> long to process handwritten code? I cannot believe that. It will take 
> much longer to execute and evaluate the internal treelike representation.
> 
Ah, but the parser can be used the SDL to generate multiple objects, each 
needing to be parsed as well. You can, for objects like trees, where 
there already exists a program to make SDL for them, use such an external 
application. But what if you wanted sea anemones? The tree program isn't 
designed for that, but you 'could' code maybe 50 lines of code in the SDL 
and have it generate the needed objects as it parses. There are examples 
of things like this, where very complex objects with thousands of parts 
are 'parsed' into existence, using simple math or rules to define them. 
On such complex structures it is also **extremely** impractical, if not 
impossible to "simplify your scene a bit" and get the same result. This 
is bound to take a lot of time to do.

There is even, if I remember right, at least one (I think more) example 
that comes with POV-Ray which has this problem. The parse time is quite 
easily significantly longer than the actual render time in them. And 
there is no way to 'simplify' it. Nor is it practical to just buy a 
faster computer. The parser needs to be efficient 'period'.

Besides, as someone else points out, you have given no real argument for 
why it would be easier to implement a custom XML parser that included the 
'missing' features, than to simply extend the existing parser and the 
programs functionality to support them. That is the point of my last 
post, you are more interested in 'how it looks' than 'how it works', 
which is *always* a far more important issue.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.