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

Andrey Skvortsov <sti### [at] listru> a écrit :


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


-- 
La mondialisation ou la délocalisation, non; L'autarcie ouverte, oui!

L'égalité des sexes ne sera une réalité que lorsqu'il y aura autant
d'entreprises, surfaces de vente et diversité de propositions tant pour 
l'habillement, les chaussures que le maquillage et les accessoires.

Post a reply to this message

Bernd Fuhrmann <Sil### [at] gmxde> a écrit :

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

-- 
La mondialisation ou la délocalisation, non; L'autarcie ouverte, oui!

L'égalité des sexes ne sera une réalité que lorsqu'il y aura autant
d'entreprises, surfaces de vente et diversité de propositions tant pour 
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

Le Forgeron <jgr### [at] freelocalhost> wrote:
> Which features are you lacking ?

  Some things are impossible to do currently. For instance, you can't
read a file with some unspecified format. For example, you can't code
a 3DS or DXF import macro with the SDL because you can't read such
files with the current SDL. In fact, you can't even write many file
types because you can't currently write the byte 0 to a file.
  Moreover, the SDL lacks tools for making data containers such as
doubly-linked lists, weighted trees, octrees, queues and so on (while
you can hack some of this into SDL arrays, it's usually quite inefficient,
slow and awkward, more or less a kludge).
  You can't take eg. a pre-defined texture and change the color of its
pigment. In general, you can't take any given item (something you can
#declare) and read/change its properties (for example, if you would
want to create an object using the same (unknown) texture as another
pre-declared object, you can't do that). Wouldn't it be nice if you
could do something like "if max_trace_level is less than 10, set it
to 10"?
  While most of these and other things could be kludged into the current
SDL, that's not really the point. Adding more and more bloat to the
current SDL with individual features is just not the way any longer.

  Another problem with the current SDL is that it's really slow.
As it currently is, however, it's next to impossible to be optimized
faster.
  I once made extactly the same ascii-mandelbrot-drawing routine in
perl and in pov-SDL (they both printed identical outputs). Perl is
also an interpreted scripting language, yet the perl version was more
than 13 times faster than the pov-SDL equivalent.
  Perl achieves its speed by byte-compiling the source and then
interpreting this bytecode. It would be quite hard to do the
same thing with the current SDL. While not impossible, a better
language designed for this purpose would be a cleaner solution.

> But remember, Povray is a 3D renderer, not a spreadsheet or an SQL 
> database.

  One of the strongest features of POV-Ray, which makes it different
from most other renderers, is its scripting language.
  However, I have always said that the strongest feature of POV-Ray is
also its weakest feature.

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

Andrey Skvortsov wrote:
> 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.

You're right and I am wrong. I just overlooked some features that POVRay 
is able to do (these # seemed a bit like preprocessing directives and 
thus I thought for some time that POVRay is basically nothing more then 
a raytracer with a very advanced preprocessor). I see now that it is a 
programming language but I still think that it isn't a good one. Some 
missing features have been mentioned by "Warp". I don't know if it's all 
true or if you can do some things some awkward way. Because of certain 
abilities of POVRay that can't be done in XML that good XML won't be a 
good solution. At least it might not be fast enough, especcially since 
XSLT isn't advanced enough yet.
What should be thought of is this: There are a lot of good programming 
languages out there: C/C++, Java, Pascal/Delphi, JavaScript, XML, 
Scheme, Prolog, PHP, and so on. Why does POVRay need to have it's very 
own programming language that is compatible to none of the existing 
ones? The only thing that POVRay needs to do is this (simplified):

* Assemble scene from different sources (include files, macros, geometry 
generating code and so on).
* Render scene.

So one has to ask: How can I get all that date in a clean and easy way 
from all kinds of different sources to the renderer? What sources might 
that be?
* Texture generating programs, texture files (in all kinds of formats)
* Geometry generating programs, 3d files (like 3dsmax, DXF and so on)
* material libraries.

So tell me: What way should be used to assemble all that data and send 
it to the POVRay renderer?

> Have you tried Povray?  it's  a very easy script.

I have written some simple scenes. Then I tried to make my own little 
object generation function library. Then I tried to generate pictures 
with labels (orthogonal camera mode) which did not work the right way.
So I say: POVRay SDL is easy for easy things but hell for certain 
advanced things (esp. modularization).

 > May be you could help
> in Pov parser/SDL development? 4th version would appear sooner.

Cool. Where do I have to go to join development team? #4 doesn't seem to 
be under development. Or is it? Couldn't find any info, any invitation, 
anything.

Regards,
Bernd Fuhrmann

Post a reply to this message

Andrey Skvortsov wrote:
> 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.

Write the Fine manual!

POV-Ray help->Index->object:

---
  Object
     2.5.11.23 Object Pattern

           adding texture to
               1.2.1.5 Adding Texture to an Object
           describing
               1.2.1.4 Describing an Object
           keyword
               2.5.11.23 Object Pattern
           modifiers, quickref
               2.8.9 Object Modifiers
           pattern
               2.5.11.23 Object Pattern
---
So what part of the manual does describe how objects can solve my 
problems? What part does give the hint?

> You can create your arrays of humans and pass the through the mesh() and 
>    not too ugly.

Argh, arrays! I demand structs or real OOP. Sorry but this isn't 
acceptable for me.

Regards,
Bernd Fuhrmann

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.
> 
Exactly, my solution was wrong. I have once again to apologize for that.

Regards,
Bernd Fuhrmann

Post a reply to this message

Warp wrote:
> 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?
> 
I hate them, yes. I know there are people who really write programs with 
them. They are neccessary for certain problems, like artificial 
intelligence (where reusability might not be that critical). But there 
aren't many programs as it seems. No complex convential software I know 
of has been developed with Lisp or Prolog. I will not use them unless I 
absolutely need them.

To give you an example for a real bad programming language:
BASIC (not visual). It just totally sucked. Do I need to explain that?

POVRay SDL is just a bit like BASIC. In fact it seems to take the 
features of BASIC and mix them with the syntax of the C preprocessor: No 
references, no structs, no namespaces, no custom types and so on. Please 
note that I don't mean that as an exact description but rather as an 
approximation. POVRay SDL is not exactly like BASIC.

Regards,
Bernd Fuhrmann

Post a reply to this message

ABX wrote:
> 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.

Yes, but I wan't real structs or objects. If I'd mimic them I could also 
call C an object oriented programming language because I could use 
structs and add pointers to functions.

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

No, no, no. I want references to functions. I want references to 
abstract data structures. I want references like they exist in Java.

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

Right. Sorry, my mistake. Replace cool with useful. Inheritance is 
useful, period. And having useful features is always a good thing.

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

Right. So I'll use for example Java to prepare the SDL. I'll write my 
own set of utilities and then modules that are based upon those 
utilities. So? What good will this do unless there are more then one 
person (me) that will use it? It will lead to one thing: You won't be 
able to use objects from my scene and I won't be able to use objects 
from yours. So how will we solve this?

Regards,
Bernd Fuhrmann

Post a reply to this message

Darren New wrote:
> No. You'd just have code that you don't yet have a way to process. 
> Parsing the SDL is only the first step. After that, you can do anything 
> you want with the parsed code.

