"MessyBlob" <nomail@nomail> wrote:
.... my point being that (with appropriate assignments) you can already know the
existing size of the sphere, given that the whole scene was constructued using
declarative statements.

Post a reply to this message

in news:web.49e39942d93ad1dd2dae03a10@news.povray.org clipka wrote:

> I'll try to describe what I have currently in mind. But first let me
> present to you a kind of "hello world" scene written in that
> language: 
> 
> 
> include "colors.inc";

include colors
 
> SphereCenter = <0,1,0>;

Spherecenter = <0,1,0>
Sphereradius = 1

> sphere {
>   center: SphereCenter;
>   radius: 1 as SphereRadius;
>   texture {
>     pigment { color: #<1,0,0> }
>   };
> } as MainSphere;

MainSphere = sphere {
  center = SphereCentre,
  radius = SphereRadius,
  texture {
    color = <1,0,0> 
    //(if we need more than a 3-vector define the kind rgbf<1,0,0,1>)
  }
}

... the as SphereRadius is confusing and obfusicating.

read http://docs.python.org/tutorial/controlflow.html#defining-
functions and espacialy the next section.

the alternative of the above Mainsphere thus should be:

MainSphere = sphere {
  SphereCentre,
  SphereRadius,
  texture {
    color = <1,0,0> 
    //(if we need more than a 3-vector define the kind rgbf<1,0,0,1>)
  }
}
... kind of exactly the same as we have now :)

taking it a bit further, the way to declare macros should be exactly as 
done in Python, but then in SDL:

macro Sphere(spherecentre=<0,0,0>,sphereradius=1, ...etc)

so using the Sphere macro in the scene looks exactly like using the 
built in sphere.

Now Warp will of course argue that this new Sphere thing should not be 
a macro but a class that inherits from the "objects" class so all the 
texture etc. stuff is readily available and he's right.

class Sphere(object){
  spherecentre=<0,0,0>
  sphereradius=1
  and all kinds of clever code to generate the object
}
 
 
> modify MainSphere {
>   radius: 0.9;
> };

MainSphere.radius=0.9

MainSphere{radius=0.9} could be mistaken for the declaration of a new 
sphere with radius, using the default centre and texture.

I realy like Python, but don't use it as an SDL but steal as much 
possible from it and use it in a sytax as close as possible tot the 
current SDL as possible and read:

The Zen of Python

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do 
it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!


Ingo

Post a reply to this message

ingo wrote:

> I realy like Python, but don't use it as an SDL but steal as much
> possible from it and use it in a sytax as close as possible tot the
> current SDL as possible and read.

This may seem a little odd, but why not use Python as an SDL?  I've used the 
C/C++ API before, and it would give us a mature, byte-compilable language 
that could easily link to a render module.  I think the license is 
acceptable, and it's certainly more optimized than anything we could easily 
come up with.

We basically would end up using the C API to compile the actual ray-
intersection code, the actual 'raytracer'.  Callbacks can give Python the 
ability to shoot extra rays, and would potentially even allow the definition 
of objects' ray-intersection functions from SDL.

If not Python, then perhaps some other established language should be 
considered.

 - Peter Hokanson

Post a reply to this message

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