 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas George wrote:
> Ger wrote in message <46f1440d@news.povray.org>:
>> This looks perfectly doable.
>
> Thanks.
>
>> The contradiction between POV SDL and ARPL (A Real Programming Language)
>> is the possibility to do something like this
>>
>> object { Thingy scale 2 #if(Big) * 3 #end }
>
> Not necessarily:
>
> object [ $thingy, scale => $big ? 2 : 6 ]
That's basically the same as
object { Thingy
#if (Big)
scale 6
#else
scale 2
#end
}
but that's not what I meant. In POV SDL it is possible to put an "#if #end"
construct just about any place to include/exclude bits of code.
Maybe this is a better example
color_map{
[0, Red]
#if (ManyColors)
[0.5, White]
#end
[1, Blue]
}
2 remarks
Please no special characters ($#) before whatever, and
"$big ? 2 : 6" is not exactly readable to a newbe
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zeger Knaepen wrote:
> "Nicolas George" <nicolas$george@salle-s.org> wrote in message
> news:46f1088f$1@news.povray.org...
>> use Colors;
>>
>> scene [
>>
>> camera [
>> location => [ 2, 5, -3 ],
>> look_at => [ 0, 0, 0 ]
>> ],
>>
>> light_source [
>> [ 0, 10, -2 ],
>> White
>> ],
>>
>> union [
>> box [
>> [ -1, -1, -1 ], [ 1, 1, 1 ],
>> pigment => Red
>> ],
>> sphere [
>> [ 0, 1.5, 0 ], 0.5
>> pigment => Yellow
>> ]
>> ]
>>
>> ]
>
> I prefer the current syntax actually. All the commas after ] seem
> completely redundant, the keyword scene is a nice idea if it would be
> possible to define multiple scenes in one file, but it should be optional.
> The line "use Colors;" seems completely out of place for two reasons:
> first, Colors what? Colors.inc ? Colors.pov ? ..? second, considering the
> rest of the syntax, wouldn't something like "include
> [colors.inc,textures.inc]" be more consistent?
>
> I also don't like the change from curly brackets to square brackets.
>
> Actually I think a new SDL should look more or less the same as the old
> one, ie. a C-like syntax, but with some new things, like cleaner syntax,
> OO, ... For example: instead of '#declare X=1;' you would have something
> like 'float X=1;' (I don't think there's need for both int and float,
> since, afaik internally it's all floats).
If vars are defined as float then why the need to define them as such? On
the other hand, integers are much faster so why not use both?
>
> However, there are many things in the current SDL that I actually like,
> although they might be considered weird by programmers.
> For example, maybe it would be cleaner to have something like:
>
> Camera ActiveCamera = new Camera();
> ActiveCamera.location = new Vector(0,0,1);
> ActiveCamera.lookAt = new Vector(0,0,0);
>
> But it's a lot easier, especially for non-programmers, the way it is now:
>
> camera {
> location z
> look_at 0
> }
>
> But well, I suppose making a cleaner, stricter syntax will always lead to
> having a more difficult to learn syntax :(
>
> cu!
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If vars are defined as float then why the need to define them as such?
you can also have other types, like String, or Vector, and so on
> On the other hand, integers are much faster so why not use both?
integers won't be faster, because they will always have to be converted to
floats internally...
... I think... :)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
According to me, POV-SDL has two aspects:
declarative features to describe objects in scenes
programmatic features such as loops, macros, includes, etc ...
My opinion is that POV is VERY efficient in the declarative aspect, and less
in the progrmmatic one. I can't see how it would be more compact and easy
than
sphere
{
0, 1
pigment
{
crackle scale 0.2
color_map {[0.1 color 0.1*Red] [0.15 color 0.5*Green][1 Blue]}
scale 2*y
}
normal {bumps 0.15 scale 0.05}
finish {specular 0.3 roughness 0.01]
scale <1.2, 0.5, 1>
translate 10*z
}
But POV lacks programmatic features like recent langages have that make them
more efficient in programming, reusability, modularity, readability, etc ...
The effort should be made first on these rather than how to declare a sphere
in the scene, or how should the brackets be, curly or square, which are very
secondary concerns. One should remind the history of ray-tracing and that of
POV.
I totally agree that it is time now to go one step further, and that POV-Sdl
needs refurbishing here, enhancement there, redefinitions and complements
(compliments also ... :o)).
In addition, the isosurfaces are one of the most powerful object type you
can ever think of in ray-tracing (blobs are also powerful, but they lack
desiging tools and the are under-employed).
To finish, I can't imagine making 'reasonably advanced' scenes without a
minimum of programming skills and a minimum of geometry knowledge. For
example, the first thing you must have in mind is the order of
translations/rotations for you objects. However, gurus are always there to
work out complicated algorithms for you, provided the language allows them
to make it reusable, and you to reuse it.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <del### [at] deletethistoo povrayorg> wrote in
message news:46ef0157$1@news.povray.org...
> Putting this another way: POV-Ray's SDL grew from a simple means of
> providing an object description to something that had many of the
> traditional language constructs, while still retaining the ability to
> define a scene in terms of objects with no 'programming' as such. This is
> a
> Good Thing since it allows non-programmers to work with it and may have
> been a significant factor in POV's acceptance.
"If it ain't broke, don't fix it?"
Just a thought Chris.
~Steve~
> -- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote in message
news:web.46f167e9e7dc7428eb26baae0@news.povray.org...
> But POV lacks programmatic features like recent langages have that make
> them
> more efficient in programming, reusability, modularity, readability, etc
> ...
> The effort should be made first on these rather than how to declare a
> sphere
> in the scene, or how should the brackets be, curly or square, which are
> very
> secondary concerns.
agreed, but my point was mainly that things that are already good should not
be changed. curly brackets are one of those things :)
I mean: as it is now, POV-SDL has a C-like syntax. I think it would be a
very bad idea to change the POV-SDL into a BASIC-like syntax, or a
Python-like syntax (whatever you make, DON'T make it whitespace-sensitive!
PLEASE! :))
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> I mean: as it is now, POV-SDL has a C-like syntax. I think it would be a
> very bad idea to change the POV-SDL into a BASIC-like syntax, or a
> Python-like syntax (whatever you make, DON'T make it whitespace-sensitive!
> PLEASE! :))
I like curly brackets over square brackets too, and agree about whitespace.
Charles
PS Woohoo! I haven't been able to log onto the web-interface in some time.
I can actually chime in!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 19 Sep 2007 19:38:18 +0100, St. wrote:
> "If it ain't broke, don't fix it?"
>
> Just a thought Chris.
I wasn't the only one who had that thought, it seems. :-)
Seriously, though, I agree with this - if there's functionality to add to
SDL I'm all for that, but changing the format of things like object
definitions is going to require people relearn the language - if that's
going to happen, there ought to be a very good reason for doing so other
than "we wanted a different syntax".
Taking what people are used to and changing it even *with* good reason
tends to be met with a lot of resistance. (As I work for Novell, just
ask anyone who has used NetWare forever how they like running Open
Enterprise Server on Linux for a prime example of the resistance to
change phenomenon).
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19 Sep 2007 15:50:26 -0400, Jim Henderson <nos### [at] nospamcom> wrote:
>Taking what people are used to and changing it even *with* good reason
>tends to be met with a lot of resistance. (As I work for Novell, just
>ask anyone who has used NetWare forever how they like running Open
>Enterprise Server on Linux for a prime example of the resistance to
>change phenomenon).
That's one of the major reasons I'm still running NetWare 6.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 19 Sep 2007 16:04:39 -0400, Kyle wrote:
> On 19 Sep 2007 15:50:26 -0400, Jim Henderson <nos### [at] nospamcom> wrote:
>
>>Taking what people are used to and changing it even *with* good reason
>>tends to be met with a lot of resistance. (As I work for Novell, just
>>ask anyone who has used NetWare forever how they like running Open
>>Enterprise Server on Linux for a prime example of the resistance to
>>change phenomenon).
>
> That's one of the major reasons I'm still running NetWare 6.
Even evidence in here. :-)
Still got a 6.5 server running under VMware, but OES2 is looking much
better than OES1 <g>. Heck, I started with 2.15....But that's probably a
povray.off-topic discussion. ;-)
(And now, back to your regularly scheduled discussion)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
