Peter Hokanson <pch### [at] riceedu> wrote:
> This may seem a little odd, but why not use Python as an SDL?
> ...
> If not Python, then perhaps some other established language should be
> considered.

This has already been discussed quite a lot and quite often.

I am by now convinced that with *all* well-established languages, such an
approach would invariably lead to an SDL that may be quite fitting for
programming complex stuff, but cumbersome for the most essential tasks the SDL
will have to be used for: Describing the actual scene elements to instantiate.

I think the right way to go is take an established free open-source language
(which should be bytecode-based, have a very simple core, and designed to be
embedded into other software; my current champion for this would be Lua) and
replace or heavily modify its parser to suit the specific needs of POV-Ray.

If there's one thing a new SDL *must not* do, then it's making plain-vanilla
scene description significantly more cumbersome than with the current SDL.

Post a reply to this message

clipka wrote:

> I think the right way to go is take an established free open-source
> language (which should be bytecode-based, have a very simple core, and
> designed to be embedded into other software; my current champion for this
> would be Lua) and replace or heavily modify its parser to suit the
> specific needs of POV-Ray.
> 

While I do see your point, I think that Python has some features that might 
make this manageable.  For example:

from povray import *
MyTex = texture(pigment=(1,1,1))
sphere((0,0,0),5,texture=MyTex)

Even if this isn't the default interface, it would be nice to have the 
programming capabilities of Python to use in a POV-Ray scene.  I've thought 
about writing something similar myself, but it would be a lot of work.

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(...)

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

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).

Post a reply to this message

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

"clipka" <nomail@nomail> wrote:
> 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?

I think this can be done with positional arguments. The constructor for a type
would have to accept variable arguments  and then determine if there is more
than one texture by if more than one argument is a texture object:

class baseobject:
  def __init__(self, *args):
    for i in *args:
      if isinstance(i, texture):
        self.textures.append(i)
        self.texture_transforms.append(transform())
      if isinstance(i, (transform, rotate, scale, translate)):
        self.transform_matrix.update(i)
        for j in self.texture_transforms:
          j.update(i)

class sphere(baseobject):
  def __init__(self, *args):
    # Extract sphere-specific arguments first and pass the rest to the base
    baseobject.__init__(self, ...)


mysphere = sphere(
  (0, 0, 0), 5,
  scale(4), # Doesn't affect any texture
  texture(
    pigment(
      checker(0.5, color(0.0, 0.0, 0.0, 0.5), color(0.5, 0.5, 0.5, 0.5))
    ),
    finish(...),
  )
  scale(x=4, y=1), # Affects the first texture only
  texture(...),
  ...
)

My question would be, how to differentiate between creating an object or just
declaring it.  Maybe a special function to add the object to the scene:

add(sphere(
  ....
))

or perhaps a special global object that if in the attributes would cause it not
to be added to the scene list

class Dummy:
  pass

nocreate = Dummy()

class baseobject:
  def __init__(self, *args):
    create = True
    for i in args:
      ...
      if i is nocreate:
        create = False
    if create:
      scene_objects.append(self)


mysphere = sphere(..., nocreate)

Post a reply to this message

"Allen" <bri### [at] yahoocom> wrote:
> My question would be, how to differentiate between creating an object or just
> declaring it.  Maybe a special function to add the object to the scene:
>
> add(sphere(
>   ....
> ))

This seems unnecessarily cumbersome to me (like a few other details of your
suggestion)...

> or perhaps a special global object that if in the attributes would cause it not
> to be added to the scene list
>
> mysphere = sphere(..., nocreate)

.... while this seems to me like a conceptual kludge. I don't think it would be
wise starting a new SDL with kludges already. They tend to accumulate anyway
over time.

I also note that your variable-parameters approach relies heavily on individual
object classes doing parsing-related work. We would end up with much of the
parser de facto implemented in individual object classes, which would be prone
to making the language inhomogenous.

I think that instead, objects should just expose certain properties and
"actions" in a standardized manner, which the parser/runtime module should
"drive", with the objects being completely oblivious of the language's details.

Note that this idea includes a separation between the basic language syntax, and
the actual obejcts, properties and actions available.

Post a reply to this message

in news:web.4a0b00b73a7e550e405e15c60@news.povray.org clipka wrote:

> Peter Hokanson <pch### [at] riceedu> wrote:
>> This may seem a little odd, but why not use Python as an SDL?
>> ...
>> If not Python, then perhaps some other established language should
>> be considered.
> 
> This has already been discussed quite a lot and quite often.
> 
> I am by now convinced that with *all* well-established languages,
> such an approach would invariably lead to an SDL that may be quite
> fitting for programming complex stuff, but cumbersome for the most
> essential tasks the SDL will have to be used for: Describing the
> actual scene elements to instantiate. 
> 
> I think the right way to go is take an established free open-source
> language (which should be bytecode-based, have a very simple core,
> and designed to be embedded into other software; my current champion
> for this would be Lua) and replace or heavily modify its parser to
> suit the specific needs of POV-Ray. 
> 
> If there's one thing a new SDL *must not* do, then it's making
> plain-vanilla scene description significantly more cumbersome than
> with the current SDL. 
> 
> 
> 

10 years ago this was written. 
Sorry for diggin up a thread this old, but, how a bout a concept like in 
the Seed7 extensible programming language 
http://seed7.sourceforge.net/faq.htm#extensible_programming . That would 
make it possible to write and render include files and when all is fine 
(trans)compile them so they become 'part' of the SDL. (This without regard 
of the choise for actual syntax.)

Ingo

Post a reply to this message

ingo <ing### [at] tagpovrayorg> wrote:
> in news:web.4a0b00b73a7e550e405e15c60@news.povray.org clipka wrote:
>
> > Peter Hokanson <pch### [at] riceedu> wrote:
> >> This may seem a little odd, but why not use Python as an SDL?
> >> ...
> >> If not Python, then perhaps some other established language should
> >> be considered.
> >
> > This has already been discussed quite a lot and quite often.
> >
> > I am by now convinced that with *all* well-established languages,
> > such an approach would invariably lead to an SDL that may be quite
> > fitting for programming complex stuff, but cumbersome for the most
> > essential tasks the SDL will have to be used for: Describing the
> > actual scene elements to instantiate.
> >
> > I think the right way to go is take an established free open-source
> > language (which should be bytecode-based, have a very simple core,
> > and designed to be embedded into other software; my current champion
> > for this would be Lua) and replace or heavily modify its parser to
> > suit the specific needs of POV-Ray.
> >
> > If there's one thing a new SDL *must not* do, then it's making
> > plain-vanilla scene description significantly more cumbersome than
> > with the current SDL.
> >
> >
> >
>
> 10 years ago this was written.
> Sorry for diggin up a thread this old, but, how a bout a concept like in
> the Seed7 extensible programming language
> http://seed7.sourceforge.net/faq.htm#extensible_programming . That would
> make it possible to write and render include files and when all is fine
> (trans)compile them so they become 'part' of the SDL. (This without regard
> of the choise for actual syntax.)
>
> Ingo
Hi, you probably missed it, otherwise your post could have been an answer to
this one posted in the last few weeks which received no answer:
http://news.povray.org/povray.pov4.discussion.general/thread/%3Cweb.5d421a0f46a21447884ec9560%40news.povray.org%3E/

Post a reply to this message