Peter Hokanson <pch### [at] mindspringcom> wrote:
> from povray import *
> MyTex = texture(pigment=(1,1,1))
> sphere((0,0,0),5,texture=MyTex)

Fine. Can we also write this as

  sphere((0,0,0),5,texture(pigment=(1,1,1)))

?

How about more complex scenarios, like multi-layered textures for instance?


> Also, Python is pretty fast, and could implement custom features/shaders
> without recompiling POV:
>
> class MyCam(camera):
>  def makeRay(x,y):
>   """Define a ray from the camera from x,y pixels"""
>   return ray(...)

See MegaPOV for how such a thing can be done even with the POV 3.6 framework.


>
> def myfunc(x,y,z):
>  """We could use traditional Python functions for isosurfaces and similar"""
>  return x+y+z

I see no valid point of using "traditional Python functions" in favor over any
other "traditional <YourFavoriteLanguage> functions" (including traditional POV
3.x SDL functions, the only ones to which I would attribute some inherent
favorability in this context).


> One of the things that has annoyed me about the existing SDL as of late is
> that not all blocks can be declared (patterns and others cannot be).

That's a totally different story. I guess *any* new SDL should address that -
and I guess any new SDL *will* address that, provided it is designed with a
sufficient degree of inherent formalism.

At its core, a next generation SDL should not know about spheres, textures,
patterns etc - all these should be just specific objects to the SDL, and
therefore all handled basically the same: They should use the same basic syntax
to create them, be all storable in variables, use the same syntax to evaluate
such a variable, etc.

The only things that might be worth treating specially are vectors and colors I
guess, as these are about as essential to POV as numbers and strings.

Post a reply to this message