Re: [grt-talk] textures

[Simon Adameit]

Nikodemus Siivola wrote:
> You bet I've thought about it -- se below. Tell me what you think!
>
> My comments in the just-recently-committed object.lisp:
>
> ;; Object struct should probably look like:
> ;;
> ;; (defstruct object
> ;;      shape
> ;;      texture
> ;;      shape-matrix
> ;;      texture-matrix)
> ;;
> ;; (defstruct shape
> ;;      intersect-first
> ;;      intersect-all
> ;;      normal
> ;;      inside)
> ;;
> ;; and ditto for texture. This way eg. all spheres could share the same
> ;; shape-struct, which would be very handy for implementing particle
> ;; systems, etc with *lots* of objects.

Sounds cool ;-)
Whats your state on bounding? I ask cause in case you don't already do 
we should also use bounding for inside test, this would enable one to do 
really big csg differences and intersections without great speed loss.

> Thats a first-level solution in my mind: it anables us to treat the
> texturing aspects of an object as a whole, without yet changing the overall
> desing all that much. Pigment function just becomes :
>
>  (funcall (texture-pigment (object-texture object)) point)
>
> in stead of:
>
>  (funcall (object-pigment object) point)
>
> Nice and simple.
>
> The second level solution would be to pass the ray-structure to the various
> texturing functions instead of just the point: voila, we have
> view-dependant textures, something not very many raytracers have...

Ok, dunno if we should go that route or just jump to 3 straight away, 
it'll require design changes anyway.

> The third level solution is to make the actual rendering function part of
> the texture: a full blown shader based architecture. This would mean that
> the initial ray would be traced into the scene, first intersection found,
> and then:

>   (funcall (object-shader object) ray scene)
>
> This just sounds too simple to be truly workable. ,)=
>  

And its exactly what we should do!
The possibilities this offers are just awesome ;-)