Right, but that won't solve my problem.

>> As mentioned earlier: I will have to think about something different 
>> to solve my problem.
> 
> 
> So far, I haven't seen what your problem specifically is. So far, you've 
> talked about generalized solutions to unspecified problems, but not 
> specifically what you've encountered that youhad problems solving.

I want to code certain mesh transformations. This will be too complex in 
SDL. Therefore I'd like to use some other programming language but I 
couldn't find any solution that will ensure reusability. So XML was my 
first idea for that but it is a bit awkward.

> I wrote my own parser to take input that was what I wanted it to be, and 
> it outputs SDL (and HTML, and .BAT, and whatever else you want). I ran 
> into a bunch of other limitations of POV-Ray that I had to work around 
> in my "source code", but the structure of the parser I wrote made that 
> not too difficult. Now, I just need to take the time to figure out how 
> to put the results up on SourceForge(*) and to solicit opinions from 
> others(+). :-)

This is almost what I was about to do. But there are some things that I 
might not like: Just imagine the following:
Other people will do the same like you did: They will write their own 
programs (each one with their own bugs and limitations and formats). 
Some poor guy will use, let's say twenty of these programs for a real 
cool scene. So he will be forced to write a build script. This leads to 
the first couple of problems:
* Will your program be able to accept special code that is ment for the 
next program?
* Will your program be able to run in the build environment (might be a 
MAC, a Linux system that cannot execute BAT files or whatever.

I'd be interested in the program you wrote. If you like I can provide 
some FTP space on a server that administrate. Just contact me via email.

Regards,
Bernd Fuhrmann

Post a reply to this message

Darren New wrote:
> Bernd Fuhrmann wrote:
> 
>> No complex convential software I know of has been developed with Lisp 
>> or Prolog. 
> 
> 
> It amazes me that someone posting on a technical board never even 
> *heard* of Emacs.

I heard of Emacs. But I never really used it or had a look at it's 
source. I guess I will have to investigate how they did that.

Regards,
Bernd Fuhrmann

Post a reply to this message

Darren New wrote:
> Bernd Fuhrmann wrote:
> 
>> So what part of the manual does describe how objects can solve my 
>> problems? What part does give the hint?
> 
> 
> What part of your posts has actually described your problem?

I didn't describe my exact problem. But <41d9996f$1@news.povray.org> 
gives you the hint what I want to do. I want to fetch some data and 
created accordingly geometry. This should be done in a way that reusable 
components are used without manual translation into POVRay SDL. 
Additionally this should be done in a clean flexible way.

To be exact: I want to assemble ornament modules with different styles. 
These are put into modules which are to be assembled in a certain way 
(which is described in a tree like structure or a network or sth with 
additional meta data). I known it is not yet very specific but I hope 
you get the idea. Additionally these structures should be theoretically 
transformable to other languages like SVG. So I would like to solve this 
problem in a language that is general enough to produce at least POVRay 
SDL and XML aswell as possible other languages (who knows what my little 
mad mind will think of in the future). I'd like to have the ability to 
used existing models in my ornament modules (POVRay specific part of it 
of course).

Regards,
Bernd Fuhrmann

Post a reply to this message

Darren New wrote:
> Warp wrote:
> 
>>   However, I have always said that the strongest feature of POV-Ray is
>> also its weakest feature.
> 
> 
> It might be worthwhile to consider the use of an existing scripting 
> language that's designed to be embedded in other programs, and use that 
> for the scripting language. Something like elisp does for emacs. REXX 
> might be a good choice, Tcl would almost certainly be a good choice, 
> Python has already been used in some 2D graphics packages as a scripting 
> language, etc.

Well, ok. That would certainly be possible. To be exact: Using another 
programming language that output some SDL code is most likely the 
solution to my problem. But: What good will it do I just I write my 
utilities for my favourite programming language. It would be better to 
develop some kind of library for that programming language that would be 
used by most people who want to develop extensions that cannot be done 
properly with POVRay SDL. A standard solution to this should emerge. 
Anyone interested in it (while having no idea what it should be like)?

Regards,
Bernd Fuhrmann

Post a reply to this message

In article <41d86f9a$1@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > Ah, but the parser can be used the SDL to generate multiple objects, each 
> > needing to be parsed as well.
> 
> Erm, I wouldn't think so. I think when people unfamiliar with POV-Ray 
> talk about "parsing", they're talking about basically understanding the 
> tokens in the source and the syntactic interrelationships between them.
> 
Well.. Yeah, but I am trying to describe 'why' it takes a lot of time. 
Even tokenizing doesn't overcome the processing needs to build something 
complex, it just means the parser is now running something closer to JIT 
type stuff. Its still executing code that isn't 'part' of the actual 
engine in the while loop, until it finally starts making pixels.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Bernd Fuhrmann wrote:
> Andrey Skvortsov wrote:
> 
>> 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.
> 
> 
> Write the Fine manual!
> 
> POV-Ray help->Index->object:
> 
> ---
>  Object
>     2.5.11.23 Object Pattern
> 
>           adding texture to
>               1.2.1.5 Adding Texture to an Object
>           describing
>               1.2.1.4 Describing an Object
>           keyword
>               2.5.11.23 Object Pattern
>           modifiers, quickref
>               2.8.9 Object Modifiers
>           pattern
>               2.5.11.23 Object Pattern
> ---
> So what part of the manual does describe how objects can solve my 
> problems? What part does give the hint?
> 
>> You can create your arrays of humans and pass the through the mesh() 
>> and    not too ugly.
> 
> 
> Argh, arrays! I demand structs or real OOP. Sorry but this isn't 
> acceptable for me.
> 
> Regards,
> Bernd Fuhrmann
Help is not fantastic, I think so too.

I meant simple CSG
say you can write:

#declare myhuman = union{sphere .... box.. tringle ....etc }
it's not yet going to be shown. And then "instantinate" it like

object{myhuman}
object{myhuman {....some modification, other textures,position etc}}


well it's not like c++

class HumanMaker
{
	HumanMaker(....)
public:
	box
protected:
	sphere
private:
	....
	DoSomething()
	TranslateSomeWhere(..)
}

HumanMaker Human1;  //should this make the object appear on the screen?

Should we also implement overloaded functions and operators and all 
other advanced C++ stuff? :))

Current SDL mimic this class/object, but you cannot access your boxes 
spheres (primitives) in the CSG, of course, that would give us more 
power and have eaten more memory!
Although the thing is that OOP code is slower for parsing and this is 
very important for 3d modeling, because you want FAST. I even think 
there are people who would wish to simplify current SDL to achieve 
faster parsing times (or whatever needed). I personaly wanted it, 
playing with objects, containing millions of primitivies (strange 
attractors)! Parsing is killingly slow and memory consumption is 
enormous for such extremes.
But programming convenience and ability to share modules (classes) is 
very attractive.
So that is totally a compromise and currently it's not too bad.

Warp has a good point here.

Andrey Skvortsov

Post a reply to this message

Perhaps this will help to understand:
http://en.wikipedia.org/wiki/Compiler#Compiler_front_end


Regards,
Bernd Fuhrmann

