 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le Forgeron <jgr### [at] free localhost> 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
|
|
| |
| |
|
|
|
|
| |
|
|
