 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay a écrit :
> // 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson escribió:
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien escribió:
> 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:
> Fa3ien escribió:
> > 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nicolas Alvarez wrote:
> 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.
He meant that you can't compile against a library unless you have the
header source files for that library.
- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
You know you've been raytracing too long when you've tried to scan your
face for a texture.
-- Quietly Watching
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHBu3FcCmTzQ++ZncRAvzNAKCbrDKZJDw92WAIcQTTLNXykrwPAwCgotBP
r4oIlN2tbYWGfKz/fNd/Gqw=
=qAPy
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote:
> ....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.
I wrote a macro preprocessor to do exactly that sort of thing, for
exactly the same reason. Imagine that. :-)
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I personally would appreciate a brand new SDL syntax, especially if it
similar to Java.
The attempt Bruno made using Classes to create objects sounds very
interesting to me, especially as it would be easy to create specialized
Classes by sub-classing as you can do with Java.
Example: The class "Glass" defines the standard glass parameters like ior,
reflectiveness, color, transparency and so on. The sub-class "Crystal" may
overwrite the parameters necessary to create a crystal-like texture.
IMHO the most people using POV-ray by writing the SDL by hand (as opposite
to using a graphical modeler) have at least some programming experience,
either Java or .NET.
- Wolf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> 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.
You know, you can write /* comments */.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Wolf" <nomail@nomail> wrote:
> IMHO the most people using POV-ray by writing the SDL by hand (as opposite
> to using a graphical modeler) have at least some programming experience,
> either Java or .NET.
or Lisp and Python.
BTW, Python accepts named parameters to functions and default values to
parameters. Let's not forget python is an option -- although slow, but not
nearly as much as the current SDL -- as embbedable scripting engine hooking
directly to C/C++ code underneath...
like:
class GlassSphere( Sphere ):
def __init__( self, pos = 0, radius = 1, ior = 1.4 ):
Sphere.__init__( self, pos, radius )
self.material = materials.Glass( ior )
you then may call it:
sph = GlassSphere( 0, 1, 1.4 )
or:
sph = GlassSphere( ior = 1.2 )
or:
sph = GlassSphere( ior = 1.2, radius = 3 )
or even:
sph = GlassSphere()
sph.ior = 1.2
etc.
A Basic povray scene with just a glass sphere over checkered board and light
could be expressed just as:
GlassSphere()
Plane( y, -1, Pigment( Checker( 0, 1 ) ) )
LightSource( (-5,5,-5) )
which is currently less than with current SDL syntax, which requires
position and radius of sphere. The python version doesn't, because it gets
default parameters.
What people should understand is that classes allow for far more modular,
reusable and easier way to define objects rather than the macros and local
variables approach. In my simple example, I've defined a new object type
which inherits behaviour from a predefined povray object (Sphere) and can
easily extend the base class by adding or overriding behaviour via method
definitions. It's much more than macros which really just define the
constructor and have to take explicit parameters because the SDL lacks
lexical scoping to share modules variables of sort.
yes, Python also supports multiple inheritance as well as a simple interface
system by the name "duck typing"...
I don't have a problem with structured programming by indentation...
BTW, just about as nice as Python or moreso is Ruby, which has not been
mentioned so far...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolf nous apporta ses lumieres en ce 2007/10/06 04:57:
> I personally would appreciate a brand new SDL syntax, especially if it
> similar to Java.
> The attempt Bruno made using Classes to create objects sounds very
> interesting to me, especially as it would be easy to create specialized
> Classes by sub-classing as you can do with Java.
> Example: The class "Glass" defines the standard glass parameters like ior,
> reflectiveness, color, transparency and so on. The sub-class "Crystal" may
> overwrite the parameters necessary to create a crystal-like texture.
>
> IMHO the most people using POV-ray by writing the SDL by hand (as opposite
> to using a graphical modeler) have at least some programming experience,
> either Java or .NET.
>
> - Wolf
>
>
>
It would'nt be a viable option, as it would prevent you from using ANY existing
scene, break all actual librarys and piss off a majority of users.
You make strange assumptions regarding typical POV-Ray users.
I don't use a modeler, but I've tried. I don't have any Java nor .NET
experience, I've not even read any documentation about either. It easier for me
to do things directly in SDL rather than use a modeler.
I do have some old programing experience using Basic (about 12 years old),
Pascal (about 20 years old), C/C++ (about 10 years old) and Fortran (over 25
years old).
--
Alain
-------------------------------------------------
Three can keep a secret, if two of them are dead.
Benjamin Franklin
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmailcom> wrote:
> "Wolf" <nomail@nomail> wrote:
> > IMHO the most people using POV-ray by writing the SDL by hand (as opposite
> > to using a graphical modeler) have at least some programming experience,
> > either Java or .NET.
>
> or Lisp and Python.
.... or any other language.
My point is that I think there is no need to define the new SDL in a way
somebody having never done any programming can deal with it.
Those people will probably go for a graphical modeler anyway.
- Wolf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Wolf" <nomail@nomail> wrote:
> My point is that I think there is no need to define the new SDL in a way
> somebody having never done any programming can deal with it.
> Those people will probably go for a graphical modeler anyway.
how about a poll?
But I'm not sure it's true that users of povray SDL have programming
experience. Of course, most of the heavy users are old timers from a time
when visual modellers were science fiction stuff and the command-line was
king.
Still, I don't think visual modellers are a good substitute for a well
designed language.
They are in fact just as much of a hinderance to productivity as the mouse.
When you're a beginner, the mouse may help you by letting you visualize and
choose options in a menu, but once you've done that 100 times a day,
there's no good substitute for a keyboard shortcut... Likewise, visual
modellers may have some appeal by letting you choose options and link
visual boxes with arrows, but soon you'll find it cumbersome and willing to
just spell pigment { foo } rather than drop a pigment box inside a texture
box and that inside a material box...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> 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.
>
> You know, you can write /* comments */.
Yes, I could.
But I still have to
- specify ALL paramters
- specify them in strict order
With built-in functions, i can write :
light_source {... area_light ... circular orient adaptive 2}
or, as well
light_source {... area_light ... adaptive 2 orient circular}
I know that almost no programming language allows that kind
of parsing feature in user-defined functions, but I regret it.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Fa3ien" <fab### [at] yourshoesskynetbe> a écrit dans le message de news:
4707ba6b$1@news.povray.org...
> Yes, I could.
> But I still have to
> - specify ALL paramters
> - specify them in strict order
>
I agree !
That's the main reason why when I write a macro, I limit the number of
parameters even if I'd wish to put a lot more to cover more cases
Marc (not a programmer)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> With built-in functions, i can write :
> light_source {... area_light ... circular orient adaptive 2}
> or, as well
> light_source {... area_light ... adaptive 2 orient circular}
>
> I know that almost no programming language allows that kind
> of parsing feature in user-defined functions, but I regret it.
seemingly, povray developers regret that "kind of parsing feature" since
it's one of the main reasons for the parser being hard to deal with and
extend and, thus, here we are talking about a brand new one from scratch
and possibly well supported externally.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmailcom> wrote:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> > With built-in functions, i can write :
> > light_source {... area_light ... circular orient adaptive 2}
> > or, as well
> > light_source {... area_light ... adaptive 2 orient circular}
> >
> > I know that almost no programming language allows that kind
> > of parsing feature in user-defined functions, but I regret it.
>
> seemingly, povray developers regret that "kind of parsing feature" since
> it's one of the main reasons for the parser being hard to deal with and
> extend and, thus, here we are talking about a brand new one from scratch
> and possibly well supported externally.
Some aspects I would like the new syntax to provide are:
Not from scratch, reuse and inherit notational features from current
syntax
Allow non-programmers to make reasonably good scenes
Provide the language with some main features we know as being very useful
or necessary but diffucult to code (complicated algotithm, advanced maths
....).
Let the gurus code these
Not over-complicate the writing of scenes because of syntax. First concern
should be creativity. However DaVinci and Michelangelo were f... creative
and had a f... technicity. Give them a few color tubes and a few brushes,
and wait 1 hour. Give me the same and wait 1 eternity. The language should
(allow to) hide technicity. Concerning POV, no one can achieve results like
Gille Tran's without having both. But it was pionneer time.
It will be well suported externally only if the syntax is enough
user-friendly.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmailcom> a écrit dans le message de news:
web.4707b008153c00f6bb2c29160@news.povray.org...
> They are in fact just as much of a hinderance to productivity as the
> mouse.
> When you're a beginner, the mouse may help you by letting you visualize
> and
> choose options in a menu, but once you've done that 100 times a day,
> there's no good substitute for a keyboard shortcut...
Well, one major reason I switched from POV-Ray to a "regular"
modelling/rendering package with GUI is that there's so, so much more than
one can do with a graphical interface. Writing script only goes so far: for
many things, eye/hand coordination remains the best combination. Of course
I'm speaking from a practical, not theoretical, point of view.
The cumbersome GUI you describe here is something that basically doesn't
exist, and is somehow one of those long-standing myths about modelling
packages in the POV-community (along with the "magical commercial plug-in
for lazy GUI users" that creates fabulous pics out of the box just by
pressing a key...).
To make things clear: all modern packages feature 1) customisable interfaces
that let people create their own keyboard shortcuts and other user-specific
GUI widgets, 2) various scripting abilities to automate the boring tasks and
3) various development kits for developers to create plug-ins. So basic
users get the best of both worlds: GUI for things where the eye is the best
tool, script for automation. Power users with CG programming knowledge can
play with the SDKs and develop their own stuff.
> Likewise, visual modellers may have some appeal by letting you choose
> options and link
> visual boxes with arrows, but soon you'll find it cumbersome and willing
> to
> just spell pigment { foo } rather than drop a pigment box inside a texture
> box and that inside a material box...
pigment{foo} only works as an example - sort of - because it's basic (and in
fact a GUI package will let you create it in two clicks: one to create the
default material, another one to choose the color in a color space). A
complex, more useful material in POV-Ray requires a lot of scripting + trial
and error. The ability to define your pigments, surface properties, blurred
refraction, subsurface scattering etc. with real time visualisation using
nodes and other GUI features isn't just handy, but a much more efficient way
to do things, and this is particularly true if there are *** lots *** of
parameters to play with. Just try to layer materials and apply blend modes
to each layer without a GUI...
There's indeed some beauty in "writing" images with script. For certain
usages, it remains a rather unique and flexible tool. There are lots of good
things about POV-Ray and its scripting-as-modelling ability is one of them,
but please let's keep things into perspective. Modern 3D software really
pack a lot of power, and their GUIs are specifically designed with
productivity and deadlines in mind.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I continue to make proposals. After class inheritance, I illustrate scene
inheritance.
File pov/scenes/BasicScene.pov4 (shipped-with stuff)
--------------------------------
package pov.scenes;
scene BasicScene
{
property sun = light_source {...} // properties of a scene can be
accessed by derived scenes
sky_sphere {...}
ground = plane {y, 0 pigment {White}} // 'White' from pov.basic.Colors
class. Package 'pov.basics' imported by default
property the_sphere = sphere
{
location 0 // 0 promoted to <0,0,0>
radius 1 // trying to see how to keep "0, 1" and current shorcuts
pigment
{
pattern radial
frequency 5
color_map {...}
}
place_on ground // Method call without parentheses.
}
}
File my_stuff.trash.BasicRSOCP.pov4
------------------------------------
package my_stuff.trash;
import pov.metals.*;
scene BasicRSOCP_ButMoreBeautiful extends BasicScene
{
ground.pigment {pattern checker color_map{...}}
the_sphere.texture = Polished_Chrome;
// The rest of the scene (sky_sphere and sun) are unchanged
}
File my_stuf.trash.BasicRSOCP_ButMoreBeautiful.pov4
---------------------------------------------------
package my_stuff.trash;
import pov.system.*;
scene BasicRSOCP_ButMoreBeautiful(date:string) extends BasicRSOCP
//date:sting --> $date?
//scene parameters from command-line?
{
// specify sun's position;
sun.sunpos(date);
// add
N = 10;
for i in 1..N
{
sphere
{
location 0
radius the_sphere.radius/10
texture {the_sphere.texture}
translate 2*the_sphere.radius*z
rotate
}
}
}
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Early click. Please read the following instead of my previous post.
File pov/scenes/BasicScene.pov4 (shipped-with stuff)
--------------------------------
package pov.scenes;
scene BasicScene
{
property sun = light_source {...} // properties of a scene can be
accessed by derived scenes
sky_sphere {...}
ground = plane {y, 0 pigment {White}} // 'White' from pov.basic.Colors
class. Package 'pov.basics' imported by default
property the_sphere = sphere
{
location 0 // 0 promoted to <0,0,0>
radius 1 // trying to see how to keep "0, 1" and current shorcuts
pigment
{
pattern radial
frequency 5
color_map {...}
}
place_on ground // Method call without parentheses.
}
}
File my_stuff.trash.BasicRSOCP.pov4
------------------------------------
package my_stuff.trash;
import pov.metals.*;
scene BasicRSOCP extends BasicScene
{
ground.pigment {pattern checker color_map{...}}
the_sphere.texture = Polished_Chrome;
// The rest of the scene (sky_sphere and sun) are unchanged
}
File my_stuf.trash.BasicRSOCP_ButMoreBeautiful.pov4
---------------------------------------------------
package my_stuff.trash;
import pov.system.*;
scene BasicRSOCP_ButMoreBeautiful(date:string) extends BasicRSOCP
//date:sting --> $date?
//scene parameters from command-line?
{
// specify sun's position;
sun.sunpos(date);
// add orbiting spheres
N = 10;
for i in 1..N
{
sphere
{
location 0
radius the_sphere.radius/10
texture {the_sphere.texture}
translate 2*the_sphere.radius*z
translate the_sphere.radius*y
rotate 360*i/N*y
}
}
}
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Tran" <gitran_nospam_@wanadoo.fr> wrote:
> Well, one major reason I switched from POV-Ray to a "regular"
> modelling/rendering package with GUI is that there's so, so much more than
> one can do with a graphical interface. Writing script only goes so far: for
> many things, eye/hand coordination remains the best combination. Of course
> I'm speaking from a practical, not theoretical, point of view.
of course. Excuse me for going a little overboard: I speak as a programmer
and it shows. Visual programming paradigms simply do not cut the mustard as
far as systems programming go. But we're here talking about an image
renderer and images lead to visual modelling and hand-eye coordination no
doubt.
However, it has always been stressed that povray -- like Renderman, Mental
Ray and other renderers -- deals exclusively with the rendering process.
It was never supposed to be a modeller, yet efforts like yours and many
others are only proof to the great strength and flexibility of povray's
SDL. And a SDL is a good thing even if regulars users don't use it.
As a programmer I understand why most open-source projects and povray indeed
are mostly command-line tools or plugins at most: adding GUI, menus,
sensible options, interactive functionality and real-time visualization of
modifications in graphical programs are huge resource eaters. And by
resource here I mean programmers.
Povray has far too few programmers to compete in GUI functionality with the
commercial players where big money and Hollywood are involved. So, they
focus on making it a renderer first and foremost. It's all about
priorities.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran escribió:
> (along with the "magical commercial plug-in
> for lazy GUI users" that creates fabulous pics out of the box just by
> pressing a key...).
Everybody I know who has Bryce has made images by putting a primitive
with one of the thousands of pre-made textures, or using the "water and
island wizard" or whatever...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis escribió:
> "Gilles Tran" <gitran_nospam_@wanadoo.fr> wrote:
>> Well, one major reason I switched from POV-Ray to a "regular"
>> modelling/rendering package with GUI is that there's so, so much more than
>> one can do with a graphical interface. Writing script only goes so far: for
>> many things, eye/hand coordination remains the best combination. Of course
>> I'm speaking from a practical, not theoretical, point of view.
>
> of course. Excuse me for going a little overboard: I speak as a programmer
> and it shows. Visual programming paradigms simply do not cut the mustard as
> far as systems programming go. But we're here talking about an image
> renderer and images lead to visual modelling and hand-eye coordination no
> doubt.
>
My ideal modeler is a text editor with a *real-time* preview on top. And
maybe also mouse-rotating the preview as a bonus, but no
clicking-and-dragging objects.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran a écrit :
> The cumbersome GUI you describe here is something that basically doesn't
> exist, and is somehow one of those long-standing myths about modelling
> packages in the POV-community (along with the "magical commercial plug-in
> for lazy GUI users" that creates fabulous pics out of the box just by
> pressing a key...).
"doesn't exist" ANYMORE. about 7 or 8 years ago, what he said was true.
But, yes things have evolved, and it's a classic fault in POV-Ray
community to overlook what is done elsewhere.
If someone wants to see what a modern (though simple) modeller can be,
have a look at Google Sketchup. It's free, for Windows and Mac.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote in message <4707ba6b$1@news.povray.org>:
> With built-in functions, i can write :
> light_source {... area_light ... circular orient adaptive 2}
> or, as well
> light_source {... area_light ... adaptive 2 orient circular}
>
> I know that almost no programming language allows that kind
> of parsing feature in user-defined functions, but I regret it.
If you do not mind naming all the parameters, a lot of languages can do
that.
Objective Caml can do something like that:
light_source ... ~area_light:true ~shape:`Circular ~adaptative:2 ()
Python has a similar feature, I think.
Perl can emulate that very well using hashes:
light_source ... area_light => 1, shape => "circular", adaptative => 2;
And in fact, almost any language that supports variable number of arguments
can emulate it. For example in C:
light_source(..., "area_light", "circular", "orient", "adaptative", 2, NULL);
This requires a little bit more work inside the user-defined function, but
not much, and some of it can be eased by common helper functions.
Some libraries, like Gtk+, use similar schemes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson a écrit :
> Some aspects I would like the new syntax to provide are:
>
> Not from scratch, reuse and inherit notational features from current
> syntax
> Allow non-programmers to make reasonably good scenes
> Provide the language with some main features we know as being very useful
> or necessary but diffucult to code (complicated algotithm, advanced maths
> ....).
> Let the gurus code these
The key, IMO, is : how many gurus will there be.
Currently, the maximum a user can do is a complex macro. There is a
good proportion of users who can do that, but these are "small gurus",
since the system doesn't allow them to go very far.
Currently, if someone wants to do more, he have to either write an
external utility (which might be cumbersome to use, hardly portable...)
or do a POV-Ray patch, which requires even more competence. These
are "big gurus", but represents a smallish fraction of users.
If the new SDL allows enough power while keeping a smooth learning
curve, there can be many "medium-to-big gurus", and everyone would
benefit from these developments.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis a écrit :
> However, it has always been stressed that povray -- like Renderman, Mental
> Ray and other renderers -- deals exclusively with the rendering process.
That's a fundamental misconception. POV-Ray ISN'T a "renderer".
POV-Ray is, and has alwas been, a "rendering system", complete out of
the box, with the ability to generate scenes through a scripting
system (until POV 2.2), then a more complete SDL (from POV 3).
With Mental Ray, you can't do that, you need a modeler with an interface
to control it.
Even with Renderman, you can't created decent scenes with a text file,
it totally lacks any feature that would allow text-based modelling.
POV-Ray allows you to do that, not as a side-effect of the SDL, but
precisely BY DESIGN. Drop that, and you kill POV-Ray (there are
already many nice and free pure renderers out there).
> It was never supposed to be a modeller, yet efforts like yours and many
(snip)
It always had a modelling system, albeit not a graphical one. CSG,
loops, macros... are there to allow modelling tasks.
> others are only proof to the great strength and flexibility of povray's
> SDL. And a SDL is a good thing even if regulars users don't use it.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez a écrit :
> Gilles Tran escribió:
>> (along with the "magical commercial plug-in for lazy GUI users" that
>> creates fabulous pics out of the box just by pressing a key...).
>
> Everybody I know who has Bryce has made images by putting a primitive
> with one of the thousands of pre-made textures, or using the "water and
> island wizard" or whatever...
And how have this ever produced "fabulous pics" ?
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Gilles Tran escribió:
> > (along with the "magical commercial plug-in
> > for lazy GUI users" that creates fabulous pics out of the box just by
> > pressing a key...).
>
> Everybody I know who has Bryce has made images by putting a primitive
> with one of the thousands of pre-made textures, or using the "water and
> island wizard" or whatever...
I think the attitude Gilles is complaining of is better expressed as the
idea that commercial apps have a "Make Art" button. I don't think it was
ever a particularly useful insight that commercial apps would have tools
not found in a free app like POVRay, but we are not in the 90s any more and
these days, nobody has any excuse at all - there are plenty of free apps out
there with extremely strong tools similar to those in commercial apps.
People using exclusively POVRay now are doing so by choice, not because of
poverty, and for anyone to complain that other tools make some things
easier would be verging on the ridiculous. Although I haven't seen anyone
mention the Magic Plugin syndrome or a make art button for a while now :)
In Bryce's case it was designed as a landscape tool aimed at home users
IIRC, so I think it's pretty clear why it has wizards for common tasks. I
think they released some recent versions of Bryce free of charge as well,
so again there's nothing I can see that's worth complaining about. I too
wonder how many of the wizard-produced images actually have any
individuality, and I also note that POVRay comes with a substantial library
of predefined textures, scenes and primitives, even if some of them are
getting on a bit these days. And is rather faster, if I remember rightly.
Tom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> nemesis a écrit :
> > However, it has always been stressed that povray -- like Renderman, Mental
> > Ray and other renderers -- deals exclusively with the rendering process.
>
> That's a fundamental misconception. POV-Ray ISN'T a "renderer".
> POV-Ray is, and has alwas been, a "rendering system", complete out of
> the box, with the ability to generate scenes through a scripting
> system (until POV 2.2), then a more complete SDL (from POV 3).
>
> With Mental Ray, you can't do that, you need a modeler with an interface
> to control it.
>
> Even with Renderman, you can't created decent scenes with a text file,
> it totally lacks any feature that would allow text-based modelling.
renderer, rendering system... what's the difference? They accept an image
model as input and produce an image as output, that's all.
What's the difference if that image model is binary mesh and textures
format, a compiled C/C++ program or an ASCII textual SDL script model?
Each has their pros and cons... certainly the SDL appeals to programmers,
though not much to people used to visual modelling tools. And its more
true today than at povray's heyday.
The point is that Renderman and Mental Ray don't come with their own VISUAL
modeller GUI. Instead, they ship as plugins for the most common commercial
Visual Modellers, like Maya or 3DStudioMax... they too, despite backed by
heavy ammounts of money and developers, chose to do what they do best:
rendering, leaving visual modelling to others. Why should povray with its
limited pool of developers do differently?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien escribió:
> Bruno Cabasson a écrit :
>> Let the gurus code these
>
> The key, IMO, is : how many gurus will there be.
And how much free time they will have.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis a écrit :
> renderer, rendering system... what's the difference?
A renderer comes at the end of the creative process, changing
tons of triangles and various directives into a good-looking
image.
A rendering system INCLUDES the creative process.
3DS Max PLUS Mental Ray is a rendering system.
POV-Ray is a rendering system on its own.
> They accept an image
> model as input and produce an image as output, that's all.
>
> What's the difference if that image model is binary mesh and textures
> format, a compiled C/C++ program or an ASCII textual SDL script model?
The difference is that the SDL is a user-friendly method to design
a scene to render, with some special capabilities.
Some years ago, there was some hype about a new raytracer that
did caustics. I can't find its name anymore, please, if someone
remembers... It was in fact a bunch of C++ libraries, and you
had to write a C++ program to setup a scene and get an image...
Of course, it attracted 1 or 2 geeks, allowed its programmer
to get a good job somewhere (maybe), and is now forgotten.
Attracting users with ease of use AND features is a requirement.
> Each has their pros and cons... certainly the SDL appeals to programmers,
> though not much to people used to visual modelling tools. And its more
> true today than at povray's heyday.
>
> The point is that Renderman and Mental Ray don't come with their own VISUAL
> modeller GUI. Instead, they ship as plugins for the most common commercial
> Visual Modellers, like Maya or 3DStudioMax... they too, despite backed by
> heavy ammounts of money and developers, chose to do what they do best:
> rendering, leaving visual modelling to others. Why should povray with its
> limited pool of developers do differently?
If POV-Ray becomes a simple renderer, just good enough to be the queue
of Blender or whatever other stuff, it might as well be stopped. There
are plenty of good pure renderers out there, POV-Ray must be something
different.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> nemesis a écrit :
>>> However, it has always been stressed that povray -- like Renderman, Mental
>>> Ray and other renderers -- deals exclusively with the rendering process.
>> That's a fundamental misconception. POV-Ray ISN'T a "renderer".
>> POV-Ray is, and has alwas been, a "rendering system", complete out of
>> the box, with the ability to generate scenes through a scripting
>> system (until POV 2.2), then a more complete SDL (from POV 3).
>>
>> With Mental Ray, you can't do that, you need a modeler with an interface
>> to control it.
>>
>> Even with Renderman, you can't created decent scenes with a text file,
>> it totally lacks any feature that would allow text-based modelling.
>
> renderer, rendering system... what's the difference? They accept an image
> model as input and produce an image as output, that's all.
>
> What's the difference if that image model is binary mesh and textures
> format, a compiled C/C++ program or an ASCII textual SDL script model?
> Each has their pros and cons... certainly the SDL appeals to programmers,
> though not much to people used to visual modelling tools.
One of my applications for POV is in a script I wrote to generate
transmembrane proteins. Input is a database with for a number of genes
the transmembrane segments and a user specified number of aminoacids you
want to highlight (possibly a database of all known mutations). Typical
use is to create a piece of celmembrane with all known mutations sorted
by disease in different colors (see attached). ATM I do the processing
of the databases in Matlab, just because that is most easy for me, and I
need a little more support for reading files, but I would love to
convert this into a POV only tool. As you can imagine the fact that POV
is a scripting language is essential for this application. Also because
I only generate a gene specific include file, but there are a number of
switches in the .pov file for various type of output (color, b/w, other
shapes apart from spheres etc).
I know of no other program that can do this for me in this way. I know
that I could generate meshes in stead of spheres, curved lines etc, but
I would not have though about starting such a project. With POV it was
incredibly easy to conceive and to execute this idea. A couple of people
have admired my use of shade and reflections in this and other images. I
am honest enough to tell them that it would be more complicated to
remove those, but not everybody believes that.
Think about that, there is a whole field of applications that are not
possible (or totally impractical) without POV. That goes much further
than personal preferences for command line or GUI interfaces.
> And its more
> true today than at povray's heyday.
>
> The point is that Renderman and Mental Ray don't come with their own VISUAL
> modeller GUI. Instead, they ship as plugins for the most common commercial
> Visual Modellers, like Maya or 3DStudioMax... they too, despite backed by
> heavy ammounts of money and developers, chose to do what they do best:
> rendering, leaving visual modelling to others. Why should povray with its
> limited pool of developers do differently?
>
As shown above, because it has its own niche.
Post a reply to this message
Attachments:
Download 'gene.png' (52 KB)
Preview of image 'gene.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> > renderer, rendering system... what's the difference?
>
> A renderer comes at the end of the creative process, changing
> tons of triangles and various directives into a good-looking
> image.
>
> A rendering system INCLUDES the creative process.
>
> 3DS Max PLUS Mental Ray is a rendering system.
>
> POV-Ray is a rendering system on its own.
Yes, you can take ages to produce a very high quality pure-SDL scene in
povray using nothing but CSG or isosurfaces and no characters. Or, like
Gilles stressed, you can do it much more fluidly, easily and faster with an
interactive GUI-based modeller with real-time visualization.
In that sense, the SDL is a very poor modelling solution and it makes povray
a very limited "rendering system". But it is a pretty good renderer anyway.
> Some years ago, there was some hype about a new raytracer that
> did caustics. I can't find its name anymore, please, if someone
> remembers... It was in fact a bunch of C++ libraries, and you
> had to write a C++ program to setup a scene and get an image...
> Of course, it attracted 1 or 2 geeks, allowed its programmer
> to get a good job somewhere (maybe), and is now forgotten.
next you'll tell me the pure SDL scene writers out there are not geeks...
like the chemical geek rendering molecules out of matlab and SDL...
> If POV-Ray becomes a simple renderer, just good enough to be the queue
> of Blender or whatever other stuff, it might as well be stopped. There
> are plenty of good pure renderers out there, POV-Ray must be something
> different.
It is something different: a renderer with the most simple, flexible and
accessible input format.
why stop something which works well?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> next you'll tell me the pure SDL scene writers out there are
> not geeks...
ahem
http://tinyurl.com/ynpfeo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Fa3ien" <fab### [at] yourshoesskynetbe> a écrit dans le message de news:
4708ac11@news.povray.org...
> POV-Ray allows you to do that, not as a side-effect of the SDL, but
> precisely BY DESIGN. Drop that, and you kill POV-Ray (there are
> already many nice and free pure renderers out there).
Really, this is what should be discussed in depth in those threads, because
it should drive the development of POV 4.0.
POV-Ray is a unique association: a modelling script + a high-quality
renderer. The modelling script is intuitive enough to be used by
non-programmers, while still powerful. That's what made POV-Ray a success at
a time where there was little competition in terms of free, powerful 3D
applications. This period more or less peaked in 1997-1998, with the
integration of radiosity. Now, the times have changed.
- The shortcomings of the script as a modelling tool have become more
evident: 3D users expect to be able to create certain things - character and
industrial design, animation, particle systems etc. - that typically require
a GUI to be done efficiently. Also, including external models into POV-Ray
isn't straightforward, which makes POV-Ray currently ill-suited as a
rendering-only application.
Using script (and only script) for modelling is generally a personal
choice - intellectual and/or aesthetical - and there are niches where it's
very efficient. Particularly, POV-Ray is relevant in sectors like education,
scientific illustration, processor benchmarking and as a testbed for
experimental CG techniques (see http://www.wikipov.org/ow.asp?PovSpotting
for examples and feel free to add some).
- The shortcomings of POV-Ray as a renderer have also become obvious to
anyone who browses the galleries of other applications. Just have a look at
Vray, FinalRender or Maxwell galleries, for instance.
So where do we go from there?
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.
Option 1 is certainly the easiest/cheapest. It's main drawback is that it
maintains POV-Ray where it is now: a hobbyist toy with some niche
professional applications. Not a bad thing per se, but not very attractive
to coders and 3rd party users. This kind of thing needs some momentum and
I'm not sure that a "hobbyist toy" with a smallish user base has it.
Option 2 is intellectually attractive for coders, and, if done well, could
promote POV-Ray as a valid open source, free high-quality rendering tool.
Problem 1: there's already some lively competition (Yafray, Indigo,
Kerkythingie...) in the "pure" renderer field.
Problem 2: will it be possible to keep intact the original simplicity and
human-writeability of the SDL without excluding the non-programmer users?
Problem 3: the attractiveness (to users and programmers) of the software is
linked to its attractiveness to artists able to create WOW pictures. Now, a
language too "programmy" is going to limit those to the smaller population
of good artists that are also serious programmers.
Of course, if POV-Ray become a 100% pure renderer that only reads SDL
written automatically or by programmers, the question becomes moot (mosts
artists will use it through a 3rd party GUI), but something will be lost I
fear.
Option 3 is clearly a mammoth undertaking, and there's already (since we're
talking pachyderms) that big elephant in the room of open source 3D that is
Blender, which is probably already sucking up the free time of many CG
programmers. Now Blender, thanks to its idiosyncratic interface, is a
love-it-or-hate-it application, and POV-Ray is all love, so there's a
possibility there ;)
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <Sha### [at] cccc> wrote:
> nemesis wrote:
> > next you'll tell me the pure SDL scene writers out there are
> > not geeks...
>
> ahem
> http://tinyurl.com/ynpfeo
yes, I saw that one before. Mighty impressive! and, manual laborer or not,
you're a geek. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
>
> next you'll tell me the pure SDL scene writers out there are not geeks...
> like the chemical geek rendering molecules out of matlab and SDL...
>
You talking to me? Huh? wanna step outside?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
> 2. Turn POV-Ray into a "pure" rendering library, <snip>
> Problem 1: there's already some lively competition (Yafray, Indigo,
> Kerkythingie...) in the "pure" renderer field.
IMO, any renderer with a shader language is not a "pure" renderer. "Drag
and drop" might be great for some surface shader effects, but will not
create as many WOW shaders as are possible with programming.
Geometry tweaking is, with some models, as important as shader tweaking.
I have created nice models which would look like crap with *any* kind of
algorithmic vertex normal scheme. Yafray, AFAIK, doesn't even allow
explicit definition of vertex normals!
I'm assuming from your Problem 2:
> Problem 2: will it be possible to keep intact the original simplicity
> and human-writeability of the SDL without excluding the non-programmer
> users?
... that by "Turn POV-Ray into a "pure" rendering library", you in fact
mean "Turn POV_Ray into a 'pure(ish)' rendering library with a bit of
accessible tweakability." Doing so would keep POV in a different
category from the competition.
And as far as Problem 2, yes it will be possible if all potential
additions to the SDL are very carefully measured by their utility in
creating WOW pictures.
> Problem 3: the attractiveness (to users and programmers) of the software
> is linked to its attractiveness to artists able to create WOW pictures.
> Now, a language too "programmy" is going to limit those to the smaller
> population of good artists that are also serious programmers.
Exactly. I believe that POV-Ray should be a "pureish" renderer with nice
Blender or Wings integration and the additional feature of accessible
tweakability and scene scripting. The hand-coding contingent will figure
out a way to do what we want to do with whatever the SDL becomes.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> > next you'll tell me the pure SDL scene writers out there are not geeks...
> > like the chemical geek rendering molecules out of matlab and SDL...
> >
> You talking to me? Huh? wanna step outside?
come on, confess you're a geek... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay wrote:
> Gilles Tran wrote:
>> 2. Turn POV-Ray into a "pure" rendering library, <snip> Problem 1:
>> there's already some lively competition (Yafray, Indigo,
>> Kerkythingie...) in the "pure" renderer field.
>
> IMO, any renderer with a shader language is not a "pure" renderer. "Drag
> and drop" might be great for some surface shader effects, but will not
> create as many WOW shaders as are possible with programming.
>
> Geometry tweaking is, with some models, as important as shader tweaking.
> I have created nice models which would look like crap with *any* kind of
> algorithmic vertex normal scheme. Yafray, AFAIK, doesn't even allow
> explicit definition of vertex normals!
>
> I'm assuming from your Problem 2:
>
>> Problem 2: will it be possible to keep intact the original simplicity
>> and human-writeability of the SDL without excluding the non-programmer
>> users?
>
> ... that by "Turn POV-Ray into a "pure" rendering library", you in fact
> mean "Turn POV_Ray into a 'pure(ish)' rendering library with a bit of
> accessible tweakability." Doing so would keep POV in a different
> category from the competition.
>
> And as far as Problem 2, yes it will be possible if all potential
> additions to the SDL are very carefully measured by their utility in
> creating WOW pictures.
>
>> Problem 3: the attractiveness (to users and programmers) of the software
>> is linked to its attractiveness to artists able to create WOW pictures.
>> Now, a language too "programmy" is going to limit those to the smaller
>> population of good artists that are also serious programmers.
>
> Exactly. I believe that POV-Ray should be a "pureish" renderer with nice
> Blender or Wings integration and the additional feature of accessible
> tweakability and scene scripting. The hand-coding contingent will figure
> out a way to do what we want to do with whatever the SDL becomes.
>
Not much to add to my fellow-geek here ;)
I only want to stress again that POV as it is now, and even more is it
will be as POV4 is a fantastic tool to use in highschool math and
physics classes. Nobody likes geometry (well nearly nobody except for us
geeks) but if you want to build a chandelier for your virtual barbie
hous, you do want your two torus sections to match up perfectly. If you
build a car (or import one from a library) you do want to let the wheels
behave physically correct when driving and when turning a corner.
As to what my solutions to some of Gilles problems are: Create
(maintain) a simple POV4 SDL understandable for highschool kids. Add
features of ordinary languages (assignment (or binding), functions, flow
control things etc). Add support for multiple camera's, our beloved
raytracer but also a fast scanline/DirectX/whatever previewer that
accepts the same scenes but without reflections and such. Make it
flexible enough to build a third party GUI or enhance Moray. That should
do it.
So who is going to write that book and interactive course for POV4?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>>> next you'll tell me the pure SDL scene writers out there are not geeks...
>>> like the chemical geek rendering molecules out of matlab and SDL...
>>>
>> You talking to me? Huh? wanna step outside?
>
> come on, confess you're a geek... :)
>
It has been a long time since anybody said that to me, but I will ask
some selection of colleagues tomorrow if I fit that description. :)
FWIW I am not chemical, but a physicist working for nearly 20 years in
cardiology. None of the patients ever ran away screaming. OK that does
not prove much, I know.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> I only want to stress again that POV as it is now, and even more is it
> will be as POV4 is a fantastic tool to use in highschool math and
> physics classes. Nobody likes geometry
no doubt! Math is much more fascinating when we can visualize equations as
graphs...
povray has always been to me an excellent tool to teach people both geometry
and introductory computer programming.
> Add support for multiple camera's, our beloved
> raytracer but also a fast scanline/DirectX/whatever previewer that
> accepts the same scenes but without reflections and such.
you do know that there are quality parameter both via the command-line and
from the Render Settings GUI dialog that allow for very fast rendering,
don't you? Only thing lacking, I guess, would be allowing the mouse to
manipulate that render window by zooming in/out and rotating freely.
Wouldn't that be a cool application for the real-time rendering in povray
3.7? :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> I only want to stress again that POV as it is now, and even more is it
>> will be as POV4 is a fantastic tool to use in highschool math and
>> physics classes. Nobody likes geometry
>
> no doubt! Math is much more fascinating when we can visualize equations as
> graphs...
>
> povray has always been to me an excellent tool to teach people both geometry
> and introductory computer programming.
>
>> Add support for multiple camera's, our beloved
>> raytracer but also a fast scanline/DirectX/whatever previewer that
>> accepts the same scenes but without reflections and such.
>
> you do know that there are quality parameter both via the command-line and
> from the Render Settings GUI dialog that allow for very fast rendering,
> don't you?
Yes but still not fast enough to me, unless I missed some.
> Only thing lacking, I guess, would be allowing the mouse to
> manipulate that render window by zooming in/out and rotating freely.
> Wouldn't that be a cool application for the real-time rendering in povray
> 3.7? :)
I don't use the beta ;) .
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> Yes but still not fast enough to me, unless I missed some.
With level 0 or 1 you don't even get basic shading, just the shapes of
objects in your scene. Couple that with a small resolution and enough CPU
and you get almost real-time-like rendering speed, even for complex scenes.
It'll get better if the SDL doesn't have to be reparsed each frame...
> I don't use the beta ;) .
I'm not saying that kind of visualization is planned, but it'd surely be
cool...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