Post a reply to this message

Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> >   Then in your opinion for example Lisp and Prolog are not true
> > programming languages?
> > 
> I hate them, yes.

  How does you hating them affect in any way the fact whether they are
true programming languages or not?

  That's like saying that you hate toyotas and thus toyotas are not cars.

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

Darren New <dne### [at] sanrrcom> wrote:
> It might be worthwhile to consider the use of an existing scripting 
> language that's designed to be embedded in other programs, and use that 
> for the scripting language.

  That has been considered many times, but doesn't seem to be a good
solution.
  POV-Ray needs a language specific for POV-Ray. Using a generic
programming language will make many things too awkward and hard to
use (too many things will have to be kludged).
  Besides, optimally the new language will somewhat resemble the
current one so that the learning curve will not be as steep. Most
POV-Ray users have never used any other language and learning a
new language which is similar to the current SDL will be easier
than learning a completely different language.

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

in news:41d9bf11@news.povray.org Bernd Fuhrmann wrote:

> It would be better to 
> develop some kind of library for that programming language that would
> be used by most people who want to develop extensions that cannot be
> done properly with POVRay SDL.

Something like:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/205451

Ingo

Post a reply to this message

In article <41d86f9a$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> Once you get to the point of *interpreting* what "#while" means, you're 
> past the parsing stage. POV-Ray may call that "parsing", but it isn't. 
> It's executing the specification. In other words, if the OP wants to do 
> something like add a namespace to some selected number of variables, you 
> don't have to understand a "while" loop to find all the variables you're 
> going to change, any more than emacs needs to understand SDL to 
> search-and-replace spheres with something else.

When POV says it's parsing, it's really parsing. POV executes the scene 
file as it parses it, rather than parsing into an intermediate form to 
be executed later. This is one of the reasons it is so slow, and one 
thing which badly needs improvement in POV4...it crawls around the input 
source files while generating the scene. The body of a loop is actually 
parsed once per iteration. Then there's a postprocessing stage where 
stuff like photons and radiosity are precalculated, basically "filling 
in the blanks" of the generated scene, and then you get to the rendering 
stage.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

ingo wrote:
> in news:41d9bf11@news.povray.org Bernd Fuhrmann wrote:
> 
> 
>>It would be better to 
>>develop some kind of library for that programming language that would
>>be used by most people who want to develop extensions that cannot be
>>done properly with POVRay SDL.
> 
> 
> Something like:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/205451
> 
> Ingo

Yes. I don't know Python good enough, but I think something like that. 
Perhaps with slightly more features or better internal structure, but I 
really don't know Python good enough to decide that. Just a feeling in 
my stomach that this can be done better.

Thanks for the hint. Btw: What is you opinion of a facility like it is 
shown in that Python code piece?

Regards,
Bernd Fuhrmann

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
> 
>>It might be worthwhile to consider the use of an existing scripting 
>>language that's designed to be embedded in other programs, and use that 
>>for the scripting language.
> 
> 
>   That has been considered many times, but doesn't seem to be a good
> solution.
>   POV-Ray needs a language specific for POV-Ray. Using a generic
> programming language will make many things too awkward and hard to
> use (too many things will have to be kludged).
>   Besides, optimally the new language will somewhat resemble the
> current one so that the learning curve will not be as steep. Most
> POV-Ray users have never used any other language and learning a
> new language which is similar to the current SDL will be easier
> than learning a completely different language.
> 
I don't understand that one. Why should people _need_ to learn new 
languages. If there is just a frontend that is able to create SDL code 
they'd still have SDL code to work with. They won't be able to 
effectively modify it but they aren't now either in many cases (those 
that are just to hard to be treated with common SDL).

Regards,
Bernd Fuhrmann

Post a reply to this message

Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>>>  Then in your opinion for example Lisp and Prolog are not true
>>>programming languages?
>>>
>>
>>I hate them, yes.
> 
> 
>   How does you hating them affect in any way the fact whether they are
> true programming languages or not?

