Re: [grt-talk] Some suggestions.

[Anton N. Mescheryakov]

Nikodemus Siivola wrote:

> On Mon, 5 May 2003, Anton N. Mescheryakov wrote:
>
>  
>
> > As I previously pointed out, usage of *scene* variable is....
> >    
OK, I'll no longer despute this subject, as there're much more 
interesting things out there.

> * 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.
>  
Ditto. Let's go and we'll see. BTW, did anyone run a profiler over grt?

> ---
>
> 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 ?
Some kind of READable dump for load/save features in future GUI.

> > 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? 
No problem. There's a LOT of repetative code patterns in grt. Example: 
CSG mechanics. Why don't merge (csg-type-thing ...)'s into (csg-thing 
'type)?

> 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.
I'm too. It's lisp, after all.

> > > 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.
>  
The term "mapping" goes from map-making department, IMO. It's a way to 
_map_ some set of points from part of curved surface to the flat. But 
for future references, I offer the term "projection" to avoid 
misunderstandings.

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

> > 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.
>  
Why *less*, BTW? I've thought it's *equal*.

> On the long term ... who knows. But I don't think a single movie studio
> will ever use GRT, no.
>  
If it'll "blossom" into decent raytracer at least, I'll use it for 
scientific visualizations. Somtimes it involves movies, so...

In meantime, I've some new fool stupid questions:
1. It looks like grt lacks some interesting feature called "scene 
graph". That is, scene objects seems to be thrown in the single layer 
without transformation groups and so on.
2. CSG stuff is really good indeed, besides one severe limitation: it's 
two-way only. I think that it may be resolved in conjuntion with more 
robust occlusion/visibliliy testing.
3. I'm somewhat new in raytracing internals, as you could see. So one 
thing is really strange for me: is it absolutely nescessary to transform 
ray->object space for each test rather than transform object->ray space 
once per traversal?

Best regards,
   Anton N. Mescheryakov.