clipka <ano### [at] anonymousorg> wrote:
> Note that my goal is for the language /per se/ to have a very simple 
> syntax, and make it pretty much oblivious to rendering, except for 
> providing a few special native data types like 3D vectors and colours. 
> It'll be up to a bunch of predefined classes to fill it with raytracing 
> life in its scene description role. Such a language should be generic 
> enough to also be suited for the shader description role, so it would be 
> rather pointless and user-unfriendly to devise yet another language for 
> that purpose.

OTOH the "shader" part has to, by necessity, be more limited than the
generic part of the language. It wouldn't make sense, for example, to
be able to create new objects into the scene while evaluating, for
example, the color of a reflected ray. That would mess up things quite
badly, I think.

(Also, the reason why shaders in graphics hardware can be so fast is
that they are highly parallelizable. Modern cards run thousands of
instances of shaders in parallel. Obviously there need to be some
limitations in the shader language for this to be possible. There
can't be inter-dependencies between shader instances being evaluated.)

-- 
                                                          - Warp

Post a reply to this message