It doesn't. "Being a true programming language" is not defined. If you 
mean Turing-complete was a good sign of true programming languages just 
have a look at brainfuck (http://www.muppetlabs.com/~breadbox/bf/). No 
sane person will use that language to code any serious software. So you 
wouldn't consider that a real programming language. On the other hand: 
What if you used such a programming language for 40 years and you could 
do things faster with that awkward programming language then with any 
other? You'd certainly consider it a real programming language. So what? 
It's a matter of opinion. So why should we argue about it?

But there are still facts: Some things just save you a lot of time, like 
OOP. Modularization is important. So we should have a good look at all 
those little nice features of all kinds of programming languages that 
allow a better form of modularization. These things should go into 
POVRay SDL or any officially recommended frontend for it.

>   That's like saying that you hate toyotas and thus toyotas are not cars.

Come on. I did'nt say that. They are considered real programming 
languages by many people. I know that. But I still don't like them. It's 
just my opinion. Call it a feeling. I once had to do a couple of things 
with Scheme and I was really pretty upset because of certain things. So 
I will not consider them as a true alternative for C(++) for my 
programming work. Other people will think different. I can live with 
that (as long as I don't have to mess up with their code).

Regards,
Bernd Fuhrmann

Post a reply to this message

in news:41daff5b$1@news.povray.org Bernd Fuhrmann wrote:

> Thanks for the hint. Btw: What is you opinion of a facility like it is 
> shown in that Python code piece?
> 

In general it works fine. In this specific case there's a few things I'd 
have done differently, the syntax is 'relative' close to POV-SDL. I'd 
probably prefer something like VPython http://vpython.org/ with an 
export to POV-Ray, becaus when working in one language I probably don't 
want to bothered by another. For generating POV-Ray SDL from another 
language I've been looking at templating systems and I think most what 
one needs can be done with them, as after all, it's only text.

Here's yet another one:
http://www.4dsolutions.net/ocn/numeracy0.html
and other pages on the site.

Personaly, I think there are three interesting options:
One is a standalone parser that interfaces with, in my case, Python. It 
would suit my current needs, but it lacks interaction, so no "trace" 
ability.

Two, the possibility to call, in my case python, scripts from POV-Ray as 
a kind of include files. I guess the chanches for the latter to happen 
are rather small.

A third and maybe most interesting option, is something like Jython 
http://www.jython.org/ . POV-Ray SDL implemented in another programming 
language in such a way that it completely interacts with that language 
and you can use any library available in the two languages. And 
regardless what you use, everything looks like POV-Ray-SDL syntax.

All that, from a non-programmers view,

Ingo

Post a reply to this message

In article <41dade0b$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> Warp wrote:
> >   POV-Ray needs a language specific for POV-Ray. Using a generic
> > programming language will make many things too awkward and hard to
> > use (too many things will have to be kludged).
> 
> I disagree that this would be the case for several languages designed 
> specifically for this purpose, such as FORTH and Tcl. I'd be interested 
> in an example of something that current SDL does that would be severely 
> awkward in (say) Tcl.

Uh...what? You disagree that Forth would be more awkward? Your brain 
must be inside out. ;-)
I actually considered a similar language (more similar to PostScript, 
actually) for driving my own raytracer, but I'd never construct a 
complex scene in it directly. I've had enough of that stuff with some 
hand coded PostScript logos I did. (I finally decided that C++ was good 
enough, considering that it was primarily a testbed for raytracing 
algorithms.)

I don't know much about Tcl, but I doubt it would be as convenient as a 
special purpose language. Simply having a built-in syntax for specifying 
vectors is a huge advantage. A quick web search tells me it's designed 
to be easily extended though, so maybe you could modify it to support a 
fairly POV-like syntax...

In a general purpose language, you're pretty much restricted to 
manipulating the raytracing engine through an API, rather than writing a 
scene in a scene description language. For just general scene coding, 
this is usually more work. For example, something like:

sphere {< 0, 1, 0>, 1
    scale < 1, 0.2, 1>
    rotate < 45, 0, 0>
}

typically turns into something like:

Sphere mySphere(Vect3(0, 1, 0), 1);
mySphere.Scale(Vect3(1, 0.2, 1));
mySphere.Rotate(Vect3(45, 0, 0));

scene.AddShape(mySphere);

It gets worse when you throw things like transformations into the mix. 
You end up with either a complex, hard to maintain API, or complex, hard 
to write and maintain scene code. An "elegant" way to handle 
transformations would be to give objects a single method for applying a 
transformation:

mySphere.Transform(Transforms::Rotation(Vect3(45, 0, 0)));

The "convenient" way would be to provide a method for each type of 
transformation, with different versions for vectors, scalars, and 
triples of vectors:

mySphere.Rotate(45, 0, 0);

Much easier to write and read. But the API now has at least 3 rotation 
methods in addition to the general Transform() method. If you add an 
axial rotation transform, you need to add at least another method to the 
shape classes.

Some languages (including Lisp, I think) allow parts of the language 
itself to be modified by programs written in the language...this could 
be a very useful feature, since you could build the scene description 
language with the base programming language. However, I don't know of 
any which would be good candidates for a POV-Ray input language.

Another thing to consider is that most scripting languages aren't 
designed for efficiently processing floating point math. The current 
POV-Ray SDL is one of the worst at this, but the new one should be good 
enough to use as a shader language and to specify functions for 
isosurfaces without needing an entirely separate VM.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <41d98ce0$1@news.povray.org>,
 Bernd Fuhrmann <Sil### [at] gmxde> wrote:

> What should be thought of is this: There are a lot of good programming 
> languages out there: C/C++, Java, Pascal/Delphi, JavaScript, XML, 
> Scheme, Prolog, PHP, and so on. Why does POVRay need to have it's very 
> own programming language that is compatible to none of the existing 
> ones? The only thing that POVRay needs to do is this (simplified):

Simplicity. None of those really cut it.


> So one has to ask: How can I get all that date in a clean and easy way 
> from all kinds of different sources to the renderer? What sources might 
> that be?

Primarily hand-written scene files. XML is basically useless for that, 
those other languages are usually just very awkward, and require 
knowledge of a complex programming language. The existing SDL is 
limited, but it's also simple. People can do substantial things while 
knowing very little about programming.
Then there's maintenance issues...keeping up with updates to the 
language, changing the language if the developers take it in a direction 
that makes it less useful to POV-Ray, etc. Plus debugging someone else's 
code base.

For someone with experience in those languages, learning the POV-Ray SDL 
shouldn't be a challenge, but the POV language will be better at what it 
needs to do.


> Cool. Where do I have to go to join development team? #4 doesn't seem to 
> be under development. Or is it? Couldn't find any info, any invitation, 
> anything.

That was probably because you weren't invited. POV 4 isn't even 
partially released yet, but that you can't see it doesn't mean there 
hasn't been any design or code written. You can write and distribute 
modifications as allowed by the license, but you'll have to work with 
3.6 for now.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> In article <41d98ce0$1@news.povray.org>,
>  Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
> 
>>What should be thought of is this: There are a lot of good programming 
>>languages out there: C/C++, Java, Pascal/Delphi, JavaScript, XML, 
>>Scheme, Prolog, PHP, and so on. Why does POVRay need to have it's very 
>>own programming language that is compatible to none of the existing 
>>ones? The only thing that POVRay needs to do is this (simplified):
> 
> Simplicity. None of those really cut it.

If you say so. Are you quite sure of what you're talking? Some of those 
languages are very powerful, especially for large projects.

>>So one has to ask: How can I get all that date in a clean and easy way 
>>from all kinds of different sources to the renderer? What sources might 
>>that be?
> 
> Primarily hand-written scene files. XML is basically useless for that, 
> those other languages are usually just very awkward, and require 
> knowledge of a complex programming language. The existing SDL is 
> limited, but it's also simple. People can do substantial things while 
> knowing very little about programming.

But they can't do advanced things as easy as they could if there existed 
some default front-end for one of those programming lanugages mentioned 
above. So there should be an alternative for those who want to do the 
more advanced stuff.

> Then there's maintenance issues...keeping up with updates to the 
> language, changing the language if the developers take it in a direction 
> that makes it less useful to POV-Ray, etc. Plus debugging someone else's 
> code base.

Programming languages don't change that much. Last change of C++ was in 
2001, I guess, and that was just a minor issue. Ok, C++ is complex. You 
might consider the use of any other programming language. They are well 
defined and if there are substantial changes you might stick to the old 
version for a while. You might even use external compilers so the POVRay 
team can concentrate on the raytracer.

> For someone with experience in those languages, learning the POV-Ray SDL 
> shouldn't be a challenge, but the POV language will be better at what it 
> needs to do.

It's not learning POVRay SDL but getting complex work done with it. I 
can tell you that it is not motivating if you are just experienced 
enough to know that the code you are writing will not be maintainable.

>>Cool. Where do I have to go to join development team? #4 doesn't seem to 
>>be under development. Or is it? Couldn't find any info, any invitation, 
>>anything.
> 
> That was probably because you weren't invited. POV 4 isn't even 
> partially released yet, but that you can't see it doesn't mean there 
> hasn't been any design or code written. You can write and distribute 
> modifications as allowed by the license, but you'll have to work with 
> 3.6 for now.

So there would be another POVRay modification. I don't have the time for 
this. I would have to redesign half of the program. This is useless 
since I would have to spend so much time and in the end noone would use 
my version (except me). All the advanced features of the next version 
and it's bugfixes would not be in my version. Therefore this is pointless.

Regards,
Bernd Fuhrmann

Post a reply to this message

Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> I once had to do a couple of things 
> with Scheme and I was really pretty upset because of certain things.

  Typical example of "extrapolation from one or less examples".

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

Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> I don't understand that one. Why should people _need_ to learn new 
> languages. If there is just a frontend that is able to create SDL code 
> they'd still have SDL code to work with. They won't be able to 
> effectively modify it but they aren't now either in many cases (those 
> that are just to hard to be treated with common SDL).

  I don't understand what you are talking about.

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

Look at this stuff
http://www.photon.at/~werner/light/
http://www.photon.at/~werner/light/doc/a00451.html

And also you can try to search the web for other projects I didn't do it 
thorougly.
What do you think?

Andrey.

Post a reply to this message

Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>   Typical example of "extrapolation from one or less examples".

If you say so. No, really. I developed (with my partner) about 10 
programs that were more or less complex. So I don't think what and how 
you say about my Scheme experience is not really fair. I won't answer 
that anymore since it's really pointless.

