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

On Wed, 12 Sep 2007 15:51:55 -0700, William Tracy wrote:

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

That would certainly make writing import tools easier - the parser could 
essentially *be* the import tool (ISTR that that's what's often said 
about import/conversion tools - that you'd have to reimplement a 
significant portion of POV to get it working properly).  Something like 
Blender (which is also GPL - since we're talking POV under GPLv3 in 4.0) 
would really benefit from that.

Jim

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Trying to think of a situation where the presence of objects can only be 
> determined during a render...

  Creating objects is not the only use for loops.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Trying to think of a situation where the presence of objects can only be 
>> determined during a render...
> 
>   Creating objects is not the only use for loops.
> 
I might be aware of that, but my question is: under what kind of 
circumstances would you need a user defined loop *after* you have fully 
specified the scene? I can't think of any, but I don't have much 
experience with shaders and complex textures.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> I might be aware of that, but my question is: under what kind of 
> circumstances would you need a user defined loop *after* you have fully 
> specified the scene? I can't think of any, but I don't have much 
> experience with shaders and complex textures.

  Loop over a series of pixels and calculate their average?

-- 
                                                          - Warp

Post a reply to this message