 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Thus all you who are worrying about the "new SDL" being some cryptic
> high-end programming language only a few can understand, you have got
> it completely wrong: Keeping the current ease-of-use and, as far as
> possible, the same syntax, is a *major* concern in the designing of
> the new SDL. You don't have to express your concern about this.
All these threads have precisely shown that there ARE people who would
like POV-Ray to be driven by some high-end language (trough an API
or whatever).
As Gilles said, people who are going to team to make POV 4 must make
a choice about POV-Ray's general orientation.
Personally, I would like to see POV-Ray in the continuity of what it
is now, with a new powerful-but-still-easy-SDL.
I guess that, in the context of an open-source development, if people
wants to create an API layer to allow the use of other languages, or to
allow control by some modeller, fine. We then could have the beer and
drink it.
> (Of course a different issue is whether there's enough manpower and
> expertise to actually develop and implement such a language.)
You idea of "get out of the core what can belong at a higher level"
would help enlarge the number of people able to work on POV-Ray (people
like me, who have some programming abilities, could participate without
the need to master C++, and without being limited to sample scenes).
Please, could you put out a draft list of "things belonging to the core"
and "things that could be implemented through a new SDL" ?
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Buck wrote:
> andrel wrote:
>> Yes something like that. Not sure about the need for a stack here.
>> And I would suggest not to include the camera *in* the scene but have
>> a scene description and an output device, that may or may not be a
>> camera,
>> that gets the scene as input.
>
> I was trying to match the existing POV syntax. If you want to separate
> the camera from the scene description, it would be trivial to do with
> this approach.
>
I know, just wanted to drive home a point ;)
And then I even forgot to stress that also the fact that you better not
change the scene after you started rendering also points to the fact
that a camera should be handled slightly different from the scene
generation. Passing it as a read only parameter to the camera function
would be an clear solution.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote:
>
>> Thus all you who are worrying about the "new SDL" being some cryptic
>> high-end programming language only a few can understand, you have got
>> it completely wrong: Keeping the current ease-of-use and, as far as
>> possible, the same syntax, is a *major* concern in the designing of
>> the new SDL. You don't have to express your concern about this.
>
> All these threads have precisely shown that there ARE people who would
> like POV-Ray to be driven by some high-end language (trough an API
> or whatever).
>
There might be but david's wasn't one. He mere pointed out how the
existing SDL could be transformed *internally* to an OO type of language
that could be parsed and executed like one.
> As Gilles said, people who are going to team to make POV 4 must make
> a choice about POV-Ray's general orientation.
>
> Personally, I would like to see POV-Ray in the continuity of what it
> is now, with a new powerful-but-still-easy-SDL.
>
> I guess that, in the context of an open-source development, if people
> wants to create an API layer to allow the use of other languages, or to
> allow control by some modeller, fine. We then could have the beer and
> drink it.
>
>> (Of course a different issue is whether there's enough manpower and
>> expertise to actually develop and implement such a language.)
>
> You idea of "get out of the core what can belong at a higher level"
> would help enlarge the number of people able to work on POV-Ray (people
> like me, who have some programming abilities, could participate without
> the need to master C++, and without being limited to sample scenes).
>
> Please, could you put out a draft list of "things belonging to the core"
> and "things that could be implemented through a new SDL" ?
>
> Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Fa3ien wrote:
>>
>>> Thus all you who are worrying about the "new SDL" being some cryptic
>>> high-end programming language only a few can understand, you have got
>>> it completely wrong: Keeping the current ease-of-use and, as far as
>>> possible, the same syntax, is a *major* concern in the designing of
>>> the new SDL. You don't have to express your concern about this.
>>
>> All these threads have precisely shown that there ARE people who would
>> like POV-Ray to be driven by some high-end language (trough an API
>> or whatever).
>>
> There might be but david's wasn't one. He mere pointed out how the
> existing SDL could be transformed *internally* to an OO type of language
> that could be parsed and executed like one.
Correct. This proposal would keep the same SDL (again, possibly without
macros as they currently exist) and internally translate it into
objects. Whether or not it actually generates code in an OO language is
an implementation detail. It can be done without any code generation at
all and, in fact, I think this is the best approach.
I should also point out that POV-Ray should be split into three layers.
1) The low-level rendering engine with an API
2) The SDL which reads the scenes and calls the renderer through the API
3) A Moray-like modeler which (likely) produces SDL
#3 could also talk directly to the rendering API but I think you'd lose
some power and flexibility that way.
The strange thing about my proposal is that the SDL can actually extend
the low-level engine. If you want a sphere, call the low-level API to
create one. If you want a NURB (Non-Uniform Rational B-Spline), code it
in the SDL layer, provide methods that do ray-surface intersection,
normal calculation, etc, and use it. The low level renderer would treat
it just like a primitive shape but call into the SDL layer to do the
calculations. The same applies to new kinds of pigments, finishes, etc.
The rendering of NURBS may be a bit slower depending on how the SDL
layer is written, but that doesn't stop you from extending the base
renderer. POV-Ray is already partially object-oriented (and has been
since DKBTrace was first released in 1986). That OO nature should work
seamlessly between the low-level rendering layer and the SDL layer.
Just to be clear, NURBS or new pigments or finishes would likely not be
coded in the SDL syntax itself but in the OO language that accompanies
the SDL. For example, I can have some methods written in the SDL
modeling language that we know and love and others written in, for
example, Smalltalk. That's where I'm developing some prototypes of this
technique.
David Buck
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Fa3ien wrote:
>>
>>> Thus all you who are worrying about the "new SDL" being some cryptic
>>> high-end programming language only a few can understand, you have got
>>> it completely wrong: Keeping the current ease-of-use and, as far as
>>> possible, the same syntax, is a *major* concern in the designing of
>>> the new SDL. You don't have to express your concern about this.
>>
>> All these threads have precisely shown that there ARE people who would
>> like POV-Ray to be driven by some high-end language (trough an API
>> or whatever).
>>
> There might be but david's wasn't one. He mere pointed out how the
> existing SDL could be transformed *internally* to an OO type of language
> that could be parsed and executed like one.
I was talking about Nemesis' posts, for example.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
> I should also point out that POV-Ray should be split into three layers.
>
> 1) The low-level rendering engine with an API
> 2) The SDL which reads the scenes and calls the renderer through the
> API
> 3) A Moray-like modeler which (likely) produces SDL
>
> #3 could also talk directly to the rendering API but I think you'd lose
> some power and flexibility that way.
>
> The strange thing about my proposal is that the SDL can actually extend
> the low-level engine. If you want a sphere, call the low-level API to
> create one. If you want a NURB (Non-Uniform Rational B-Spline), code it
> in the SDL layer, provide methods that do ray-surface intersection,
> normal calculation, etc, and use it. The low level renderer would treat
> it just like a primitive shape but call into the SDL layer to do the
> calculations. The same applies to new kinds of pigments, finishes, etc.
SDL capable of extending the engine is more or less what Warp suggests.
If doable, and if it doesn't require as much programming skills as
modifying the core itself, it would greatly enhance the number of
people able to help getting POV 4 to a usable state.
In your model, is #2 conceived to be human-writeable-and-readable ?
It seems to me that a combination between the backward-compatibility
thing you suggested and Bruno Cabasson's samples would be ideal.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote:
>>
>> I should also point out that POV-Ray should be split into three layers.
>>
>> 1) The low-level rendering engine with an API
>> 2) The SDL which reads the scenes and calls the renderer through
>> the API
>> 3) A Moray-like modeler which (likely) produces SDL
>>
>> #3 could also talk directly to the rendering API but I think you'd
>> lose some power and flexibility that way.
> >
>> The strange thing about my proposal is that the SDL can actually
>> extend the low-level engine. If you want a sphere, call the low-level
>> API to create one. If you want a NURB (Non-Uniform Rational
>> B-Spline), code it in the SDL layer, provide methods that do
>> ray-surface intersection, normal calculation, etc, and use it. The low
>> level renderer would treat it just like a primitive shape but call
>> into the SDL layer to do the calculations. The same applies to new
>> kinds of pigments, finishes, etc.
>
> SDL capable of extending the engine is more or less what Warp suggests.
> If doable, and if it doesn't require as much programming skills as
> modifying the core itself, it would greatly enhance the number of
> people able to help getting POV 4 to a usable state.
>
> In your model, is #2 conceived to be human-writeable-and-readable ?
#2 is effectively the same SDL as POV-Ray currently has. There may need
to be small changes but it should look extremely familiar to POV artists.
David Buck
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoes skynetbe> wrote:
> It seems to me that a combination between the backward-compatibility
> thing you suggested and Bruno Cabasson's samples would be ideal.
>
> Fabien.
I continue to dig... Here is a more signifiant fragment of code: a sample
scene with the related shipped-with classes that would be part of POV4
(skeletons for basic objects like spheres, planes, ...).
// my_stuff/trash/sample_scene.pov4 -------------------------------------
package my_struff.trash;
scene sample_scene
{
camera {...}
light_source{...}
// Create a plane
the_plane = plane
{
y, 0 // properties not named => valued in the order they apear
// in the definition
pigment // Hope this syntax can be kept, and the parser can assume
//(as POV does today):material{texture{pigment{...}}}
{
agate
turbulence 0.3
color_map
{
...
}
}
finish {shiny}
}
// Create a sphere
my_sphere = sphere
{
location 0 // Valuation by property name
radius 1
texture {metals.brass_1D} // 'metals' in pov.primitives.*, imported
by default.
// Inside construction blocks, methods returning something cannot
// be invoked, especially conversion methods.
// tomesh() is illegal here
dropon(the_plane)
timeline
{
// Animation parameters only available in this section.
// And 'timeline' bocks only allowed in creation blocks.
// POV4 would handle the time lines of objects properly,
// with well defined mechanisms, and then send the sucessive
// results to the renderer in a loop it controls, either as a
// new scene (as POV does today), or as deltas for animated
// objects, provided the renderer is designed for that.
// The user could also specify whether or not the photon map
// and radiosity data should be recomputed with the new
// situation. By default, it would be 'yes'.
// Make the ball roll: use the method predefined in the
// 'sphere' class.
// 'delta_t' keyword (or field of some provided
// 'animation' module).
roll_on_plane (my_plane, define_trajectory(), delta_t)
}
}
// Make a mesh out of the sphere
my_other_sphere = my_sphere.tomesh();
my_other_sphere.subdivide();
object // could be 'mesh'?
{
my_other_sphere
timeline
{
// Make it follow the other sphere
follow (my_sphere, 1)
// make the ball bounce at the same time: use the scene's
// 'bounce' method.
bounce(this, 3, 2, clock-initial_clock)
}
}
// Methods specific to that scene. Better than macros.
spline define_trajectory()
{
...
}
bounce (obj:object, frequency, amplitude, t)
{
// Bouncing formula.
// Modify obj.matrix accordingly.
...
obj.matrix = result;
}
follow (obj:object, distance, delay)
{
...
}
}
// ----------------------------------------------------------------------
With the following definitions:
// pov/primitives/renderer.pov4 -----------------------------------------
package pov.primitives;
// A module cannot be instanciated. Pretty much like static classes in Java.
// Parse-time access to renderer features and API. Can be used to
// define shaders.
module renderer
{
// The 'trace' method ...
vector[] trace (from:vector, direction:vector, o:object) {external
"trace"}
// The 'hits' method is like 'trace', nut only return true if
// the object was hit by the ray.
boolean hits (from:vector, direction:vector, o:object) {external "hits"}
// The 'visible' method returns true if a given point is visible
// from another point.
// Might be implemented by the renderer, or coded here.
//boolean visible (target:vector, from:vector) {external "visible"}
boolean visible (target:vector, from:vector)
{
}
// The 'intersections' method intersects a ray with the whole scene
// so far. It returns an array of vector triplets, one triplet per
// intersection encountered by the ray from its start position.
// They are ordered in the order of encounter.
// Each triplet is the form:
//
// <n, 0, 0> <ix, ix, iz> <nx, ny, nz>
//
// where
// n is the number of the object intersected. Objects are numbered
// from 0 while added to the scene.
// (Encapsulated in a vector for simplification of interface).
// <ix, ix, iz> is the intersection point of the ray on the suraface
// of the object.
// <nx, ny, nz> is the normal at that point.
vector [][3] intersections(from:vector, direction:vector) {external
"intersections"}
color evalpigment (pigm:pigment, p:vector) {external "evalPigment"}
color evalpigment (obj:object, p:vector) {evalpigment(obj.pigment)}
}
// ----------------------------------------------------------------------
// pov/primitives/matrix.pov4 -------------------------------------------
package pov.primitives;
class matrix
{
const I:float[][] = {{1,0,0,0}, {0,1,0,0}, {0,0,1,0}, {0,0,0,0}}
property m:float[][] = I;
scale(x,y,z) {/* apply <x,y,z> scale to m */}
rotate(x,y,z) {/* apply <x,y,z> rotate to m */}
translate(x,y,z) {/* apply <x,y,z> translate to m */}
moveto(x,y,z) {/* apply <x,y,z> moveto to m */}
apply (m00, m01, ... m33) {/* apply m00..m33 matrix to m */}
}
// ----------------------------------------------------------------------
// pov/primitives/object.pov4 -------------------------------------------
package pov.primitives;
class object
{
// properties can become 'pseudo-keywords' for syntax highlighting
property location = origin; // or <0,0,0>, or 0
property matrix = Matrix.I; // I = Identity matrix
property bbox:vector[];
// properties used by POV’s default shader
property material = White; // Notational shortcut: material -> texture-
> pigment -> color (if possible, TBC)
property hollow = false;
property double_illuminate = false;
property no_shadow = false;
property no_image = false;
property no_reflection = false;
property inverse = false;
property MotionBlur motion_blur = null;
// transformation methods (common to all objects)
translate (v:vector) {translate(v.x, v.y, v.z)}
translate (f:float) {translate <f,f,f>} // Promotion through method
overloading. But can be done by the parser. TBD.
translate (x,y,z) {matrix.translate (x,y,z)} // translate 'matrix'
property ;
rotate (v:vector) {rotate (v.x, v.y, v.z)}
rotate (f:float) {rotate <f,f,f>}
rotate (x,y,z) {matrix.rotate(x,y,z)}
scale (v:vector) {scale (v.x, v.y, v.z)}
scale (f:float) {scale <f,f,f>}
scale (x,y,z) {matrix.scale(x,y,z)}
matrix (m00, m01, ... m33) {...}
matrix (m:Matrix) {matrix.apply(m)}
moveto (v:vector) {moveto (v.x, v.y, v.z)}
moveto (f:float) {moveto <f,f,f>}
moveto (x,y,z) {matrix.moveto(x,y,z)}
// Get inspired by transforms.inc
shear (a,b,c:vector) {...}
axisscale (axis:vector, amount) {...}
axisrotate (axis:vector, angle) {...}
rotatearound (rotation:vector, point:vector) {...}
reorient(target;object) {...}
pointat (yaxis:vector) {...}
center (axis:vector) {...}
align(target;object) {...}
// CSG methods?
union (o:object) {...}
merge (o:object) {...}
difference (o:object) {...}
intersection (o:object) {...}
// Object conversion methods
tomesh() {} // To be overriden by specific object types.
tomesh2() {} // To be overriden by specific object types.
// Placement methods
dropon(target:object) {dropon(target, <0,0,0>)}
dropon(target:object, yoffset) {dropon(target, <0, yoffset, 0>)}
dropon(target:object, offsets:vector) {dropon(target, xoffset, yoffset,
zoffset)}
dropon(target:object, xoffset, yoffset, zoffset)
{
// try downwards first
res = trace (location, -y, target)
if (vlength(res[1]) != 0)
moveto res[0]
else
{
// try upwardsthen
res = trace (location, y, target)
if (vlength(res[1]) != 0)
moveto res[0]
}
}
placeon(target:object)
{
...
}
//
// The ray-object intersection algo is hardcoded and optimized
// in the renderer for performance. If different from 'native'
// the renderer will call user code for intersection testing.
intersect {native}
// The standard, hardcoded POV shader (standard materials, standard
// radiosity, standard photons) will be used.
shader {default}
}
// ----------------------------------------------------------------------
// pov/primitives/sphere.pov4 -------------------------------------------
package pov.primitive;
import pov.math.*;
class sphere extends object
{
// Shape properties
property radius = 1.0;
// Methods
mesh tomesh() {...} // Sphere-specific
mesh2 tomesh2() {...}
}
// ----------------------------------------------------------------------
// pov/primitives/box.pov4 ----------------------------------------------
package pov.primitive;
import pov.math.*;
class box extends object
{
// Shape properties
property start = origin;
property end:vector = 1; // As 'vector' is specified, 1 is promoted to
<1,1,1>;
// Methods
tomesh() {...} // Box-specific
tomesh2() {...}
// sphere-specific method
roll_on_plane (p:object, s:spline, delta_t)
{
// Attitude propagator wrt previous position:
// Changes the matrix by applying the changes between
// t and t+delta_t, by folowing the spline s
...
}
}
// ----------------------------------------------------------------------
// pov/primitives/box.pov4 ----------------------------------------------
package pov.primitive;
import pov.math.*;
class plane extends object
{
// Shape properties
property normal = y;
property offset = 0;
// Methods
tomesh() {...} // Plane-specific
tomesh2() {...}
}
// ----------------------------------------------------------------------
// pov/primitives/box.pov4 ----------------------------------------------
package pov.primitive;
import pov.math.*;
class mesh extends object
{
// Shape properties
property normal = y;
property offset = 0;
property triangles:triangle[] = null; // Might be much more than an
array of 'triangles'
property inside_vector = null;
property hierarchy = on;
// Methods
tomesh() {return this}
tomesh2() {...} // mesh->mesh2 conversion
merge(msh:mesh) {...} // Merge a mesh to this one
}
// ----------------------------------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
>
> Here are the 3 basic options (which could be mixed/nested of course):
>
> 1. Keep POV-Ray as it is, with a relatively accessible SDL, with a few
> additional bells and whistles (better mesh support, better integration of
> 3rd party objects, more complete shading language...) and an improved
> rendering engine.
>
> 2. Turn POV-Ray into a "pure" rendering library, that could be controlled
> through different programming languages and used by external packages.
>
> 3. Turn POV-Ray into a standalone modelling+rendering package (using Moray
> as a starting point for the GUI, for instance), with a deep integration
> between the modeller and the script.
>
FWIW, I think Gilles has nailed it down nicely. May I add my 2 cents?
1. I think this is the approach that would be the most useful to the
greatest number of end users. Three things occur to me that are in the
nature of "First, do no harm": (a) Backwards compatibility. Please
don't break my old stuff. (I wouldn't mind if things like media or
lighting got "tweaked" a bit, but I'd really hate to rebuild a 1500-line
hunk of CSG to use it again.) (b) After having spent around a decade
learning SDL and POV in general, please don't make me relearn it. I'm
not getting any younger. (c) For the love of God, don't make me buy a
new computer. I'm not getting any richer, either.
2. I'm not a CompSci type, just a poor stupid applications programmer,
but isn't (2) basically compatible with (1)? Couldn't POV-Ray (the app
seen by the end user) use POV-Ray (the pure rendering library), which
would also be available to other languages/packages? Please don't hurt me.
3. How about a new, improved Moray (or whatever) as a *separate*
POV-Ray application from "classic" POV-Ray? Let the coders code, and
let the modellers model. Plus, it is my personal conviction that small
programs run better than large ones--less to get broken, easier to
maintain, easier to keep Tab A compatible with Slot B, so to speak.
Going to duck out of the line of fire now...
--Sherry Shaw
--
#macro T(E,N)sphere{x,.4rotate z*E*60translate y*N pigment{wrinkles scale
.3}finish{ambient 1}}#end#local I=0;#while(I<5)T(I,1)T(1-I,-1)#local I=I+
1;#end camera{location-5*z}plane{z,37 pigment{granite color_map{[.7rgb 0]
[1rgb 1]}}finish{ambient 2}}// TenMoons
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