Bernd Fuhrmann

Post a reply to this message

In article <41dbac8c@news.povray.org>,
 Bernd Fuhrmann <Sil### [at] gmxde> wrote:

> >>What should be thought of is this: There are a lot of good programming 
> >>languages out there: C/C++, Java, Pascal/Delphi, JavaScript, XML, 
> >>Scheme, Prolog, PHP, and so on. Why does POVRay need to have it's very 
> >>own programming language that is compatible to none of the existing 
> >>ones? The only thing that POVRay needs to do is this (simplified):
> > 
> > Simplicity. None of those really cut it.
> 
> If you say so. Are you quite sure of what you're talking?

Yes, I am quite sure. I have done complex simulations in POV-Ray, it's a 
pain in the ass. I have also done scenes coded directly in Java and C++, 
that's a bigger pain in the ass than writing the raytracers. As I 
mentioned before, simply the lack of a built-in vector syntax makes 
things much harder to write and read. My C++ tracer can be made to do 
Monte-carlo path tracing by simply coding the materials in a certain 
way, but building a scene of any complexity is maddening due to all the 
C++ syntax I have to work through.

Pascal, Delphi, JavaScript, and PHP would all have similar problems to 
C++ and Java related to the requirement of using an API. A Prolog SDL 
would be...very interesting, but probably not very good for general use. 
Scheme might make a useful, but idiosyncratic SDL. XML is useless for 
hand coding, and no easier for automated programs to write than a custom 
SDL would be.


> Some of those languages are very powerful, especially for large projects.

And this shows you completely miss the point. It doesn't matter how 
powerful the language is if you must be a programmer to use it. Most POV 
users aren't programmers, despite hand coding their scenes in a 
Turing-complete programming language.


> But they can't do advanced things as easy as they could if there existed 
> some default front-end for one of those programming lanugages mentioned 
> above. So there should be an alternative for those who want to do the 
> more advanced stuff.

They can't do them *now*. They could with a improved scene description 
language, more easily than they could with a general programming 
language.


> Programming languages don't change that much. Last change of C++ was in 
> 2001, I guess, and that was just a minor issue. Ok, C++ is complex. You 
> might consider the use of any other programming language. They are well 
> defined and if there are substantial changes you might stick to the old 
> version for a while. You might even use external compilers so the POVRay 
> team can concentrate on the raytracer.

...

The POV-Team, and all the people developing patches, will concentrate on 
what they want. Much of the time, that is extending the language to be 
more powerful for describing scenes. It is not just a minor subsystem 
for loading scene data.

In addition, an external language will either lose a great deal of 
versatility because it can't tie directly into the tracer, or lose 
portability due to having to dynamically load the POV-Ray renderer as a 
library. Evaluation of pigments, transformations, and ray intersections 
during scene construction are extremely important features. You just 
can't do this without adding problems with portability, dependency on 
other libraries or utilities, etc. And then you have the issues with 
ensuring security from malicious scripts, convincing users that they 
have to learn a complex programming language and scene API, etc...


> It's not learning POVRay SDL but getting complex work done with it. I 
> can tell you that it is not motivating if you are just experienced 
> enough to know that the code you are writing will not be maintainable.

You miss the point again...that can be fixed by improving the SDL, 
without losing its advantages...which would be lost by moving to a 
general programming language. Ease of learning the language and using it 
for things which are simple in terms of programming are far more 
important than you seem to realize.


> So there would be another POVRay modification. I don't have the time for 
> this. I would have to redesign half of the program. This is useless 
> since I would have to spend so much time and in the end noone would use 
> my version (except me). All the advanced features of the next version 
> and it's bugfixes would not be in my version. Therefore this is pointless.

I think this should be obvious, but if nobody finds it useful, it 
shouldn't be in the official version.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <41db3709$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> > I don't know much about Tcl, but I doubt it would be as convenient as a 
> > special purpose language. Simply having a built-in syntax for specifying 
> > vectors is a huge advantage.
> 
> You can write OO-ness in Tcl, entirely in Tcl. Many of Tcl's control 
> structures are written in Tcl.  Adding a vector type to Tcl is *trivial*.

After looking at some examples online, I begin to see...it's one of 
those "mutable" languages I was talking about.


> Yes. That's called an "extensible" language, and includes Tcl, FORTH, 
> and Lisp. Lisp still has the ((())) syntax to deal with, FORTH has the 
> postscript, and Tcl has very few drawbacks in this regard. Altho, as you 
> mention, Tcl expression syntax can be a little bit ugly, just a tad.

Sounds like we're talking about the same thing, just that I don't know 
anything about Tcl.


> Tcl, I'd venture. :)
> 
> Mind, Tcl isn't really good at math as such, but on the other hand since 
> math isn't technically built into the language, that would probably be 
> pretty easy to improve.

Well, I'll have to put Tcl near the top of my list of alternative 
existing languages. However, I'd still prefer a custom one, for the 
control over architecture and reduction in dependency, and more clear 
responsibility for bugfixes and such. Based in spirit on languages like 
Tcl, but not in actual code. Writing a language parser isn't all that 
difficult, it's mainly tedious after you get basic expression parsing 
done...and once it's done, adding or minor modification is pretty easy.

And, if it's not designed for it from the start, making the VM 
high-performance for things like shaders would probably be quite 
difficult. Going from dynamic dispatch of an operator method to 
performing a VM operation on a numeric primitive type is quite a change. 
Something like overlapping it with a far more static language...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <cjameshuff-C93C28.15390704012005@news.povray.org>, 
cja### [at] earthlinknet says...
> In article <41d86f9a$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
> wrote:
> 
> > Once you get to the point of *interpreting* what "#while" means, you're 
> > past the parsing stage. POV-Ray may call that "parsing", but it isn't. 
> > It's executing the specification. In other words, if the OP wants to do 
> > something like add a namespace to some selected number of variables, you 
> > don't have to understand a "while" loop to find all the variables you're 
> > going to change, any more than emacs needs to understand SDL to 
> > search-and-replace spheres with something else.
> 
> When POV says it's parsing, it's really parsing. POV executes the scene 
> file as it parses it, rather than parsing into an intermediate form to 
> be executed later. This is one of the reasons it is so slow, and one 
> thing which badly needs improvement in POV4...it crawls around the input 
> source files while generating the scene. The body of a loop is actually 
> parsed once per iteration. Then there's a postprocessing stage where 
> stuff like photons and radiosity are precalculated, basically "filling 
> in the blanks" of the generated scene, and then you get to the rendering 
> stage.
> 
Ah hah... I knew I was right about that. I look forward to a more JIT 
type system in 4.0, if they do so.


