Jim Henderson <nos### [at] nospamcom> wrote:
> IIRC (and I probably don't), unrolling loops (in particular) is an 
> optimization;

  So how do you unroll a loop which depends eg. on the color of a pixel,
determined at rendertime?

-- 
                                                          - Warp

Post a reply to this message

in news:46e7797a$1@news.povray.org Fa3ien wrote:

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

I like that.

somewhat related, here is a link to something somebody did in Python to 
creat POV-Ray scenes. http://arrowtheory.com/software/python/pypov/
I did simmilar things myself and immediatly missed a built in vector <>.

ingo

Post a reply to this message

in news:Xns99A9CF023F162seed7@news.povray.org ingo wrote:

> somewhat related, here is a link to something somebody did in Python to 
> creat POV-Ray scenes. http://arrowtheory.com/software/python/pypov/
> 

I should not this was written for Python users, so it uses things not 
ovious for POV-Ray users like list comprehention. There is non need to use 
it that way.

ingo

Post a reply to this message

Jim Henderson wrote:
> 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.
> 
That was indeed my suggestion. Add sophisticated control structures to a 
high level language and while executing that, fill a pipeline with 
objects and other necessary descriptions of the scene.

For what I mostly do that would be enough and I could even imagine that 
I would write my matlab programs in such a way that I could directly 
fill the pipeline. But I have never used complex textures, so I am not 
in a position to judge if you really need a full blown programing 
language to define those. Nor if that would be incompatible with such a 
pipeline.

Post a reply to this message

On Wed, 12 Sep 2007 13:38:41 -0400, Warp wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> IIRC (and I probably don't), unrolling loops (in particular) is an
>> optimization;
> 
>   So how do you unroll a loop which depends eg. on the color of a pixel,
> determined at rendertime?

I presume that would be done when the SDL is parsed and the colour was 
determined.  Just at a guess - I don't claim any expertise.

I think what andrel was getting at was not that users should code in 
tokenized form, but instead was suggesting a way that the developers 
might use the tokenized/bytecode generated from the parser.

Jim

Post a reply to this message

Warp wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>> IIRC (and I probably don't), unrolling loops (in particular) is an 
>> optimization;
> 
>   So how do you unroll a loop which depends eg. on the color of a pixel,
> determined at rendertime?
> 
Interesting concept.
Trying to think of a situation where the presence of objects can only be 
determined during a render...
Failing...
I think that would imply that the order of evaluation would be relevant, 
which would make parallel rendering impossible.
Perhaps not a good example. But feel free to come up with another. I 
think such examples are vital in determining how intertwined the 
language has to be.

Perhaps one case could be that you want to create a marble bas relief by 
creating a displacement map from another scene.
Can I donate this one to Fabien's list?

Post a reply to this message

Le 12.09.2007 21:12, andrel nous fit lire :
> Warp wrote:
>> Jim Henderson <nos### [at] nospamcom> wrote:
>>> IIRC (and I probably don't), unrolling loops (in particular) is an
>>> optimization;
>>
>>   So how do you unroll a loop which depends eg. on the color of a pixel,
>> determined at rendertime?
>>
> Interesting concept.
> Trying to think of a situation where the presence of objects can only be
> determined during a render...
> Failing...

Have a look at trace function... In still parsing time, already
performing some rendering, usually to place some additional objects.

> I think that would imply that the order of evaluation would be relevant,
> which would make parallel rendering impossible.

There is parse time, and then render time.
But particule system just want to mix them...
And radiosity is another hell.

Of course, once parsed, a full scene could be output just as a
serialisation of all the objects in the scene.

But if you have some parameters for your scene, instead of accessing
only these parameters, you have to make each possible scenes...
Let's say you have a macro to generate a cubic cristal of spheres.
The parameter is the number of sphere per side of the cube. Just
three nested loops, one parameter.

Unroll them... and now what if you want a cube of 4 instead of a
cube of 3 ? A cube of 6 ?

-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

Warp wrote:
>   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).

I don't see why this sort of thing can't be implemented via callbacks or 
objects (we are using C++, so why not take advantage of it?).

Maybe I can say it more clearly this way: We could use some sort of 
event-driven architecture where the rendering engine fires off events to 
the script interpreter and gets instructions that way.

I would expect it would be possible to do something like this in a way 
that's almost invisible to the scripting language itself.

OTOH, I would expect a performance penalty for something like this, but 
I would also expect it to be fairly minor. Correct me if I'm wrong.

-- 
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

You know you've been raytracing too long when you spend more time 
"tweaking" a texture than modelling the rest of the scene.
     -- Twyst

Post a reply to this message

BTW, what I would really like is to see a half-dozen different prototype 
new SDLs appear as working prototypes that people can play with. After 
people have kicked the tires on them for a few months, at some point by 
consensus/vote/royal decree/Voice of God/whatever one of them would be 
"blessed" as the new official SDL.

It's a bit messy, but strikes me as *much* better than some 
design-by-committee monster.

Anyway, that's why I'd really like to get some decent separation between 
the parser and renderer code, within reason.

-- 
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

You know you've been raytracing too long when you know a lot more about 
basic anatomy and proportions than the average person with a degree in 
fine arts.
     -- Quietly Watching

Post a reply to this message

On Wed, 12 Sep 2007 15:44:29 -0700, William Tracy wrote:

> OTOH, I would expect a performance penalty for something like this, but
> I would also expect it to be fairly minor. Correct me if I'm wrong.

Well, from a performance computing standpoint, remember that "minor" 
times a million/billion/trillion suddenly becomes something other than 
"minor". ;-)

Jim

Post a reply to this message