 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Buck wrote:
[snip]
>
> Discussion is welcome.
>
Something that I think has not been mentioned in this discussion so far
(unless I accidentally skipped it):
One of the interesting things of POV is that it is a great environment
to learn maths. Often you want to position two objects in such a way
that they touch each other or such that the combined surface is
continuous or... You can do this by trial and error, but soon you'll end
up motivated to learn how to solve a particular second order equation or
some equation involving sin() or tan().
Whatever direction a new SDL is going to take, it would be great if the
simplest subset could (still) be used in a high school math class. The
only thing we then need is someone to write something like 'Mindstorms
for high school students'.
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
hey, how about pretty much no syntax at all?
(union (plane y (pigment (checker 0 1)))
(sphere 0 1
(texture (pigment (rgb x))
(finish (phong 0.8 30)))))
(light-source white (* 5 #(-1 1 -1)))
(camera (z -3) 0)
well, except for Lots of Irritating Silly Parentheses, that is... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ger nous apporta ses lumieres en ce 2007/09/19 13:16:
> Zeger Knaepen wrote:
>
> 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?
>
Integer operations are not faster than floating point ones, this is due to the
arithmetic coprocessor that is integrated in all processors since the advent of
the Pentium. In fact, the oposite is almost always thrue for any multiplication,
division and modulo. It was even the case for the 286, 386 and 486 whenever you
also had an arithmetic coprocessor installed on your machine.
--
Alain
-------------------------------------------------
Don't cry because it is over, smile because it happened.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis nous apporta ses lumieres en ce 2007/09/19 17:10:
> "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
>
> hey, how about pretty much no syntax at all?
>
> (union (plane y (pigment (checker 0 1)))
> (sphere 0 1
> (texture (pigment (rgb x))
> (finish (phong 0.8 30)))))
> (light-source white (* 5 #(-1 1 -1)))
> (camera (z -3) 0)
>
> well, except for Lots of Irritating Silly Parentheses, that is... :)
>
>
>
Makes me think of Lisp! TONS of parenteses ;-)
--
Alain
-------------------------------------------------
Experience hath shewn, that even under the best forms of government those
entrusted with power have, in time, and by slow operations, perverted it
into tyranny.
Thomas Jefferson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> 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".
I don't think it is necessary to change object definitions. That's not to
say there may not be another means to create them programmatically if you
happen to be generating a scene from an algorithm, but the basic definition
syntax for objects, cameras, etc, could reasonably stay the same.
As has been mentioned elsewhere in this thread, SDL is really two things: a
scene description language and a scripting language. It started with the
pure SDL and the scripting was added later. Therefore it's not unreasonable
to suggest that scripting can be changed without changing the core object
syntax.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Zeger Knaepen wrote:
>>
>> 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?
>>
actually, I didn't
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 20 Sep 2007 08:05:22 +1000, Chris Cason wrote:
> I don't think it is necessary to change object definitions. That's not
> to say there may not be another means to create them programmatically if
> you happen to be generating a scene from an algorithm, but the basic
> definition syntax for objects, cameras, etc, could reasonably stay the
> same.
>
> As has been mentioned elsewhere in this thread, SDL is really two
> things: a scene description language and a scripting language. It
> started with the pure SDL and the scripting was added later. Therefore
> it's not unreasonable
> to suggest that scripting can be changed without changing the core
> object
> syntax.
No argument from me on this. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <46f198c1$1@news.povray.org>, ele### [at] netscapenet
says...
> Ger nous apporta ses lumieres en ce 2007/09/19 13:16:
> > Zeger Knaepen wrote:
> >
> > 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?
> >
> Integer operations are not faster than floating point ones, this is due t
o the
> arithmetic coprocessor that is integrated in all processors since the adv
ent of
> the Pentium. In fact, the oposite is almost always thrue for any multipli
cation,
> division and modulo. It was even the case for the 286, 386 and 486 whenev
er you
> also had an arithmetic coprocessor installed on your machine.
>
Tell that to the people that wrote Franctint (on a 486, Pentium or
anything else). lol But seriously, even if they where marginally faster
at one point, for specific situations, this isn't necessarily true now,
nor applicable to what **this** program is doing. The results even in
Fractint differed in some cases, depending on if you used the faster
integers or floating point. One of the points of having POVRay behave as
it does is "predictability" in what you get from it.
--
void main () {
If Schrödingers_cat is alive
call functional_code()
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott nous apporta ses lumieres en ce 2007/09/19 23:13:
> In article <46f198c1$1@news.povray.org>, ele### [at] netscapenet
> says...
>> Ger nous apporta ses lumieres en ce 2007/09/19 13:16:
>>> Zeger Knaepen wrote:
>>>
>>> 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?
>>>
>> Integer operations are not faster than floating point ones, this is due to the
>> arithmetic coprocessor that is integrated in all processors since the advent of
>> the Pentium. In fact, the oposite is almost always thrue for any multiplication,
>> division and modulo. It was even the case for the 286, 386 and 486 whenever you
>> also had an arithmetic coprocessor installed on your machine.
>>
> Tell that to the people that wrote Franctint (on a 486, Pentium or
> anything else). lol But seriously, even if they where marginally faster
> at one point, for specific situations, this isn't necessarily true now,
> nor applicable to what **this** program is doing. The results even in
> Fractint differed in some cases, depending on if you used the faster
> integers or floating point. One of the points of having POVRay behave as
> it does is "predictability" in what you get from it.
>
If using a 486 or earlier, AND NOT using an arithmetic coprocessor, integer
operations where much faster than floating point. Especialy the add and
substract. Multiplications where only slightly faster.
Add in the coprocessor and, apart from int add and sub, floating point jumps
ahead, largely ahead!
At that time, you could get slightly different results depending on the brand of
your coprocessor: differing algorythm and rounding method, as well as intrinsic
precision.
--
Alain
-------------------------------------------------
You know you've been raytracing too long when you stop using a protractor to
measure angles because you can do it just by looking.
Taps a.k.a. Tapio Vocadlo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Zeger Knaepen" wrote in message <46f15701$1@news.povray.org>:
> 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 believe you somewhat missed my point. The sample code I just posted is not
just a random suggestion of syntax: it is perfectly valid Perl code: if
someone writes the few functions it uses, it will parse and run perfectly.
My point is to show that, although it is not possible to keep exactly the
same syntax as the current one, it is possible to use a real programming
language while keeping the syntactic noise very low.
And please note that a part of your remarks comes from habit rather than
real syntactic superiority.
The advantages of using a real programming language are obvious: the time of
PoV developers is better spent improving the rendering features than
reinventing support for data structures and control loops.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nicolas George wrote:
> My point is to show that, although it is not possible to keep exactly the
> same syntax as the current one, it is possible to use a real programming
> language while keeping the syntactic noise very low.
If we're going to re appropriate an existing language, maybe we could
look at some of the functional languages (Lisp, ML, etc.).
I don't normally like functional programming, but it does strike me as a
good match for describing scenes.
- --
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu
You know you've been raytracing too long when you're starting to find
these quotes more unsettling than funny.
-- Alex McLeod a.k.a. Giant Robot Messiah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG8rd4cCmTzQ++ZncRApKuAKChyuD1k3G5lniHBDOogM290T3pewCgshxV
BQzVutm/DGb4E6YAvPlo0P0=
=ylrj
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alain wrote:
> nemesis nous apporta ses lumieres en ce 2007/09/19 17:10:
>> "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
>>
>> hey, how about pretty much no syntax at all?
>>
>> (union (plane y (pigment (checker 0 1)))
>> (sphere 0 1
>> (texture (pigment (rgb x))
>> (finish (phong 0.8 30)))))
>> (light-source white (* 5 #(-1 1 -1)))
>> (camera (z -3) 0)
>>
>> well, except for Lots of Irritating Silly Parentheses, that is... :)
>>
> Makes me think of Lisp! TONS of parenteses ;-)
>
Look more closely at his last sentence. Especially the capital
letters... ;)
Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
| mailto:jeb### [at] freefr | ICQ: 238062172 |
| http://jeberger.free.fr/ | Jabber: jeb### [at] jabberfr |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG8r7md0kWM4JG3k8RAqIyAJ0a4iYBVeFjIefqqKMmEkbhy9+xwACgqZr4
nT0UHuDa7uYX5a4gVhN21bI=
=XaAF
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy <wtr### [at] calpolyedu> wrote:
> If we're going to re appropriate an existing language, maybe we could
> look at some of the functional languages (Lisp, ML, etc.).
Next you are going to suggest Haskell.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> William Tracy <wtr### [at] calpolyedu> wrote:
> > If we're going to re appropriate an existing language, maybe we could
> > look at some of the functional languages (Lisp, ML, etc.).
>
> Next you are going to suggest Haskell.
>
> --
> - Warp
oh boy! this is getting exciting! I just hope someone doesn't mention java
or .net... and while haskell is rather nice, to get any performance with it
you need the friggin huge GHC compiler!
come on! let's be realistic: the SDL just needs a scripting language with
small foorprint, high performance and syntax and semantics flexible enough
to allow for easy DSL creation (SDL). And this most likely mean AST
interpreters or similar.
I like Scheme but I understand there's not really any interpreter for it out
there that matches these requirements, and of course many people are put
down by the parentheses as much as are put down by python indented blocks
or perl's cryptic nature. I guess Lisp macros are wonderful for DSL
building, which is a shame.
Python and Perl are pretty heavy by now. Lua or Tcl are more lightweight.
Lua is a lot more modern and well supported than Tcl these days. Anything
else which doesn't require a java VM or .NET?
As far as I understand, the purpose about this discussion is not really
about having a completely new SDL with new syntax, but mostly to alleviate
the need for a builtin and complex C parser maintained by povray
developers. And of course, putting more power in the hands of those who
want more than basic SDL, ifs and loops by leveraging a complete and well
supported external programming language...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> As far as I understand, the purpose about this discussion is not really
> about having a completely new SDL with new syntax, but mostly to alleviate
> the need for a builtin and complex C parser maintained by povray
> developers.
This would support a C(++)-like syntax, and may be as efficient as lua:
http://www.angelcode.com/angelscript/
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> David Buck wrote:
> [snip]
>>
>> Discussion is welcome.
>>
> Something that I think has not been mentioned in this discussion so far
> (unless I accidentally skipped it):
> One of the interesting things of POV is that it is a great environment
> to learn maths. Often you want to position two objects in such a way
> that they touch each other or such that the combined surface is
> continuous or... You can do this by trial and error, but soon you'll end
> up motivated to learn how to solve a particular second order equation or
> some equation involving sin() or tan().
> Whatever direction a new SDL is going to take, it would be great if the
> simplest subset could (still) be used in a high school math class. The
> only thing we then need is someone to write something like 'Mindstorms
> for high school students'.
>
There is a lot more that I would want to say, but I find this format of
discussing in a subthread a bit confusing. I am not sure if a wiki is
the right solution, but I'd really like a discussion forum where we
could combine remarks by subject.
Can someone set something up somewhere?
If not, I might feel forced to sift through this mess again to collect
all arguments and put them on a simple html page, but be aware that that
one will be highly biased and not changeable by others ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme M. Berger nous apporta ses lumieres en ce 2007/09/20 14:41:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Alain wrote:
>> nemesis nous apporta ses lumieres en ce 2007/09/19 17:10:
>>> "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
>>> hey, how about pretty much no syntax at all?
>>>
>>> (union (plane y (pigment (checker 0 1)))
>>> (sphere 0 1
>>> (texture (pigment (rgb x))
>>> (finish (phong 0.8 30)))))
>>> (light-source white (* 5 #(-1 1 -1)))
>>> (camera (z -3) 0)
>>>
>>> well, except for Lots of Irritating Silly Parentheses, that is... :)
>>>
>> Makes me think of Lisp! TONS of parenteses ;-)
>>
> Look more closely at his last sentence. Especially the capital
> letters... ;)
>
> Jerome
It makes for a nice alternative for LISP, but not what the creators had in mind ;-)
Similar to:
I Built a Monster
It's Beter Manualy
The legend tell that those where from peoples working in THAT compagny...
--
Alain
-------------------------------------------------
I went to a massage parlor. It was self service.
Rodney Dangerfield
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> William Tracy <wtr### [at] calpolyedu> wrote:
> > If we're going to re appropriate an existing language, maybe we could
> > look at some of the functional languages (Lisp, ML, etc.).
>
> Next you are going to suggest Haskell.
>
> --
> - Warp
BTW, just saw this in reddit:
http://www.nobugs.org/developer/htrace/index.html
though it's just a toy raytracer from 2001...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Can someone set something up somewhere?
Can someone recommend specific Wiki software?
It'd need to support external authentication (to link in to the POV user
registration system), and captchas or other anti-spam measures.
Anyone have any experience with this?
Alternatively if someone here wants to undertake to maintain an official
POV wiki and has some experience in site management, let me know and I'll
set them up with some webspace on the povray.org server and let them loose.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 24 Sep 2007 17:47:45 +1000, Chris Cason
<del### [at] deletethistoopovrayorg> wrote:
>Can someone recommend specific Wiki software?
Some time ago, I set up MediaWiki at work for use as a company-wide wiki. It's the
same one used for Wikipedia. It works very well. At the time, it was the best one
out there. This may still be
the case...
http://www.mediawiki.org/
>It'd need to support external authentication (to link in to the POV user
>registration system), and captchas or other anti-spam measures.
I believe there are extensions written for MediaWiki that support these requirements.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
As with Kyle, I have some experience with MediaWiki - I've set it up a
few times and we use it at work. I'm rubbish at the stylesheets and
whatnot, but authentication and whatnot should be fairly easy to get
going. What type of database is used on the backend to hold the user
information?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson <nos### [at] nospamcom> wrote:
> As with Kyle, I have some experience with MediaWiki - I've set it up a
> few times and we use it at work. I'm rubbish at the stylesheets and
> whatnot, but authentication and whatnot should be fairly easy to get
> going. What type of database is used on the backend to hold the user
> information?
>
> Jim
Is this undertaking going to coincide with the SDL object/code repository
that was discussed sometime back?
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 24 Sep 2007 19:50:34 -0400, Charles C wrote:
> Is this undertaking going to coincide with the SDL object/code
> repository that was discussed sometime back?
> Charles
Personally, I couldn't answer that, but I don't see why such a wiki
couldn't include a collection of examples.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
why not go super-simple?
lighting {4pm, August 12, Milan, Italy, outdoors}
city{detail=fine}
camera{Canon AE-1, F2.8, 1/100th
filters{anti-glare, polarized}
}
car{Bentley, color Red, very shiny}
woman{sexiness 9.5, evening_wear{color Black fabric Silk} winking}
nemesis wrote:
> "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
>
> hey, how about pretty much no syntax at all?
>
> (union (plane y (pigment (checker 0 1)))
> (sphere 0 1
> (texture (pigment (rgb x))
> (finish (phong 0.8 30)))))
> (light-source white (* 5 #(-1 1 -1)))
> (camera (z -3) 0)
>
> well, except for Lots of Irritating Silly Parentheses, that is... :)
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia wrote:
> why not go super-simple?
>
> lighting {4pm, August 12, Milan, Italy, outdoors}
> city{detail=fine}
>
> camera{Canon AE-1, F2.8, 1/100th
> filters{anti-glare, polarized}
> }
What if you don't have a Canon?
>
> car{Bentley, color Red, very shiny}
>
> woman{sexiness 9.5, evening_wear{color Black fabric Silk} winking}
>
>
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Can someone set something up somewhere?
> If not, I might feel forced to sift through this mess again to collect
> all arguments and put them on a simple html page, but be aware that that
> one will be highly biased and not changeable by others ;)
Ok, some of the discussion is summarized at:
http://members.chello.nl/a.c.linnenbank/newsdlforpov.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia wrote:
> why not go super-simple?
>
> lighting {4pm, August 12, Milan, Italy, outdoors}
> city{detail=fine}
>
> camera{Canon AE-1, F2.8, 1/100th
> filters{anti-glare, polarized}
> }
>
> car{Bentley, color Red, very shiny}
>
> woman{sexiness 9.5, evening_wear{color Black fabric Silk} winking}
>
>
IOW, you want an SDL that fully supports DWIM. :-)
-=- Larry -=-
PS. If you've never run across this acronym: DWIM = "Do What I Mean"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> http://members.chello.nl/a.c.linnenbank/newsdlforpov.html
Here are some ideas of mine, if the new SDL is created as an enhancement
of the current SDL (instead of creating a completely separate new scripting
language):
* Even if it's based on the current SDL, it should still be byte-compilable
(and even JIT-compilable to native machine code if so needed), which means
that at least some backwards-compatibility must be broken and there's no
way around it. One example is that #macros can no longer be used in the
same ways as current ones, but instead they must work as pure functions.
For example, current macros can be used for "ugly" tricks like this:
#macro M(a, b)
, a, b>
#end
sphere { <1 M(2, 3), 4 }
This just doesn't fit in for byte-compiled code (at least not with very,
very ugly hacks which would only burden and slow down the VM interpreting
the bytecode).
The vast majority of #macros out there already work as pure functions,
though, so only the "ugliest" ones would break.
* Existing data containers, namely arrays and strings (which are special
arrays of characters), should be enhanced and new data containers introduced.
For example the current array could be internally implemented as a C++ deque,
which would make it work like the current one plus you can freely resize it
(larger or smaller), append elements at the beginning and at the end, and
you can still access any element fast, and none of these operations will be
slow (eg. resizing does not require copying/moving any existing elements).
Even inserting or removing elements from the middle of the array would be
possible, although it would not be a constant-time operation.
Strings could also be internally implemented as C++ strings. This would
also allow easy resizing and appending. Also any byte values should be
supported so that strings could also be used as raw byte arrays (for example
for reading and writing files in binary mode). More operators and functions
for accessing and manipulating strings should be added.
Some syntactical technique should be introduced which would allow handling
and accessing other types of data containers as well, such as lists and
sets (balanced binary trees). Using the same idea as with C++ iterators for
this could be one possibility. This would allow offering the C++ data
containers at the SDL level.
* The language should be enhanced in such a way that you can create your
own (efficient) data containers. For this it may be necessary to introduce
the concept of modules (ie. classes without inheritance) or classes (with
perhaps a simple inheritance support) and references. These modules or
classes could have member variables and perhaps even member functions.
Accessing the elements could be done with the dot operator.
* Many of the existing features of the current SDL, such as the camera,
global_settings, etc, could be enhanced to behave like such modules/classes.
For example, I envision this kind of code being possible:
#if(global_settings.max_trace_level < 10)
global_settings { max_trace_level 10 }
// or alternatively: global_settings.max_trace_level = 10
#end
#declare CameraAngle = camera.angle;
Perhaps even objects could behave like modules/classes like this, so
you could do something like:
#declare S = sphere { 0, 1 };
#declare R = S.radius;
This could be especially useful for writing SDL libraries which modify
triangle meshes (eg. subdivision, smoothing...)
* There should be support for binary reading and writing of files (into
strings, which have been enhanced to support raw byte data). Maybe other
methods of reading and writing files could be introduced as well (in order
to make it easier to write file format parsers).
* If possible, introduce alternative ways of handling identifiers/variables
so that all of these lines are valid:
#declare Var = Var + 1;
Var = Var + 1;
#declare Var += 1;
Var += 1;
* The most difficult thing of all: Some kind of shader language, and deciding
if this will be a completely separate language from the SDL (in the same
way as current user-defined functions are) or if it will be the same.
Perhaps a limited set of the SDL itself could be used as a shader language
(for example a shader would be a macro/function which takes certain
parameters and only uses a subset of the whole SDL, and which has access
to certain special functions not accessible normally; the parser would check
that this is so).
Ideally such shader function could do things like trace additional rays,
read information from objects, textures, etc.
* Likewise some way of post-processing the rendered image with the SDL should
be possible. This could also be, for example, a special macro/function which
takes certain parameters and which has access to certain functions.
Ideally the post-processing step is not completely separate from the
rendering step. For It may be cool if the post-processing function could,
for example, trace new rays if it wants to.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm sure this has already been requested at some point, but I'd like to have the
ability to define image parameters from within the scene file. These parameters must
currently be defined at the
command line or within an ini file.
For example:
#declare Image.width = 800;
#declare Image.height = 600;
#declare Image.antialiasing.threshold = 0.1;
Or alternatively, if the current syntax is retained, something like this:
#declare image_width = 800;
#declare image_height = 600;
#declare image_antialiasing_threshold = 0.1;
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia nous apporta ses lumieres en ce 2007/09/25 14:16:
> why not go super-simple?
>
> lighting {4pm, August 12, Milan, Italy, outdoors}
> city{detail=fine}
>
> camera{Canon AE-1, F2.8, 1/100th
> filters{anti-glare, polarized}
> }
>
> car{Bentley, color Red, very shiny}
>
> woman{sexiness 9.5, evening_wear{color Black fabric Silk} winking}
>
>
>
>
Positive point: this simplify things for some peoples.
Negative point: this imply several HUGE libraries of premade shapes, textures,
environments, models,...
Another negative point: Humongous code bloat. How about a 5+ Gb download?
--
Alain
-------------------------------------------------
If you're ever about to be mugged by a couple of clowns, don't hesitate - go for
the juggler.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kyle <hob### [at] gatenet> wrote:
> I'm sure this has already been requested at some point, but I'd like to have the
ability to define image parameters from within the scene file. These parameters must
currently be defined at the
> command line or within an ini file.
Not gonna happen because it breaks the boundary between the frontend and
the backend, and this cannot be broken while still preserving the abstraction
level necessary for distributed rendering and such.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
page updated with your and warp's comments. Hmm, I think I need some
version control system here. Perhaps I should also leave my old habit of
writing plain HTML in a text editor. Anyone some (meta) suggestions?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> Perhaps I should also leave my old habit of
> writing plain HTML in a text editor.
If you are writing HTML, then please use the available features HTML
offers, such as <pre>, <code>, etc, to make the page clearer and easier
to read.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Perhaps I should also leave my old habit of
>> writing plain HTML in a text editor.
>
> If you are writing HTML, then please use the available features HTML
> offers, such as <pre>, <code>, etc, to make the page clearer and easier
> to read.
>
Sorry, I'll see what I can do. As some kind of excuse: I have been
writing simple HTML since the first Mosaic came out and I designed the
first version of a website for a biomedical engineering federation (the
IFMBE.org), and I did not need code snippets for that. I never improved
my knowledge of html since. ;) So no style sheets for me. BTW I also
made the changes bold, does that improve the reading or does it hamper it?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 26 Sep 2007 08:57:39 -0400, Alain wrote:
> Positive point: this simplify things for some peoples. Negative point:
> this imply several HUGE libraries of premade shapes, textures,
> environments, models,...
> Another negative point: Humongous code bloat. How about a 5+ Gb
> download?
Bottom line point: I think it's safe to assume that Bryan was making a
joke. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson nous apporta ses lumieres en ce 2007/09/26 13:48:
> On Wed, 26 Sep 2007 08:57:39 -0400, Alain wrote:
>
>> Positive point: this simplify things for some peoples. Negative point:
>> this imply several HUGE libraries of premade shapes, textures,
>> environments, models,...
>> Another negative point: Humongous code bloat. How about a 5+ Gb
>> download?
>
> Bottom line point: I think it's safe to assume that Bryan was making a
> joke. ;-)
>
> Jim
I agree, let just assume it IS a joke ;-)
--
Alain
-------------------------------------------------
"Having a smoking area in a restaurant is like having a peeing area in a pool."
--Thomas Pfeffer, American Heart Association
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 26 Sep 2007 14:48:52 -0400, Alain wrote:
> Jim Henderson nous apporta ses lumieres en ce 2007/09/26 13:48:
>> On Wed, 26 Sep 2007 08:57:39 -0400, Alain wrote:
>>
>>> Positive point: this simplify things for some peoples. Negative point:
>>> this imply several HUGE libraries of premade shapes, textures,
>>> environments, models,...
>>> Another negative point: Humongous code bloat. How about a 5+ Gb
>>> download?
>>
>> Bottom line point: I think it's safe to assume that Bryan was making a
>> joke. ;-)
>>
>> Jim
> I agree, let just assume it IS a joke ;-)
What I want to know is why he only went a 9.5 on sexiness....
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Warp:
> Here are some ideas of mine
As good a place as any to start. I want to contribute to this discussion
as someone who is not a knowledgeable programmer but has possibly
written at as much POV SDL code as any other person on this server.
I have put some thought over the past two weeks into deciding what
exactly POV-Ray is. A renderer of course; A modeler perhaps. But, beyond
that, what is POV-Ray in relation to other "free" renderers out there?
My conclusion is that POV-Ray is, importantly, the renderer whose users
best understand it. Here's an example: I asked on the Yafray forum
whether Yafray allowed a user to explicitly define the vertex normals of
a mesh; 165 views so far - 0 answers. No user on the forum seems to
know. Blender can't do it, so Blender's limitation has become, literally
or practically, Yafray's limitation. Contrast this with the POV-Ray user
base, the even moderately experienced of which are familiar with both of
our mesh formats, light_groups, no_image, and many other critical
features which the mouse-modeler crowd might consider merely "tweaks."
Given that, what can and cannot be changed without changing POV-Ray's
identity?
> Warp:
> * Even if it's based on the current SDL <snip> some backwards-
> compatibility must be broken
Must be based around certain characteristics of the current SDL. A scene
with a camera, light_source, and sphere must require familiarity only
with the camera, light_source, and sphere objects. There should never be
a section in the documentation titled, "Structure of a POV-Ray Scene
File" or anything similar.
Forget backwards compatibility. Now is the best opportunity that will
likely ever come to undo any "mistakes" of the past.
> Warp:
> * Existing data containers, namely arrays and strings (which are
> special arrays of characters), should be enhanced and new data
> containers introduced <snip> it may be necessary to introduce the
> concept of modules (ie. classes without inheritance) or classes
> (with perhaps a simple inheritance support) and references. These
> modules or classes could have member variables and perhaps even member
> functions. Accessing the elements could be done with the dot operator.
All of this would add piles of pages to the documentation (a bad thing),
and provide (in most cases) nothing which could not be provided by
generating SDL with any given user's programming language of choice.
The way I work now is by generating POV SDL in Python, but I still make
use of POV-Ray macros. An example is a macro which uses eval_pigment.
POV-Ray knows the value of "leopard" at <3,4,5> - Python doesn't.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Any addition to the procedural part of POV SDL must either be necessary
to create a scene, significantly decrease the size of a scene-file, or
significantly increase the readability of a scene-file.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> Warp:
> * The most difficult thing of all: Some kind of shader language,
How about keeping it simple? For instance, a function "surface" which
knows what every ray knows and works with POV-Ray's existing texture and
finish options.
How a colored specular shader might look (if functions could return
vectors):
#local colored_specular = function {
pigment {
function { surface().specular }
pigment_map {
[0 object_pigment]
[1 rgb <1,1,0>]
}
}
}
sphere { 0, 1
pigment { rgb <1,0,0> }
finish { specular .8 }
shader { function { colored_specular() } }
}
A toon shader might make use of surface().illumination or
surface().angle_of_incidence
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <Sha### [at] cccc> wrote:
> All of this would add piles of pages to the documentation (a bad thing),
A bad thing why? You don't have to read those parts of the documentation
if you don't want to. You don't have to use the extra features if you don't
want to. But why would you want to remove the extra features from people
who could create awesome things with them?
Imagine you could write this scene in POV-Ray:
#include "import3ds.inc"
import3ds("myscene.3ds");
And that's it. Nothing more. And the scene renderes beautifully.
But no, you don't want this. You want to remove any possibility of
doing this. You want to keep POV-Ray simple and dumb, without any tools
to actually make it more versatile and powerful than it already is.
When some newbie asks "can I convert a 3DS file to povray" you will
answer the old same "try this converter software which does a half-assed
job and might work or not".
Making povray simpler and dumber is only going to hurt it.
> and provide (in most cases) nothing which could not be provided by
> generating SDL with any given user's programming language of choice.
How would you generate a shader which accesses a data container with
an external programming language if povray does not support that?
> > * The most difficult thing of all: Some kind of shader language,
> How about keeping it simple? For instance, a function "surface" which
> knows what every ray knows and works with POV-Ray's existing texture and
> finish options.
Why keep it needlessly simple when you could just as well write the
shader with the exact same scripting language you are creating the
scene with?
What if you wanted to write a shader which, for example, spawns
additional rays? Or one which gives different results depending on
whether it's inside or outside a specific object?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Wed, 26 Sep 2007 14:48:52 -0400, Alain wrote:
>
>> Jim Henderson nous apporta ses lumieres en ce 2007/09/26 13:48:
>>> On Wed, 26 Sep 2007 08:57:39 -0400, Alain wrote:
>>>
>>>> Positive point: this simplify things for some peoples. Negative point:
>>>> this imply several HUGE libraries of premade shapes, textures,
>>>> environments, models,...
>>>> Another negative point: Humongous code bloat. How about a 5+ Gb
>>>> download?
>>>
>>> Bottom line point: I think it's safe to assume that Bryan was making a
>>> joke. ;-)
>>>
>>> Jim
>> I agree, let just assume it IS a joke ;-)
>
> What I want to know is why he only went a 9.5 on sexiness....
>
> Jim
Any value higher then 9.5 could be considered by some as being of a too
profound sexual nature, and this is still a public access server.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