-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <41db0035@news.povray.org>, Sil### [at] gmxde says...
> I don't understand that one. Why should people _need_ to learn new 
> languages. If there is just a frontend that is able to create SDL code 
> they'd still have SDL code to work with. They won't be able to 
> effectively modify it but they aren't now either in many cases (those 
> that are just to hard to be treated with common SDL).
> 
Except that the frontend is entirely unneeded if you extend the SDL to 
support things properly in the first place. Moray does a decent, but not 
complete job of acting as a front end and even solves some problems, in a 
general way, like animation that are troublesome with pure SDL. But it 
falls short of supporting some basic things, like being able to link a 
light source to an object, so they move together, let alone some more 
complex things. The more abstraction you put between the core functions 
and the user, the more limited you end up making their options and the 
more the perception becomes, "That program can't do X". Of course, some 
times, like with media for subsurface scattering, the 'correct' solution 
can actually have the opposite result, making it so complicated to use 
the feature that the abstracted simulation of it might be preferable, but 
that is generally a far more rare situation. Any abstraction shouldn't be 
in the language someone uses to manually edit things in most cases, but 
more like Moray, when the abstraction is to a simpler representation of 
what it really being done. XML or other structures can't improve the 
ability to see that, it only obfuscates the actual process or nature of 
the objects in it even more.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <41dc85a1$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> > And, if it's not designed for it from the start, making the VM 
> > high-performance for things like shaders would probably be quite 
> > difficult.
> 
> Errr, well, I'd expect there's be a call that says "Trace." :-) Tcl's 
> all in C, and it's designed to call C routines pretty seemlessly. I 
> wouldn't think you'd implement the shaders in Tcl, but in C.

C is impractical for other reasons...you'd need a C compiler, obviously. 
This is a bigger problem than you'd think. The compiler must exist for 
all the platforms POV is likely to run on, and is an obstacle to porting 
to new platforms.

Then you need to run this external compiler with the shader code and 
link in the result. A C development environment is a bit heavy to 
include along with the raytracer, and is likely to be a huge source of 
problems on different configurations. Plus there's the security risks of 
using such a low level language...you'd pretty much have to disable 
programmable shaders for a web-driven application, for example.

Also, with no support for vector/color math or operator overloading, C 
shaders would get pretty ugly...though if you can solve the compiler 
problem, I suppose you could translate from a customized language into 
C, as was done for early C++ and Objective C compilers.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <41dcb8a3@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> > C is impractical for other reasons...you'd need a C compiler, obviously. 
> 
> Um, well, yes. I was under the impression POV-Ray is written in C 
> already anyway. Indeed, you'd need a C compiler to extend POV-Ray in C. 
> If your implication is that no code written in C can be run on a user's 
> machine that doesn't have a C compiler installed... erm... :-)

No. I'm saying you'll need a compiler to run C source code, such as 
shaders written in C.


> I suspect Tcl already runs on more platforms than POV-Ray, altho I 
> wouldn't guarantee it runs on every platform POV-Ray runs on. I suspect 
> Tcl runs on more platforms than you think it does, tho. ;-)

I'm talking about the C compiler you suggested using for shaders. GCC 
might suffice, if the license allows bundling it like this, but it would 
add several megabytes at minimum to the POV-Ray distribution.


> You'd have to compile it, once per platform. Just like any attribute 
> you'd add to the SDL anyway. You wouldn't need to recompile the base 
> POV-Ray, tho.

But you would still have to compile the shader. It would probably then 
be loaded as a dynamic library by the POV executable, assuming the 
interface for doing so is reasonably easy to port. Tcl might have 
built-in facilities for doing this portably, but it's the first step 
that's hard.


> > A C development environment is a bit heavy to 
> > include along with the raytracer, and is likely to be a huge source of 
> > problems on different configurations.
> 
> I don't need a C development environment to run POV-Ray. I don't 
> understand what point you're trying to make.

Because it has its own custom language for functions, the closest thing 
it currently has to shaders. If you used C for a shader language, you 
would need a C development environment.


> Yes. Except that's already built into Tcl. It's called a "safe 
> interpreter". Been around for about 15 years now. I work with the guys 
> who invented it.

I don't see how that helps the security of the code written in C.


> Well, it's possible I just don't understand what you mean by a "shader". 
> However, what I was *trying* to say was, you can extend the SDL with C 
> if the extension is compute-intensive, and it wouldn't need to be part 
> of the official POV-Ray release, but it wouldn't be an entirely new 
> program either - just an extention.

That's essentially what a shader is. A mini-program used to do texturing 
and lighting calculations for the renderer. (Sometimes other stuff like 
geometry as well.)
They're typically compiled to bytecodes and interpreted. I think the big 
packages do let you load C object code or libraries, but you need the 
development tools...


> Or you can extend it directly in SDL, if the performance is good enough. 
> You could, for example, write Tcl code to import Wings3D files directly. 
> If that was too slow, you'd build an ImportWings.DLL (an ImportWings.SO 
> and etc) to run faster, and write Tcl code that if the DLL isn't there, 
> you fall back to the slower method.

But if Tcl doesn't even have built-in numeric calculations, it would 
probably be difficult to add them in a way that gets good enough 
performance for shaders.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

On Wed, 05 Jan 2005 21:35:34 -0800, Darren New <dne### [at] sanrrcom> wrote:
> > But you would still have to compile the shader.
>
> I'm not following. Why would I need to compile it myself, any more than 
> I need to compile POV-Ray myself? Why would compiling a shader be harder 
> than compiling POV-Ray is today?

I have a feeling that what Christoph is referencing here is that current
functions engine can be compiled into so called machine code without any
external C/CPP compiler. AFAIK all is required is kind of table for
"translating" function virtual machine codes into cpu codes as (IIRC) it is
done for (some of) Macs.

4.5.1.1.2 Fast Functions
http://www.povray.org/documentation/view/3.6.1/747/

ABX

Post a reply to this message

In article <l6spt0lpe76t20v524bkp5naifi490qfka@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> I have a feeling that what Christoph is referencing here is that current
> functions engine can be compiled into so called machine code without any
> external C/CPP compiler. AFAIK all is required is kind of table for
> "translating" function virtual machine codes into cpu codes as (IIRC) it is
> done for (some of) Macs.
> 
> 4.5.1.1.2 Fast Functions
> http://www.povray.org/documentation/view/3.6.1/747/

No, that's not what I'm referring to. I do know where the 
miscommunication is happening though...see other reply.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

On Thu, 06 Jan 2005 06:44:34 -0800, Darren New <dne### [at] sanrrcom> wrote:
> So why would you need a C compiler to do this? That's what I'm not 
> following. Why is it easier to do that on POV-Ray 3.6 than it would be 
> to do on POV-Ray 4.0? Why not just do it the same way as already works?

I do not know what was meant in earlier discussion here but I suppose that
build-in compiler is in POV-Ray 3.6 because POV-Ray 3.6 is between POV-Ray 3
and POV-Ray 4. In other words, I think that's imposssible to introduce all the
changes in single release without releasing anything for years.

ABX

Post a reply to this message

In article <41dcce25$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> I don't need a C compiler to run shaders written in C, any more than I 
> need a C compiler to run POV-Ray written in C.

You do, since shaders are almost never distributed as native machine 
code.


> > I'm talking about the C compiler you suggested using for shaders.  GCC
> > might suffice, if the license allows bundling it like this, but it would 
> > add several megabytes at minimum to the POV-Ray distribution.
> 
> I'm not sure why you wouldn't distribute shaders (or whatever you wanted 
> efficiently) in the same way you distribute POV-Ray now.

Because shaders are written by the users, not the developers. This is 
the point I think you've been missing. Shaders are used when the built 
in primitives are too limited or awkward to accomplish a given job.


