grt-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [grt-talk] Some suggestions.


From: Nikodemus Siivola
Subject: Re: [grt-talk] Some suggestions.
Date: Mon, 5 May 2003 15:11:00 +0300 (EEST)

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

> >There is also the question of less than trivial scenes (say anything with
> >over 1000 lines of code): the interface has to be nice for them as well.
> >
> Hey, guy! Why 1000 lines of code? 11 looks enough!

You misread me. I'm talking about big scenes, not big macroes.

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.

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.

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.

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

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

> 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

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

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?

  -- Nikodemus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]