Re: [grt-talk] GRT in the year 2004 (space and beyond!)

[Nikodemus Siivola]

On Tue, 25 May 2004, Jason Dagit wrote:

>  >  * Supporting both wavelength and RGB models. I have no idea how to
>  >    do this yet, or what it involves.
>
> That is an interesting idea.  Sometimes I'm glad I saved my physics
> texts.  I'm sure I can find some useful equations or starting points
> for modeling wavelengths.  Combining the two intelligently may become
> (more) obvious after we know how to model wavelength.

If you're interested in this, "salex" on #lisp knows about wavelength
models in rendering: ask him to recommend a reference.

>  >  * Better scene introspection thru layered scene component
>  >  representation:
>  >    scene objects will be CLOS objects, making it easy to poke
>  >    around a scene. They will be compiled into an efficient
>  >    representation (similar to what is used now) for actual
>  >    rendering. The compiled representation may or may not have a
>  >    back-pointer to the original -- keeping it *might* make *some*
>  >    fancy stuff easier, but is also less space-efficient.
>
> I'd need to see your ideas on this one.  Sounds like an neat idea, but
> I have no clue what it really implies.  I assume this is a solution to
> needing access to state for shaders to use.

Not really, this is mostly orhtoganonal to shaders. It means that our
scenes are initially built as grahs of objects, looking like eg.

 (defclass object ()
   ((transformations :initarg () :accessor get-transformations)
    ...))

 (defclass sphere (object)
   ((radius :initarg :radius :accessor get-radius)
    (center :initarg :center :accessor get-center)))

Now you can poke at the scene and do some things that were either a lot
harder or impossible before: get (and change) indivual properties of a
sphere, including each separate transformation that has been applied.
You can eg. re-order those transformations. I'm also hoping that this
intermediat form is more amenable to eg. OpenGL rendering / previews.

This format is dog-slow to render, of course, so we compile it into
something very much like the current representation, where most individual
slots hold closures ready for application.

 (defstruct primitive
   ...
   inverse-matrix
   intersect-first
   intersect-all
   ...)

Oh, when I say "compile", I don't mean "generate code", but rather
"generate those structure instances out of the data held in the other
representation".

>   4) We use 2 or 3 different licenses for the code.  I'm not sure of
>      all the pros/cons, but I've seen several projects do this.  Just
>      an idea to consider.  That would allow the users of GRT to choose
>      the license that fits their needs.  For example, if anyone wanted
>      to create a GPL'd project using our code is able to wrap GRT in
>      the GPL.  On the other had, if some commercial company wanted to
>      use GRT they could use the MIT license.  The way I understand the
>      MIT license is that GLP'd projects that borrow code have to get
>      permission to GPL the borrowed code if they want to extend it and
>      have it be covered under the GPL.  I think this approach
>      circumvents the need for permission.

Nope. MIT-license for all practical purposes allows relicencing under GPL:
it's essentially what "GPL compatible" means. You must keep the permission
notice, but you're allowed to sublicense.

I think that cases where dual licensing makes sense are when various bits
of the software have diverse origins and licenses, eg. offering individual
parts under their own license, or the whole under XYZ.

The only problem with MIT is that's it's not a strong copyleft, and hence
frowned upon by FSF. Well, they do a great job in many respects, but here
I do not agree politically. I'd prefer to put my stuff in public domain if
that was an internationally viable option. (Not all countries have a
consept of public domain, so any time someone eg. from Germany contributes
somehting like a MIT-license has to be slapped on the code).

> Keeping the 0.1 release at savannah under the GPL is the
> least we can do to pay back the FSF for letting us use their system
> to create GRT.  And it has little impact on the future of GRT.  It
> would become a project in need of a new maintainer is all.

Keeping "grtlite" and "GRT 0.1" around indefinitely is easy enough --
either by letting them hang around on savannah or moving them elsewhere.
Also, if you or Simon wants to maintain a GPL branch/fork, it's cool.

However, what I do not want to see is GRT turn into a yet another
maintainerless savannah project: *if* development is moved elsewhere and
*if* there is no fork, keeping the savannah project alive is just
confusing, and serves no purpose at all that I can see.

Cheers,

 -- Nikodemus                   "Not as clumsy or random as a C++ or Java.
                             An elegant weapon for a more civilized time."