 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <41d6ae1a$1@news.povray.org>, Sil### [at] gmx de says...
> Thorsten Froehlich wrote:
> But POVRay
> files are rather small. Parsing speed does not matter that much.
>
Ah.. A real professional user of POV-Ray are we? Some SDL takes longer to
parse than the actually rendering. The very idea that size, complexity
and speed in that step is irrelevant is.... incomprehensible..
> Now for the 4.0 rewrite: What will it be like? I just googled a bit, but
> I couldn't find anything about it. How do you know that similar
> limitations like the ones described won't appear again? Is there any
> information about it available?
>
First off... Thorsten Froehlich is on the development team for this
program, so one would think he would have a clue what the flaws are and
why your idea is purely nuts. Yeah, there is one application of XML I can
think of that provides for programming, but it does so by borrowing the
<script></script> tags from HTML and using real languages to do the work.
The rest of it is just parsing of user readable information that defines
simple behaviours and settings for inbuilt functions, not complex
objects. It also uses name spaces to keep things straight, but doesn't
allow directly talking between things in different name spaces. Why?
Because the same 'include' might be used in several different XML
plugins. Each of them could use the same function names, the same names
for objects, etc. and keeping all of them straight, even with namespaces,
is easier is they never directly interface in any way. The interfaces
that are supported involve using a unique UID for each one, to make sure
they don't interfere. With POV-Ray, even with separate spaces, these
things have to interoperate and coexist. That has to be handled 'by the
application'.
What form the data takes in the source file has nothing to do with the
function, only the time wasted a) coding it and b) parsing it. Making it
intentionally more complex doesn't fix the problem, which is not in the
file, but in the way the application handles the information. You could
use bloody Sanskrit on punch cards, Tolkein's elven language transmitted
by brain waves or even your XML idea and it wouldn't alter the fact that
the problem is in the limitation of how the data is handled 'in the
program', not how it is represented in the SDL itself.
Argh.. Its like arguing with someone that insists printing Bible quotes
on toilet paper would be sacrilegious, it has to be exactly such and such
font, this specific size, the paper made from only the finest rose wood
pulp, blah, blah, blah. Only the real argument is if the Reader's Digest
Condensed version leaving out all the verse names and insisting on
calling Moses, "the bearded guys with a stick" was the best way to get
the story across. lol Which is more important, that the program supposed
the feature everyone admits is missing, or that it was painted in the
most recent style? BTW, I equate XML with pointillism. Complicated,
insanely anal and totally pointless if there is a more efficient method
to solve the problem. Maybe, given 50-60 years it will actually look
'useful' for some programming applications, much the way pointillism more
or less accidentally hit on the idea for digital video, years before it
was remotely practical for anyone without a lot of patience and several
loose screws to use the idea. However, I strongly suspect it won't. lol
And for the 99,999th time on these news groups. Version 4.0 features are
not yet even technically 'in development' yet, which makes it a bit hard
to discuss what or how anything will be implemented in it.... Nor has the
team expressed a desire to discuss it and have 500 people telling them
not what will improve the ideas, but how they are doing it all totally
wrong.
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> In article <41d6ae1a$1@news.povray.org>, Sil### [at] gmxde says...
>
>>Thorsten Froehlich wrote:
>>But POVRay
>>files are rather small. Parsing speed does not matter that much.
>>
>
> Ah.. A real professional user of POV-Ray are we? Some SDL takes longer to
> parse than the actually rendering. The very idea that size, complexity
> and speed in that step is irrelevant is.... incomprehensible..
To be honest: I am not a professional user of POVRay. I just want to
render some illustrations for my documents and my webpage with POVRay.
No landscapes, no complex meshes and so on. The sentence you quoted lost
its context: In MPEG parsing speed is essential. It can make the
difference if you can watch a movie on a 300Mhz processor or if you need
a 1000Mhz processor. Assembler optimization is absolutely neccessary for
such parsers. But in POVRay its different: There is no time limitation
of that kind. You don't render 25 pics per second, do you? So what if
you need twice the time for parsing? It won't do that much harm. You
just have to wait a bit longer or buy a faster computer or simplify your
scene a bit.
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.
>>Now for the 4.0 rewrite: What will it be like? I just googled a bit, but
>>I couldn't find anything about it. How do you know that similar
>>limitations like the ones described won't appear again? Is there any
>>information about it available?
>>
>
> First off... Thorsten Froehlich is on the development team for this
> program, so one would think he would have a clue what the flaws are and
> why your idea is purely nuts. Yeah, there is one application of XML I can
> think of that provides for programming, but it does so by borrowing the
> <script></script> tags from HTML and using real languages to do the work.
> The rest of it is just parsing of user readable information that defines
> simple behaviours and settings for inbuilt functions, not complex
> objects. It also uses name spaces to keep things straight, but doesn't
> allow directly talking between things in different name spaces. Why?
> Because the same 'include' might be used in several different XML
> plugins. Each of them could use the same function names, the same names
> for objects, etc. and keeping all of them straight, even with namespaces,
> is easier is they never directly interface in any way. The interfaces
> that are supported involve using a unique UID for each one, to make sure
> they don't interfere. With POV-Ray, even with separate spaces, these
> things have to interoperate and coexist. That has to be handled 'by the
> application'.
>
> What form the data takes in the source file has nothing to do with the
> function, only the time wasted a) coding it and b) parsing it. Making it
> intentionally more complex doesn't fix the problem, which is not in the
> file, but in the way the application handles the information. You could
> use bloody Sanskrit on punch cards, Tolkein's elven language transmitted
> by brain waves or even your XML idea and it wouldn't alter the fact that
> the problem is in the limitation of how the data is handled 'in the
> program', not how it is represented in the SDL itself.
Right. That is why I suggest to put some processing outside of POVRay.
POVRay is a good raytracer. I'm really impressed by it's fine
performance. But I think that not all processing of data should be done
by POVRay. There are e.g. programs that build meshes out of other data.
A good example might be the creation of humanoids out of a collection of
sizes. I will never be able to write anything like human{<0,0,0> 30 40
10} because I cannot define my own objects. It wouldn't make sense
anyway if I could because this would lead to total anarchy in the lower
namespace. But it is still incredible difficult for me to write a parser
that will just replace all "human {...}" with something that POVRay can
render like a mesh. That is what I want. I don't want to touch the
POVRay parser. I just want to get my own preprocessing done. This is
possible with XSLT (though it sometimes looks ugly, I admit).
> Argh.. Its like arguing with someone that insists printing Bible quotes
> on toilet paper would be sacrilegious, it has to be exactly such and such
> font, this specific size, the paper made from only the finest rose wood
> pulp, blah, blah, blah. Only the real argument is if the Reader's Digest
> Condensed version leaving out all the verse names and insisting on
> calling Moses, "the bearded guys with a stick" was the best way to get
> the story across. lol Which is more important, that the program supposed
> the feature everyone admits is missing, or that it was painted in the
> most recent style?
No, that isn't the point. Example: BASIC is a language that is capable
of many things. But C/C++ is better. At least for professional
programmers. No sane man would ever start to write a complex software
project (like Mozilla or sth similar) with BASIC. So it's not a question
of style but a question of language features. POVRay SDL lacks a lot
features I'd like to see. So what do I do? Change POVRay? No! I cannot
because I don't have the time. I'll rather invent some cool system that
is able to emulate the features I'd like to have.
> BTW, I equate XML with pointillism. Complicated,
> insanely anal and totally pointless if there is a more efficient method
> to solve the problem. Maybe, given 50-60 years it will actually look
> 'useful' for some programming applications, much the way pointillism more
> or less accidentally hit on the idea for digital video, years before it
> was remotely practical for anyone without a lot of patience and several
> loose screws to use the idea. However, I strongly suspect it won't. lol
Do whatever you like.
> And for the 99,999th time on these news groups. Version 4.0 features are
> not yet even technically 'in development' yet, which makes it a bit hard
> to discuss what or how anything will be implemented in it.... Nor has the
> team expressed a desire to discuss it and have 500 people telling them
> not what will improve the ideas, but how they are doing it all totally
> wrong.
>
Exactly. And that is why I won't base my faith upon it. I never said
that it should be done this way or that way. I just asked if someone
would like to design an XML version of the POVRay SDL in order to gain
customizable proprocessing levels. No change in POVRay was suggested. If
I did, I apologize.
Besides: If that has been discussed so many times: Why don't you put it
in the FAQ?
Regards,
Bernd Fuhrmann
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <41d7e026$1@news.povray.org> , Bernd Fuhrmann
<Sil### [at] gmxde> wrote:
> To be honest: I am not a professional user of POVRay. I just want to
> render some illustrations for my documents and my webpage with POVRay.
> No landscapes, no complex meshes and so on. The sentence you quoted lost
> its context: In MPEG parsing speed is essential. It can make the
> difference if you can watch a movie on a 300Mhz processor or if you need
> a 1000Mhz processor. Assembler optimization is absolutely neccessary for
> such parsers. But in POVRay its different: There is no time limitation
> of that kind. You don't render 25 pics per second, do you? So what if
> you need twice the time for parsing? It won't do that much harm. You
> just have to wait a bit longer or buy a faster computer or simplify your
> scene a bit.
>
> 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.
Sorry, but you just disqualified yourself. There is no point to continue
this whole thread based on your current knowledge.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> But POVRay SDL isn't a full featured programming langugage.
What is, in your opinion, a "full featured programming language"?
The SDL is turing-complete.
> and so on...
Exactly my point. Too tedious to write?
Besides, you conveniently skipped the hard parts of the code, for
example the conditional inside the sphere.
What good does it do to simply put the code into quotation marks and
add some extra junk around them? That doesn't help the user nor the
program trying to interpret the code (it simply gets the code as a
bunch of strings which it has to parse and interpret anyways, without
the help of any XML parser).
> Besides: Your code is nonsense. 0*0.125 is always 0. Your code will
> either do nothing or never finish.
Besides the point. It was just an abstract example. Set the initial
values to 1 if you want to feel better about it. ;)
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
>
>>But POVRay SDL isn't a full featured programming langugage.
>
> What is, in your opinion, a "full featured programming language"?
> The SDL is turing-complete.
Yes, it is. There are a lot of features missing that are used in a lot
of modern programming languages. Examples:
* Structs/Classes
* References, esp. to functions
* Namespaces
* strict type checking
Other possibly cool features
* Inheritance
* Java-like classes inside classes
* C++ like multiple inheritance
* Lambda expressions (Scheme)
>>and so on...
>
>
> Exactly my point. Too tedious to write?
Well, yes. But I'm even more tedious to rewrite that POVRay parser.
> Besides, you conveniently skipped the hard parts of the code, for
> example the conditional inside the sphere.
Ooops. Sorry for that. What you're missing is this:
[...]
<sphere center="$IndX*5+1, $IndY/4-1.25, -5" radius="$IndX*$IndY/10">
<xsl:if test="$IndX<MaxX/2">
<rgbpigment value="$IndX/$MaxX, IndY/MaxY, 0"/>
</xsl:if>
</sphere>
[...]
But as I just found out: XSLT won't be able to do all transformations
that POVRay would be able to do, since POVRay knows sometimes more about
objects (like max_extent) and so on. Sorry for not knowing this.
Still, this does not solve those namespace and data access problems.
There still needs something to be done. I just have to think about
another way...
> What good does it do to simply put the code into quotation marks and
> add some extra junk around them? That doesn't help the user nor the
> program trying to interpret the code (it simply gets the code as a
> bunch of strings which it has to parse and interpret anyways, without
> the help of any XML parser).
XSLT can process it. Nothing more nothing less.
>>Besides: Your code is nonsense. 0*0.125 is always 0. Your code will
>>either do nothing or never finish.
>
>
> Besides the point. It was just an abstract example. Set the initial
> values to 1 if you want to feel better about it. ;)
Ok, never mind.
I must admit that using XML/XSLT exclusively for scene design and
parsing is mad. But on the other hand I will still require a SDL that
has more features, with configurable preprocessing levels. To give you a
nice example: What about a JavaDoc/Doxygen-like processing? Wouldn't
that be cool?
Regards,
Bernd Fuhrmann
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Bernd Fuhrmann wrote:
>
>> Yes, it is. There are a lot of features missing that are used in a lot
>> of modern programming languages. Examples:
>> * Structs/Classes
>> * References, esp. to functions
>> * Namespaces
>> * strict type checking
>
>
> There are plenty of large high-performance production servers as well as
> end user desktop software written in languages that lack most or all of
> these features. Their lack doesn't make programming languages "not real".
>
>> <xsl:if test="$IndX<MaxX/2">
>
>
> The problem with doing something like this is, you then get to ask a
> question like "transform this scene to remove items that fail this
> condition." How about "select in this scene objects that don't
> intersect the sphere"?
This is not possible without giving XSLT some information about what a
sphere is. This is possible, but it will get
> If you're not going to code everything in XML, anything you don't code
> in XML is going to be opaque to whatever transforms you want to do. You
> won't even be able to say "shift this element 10 units right."
Right.
>> Still, this does not solve those namespace and data access problems.
>> There still needs something to be done. I just have to think about
>> another way...
>
> Write a parser for SDL. Since the help files describe the SDL using
> basically BNF notation, you can use yacc/bison to write a parser for it.
> I'm not understanding why it would be difficult, unless the docs don't
> match the reality, in which case you have a bug report. I mean, you
> even get the source to an existing parser, yes? :-)
I could write my own parser, sure. But that wouldn't fix the problem.
I'd still have unprocessable code.
As mentioned earlier: I will have to think about something different to
solve my problem. XML is a solution but due to certain limits of XSLT
not the best one.
Regards and thanks for all your comments,
Bernd Fuhrmann
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This thread was intersting to read.
I think you guys both (Warp, Bernd) made the point.
I really did think that xml might be more universal way to code.
Povray is just very specific and only for 3d modeling.
But then you realize all the drawbacks... XML is really bloated and less
convenient to read and code, no doubts, even though it may have some
advanced features, which most of people will use very rarely.
It took me 3-4 days to learn and start understanding Povray codings, but
xml I'm not sure at all. For me it would be annoying even to always
write < /> and at the same time it is really easy to learn Povray (if
you familiar with progr. languages).
Another point made by Bernd and he is right that Povray SDL indeed needs
more features to be implemented, I very much support his idea about
1.Namespaces
2.Classes and inheritance
3.References
So you see closer to C++ cooler:)
And they should be easier and more intersting to implement than to write
another parser (for the language which standart may change). Sure that's
a heck of a work, but eventually it should be done.
I'd love too see some of these features in the next version of Povray.
Andrey Skvortsov
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bernd Fuhrmann wrote:
> Patrick Elliott wrote:
>
>> In article <41d6ae1a$1@news.povray.org>, Sil### [at] gmxde says...
>>
>>> Thorsten Froehlich wrote:
>>> But POVRay files are rather small. Parsing speed does not matter that
>>> much.
>>>
>>
>> Ah.. A real professional user of POV-Ray are we? Some SDL takes longer
>> to parse than the actually rendering. The very idea that size,
>> complexity and speed in that step is irrelevant is.... incomprehensible..
>
>
> To be honest: I am not a professional user of POVRay. I just want to
> render some illustrations for my documents and my webpage with POVRay.
> No landscapes, no complex meshes and so on. The sentence you quoted lost
> its context: In MPEG parsing speed is essential. It can make the
> difference if you can watch a movie on a 300Mhz processor or if you need
> a 1000Mhz processor. Assembler optimization is absolutely neccessary for
> such parsers. But in POVRay its different: There is no time limitation
> of that kind. You don't render 25 pics per second, do you? So what if
> you need twice the time for parsing? It won't do that much harm. You
> just have to wait a bit longer or buy a faster computer or simplify your
> scene a bit.
>
> 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.
>
>>> Now for the 4.0 rewrite: What will it be like? I just googled a bit,
>>> but I couldn't find anything about it. How do you know that similar
>>> limitations like the ones described won't appear again? Is there any
>>> information about it available?
>>>
>>
>> First off... Thorsten Froehlich is on the development team for this
>> program, so one would think he would have a clue what the flaws are
>> and why your idea is purely nuts. Yeah, there is one application of
>> XML I can think of that provides for programming, but it does so by
>> borrowing the <script></script> tags from HTML and using real
>> languages to do the work. The rest of it is just parsing of user
>> readable information that defines simple behaviours and settings for
>> inbuilt functions, not complex objects. It also uses name spaces to
>> keep things straight, but doesn't allow directly talking between
>> things in different name spaces. Why? Because the same 'include' might
>> be used in several different XML plugins. Each of them could use the
>> same function names, the same names for objects, etc. and keeping all
>> of them straight, even with namespaces, is easier is they never
>> directly interface in any way. The interfaces that are supported
>> involve using a unique UID for each one, to make sure they don't
>> interfere. With POV-Ray, even with separate spaces, these things have
>> to interoperate and coexist. That has to be handled 'by the application'.
>>
>> What form the data takes in the source file has nothing to do with the
>> function, only the time wasted a) coding it and b) parsing it. Making
>> it intentionally more complex doesn't fix the problem, which is not in
>> the file, but in the way the application handles the information. You
>> could use bloody Sanskrit on punch cards, Tolkein's elven language
>> transmitted by brain waves or even your XML idea and it wouldn't alter
>> the fact that the problem is in the limitation of how the data is
>> handled 'in the program', not how it is represented in the SDL itself.
>
>
> Right. That is why I suggest to put some processing outside of POVRay.
> POVRay is a good raytracer. I'm really impressed by it's fine
> performance. But I think that not all processing of data should be done
> by POVRay. There are e.g. programs that build meshes out of other data.
> A good example might be the creation of humanoids out of a collection of
> sizes. I will never be able to write anything like human{<0,0,0> 30 40
> 10} because I cannot define my own objects. It wouldn't make sense
> anyway if I could because this would lead to total anarchy in the lower
> namespace. But it is still incredible difficult for me to write a parser
> that will just replace all "human {...}" with something that POVRay can
> render like a mesh. That is what I want. I don't want to touch the
> POVRay parser. I just want to get my own preprocessing done. This is
> possible with XSLT (though it sometimes looks ugly, I admit).
>
>> Argh.. Its like arguing with someone that insists printing Bible
>> quotes on toilet paper would be sacrilegious, it has to be exactly
>> such and such font, this specific size, the paper made from only the
>> finest rose wood pulp, blah, blah, blah. Only the real argument is if
>> the Reader's Digest Condensed version leaving out all the verse names
>> and insisting on calling Moses, "the bearded guys with a stick" was
>> the best way to get the story across. lol Which is more important,
>> that the program supposed the feature everyone admits is missing, or
>> that it was painted in the most recent style?
>
>
> No, that isn't the point. Example: BASIC is a language that is capable
> of many things. But C/C++ is better. At least for professional
> programmers. No sane man would ever start to write a complex software
> project (like Mozilla or sth similar) with BASIC. So it's not a question
> of style but a question of language features. POVRay SDL lacks a lot
> features I'd like to see. So what do I do? Change POVRay? No! I cannot
> because I don't have the time. I'll rather invent some cool system that
> is able to emulate the features I'd like to have.
>
> > BTW, I equate XML with pointillism. Complicated,
>
>> insanely anal and totally pointless if there is a more efficient
>> method to solve the problem. Maybe, given 50-60 years it will actually
>> look 'useful' for some programming applications, much the way
>> pointillism more or less accidentally hit on the idea for digital
>> video, years before it was remotely practical for anyone without a lot
>> of patience and several loose screws to use the idea. However, I
>> strongly suspect it won't. lol
>
>
> Do whatever you like.
>
>> And for the 99,999th time on these news groups. Version 4.0 features
>> are not yet even technically 'in development' yet, which makes it a
>> bit hard to discuss what or how anything will be implemented in it....
>> Nor has the team expressed a desire to discuss it and have 500 people
>> telling them not what will improve the ideas, but how they are doing
>> it all totally wrong.
>>
>
> Exactly. And that is why I won't base my faith upon it. I never said
> that it should be done this way or that way. I just asked if someone
> would like to design an XML version of the POVRay SDL in order to gain
> customizable proprocessing levels. No change in POVRay was suggested. If
> I did, I apologize.
>
> Besides: If that has been discussed so many times: Why don't you put it
> in the FAQ?
>
> Regards,
> Bernd Fuhrmann
I have a simple question. Bernd, why do you think it's easier to write
xml/xslt parser with the suport of advanced features rather than to
extend current Povray SDL. i think to write XML parser is more difficult.
Have you tried Povray? it's a very easy script. May be you could help
in Pov parser/SDL development? 4th version would appear sooner.
Povray is not a commercial project so certainly guys work on it with
their spare time, but enthusiastic people like you should be encouraged.
Later it will be possible to write direct convertors from povray to xml.
Though an application of this for me is not obious.
Andrey Skvrotsov
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Right. That is why I suggest to put some processing outside of POVRay.
> POVRay is a good raytracer. I'm really impressed by it's fine
> performance. But I think that not all processing of data should be done
> by POVRay. There are e.g. programs that build meshes out of other data.
> A good example might be the creation of humanoids out of a collection of
> sizes. I will never be able to write anything like human{<0,0,0> 30 40
> 10} because I cannot define my own objects. It wouldn't make sense
> anyway if I could because this would lead to total anarchy in the lower
> namespace. But it is still incredible difficult for me to write a parser
> that will just replace all "human {...}" with something that POVRay can
> render like a mesh. That is what I want. I don't want to touch the
> POVRay parser. I just want to get my own preprocessing done. This is
> possible with XSLT (though it sometimes looks ugly, I admit).
>
I think you are wrong and really underestimate current povray
capabilities! What you have written (except discussed namespaces) can
be done without a problem right now. Not exactly the way you wrote but
similar, there are such things in Povray called objects... RTFM.
You can create your arrays of humans and pass the through the mesh() and
not too ugly.
Andrey Skvortsov
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
