[Top][All Lists]
[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
- Re: [grt-talk] Some suggestions., Anton N. Mescheryakov, 2003/05/05
- Re: [grt-talk] Some suggestions.,
Nikodemus Siivola <=
- Re: [grt-talk] Some suggestions., Nikodemus Siivola, 2003/05/05
- Re: [grt-talk] Some suggestions., Anton N. Mescheryakov, 2003/05/08
- Re: [grt-talk] Some suggestions., Nikodemus Siivola, 2003/05/08
- Re: [grt-talk] Some suggestions., Anton N. Mescheryakov, 2003/05/08
- Re: [grt-talk] Some suggestions., Nikodemus Siivola, 2003/05/08
- Re: [grt-talk] Some suggestions., Anton N. Mescheryakov, 2003/05/10