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

Bernd Fuhrmann <Sil### [at] gmxde> 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

  Then in your opinion for example Lisp and Prolog are not true
programming languages?

-- 
#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

Andrey Skvortsov <sti### [at] listru> wrote:
> Another point made by Bernd and he is right that Povray SDL indeed needs 
> more features to be implemented

  I don't think anyone has questioned that. His solution to this problem
was just simply wrong.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp wrote:
> Andrey Skvortsov <sti### [at] listru> wrote:
> 
>>Another point made by Bernd and he is right that Povray SDL indeed needs 
>>more features to be implemented
> 
> 
>   I don't think anyone has questioned that. His solution to this problem
> was just simply wrong.
> 
That's right I meant that too I saw your postings.

Post a reply to this message

On Sun, 02 Jan 2005 17:17:30 +0100, Bernd Fuhrmann <Sil### [at] gmxde>
wrote:
> >   What is, in your opinion, a "full featured programming language"?
> >   The SDL is turing-complete.
>
> There are a lot of features missing that are used in a lot 
> of modern programming languages.

I have to admit that term "modern" in case of programming makes me think about
all those annoying features of VisualC which makes programming harder. I like
plain simple programming when you think about algorithm rather than "cool"
features of the "language".

> Examples:
> * Structs/Classes

You can mimic structs array of arrays.

> * References, esp. to functions

AFAIK POV-Ray does use references where it benefits in optimizations. Is there
a place in current SDL when POV-Ray does copying of the object rather than
referencing it, you can for sure fix it without introducing XML.

> Other possibly cool features
> * Inheritance
> * Java-like classes inside classes
> * C++ like multiple inheritance
> * Lambda expressions (Scheme)

Obviously POV-Ray SDL is not perfect tool but also obviously it is a lot of
power already and I very often choose it as simple scripting tool for series
of simple operations. For example in samples there is a portfolio which easily
outputs html files with all images rendered. But adding "cool" programming
features just because they are "cool" is questionable. In spite of all POV-Ray
is a renderer so let's concentrate on rendering features: types of objects,
cameras, lights, build-in patterns, antialiasing, HDRI, splines, visual
effects, radiosity etc, etc. There is so much to do around such features that
making programming "cool" if you probably have already your favourite
programming language which you can easily adopt to preparing SDL file is
wasting of man power (IMO).

ABX

Post a reply to this message

> 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:)

Could you elaborate on the 'need' and 'use' of such additional features.
(named Namespaces has been illustrated in this thread, but what about the 
others ?)

I can hardly understand the need of 'named Namespace' feature for a 3D-
rendering program (put aside the Variable programming of the SDL, which 
allow to perform symbolic computation in the SDL rather than on the user-
table), but the 'Classes & Inheritance' as well as 'Reference' really 
trigger nothing in my poor head. So please, bring me some lights on these 
subjects.


-- 




l'habillement, les chaussures que le maquillage et les accessoires.

Post a reply to this message

> 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.
> 

Which features are you lacking ?
Please be as explicit as possible, and try to provide examples if possible.
But remember, Povray is a 3D renderer, not a spreadsheet or an SQL 
database.

I'm really curious to know what features you want.

-- 




l'habillement, les chaussures que le maquillage et les accessoires.

Post a reply to this message

Le Forgeron <jgr### [at] freelocalhost> wrote:
> Could you elaborate on the 'need' and 'use' of such additional features.
> (named Namespaces has been illustrated in this thread, but what about the 
> others ?)

> I can hardly understand the need of 'named Namespace' feature for a 3D-
> rendering program (put aside the Variable programming of the SDL, which 
> allow to perform symbolic computation in the SDL rather than on the user-
> table), but the 'Classes & Inheritance' as well as 'Reference' really 
> trigger nothing in my poor head. So please, bring me some lights on these 
> subjects.

  Let's put it this way: High-end programming features will allow
experienced programmers to make awesome include files for you to use
(things which are currently impossible to do with the current SDL)
in an easy way.

  For example, imagine you could do this:

#declare Scene = load_3DS_file("theScene.3ds");

(Probably not with this syntax, but I wrote it like that for easier
understanding of what I mean.)

  While you might not understand how the things needed to implement this
function work, that doesn't matter if someone else has already made the
hard work for you and is giving you this simple interface to use this
feature.

  So adding high-end features is not so much about what the average user
needs, but more about what some people might then be able to offer to
the average user, for the benefit of the whole community.

-- 
#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