 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Before I begin:
Just a question: should reused stuff be re-parsed and recompiled every time
we need it, as it is the case now with #include? Let's make the answer 'no'
for POV4. Then the new parser/compiler should rely on existing compilation
results to compile new stuff. Like Java does. But C/C++ does not.
This implies a repository for compiled stuff. That's a good thing, and
nobody in Java world complaints, on the contrary!
OK. I begin.
1) Let's say the top-level syntactic structures are classes and scenes.
---------------------------------------------------------------
Let's borrow from Java the structural organisation of classes and its
related notational features. We can write in
household/furniture/Stool.pov4:
package household.furniture;
import pov.primitive.*; // This import might be implicit and not required
import pov.advanced.Isowood;
class Stool
{
const DEFAULT_HEIGHT = 0.7;
// let's define properties
property height = DEFAULT_HEIGHT; // type not specified --> float.
Default value specified
property leg_shape:object; // type specified ('object'). No default
value.
property seat_shape = round_cylinder {...}; // Default value specified,
loose typing of variables
// Default constructor (without parameters)
make
{
// We make a 4-leg stool
union
{
p = pigment{P_IW_06 color_map{CM_IW_02}}
union
{
object {leg_shape translate <...>}
object {leg_shape translate <...>}
object {leg_shape translate <...>}
object {leg_shape translate <...>}
pigment {p}
}
object {seat_shape translate height*y}
}
}
}
This is better, I think, than having a #macro makeStool (...) <code> #end
somewhere in a #include'd file (with the old notation, is is difficult to
locate stuff we use).
2) Now, in our scene we want a stool. We write something like:
------------------------------------------------------
package scenes.indoor;
import <whatever is necessary>;
import household.furniture.Stool;
scene AmericanBar
{
<stuff>
Floor = plane {...}
Stool // invokes the default constructor (without parameters)
{
// 'height' is not mandatory.
// If not overridden, this property takes the default value
// 'leg_shape' property is mandatory
// Might be related to DEFAULT_HEIGHT, or Stool.DEFAULT_HEIGHT
// if name is ambiguous (naming range)
leg_shape box {...}
dropon(Floor); // can be inherited from the 'object' top class
translate <...>
}
}
3) We want to create a magic stool
-----------------------------
package household.furniture;
class MagicStool extends Stool
{
// A magic stool glows
property glowing_sphere:object.glow;
// It has also levitation capabilities
levitate (ceiling:object)
{
distance_to_ceiling = ceiling.y - max_entend().y; // max_extend is
an all-object property
actual_height = min(height, distance_to_ceiling);
translate actual_height*y
rotate <grand(), grand(), grand()> // 'grand' is a global random
stream
}
}
4) And in our scene
---------------
ceiling = plane {...}
MagicStool
{
// we must specify the 'glowing_sphere' property.
// Property names can be highlighted within a constructor by the editor.
glowing_sphere glow{...}
levitate (ceiling);
}
Quick comments on this embryo of pov4 syntax:
packages:
Organise things, reuse already parsed and compiled code.
classes:
Within packages.
OO, but not too much. Only basic OO.
Single inheritance
constants, properties, methods, constructors
properties:
Specific to the class being defined
Used to create objects
Different from variables (do not require '=' for valuation in
contructors blocks)
constructors:
Invoke the 'make' method.
The block specifies properties of the class. Syntax like
ClassName
{
// for values that are instances of a class
// i.e. value has a {...} block
my_class_property <object value>
// for primitive values (numbers, vectors, colors)
my_primitive_property <value>;
}
Properties that have a default value are not mandatory in the
constructor block.
If a non-defaulted property is not stated in the constructor block, the
parser generates an error.
It should be quite easy to generate Java classes from such a POV4 syntax.
Anybody interrested in digging in that direction? Or do you think it is a
dead-end?
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson wrote:
would you still be able to do things like: ?
union {
some code
some objects
}
Is there a way to eliminate the 'make' and thus one set of nested {}?
Instead of make (most often used), require 'method' or 'action' in from
of methods like levitate.
Why a name for scene? Is the scene block necessary at all? This scene
block is where it really gets "programmy" and where identical scenes in
the NEW SDL will take more lines of code than those in 3.6 SDL.
I believe it would be cleaner if you could make CSG objects work more
like primitive objects.
// three and four are "all the time" values like position
// and rad for sphere. In this case, they could represent
// Number of legs and height
// 'box' is an object definition OR another class with its
// own parameters. This is how its often done with macros
// now.
Stool { 3, 4, leg_shape { box 2 3 } pigment { rgb 1 } }
// The object definition might look like a function definition:
class Stool { Legs, Height, leg_shape=box {2, 3} }
// properties like pigment, texture, translate, etc. would have
// to be handled in a special way. Class-specific defaults for
// these values would not be allowed.
// This is sort of a class/macro cross.
For the most part, I think yours is a nice syntax which will allow
things like rigging animation characters without allowing too much
"elegance."
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay wrote:
> Why a name for scene? Is the scene block necessary at all?
One answer would be that if you can refer to a scene it becomes possible
to pass that scene to a camera or output device. Thus allowing other
output possibilities for the same scene apart from our beloved
ray-tracer bitmapped output. That has a relation to my question on
whether POV4 should be a scene description language or purely a
ray-tracer. I am getting more and more convinced that is should be a
scene description language.
> This scene
> block is where it really gets "programmy" and where identical scenes in
> the NEW SDL will take more lines of code than those in 3.6 SDL.
yes. But not much and in most cases it is so standard that you don't
have to change anything in a scene template. (but it could kill our
short code competition)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> // three and four are "all the time" values like position
> // and rad for sphere. In this case, they could represent
> // Number of legs and height
> // 'box' is an object definition OR another class with its
> // own parameters. This is how its often done with macros
> // now.
>
> Stool { 3, 4, leg_shape { box 2 3 } pigment { rgb 1 } }
Note :
some years ago, I had to produce individual images of a great number of
windows.
I had a macro like this :
#macro Window (Height,Width,TopArc,MullionThick,...) //many parameters
When invoked, it looked like :
Window (250,300,25,5,2,1,1,4,6,120,5)
...unreadable as hell. I would loved to be able to do
Window {height = 250 width = 130 mullion_thickness = 5 ...}
in any order, and with default values.
This is an example where an apparently more complex syntax
leads to easier understanding.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Then the new parser/compiler should rely on existing compilation
> results to compile new stuff. Like Java does. But C/C++ does not.
What do you mean "C/C++ does not"? When have you needed to recompile all
libraries before compiling a C++ program? Even within the same project,
if you change a single file, you can recompile that single file.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> some years ago, I had to produce individual images of a great number of
> windows.
> I had a macro like this :
> #macro Window (Height,Width,TopArc,MullionThick,...) //many parameters
>
> When invoked, it looked like :
> Window (250,300,25,5,2,1,1,4,6,120,5)
>
> ...unreadable as hell. I would loved to be able to do
> Window {height = 250 width = 130 mullion_thickness = 5 ...}
> in any order, and with default values.
>
> This is an example where an apparently more complex syntax
> leads to easier understanding.
>
> Fabien.
Well, most languages don't have named parameters. But you can do this in
OOP languages:
Window w = new Window();
w.height=250;
w.width=130;
...
w.createForReal(); //this creates the actual POV object
Or use the named parameter idiom, quite interesting:
http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.18
None of the three (real named params, the idiom using constructors, or
changing properties) can be done with POV-Ray currently... Yep, we
really need a new language :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
>
> Well, most languages don't have named parameters.
Matlab has untyped variable length arguments. I use that often to have
name-value pairs. It does, however, depend on having an eval facility.
(even an evalin('caller'...) ) That might make the whole process a bit
slow. So it might not be the best solution here.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Shay" <Sha### [at] cc cc> wrote in message news:4706806a$1@news.povray.org...
> Why a name for scene? Is the scene block necessary at all?
I for one would like to be able to define multiple scenes in one POV-file.
A while ago, someone here asked who to make transparant the visually
overlapping parts of specific objects. I offered a solution with
camera_view pigments which worked, but which would be a lot cleaner and
easier if one could define multiple scenes in one file.
That's just one example. Another, probably more frequently used example
might be to define layers of scenes, like a HUD, or static background. Or
maybe lensflares. That would all be much easier if you could tell POV-Ray
to render one scene on top of another, or using one scene as background for
another.
cu!
--
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x) // ZK http://www.povplace.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> Nicolas Alvarez wrote:
> >
> > Well, most languages don't have named parameters.
> Matlab has untyped variable length arguments. I use that often to have
> name-value pairs. It does, however, depend on having an eval facility.
> (even an evalin('caller'...) ) That might make the whole process a bit
> slow. So it might not be the best solution here.
Java provides many of the data stuctures one ever needs. One of them is a
key-value structure (java.util.Dictionnary and its derived classes
Hashtable and hashmap). It could help implementing many syntactic
convienence features, such as name-value pairs and named parameters. But it
also has Collections, Vector (not the same meaning as POV,) LinkedList (with
the derived ArrayList), StringTokenizer, Arrays, etc ...
Concerning typing, my feeling is that we should have loose typing, implicit
typing, explicit typing when needed. Polymorphism is quite confusing and
dangerous if you are not an experienced programmer. A single variable
should only one run-time type.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> > some years ago, I had to produce individual images of a great number of
> > windows.
> > I had a macro like this :
> > #macro Window (Height,Width,TopArc,MullionThick,...) //many parameters
> >
> > When invoked, it looked like :
> > Window (250,300,25,5,2,1,1,4,6,120,5)
> >
> > ...unreadable as hell. I would loved to be able to do
> > Window {height = 250 width = 130 mullion_thickness = 5 ...}
> > in any order, and with default values.
here:
#local Height = 250;
#local Width = 300;
#local TopArc = 25;
#local MullionThick = 5;
Window (Height,Width,TopArc,MullionThick,...) //many parameters
it's pure idiomatic povray SDL and well-known.
Of course, real named parameters accept parameters given in any order.
> > This is an example where an apparently more complex syntax
> > leads to easier understanding.
yes, it makes it easier. But it's not like current SDL prevents it.
> Well, most languages don't have named parameters. But you can do this in
> OOP languages:
> Window w = new Window();
> w.height=250;
> w.width=130;
> ...
> w.createForReal(); //this creates the actual POV object
I don't like this idiom too much: it only works if you know the required
parameters to the function, which means you know the inner workings of the
function and is kissing encapsulation and abstraction bye-bye. What
happens if you forget about providing one of them or doesn't update it
before calling? bad things happen, in my experience.
Positional parameter passing provide the strongest contract for function
application, that's why it's the default in most languages.
You can of course get around this somewhat by providing default values
inside the function for the case it's missing. And this is indeed another
old time povray SDL idiom, used from times even before to macros...
> None of the three (real named params, the idiom using constructors, or
> changing properties) can be done with POV-Ray currently... Yep, we
> really need a new language :)
this of course is not true. But surely it could be improved.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
