 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] yourshoes skynetbe> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> (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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> "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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
