Re: [grt-talk] Some suggestions.

[Nikodemus Siivola]

On Mon, 5 May 2003, Anton N. Mescheryakov wrote:

> As I previously pointed out, usage of *scene* variable is
> 1) Bad Lisp style

This is debatable. Abuse of varibales is always bad, but not all
variable use is abuse. Btw: note that it's not exported from GRT.

Anyways, I do actually agree that it's a mild kludge in scene-creation, but
I'm beginning to feel that using a special variable set by RENDER to hold
the scene being rendered (and the rendering state) can afford a much
cleaner design of some of the internals, eps.  regarding the planned
shader/filter architecture. (See archive.)

> 2) Root of possible subtile run-time errors

I really doubt this one. Really. In general this is accepted wisdom
regarding lexical global variables, but I truely fail to see how this
applies here.

Can you show an example of how you could do that without breaking the
encapsulation offered by packages?

> 3) Abuse of language features

Like 1) this is debatable. *SCENE* may be bad design, but abuse of language
features? Variables are ment to hold state. That's what it does.

It's not even being used to communicate mutable state between multiple
functions (which is the problem with overuse of lexical globals), just used
to accumulate state (which is later used as a default) via functional
interface.

> 'form-scene is _an_example_ of small macro that makes the same job
> without additional run-time overhead. It fits nicely into examples.lisp,
> among other things.

This is actually pretty much what I was trying to point out: it's good for
small scenes. For big scenes people are going to use custom interfaces
anyways.

> You must assume that there must be some room for scenes other than
> default *scene*, too.

There is:

 (let ((scene (make-scene ...))
    (render :scene scene ...))

> You're almost right. But you see, grt in general is useless for anything
> big and will remain in this state unless some degree of  Good Lisp Style
> will be here; destructive modification and usage of global variables
> isn't good style unless unavoidable.

I think there are several, separate issues at work here:

 * Currently GRT is useless for anything big.

 * In order to be useful for anything big GRT needs to be
   a) efficient, b) flexible, c) featureful

Good Lisp Style (tm) is instrumental in keeping things flexible and adding
new features at a fast pace.

Good Lisp Style (tm) is not the same thing as functional programming.
Variables and destructive modification are OK, it's their misuse that's
bad.

And finally: since an inefficient raytracer is not worth the bits it
contains, Good Lisp Style (tm) will be sacrificed with glee on the altar of
efficiency when necessary.

---

A totally separate issue is the scene-construction code. It has nothing to
do with efficiency: if has to do with user-friedliness. This is why I think
we should provide several alternative scene-construction interfaces:

 SCENE-FORMS style for small scenes.

 MAKE-SCENE (and related accessors) for those who need / want to roll
 their own.

 ? others ?

But I *do* agree that NEW-SCENE, SCENE, etc. should be replaced by
other things.

> But both files can share _code_ even working on different data. It's
> said that Lisp program has ~20% of size of corresponding C++ program...

Ok, can you write a patch? The important bits are to maintain a separate
color and vector -type, and separate interfaces. I'm all go for using the
same code behind those interfaces.

> > pattern = mapping of values 0.0 - 1.0 to space

> Terminology 'pushnew: "mapping" in computer graphics is usualy referred

I used the word mapping in purely descriptive sense, as in

  R: 3D -> [0.0 .. 1.0]

The point was about *pattern*, which as far as I can tall has no clear
accepted usage, but which has a very clear meaning in the internals of GRT.
Or at least should.

> to the way of translation object-space #(x y z) coordinates into
> texture-space #(u v w) coordinates (yes, textures can be 3D). In that
> terms mapping is referred as "spherical", "planar", "cylindrical" etc.,
> so I've meant this in that way.

Actually, are you certain this is so? I'm thinking that when the word is
used the contex is usually obious, so the relational understaning of
"mapping" is quite adaquate.

Maybe we should defer to the native speakers on the list?

> Alpha is _a_ way to blend patterns. Pattern can generate alpha values
> and image patterns can introduce their own alpha. Useful for layered
> textures, decals etc.

Note your usage of "pattern": you are talking about pigment (or color)
patterns. Pattern as such is just a function that returns a value in range
0.0 - 1.0 for a point in space. Eg. gradient. This value can then be mapped
to a color, vector, or anything you will..

But you point about using alpha to blend colors is taken. But I don't think
using RGBA internally in light transport is the way to solve this. It's not
clean.

My thinking is that if you are blending two procedural pigments you can
just as easily specify a procedural pattern that functions as the alpha
channel. And if you are dealing with image-maps you get the alpha from the
image and use that interpolate the colors.

> OK,  we've come to some interesting point there. Do you mean grt as,
> say, Lisp povray clone, or bias it towards real production?

I'd say that neither. Or both.

On the sort term GRT's goal is to become a nice classical raytracer. This
is *less* than POVRay is.

On the long term ... who knows. But I don't think a single movie studio
will ever use GRT, no.

> sides, but questions like "why environment mapping" give me a clue that

Not why, what. I was wondering if you were using it in some other sense
than usually, which you weren't.

> about it. But I've seen some hype about "image synthesis system" so now
> I'm a bit confuced...

I think I can clarify. By image synthesis system I mean a system that can
be used to generate images by a variety of means and paradigms: not and
industrial quality rendered.

Cheers,

  -- Nikodemus