> > Because it has its own custom language for functions, the closest thing 
> > it currently has to shaders.
> 
> This has too many typos and pronouns for me to figure out what you're 
> talking about. What's "it"?

"It" is POV-Ray. It supports user-defined functions which are compiled 
into opcodes for a virtual machine, and optional further compilation 
into native machine code. These functions can be used to define 
isosurfaces, patterns, and with a little extra work, pigments. Not quite 
a full-blown shader language, but the closest thing POV-Ray currently 
has.


> > If you used C for a shader language, you 
> > would need a C development environment.
> 
> I'm not sure what a shader language is. I'm not suggesting a shader 
> language, but rather the use of Tcl as the basis for SDL.

Rather than assembling a material out of predefined patterns, the user 
writes a "shader program", a function that computes the resulting color 
for the renderer. Tcl is probably quite unsuitable for this, so you 
would need a separate language just for shaders and similar 
high-performance functions. There isn't any particular reason the entire 
SDL couldn't use the same VM. Some capabilities, such as defining 
objects, would be "low performance" and would be a bad thing to put in a 
shader, but I don't see a definite reason to have separate languages.


> > I don't see how that helps the security of the code written in C.
> 
> I don't know why you're fixated on C.

Because you suggested it as a high-performance alternative to Tcl, for a 
shader language.


> > They're typically compiled to bytecodes and interpreted.
> 
> You mean, like Tcl.

Superficially. What I was trying to point out was the difference from C, 
in that machine-specific forms are rarely distributed widely. You need a 
compiler that supports the platforms, or you need a VM capable of high 
performance FP math. That practically means a custom VM, 


> > But if Tcl doesn't even have built-in numeric calculations, 
> 
> Of course it has numeric calculations built in. I just said the syntax 
> isn't quite as standard as you might want, nor are numeric expressions 
> likely as efficient as a language compiled all the way down to machine code.

Earlier, you said:
> Mind, Tcl isn't really good at math as such, but on the other hand since 
> math isn't technically built into the language, that would probably be 
> pretty easy to improve.

I might have misunderstood this, but I took it to mean that math is 
implemented on top of mechanisms provided by the VM, rather than built 
into the VM. The extra abstraction can be useful, but can really hurt 
performance in floating-point heavy stuff like shaders.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <41dd6fb2$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> Let's reset a little bit. I'm talking about whether it would be better 
> to base SDL 4.0 on an existing extensible scripting language with 
> ray-tracing primitves added, rather than basing it on a whole new 
> parser/runtime.  (Note: I am not suggesting anything about POV4. Just 
> talking. :-)
> 
> In either case, if the primitves are inadequate and you don't have a 
> precompiled version of the shader, then you're SOL. So maybe I'm missing 
> why shaders even came up in the discussion.

It's a reason why a new parser/runtime could be better than an existing 
one, like your suggestion of Tcl.


> > "It" is POV-Ray. It supports user-defined functions which are compiled 
> > into opcodes for a virtual machine, and optional further compilation 
> > into native machine code. These functions can be used to define 
> > isosurfaces, patterns, and with a little extra work, pigments. Not quite 
> > a full-blown shader language, but the closest thing POV-Ray currently 
> > has.
> 
> OK. And surprisingly enough, this implementation doesn't require a C 
> development environment. So....

POV doesn't currently use a "standard" programming/scripting language 
like Tcl. It uses its own language, and its own VM, designed 
specifically for floating point functions. Isosurfaces would render a 
lot slower if their functions were written in Tcl. They'd be faster if 
they were written in C, but that isn't very practical.


> Actually, I'd expect it to be quite suitable, but relatively slow since 
> it is after all byte-compiled. If you wanted it to be fast, you'd either 
> do something like POV-Ray does now, or you'd write the shader primitve 
> you're interested in in a faster compiled language like C and 
> dynamically load it as needed, or you'd write it in Tcl with possibly an 
> option to look for the already-compiled code and load that if it's 
> available.

We're talking about something that could be a complex function evaluated 
for every ray traced, possibly hundreds of times per pixel...thousands 
of times with antialiasing. Much more with blurred reflection, media 
shaders, and so on, and there's no reason the intersection calculations 
themselves couldn't be done in it for custom shapes. "Relatively slow" 
is too slow. Interpreted languages are barely suitable but practically 
necessary, which is why the POV-Ray function VM has hooks for JIT 
compilation. You really need a language optimized for floating point 
calculations, preferably with optimizations for colors, points, and 
normals.


> The benefit having to do with compiled shaders is the same, regardless 
> of what syntax you use for the SDL. Either you support user-defined 
> shaders in some custom language, or you support them as C libraries, or 
> you don't support them at all, and all three of those are available 
> regardless of the syntax of the language.

But once you have a custom language for shaders, why do you need another 
language like Tcl for the SDL? You could use one language, one VM for 
both purposes. The result is less internal code, and less stuff for 
people to learn.


> > Superficially. What I was trying to point out was the difference from C, 
> > in that machine-specific forms are rarely distributed widely.
> 
> Well, ask yourself why.  It's not like *no* software is widely 
> distributed precompiled. If it's easy to dynamically load shaders on 
> demand, there's no reason they couldn't be precompiled. Imagine an SDL 
> that would do a google search for a precompiled shader for your platform 
> if it ran into a Tcl implementation of that shader....

They can't be precompiled because they are written and distributed by 
users! You can't expect every user that wants to write shaders for 
others to use to have a C development environment with cross-compilers 
for every platform someone might want to use it on.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <41ddac99@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> Translating the description of the shader into specific machine code or 
> specific byte codes would be the same amount of work to implement 
> regardless of whether you used Tcl or not to invoke the scripts.

Writing and maintaining both a shader language + VM and a Tcl SDL would 
be more work than writing and maintaining an SDL that also serves as a 
shader language. If you have a decent custom language already in the 
project, I see no reason to add another one.


> I expect the way you would use Tcl in this project is to implement 
> "sphere" in Tcl to output the appropriate bytecodes for the optimized 
> VM. I don't see writing the ray-tracer itself (i.e., the thing that 
> follows the rays and calculates pixel colors) in Tcl to be feasible any 
> more than doing so in SDL is feasible.

But maybe you don't want a plain sphere. Maybe you want a sphere with 
ripples on it. Thus, you need to execute user-defined code, and the 
faster the better.
With an improved custom-purpose SDL, replacing most of the raytracer 
with user-written code would be slower, but perfectly feasible. You 
could even implement your own raytracer, though there would be no reason 
I can think of to do so.


> Basically, you'd use Tcl to build the scene, and then your specific VM 
> to interpret the stream.  Layering, ya know?

But what purpose is there to another layer?


> The language that builds the VM byte stream doesn't have to be 
> especially fast. I mean, heck, POV-Ray 3.x (as far as I understand) 
> actually reparses the source text to do so. Tcl would be faster because 
> after the first time thru the loop, the parsing is byte-compiled.

But not fast enough. Not all VMs are equal. It's byte compiled, so are 
POV functions. However, the POV function VM is built for crunching 
numbers, and is almost certainly much faster at it than Tcl.


> > But once you have a custom language for shaders, why do you need another 
> > language like Tcl for the SDL?
> 
> The "custom language" would be Tcl.

