 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle <evi### [at] hotmail com> wrote:
> By the way, I have been reading the stuff Pixar has at
> http://graphics.pixar.com
wow! wonderful collection of papers! thanks for the link!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My 2 cents...
I think that, prior to discussions about which approach should be
taken, we should create a dozen (or so) of typical simple scenes
which would include most typical SDL features (one with a loop, one
with a macro, one with textures, one with 'trace', etc...).
Each envisioned language and/or paradigm should be tested 'against'
these scenes, with sample would-be code. This would allow, IMO,
better evaluation upon criterias such as features, powerfulness,
expandability, readability, user-friendliness, ease of implementation, etc...
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> This would COMPLETELY DESTROY the way this community works. The language
> *must* be human-friendly.
I second that. In these days of point-and-click systems, people are already
frightened enough at the idea of *typing* something to get an image. If
the language becomes human-unfriendly, the future of POV-Ray is, at best,
to become some other Blender-compliant rendering engine...
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote:
> My 2 cents...
>
> I think that, prior to discussions about which approach should be
> taken, we should create a dozen (or so) of typical simple scenes
> which would include most typical SDL features (one with a loop, one
> with a macro, one with textures, one with 'trace', etc...).
>
> Each envisioned language and/or paradigm should be tested 'against'
> these scenes, with sample would-be code. This would allow, IMO,
> better evaluation upon criterias such as features, powerfulness,
> expandability, readability, user-friendliness, ease of implementation,
> etc...
Very good idea!!!
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Buck schrieb:
>
> I'm going to make a radical proposal for you to think over.
>
> As POVRay's SDL has evolved over the years, it's become more and more
> like a programming language. I think it's worth considering pushing it
> into a real programming language.
>
> These days, I do most of my work in Smalltalk. It's one of the simplest
> yet most powerful programming languages around.
> [...]
The question of the general concept of a new SDL or extension of the
existing one has already been discussed quite a lot (some of it in
private) - although there has not been anything definite on the matter
yet some important issues have crystallized that stand against your
suggestion.
Anyone agrees that the current SDL lacks important features for coding
more complex functionality and the current design significantly limits
performance of SDL code interpretation. Both together make it difficult
to extend POV-Ray's features using the SDL.
Another problem of the current language is that the different levels of
the language are difficult to understand for the beginner - the use of
loops and macros in user defined functions being a good example.
But the most important thing is it needs to be straight away to do
simple scenes using it. Languages like Smalltalk appeal to the ones who
know them because they are very consistent on the whole. The price for
this however is that even for the most simple tasks you need to
understand most of the language's advanced concepts and this makes it
fairly unsuited as a SDL.
In short: Simple tasks like a reflective sphere over checkered plane
need to be straight away to implement and to read - without knowing
about language concepts. Like in the current SDL version of such a
simple scene the purpose of every token should be intuitively
understandable. More complex features of the language would need to be
optional additions to this.
-- Christoph
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> Warp wrote:
> > andrel <a_l### [at] hotmailcom> wrote:
> >> My suggestion for a 'new' language would be to have an as simple as
> >> possible language (without loops and control structures)
> >
> > Bad idea. The new language should be more powerful, not less.
> >
> A small misunderstanding, I guess. What I proposed was to have a well
> defined low level language (think RISC)
A RISC without loops and control structures? I still think it's a bad idea.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> It even features the infamous tail call optimization from functional
> languages!
I believe the word "infamous" has a negative connotation to it. Was that
really what you wanted to express?-)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle <evi### [at] hotmailcom> wrote:
> How hard would it be to separate the parser and the renderer as much as
> possible, and thereby allow for both a parser based on the current SDL,
> and another parser based on an entirely different SDL (as well as a
> rendering engine that is not primarily a ray-tracer)?
I'm not 100% sure that separating the parser from the renderer even
further is actually the right thing to do.
It may sound rational because it would allow changing the parser easily.
However, that's where the advantages end. The disadvantage is, however,
that it would limit the usability of the language *during rendering* even
more than the current SDL (which at least has user-defined functions which
can be evaluated during render-time).
A separate "shader" language and a "post-processing" language would be
needed for enhanced functionality. That's already three separate languages
in one. Is that really what we want? Or do we want one language which can
be used for everything?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 12 Sep 2007 07:27:16 -0400, Warp wrote:
>> A small misunderstanding, I guess. What I proposed was to have a well
>> defined low level language (think RISC)
>
> A RISC without loops and control structures?
IIRC (and I probably don't), unrolling loops (in particular) is an
optimization; but at a low level, I don't necessarily see that as a bad
idea myself. But the high-level language does need these structures.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> > It even features the infamous tail call optimization from functional
> > languages!
>
> I believe the word "infamous" has a negative connotation to it. Was that
> really what you wanted to express?-)
>
> --
> - Warp
that was my half-assed attempt at a joke at replacing the term "famous". :P
obviously, tail call optimization is a very Good Thing!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
