Re: [grt-talk] Some suggestions.

[Anton N. Mescheryakov]

> Any interesting scene is going to be non-trivial by definition, and with
> some supporting (procedural object placement, etc) code 1000 lines can
> easily happen.
>
> And nobody wants to cram 1000 lines of code inside a single with-scene.
> Hell, nobody wants to put in a single file if they can avoid it.
As I previously pointed out, usage of *scene* variable is
1) Bad Lisp style
2) Root of possible subtile run-time errors
3) Abuse of language features
'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. Also, there isn't anything that hinders  procedural 
object placement; just some overconsing, but it's said that modern lisp 
GC's are good while destructive modification might be not.

> You must assume that people are going to do funky things in their
> scene-generation code: either they are going to have to generate the input
> for FORM-SCENE, or they are going to be stuffing objects into lists and
> calling MAKE-SCENE manually at the end.
You must assume that there must be some room for scenes other than 
default *scene*, too.

> What I mean, is that WITH-SCENE, or FORM-SCENE, or whatever is very good
> far small, trivial scenes, but pretty useless for anything big. It doesn't
> seem to scale. I may be wrong, though.
>  
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.

>  
>
> > BTW. It looks like background isn't accounted in reflections, or I'm
> > wrong?
> >    
>
> Sure it is: if nothing is hit, the backgound color is returned by TRACE.
> Or are you referrring to something else?
>  
Sorry, I've missed t clause in trace-ray somehow.

>  
>
> > Another BTW: math.lisp and color.lisp both have much in common,
> > agree? Just the same operations with grt-float triples. Why don't merge?
> >    
>
> Several reasons:
>
> * Clarity: it should be explicit whether we are dealing with colors
>   or vectors.
>
> * We may wish to change vector and color representations independently.
>   (Different color-spaces, double-float vectors, integer colors, etc...)
>  
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... 
if the problem can be expressed in C++ anyway. So let's stress language 
strengths and avoid its flaws.

>  
>
> > This is the stuff I'm currently thinking or working on:
> >    
>
> You can add a file "proto-mapping.lisp" to CVS, and develop this stuff
> there. That way it'ss be easier to integrate.
>
> Terminology note:
>
> pattern = mapping of values 0.0 - 1.0 to space
>  
Terminology 'pushnew: "mapping" in computer graphics is usualy referred 
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.

>  
>
> > 1. Pattern mapping. That is, explicit, planar, spherical etc. Just
> > transforms object coords into pattern space. Almost obligatory for image
> >    
>
> Goodygood.
>
>  
>
> > 2. Pattern blending. That's why my previous question about RGBA arises.
> >    
>
> I don't understand what you mean. Blending patterns needs a blending
> function, not alpha. What am I misunderstanding?
>  
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.

> Be aware that I am planning a generalized pattern mapping: specify a
> pattern, a set of samples, and a blending function, and get a function that
> return whatever you want a point in space. Something like this:
>
> (funcall (make-mapping :pattern #'gradient
>                        :samples ((0.0 'foo) (0.2 'bar) (0.9 'quux))
>                        :blend #'blend-symbols)
>          (grt-vector 0.0 0.5 0.0))
>
>  => 'boux
>
> Of course, it'll no doubt be more common to blend colors than symbols, but
> that's beside the point. ;)
>
>  
>
> > 3. Patterned background/environmental mapping.
> >    
>
> Patterned backgound seems clear enough, but what do you mean by
> environmental mapping in conjuction with raytracing?
Environmental mapping is quite useful for raytracing, too. First of all, 
it's a good way to cache rendering data. Render some static environment 
of chrome object once and use it as you heart desires. Next, it's useful 
then you CAN'T render environment but you've to render some 
reflections/refractions or so.

OK,  we've come to some interesting point there. Do you mean grt as, 
say, Lisp povray clone, or bias it towards real production? In the 1st 
case, our aim is robust, mathematicaly correct program that create nice 
pictures like chrome torus knot over checker plane; on other side are 
programs like Lightwave, Maya, RenderMan systems and so on which stress 
_visual_quality_. POVRay is a pain in many places than it comes to  
photorealistic matters. Of course, grt is fairly far away from both 
sides, but questions like "why environment mapping" give me a clue that 
the course is plotted to the first case - and here isn't anything wrong 
about it. But I've seen some hype about "image synthesis system" so now 
I'm a bit confuced...

Just some random remarks,
   Anton N. Mescheryakov.