No, the custom language I'm speaking of here is the shader language. 
Tcl's too slow for that.


> > You could use one language, one VM for both purposes.
> 
> Well, are you assuming that a VM needs a custom language to write a 
> compiler for? That may be the miscommunication.

No, of course not. The "custom language" could be essentially a clone of 
Tcl, with floating point and vector optimizations. Then there'd be even 
less reason to use standard Tcl.


> You can expect, however, that there is at least one person who has a 
> compiler for your platform, or POV-Ray wouldn't be running there. The 
> stumbling block isn't that compiled versions don't work for some reason. 

Yes, it is! I can't run x86 machine code on my iBook. Without a 
compiler, I can't run stuff I just wrote in C. Having someone else 
compile stuff for me every time I tweak the code just isn't an option.


> The stumbling block is a lack of distribution facilities where you can 
> find it precompiled. If there's a central place holding shaders, there's 
> a central place where people could contribute executable versions.

No, it isn't. I can't go download a compiled version of a shader I just 
wrote. Again, shaders are written by *users*. They need to be able to 
write the code, then run it. It needs to run as fast as feasible.


> Plus, if the shaders are written to compile down to some VM, the VM 
> code could be either built into POV or could be distributed along 
> with or instead of the source.

That is exactly what is done with many shaders, though it is a bit more 
flexible and useful to distribute the source.


> I mean, Tcl has a whole bunch of executable extensions that are written 
> and distributed by users. It's really not that hard. :-)  And I suspect 
> that POV-Ray doesn't run on *so* many platforms that, say, 6 different 
> executables wouldn't satisfy >95% of the users using it, and the other 
> 5% probably have the development environment anyway.

Requiring people to have a 6-way cross-compiling development environment 
in order to write and distribute a reasonably advanced scene is 
ridiculous. Alternatively, requiring them to have a development 
environment for their own system or know someone who does in order to 
render the scene is equally ridiculous. Interpreted languages are 
practically necessary for useable shader languages. However, even the 
fastest ones are also nearly too slow to be of practical use for that.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

"Chris B" <c_b### [at] btconnectcom> wrote:

> It is already possible to use VRML to describe a scene (not a POVRay scene).
> VRML has been about since about 1994.
> There is a project working to convert it to an XML base (xVRML) as it was
> originaly based on SGML principles. In fact I think they released an XML
> schema for it way back in 2003.

yes
and the xVRML Project has mad significant strides
since this note was posted...

see:  http://www.xvrml.net/

the spec sections for static scene elements are almost completed
and the sections for dynamics come next

an initial tech-demo viewer application is avail through the above URI

> I think there are probably lots of people on the VRML news groups and in the
> xVRML community that are interested in such a system.

I would agree

> I myself took a brief interest in this before discovering POVRay.

interesting the paths we all follow...
I took the opposite route
shifting my energy from PoV to VRML in 1994
and these past couple of years
focusing on developing an XML-based VR language (xVRML)

> put me off VRML (and the concept of using tagged markup languages for scene
> description in general) is the enourmously verbose manner used to describe
> an object.
> As has already been mentioned, POVRays Scene Description Language provides a
> highly elegant and concise yet flexible way to describe objects.

IMHO: PoV and other static-image-oriented systems
have different target domains and audiences than web-based VR
so I think of this as comparing apples and doughnuts

Constructivist approaches in education include
structuring lessons to "build on prior knowledge"
and we are trying to apply that lesson to xVRML

anyone who can understand HTML code
can learn to understand xVRML in a **very** brief time
because it is deliberately structured to take advantage of
existing understanding of HTML and other tag-based markup languages
already held by new content creators

I have been testing this out this Quarter
at the college where I teach...
I am teaching the same "intro to vr" class
which I have taught for five years now...
the students seem to have
about the same base of prior knowledge as always
and are about as smart as always
and yet this term
I switched to using the current (beta) xVRML version
and to using the current (alpha) tech-demo viewer app ("Carina")
and suddenly I have a class going through the material
at literally twice the rate that classes have done
so over the past 5 years
so I feel there is at least preliminary/anecdotal evidence
that this approach is working effectively

> scenes, and even then I've never seen any VRML scenes that come close to the
> sophistication of some of the newbie POVRay scenes posted on the povray
> newsgroups.

but of course...
the PoV newbies are working to create things which
consist of one rendered frame at a time
and which is not necessarily going to be
downloaded off of the web
while VR scene newbies are working to create things which
people can "fly through" at a decent multi-framerate
and which *are* necessarily going to be
accessed over the Web

different targets and domains

IMHO a lot of people who want to generate
photorealistic raytraced stills
and slowly-constructed animations
can also find a lot of interesting things to do
with lightweight 3D VR
rapidly obtained from the Web
and rapidly rendered as a just-in-time
animation under the control of the user

jeffs
http://www.xvrml.net/

Post a reply to this message

ABX <abx### [at] abxartpl> wrote:

> 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


I completly agree, POV-Ray shouldn't become an advanced programming language
like C++ or Java, but it should offer POV-artists a much more easier way of
making complex and realistic scenes. I think concentrating on that is the
only way of making POV more efficient.

I don't want to have to learn C++ before using POV, because POV is good as
it is now, the only thing i want is an easier way to make my scenes look
good. Making the language more complex isn't going to help anyone who's not
interested in the technological details, but wants to make a nice scene.

POV's got enough handy programming-features that i use to make my work
easier (like macro's, loops and defining variables and objects), they're
not to hard to understand and i'd like to keep it that way.

Post a reply to this message

iceqb <nomail@nomail> wrote:
> I completly agree, POV-Ray shouldn't become an advanced programming language
> like C++ or Java, but it should offer POV-artists a much more easier way of
> making complex and realistic scenes.

  One could argue that those two things are actually the same thing.

> I don't want to have to learn C++ before using POV

  A fully-featured object-oriented language does not automatically mean
that you *must* learn *all* the intrinsic complicated details of the
language in order to create scenes. I have always wondered why so many
people seem to think like it does.

  Let me present a comparison, using Windows:

  Does a regular user, who just wants to surf the net and read his email,
have to learn how to edit the Windows registry?
  The answer is naturally: No.

  Is it *bad* that Windows includes the means to edit the registry?
  Of course not. Those who want to edit it can do so. Is that bad?

  The fact that a feature *exists* does not mean that you *must* even
know about its existence in order to use the program.

  If fully object-oriented features are added to the scene description
language, so what? It doesn't necessarily mean that you must learn to
use them in order to create scenes.

  You have to realize that there are two kinds of POV-Ray users: Artists
and developers.
  The idea with enhancing the language is that developers have better
better tools to create easy-to-use libraries for the artists to use.

  Wouldn't you like it if you could just write 'import("scene.3ds")' and
magically the 3ds file is imported and rendered?
  If the SDL is enhanced enough and if some developer creates such a
library, then you can do exactly that, ie. import 3D-Studio files with
a one-liner (without even having to know that something called
"object-oriented programming" even exists).

  So I more or less completely disagree with you: POV-Ray *needs* and
would greatly benefit from a fully-featured programming language.

-- 
Hanki elämä, hanki Linux.
                                                          - Warp

Post a reply to this message