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