 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Andrey Skvortsov <sti### [at] list ru> 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 () {
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
|
|
| |
| |
|
|
|
|
| |
