 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoo povrayorg> wrote:
> Shay wrote:
> > However, the slow development of POV-Ray leaves me concerned that this
> > quality program (or at least, a good deal of the community around it)
> > may one day disappear.
I feel that too: Pixie is just like all renderers out there, obsessed with
polygon meshes or the likes. Other than POV, I don't know of any other
renderer allowing for true mathematical surfaces as shape primitives...
> Now that process has been completed, as a group we feel the GPL3 is the way
> to go and have informally decided that 4.0 will be GPL3-licensed. [While at
> this point the GPL3 is not (as far as I know) OSI-approved, we expect that
> this will occur in due course, and in any event, the GPL has enough
> standing to hold its own.]
That's wonderful news, Chris! I'm sure POV has many fans among the
open-source community which have not pronouced themselves until now because
of the non-usual POV license from the freeware days.
> Overall you may now have some better idea of what is in our minds and
> the process we intend to follow. The matter is we simply have to get the
> time to polish off 3.7 and do the requisite modifications to the tree to
> make it ready for the above.
thanks for the feedback, Chris. Take all the time you need. It's not like
3.6 sucks or has plenty of bugs...
> We are as always interested in hearing from anyone with reasonable coding
> skills who can assist, not only with the future 4.0 work but also with
> finishing 3.7.
hmm, I have some C coding skills, but I guess the main problem is not C
coding, but 3D algorithms and understanding the SDL parser...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> The process we intend to follow (note this is not set in stone) is that
> once 3.7 is stable enough for an RC, we will make a public release of the
> 3.7 source. Some time after that (once the source is stable enough) we will
> release a modified version of the 3.7 source labeled 4.0, with all portions
> of the code that we cannot re-license stubbed out or otherwise removed.
Does this mean that 4.0 will *not* have any kind of revised SDL language?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> The process we intend to follow (note this is not set in stone) is that
>> once 3.7 is stable enough for an RC, we will make a public release of the
>> 3.7 source. Some time after that (once the source is stable enough) we will
>> release a modified version of the 3.7 source labeled 4.0, with all portions
>> of the code that we cannot re-license stubbed out or otherwise removed.
>
> Does this mean that 4.0 will *not* have any kind of revised SDL language?
It means that it will have whatever developer resources permit it to have ;-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
nemesis wrote:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> Shay wrote:
>>> However, the slow development of POV-Ray leaves me concerned that this
>>> quality program (or at least, a good deal of the community around it)
>>> may one day disappear.
>
> I feel that too: Pixie is just like all renderers out there, obsessed with
> polygon meshes or the likes. Other than POV, I don't know of any other
> renderer allowing for true mathematical surfaces as shape primitives...
>
?? Pixie is a renderman compliant REYES renderer. That means it has
true mathematical surfaces (including true Bezier patches, which POV
doesn't have btw).
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)
iD8DBQFG4Yi6d0kWM4JG3k8RAi2oAJ98lzJf3EysiKKRy14LSgduE+VIywCdG5e+
bDwwPTIuBYhyTiTzzPzUxuw=
=Q3N4
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Shay" <Sha### [at] cccc> wrote in message news:46e0875d$1@news.povray.org...
> Zeger Knaepen wrote:
>>>
>>> [2] ie "Pass by reference" bug.
>>
>> that's a bug? I thought it was a feature.
>
> Try this code:
>
> #macro Pass_By_Reference ( VARIABLE )
> #local VARIABLE = 9;
> #local Something = str(10,0,0);
> #end
>
> #local Counter = 0;
> #while ( Counter < 100000 )
> #local Var = 12;
> Pass_By_Reference ( Var )
> #if ( Var = 9 )
> // do nothing
> // worked as intended
> #else
> #debug "didn't work this time\n"
> #end
> #local Counter = Counter + 1;
> #end
So far no problems (halfway there)
60000 done, no problems
nearly there!
80000, still no problems
and...
we're there !
without any problem, using MegaPOV 1.2.1
Now, the same with the official POV-Ray
ah, yes, with the official POV-Ray, I get a lot of "didn't work this time"'s
wierd! or is it weird..
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jérôme M. Berger" <jeb### [at] freefr> wrote:
> ?? Pixie is a renderman compliant REYES renderer. That means it has
> true mathematical surfaces (including true Bezier patches, which POV
> doesn't have btw).
AFAIK "bicubic patch" and "bezier patch" are synonyms (but not to be
confused with "NURBS", which is a different thing).
POV-Ray does have true Bezier patches.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Warp wrote:
> "J�r�me M. Berger" <jeb### [at] freefr> wrote:
>> ?? Pixie is a renderman compliant REYES renderer. That means it has
>> true mathematical surfaces (including true Bezier patches, which POV
>> doesn't have btw).
>
> AFAIK "bicubic patch" and "bezier patch" are synonyms (but not to be
> confused with "NURBS", which is a different thing).
>
> POV-Ray does have true Bezier patches.
>
According to the documentation, POV converts its Bezier patches
into meshes before rendering them, which is precisely the gripe
nemesis seems to have with other renderers...
http://povray.org/documentation/view/3.6.1/290/
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)
iD8DBQFG4aVcd0kWM4JG3k8RAmb/AKC5k4MzS7cFa8fn0D2yhVRoSx4PswCcC7xh
Uvib0WJ4A4le4mQxuA9xFOQ=
=NS9n
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jérôme M. Berger" <jeb### [at] freefr> wrote:
> According to the documentation, POV converts its Bezier patches
> into meshes before rendering them, which is precisely the gripe
> nemesis seems to have with other renderers...
That's only with type 1 bicubic patches. Type 0 are not tesselated.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:46e1acbe@news.povray.org...
> "Jérôme M. Berger" <jeb### [at] freefr> wrote:
>> According to the documentation, POV converts its Bezier patches
>> into meshes before rendering them, which is precisely the gripe
>> nemesis seems to have with other renderers...
>
> That's only with type 1 bicubic patches. Type 0 are not tesselated.
Are you sure? The docs state clearly: "A bicubic_patch is a 3D curved
surface created from a mesh of triangles.", and rendering the example in the
docs, which uses type 0, results in visible mesh-like artifacts (jagged edge
and shadowline).
camera {
location <1,0,-4>
look_at 1.5
}
light_source {<500,500,-500> rgb 1}
bicubic_patch {
type 0
flatness 0.01
u_steps 4
v_steps 4
<0, 0, 2>, <1, 0, 0>, <2, 0, 0>, <3, 0,-2>,
<0, 1 0>, <1, 1, 0>, <2, 1, 0>, <3, 1, 0>,
<0, 2, 0>, <1, 2, 0>, <2, 2, 0>, <3, 2, 0>,
<0, 3, 2>, <1, 3, 0>, <2, 3, 0>, <3, 3, -2>
pigment {rgb 1}
}
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Warp wrote:
> "J�r�me M. Berger" <jeb### [at] freefr> wrote:
>> According to the documentation, POV converts its Bezier patches
>> into meshes before rendering them, which is precisely the gripe
>> nemesis seems to have with other renderers...
>
> That's only with type 1 bicubic patches. Type 0 are not tesselated.
>
The documentation isn't very clear on that point. I've just taken a
look in the code and the way I understood it:
- Type 1 are tesselated at parse time, then rendered as meshes;
- Type 0 are tesselated dynamically during render time and the
tesselation results are discarded immediately once the intersections
are found. In particular, I noticed that POV accessed the u_order
and v_order variables and repetitively called the DeCasteljau
subdivision functions during intersection computations...
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)
iD8DBQFG4bHZd0kWM4JG3k8RAjzEAJ0RF5HgZZWQm+Gz/6wYkyh+PL/ctQCbBNJ5
SQJojFTtVMIUHnwuUgLaQKc=
=3pme
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger@free.fr> wrote:
> According to the documentation, POV converts its Bezier patches
> into meshes before rendering them, which is precisely the gripe
> nemesis seems to have with other renderers...
actually, my gripe is that to define polygon, bezier or NURBS surfaces, you
have to define them by their vertices/control points/etc. I enjoy saying
sphere { point, radius } and having a perfect sphere. Or getting complex
isosurfaces by playing with functions. I don't like playing with points,
let alone lots of them. And yes, it's annoying even in visual modellers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jérôme M. Berger" <jeb### [at] freefr> wrote:
> - Type 0 are tesselated dynamically during render time and the
> tesselation results are discarded immediately once the intersections
> are found. In particular, I noticed that POV accessed the u_order
> and v_order variables and repetitively called the DeCasteljau
> subdivision functions during intersection computations...
I see.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
>
> I feel that too: Pixie is just like all renderers out there,
> obsessed with polygon meshes or the likes. Other than POV, I
> don't know of any other renderer allowing for true mathematical
> surfaces as shape primitives...
Untested (and I don't know RIB well) code:
// POV-Ray SDL:
intersection {
difference {
sphere { <0,.5,0>, 1 pigment { rgb <1,0,0> } }
sphere { <0,.5,0>, 1 pigment { rgb <0,1,0> } rotate z*120 }
}
sphere { <0,.5,0>, 1 pigment { rgb <0,0,1> } rotate z*240 }
translate <1,2,3>
}
# Pixie RIB:
Surface "matte"
AttributeBegin
Translate 1 2 3
SolidBegin "intersection"
SolidBegin "difference"
AttributeBegin
Color 1 0 0
Translate 0 .5 0
Sphere 1 -1 1 360
AttributeEnd
AttributeBegin
Color 0 1 0
Translate 0 .5 0
Rotate 120 0 0 1
Sphere 1 -1 1 360
AttributeEnd
SolidEnd
AttributeBegin
Color 0 0 1
Translate 0 0.5 0
Rotate 120 0 0 1
Sphere 1 -1 1 360
AttributeEnd
SolidEnd
AttributeEnd
I don't want to start a drawn out POV vs. RIB comparison - I'm not
qualified to do so even if I did want to. But, having used both, I will
say that neither is a replacement for the other and that POV suits my
needs better.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
>
> The process we intend to follow ...
This is extremely encouraging and exciting. Thank you for sharing this.
> We are as always interested in hearing from anyone with
> reasonable coding skills who can assist
I wish I were qualified; Best wishes to those who are.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
nemesis wrote:
> =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger@free.fr> wrote:
>> According to the documentation, POV converts its Bezier patches
>> into meshes before rendering them, which is precisely the gripe
>> nemesis seems to have with other renderers...
>
> actually, my gripe is that to define polygon, bezier or NURBS surfaces, you
> have to define them by their vertices/control points/etc. I enjoy saying
> sphere { point, radius } and having a perfect sphere. Or getting complex
> isosurfaces by playing with functions. I don't like playing with points,
> let alone lots of them. And yes, it's annoying even in visual modellers.
>
Well, then any renderman compliant renderer has the ability to
define spheres, cones, cylinders, toruses, disks, paraboloids,
hyperboloids and blobs. The only truly missing POV primitive is the
box. As for isosurfaces(1), there are mostly two uses: making
abstract geometric shapes (which is easier in POV) or adding
irregularities to the surface of some objects (which is much easier
to do with renderman displacement shaders).
I'm not saying that renderman renderers are better, or that you
should abandon POV for them, but just that you weren't really fair
in your appreciation of them.
Jerome
(1) Isosurfaces are possible in renderman, but they require to be
programmed in C and either added to the renderer as an external
plugin, or that you not use the renderer, but instead use the
associated lib and program everything in C. A rather cumbersome if
extremely flexible method...
- --
+------------------------- 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)
iD8DBQFG4kU6d0kWM4JG3k8RAiXGAJ9F8cv2AAQ5yXBSpMHLzIoLQAl5ugCgkOT7
dpLVYDyJjep5gYOHFV6CV30=
=jN6n
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> hmm, I have some C coding skills, but I guess the main problem is not C
> coding, but 3D algorithms and understanding the SDL parser...
C coding with a basic understanding of C++ would probably be sufficient for
many of the tasks in re-writing the code that has to be replaced. Recall that
all the POV code was originally c, and the fundamental core of the algorithms
and objects are still readable by a C programmer.
The re-write basically involves reading and understanding an existing
function (or group of related functions), and writing a clean version to
replace it.
One way to approach it (and one that I would favour) would be for one group
of people to reverse-engineer the functionality into pseudo-code or similar,
and for another group to then take that and write new code. This helps to
ensure that the new code does not inadvertently copy from the old.
Whichever way it's done, those involved will get a real sense of satisfaction
as each bit is done and plugged back into the program - given a working
infrastructure such as we will have, it will in many cases be possible to see
immediate results as things are turned back on. [This will depend mainly on
the order in which things are done].
Plus there's always the community and primary developers available to guide
things. And anyone who is working on the code actively is welcome to IM me
any time for assistance.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Does this mean that 4.0 will *not* have any kind of revised SDL language?
I have to be realistic here and take the approach that attempting to write a
new SDL prior to releasing the tree for folks to work on would not be
practical. On the other hand, the existing parser has to be replaced since it
is fairly cumbersome and hard to maintain.
The fact is that once we are done, it will be possible to have any number of
parsers that interface to the rendering engine; whatever we put into the tree
for initial development will only be one of them (and most likely not the
final). Once we've got some momentum and reasonable functionality in the re-
development of the rendering core, I expect more attention can be paid to the
parser.
Of course, there's nothing to stop people discussing and perhaps designing a
new SDL in advance - and perhaps even prototyping it in a stand-along app
(e.g. perhaps something that spits out POV 3.x code).
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <Sha### [at] cccc> wrote:
> I don't want to start a drawn out POV vs. RIB comparison
too late. ;)
anyway, I was wrong about Pixie. Good to know it has native support for
geometric primitives, CSG and the likes, without resorting to huge meshes.
Good to know too about its SDL.
It's a bad thing though that XML has f*cked up so many minds through the
industry: you can't have anymore a good ol' little domain specific
language to do the job without resorting to XML syntax or something quite
the same, like Pixie's and YAFRay's. What's wrong with {} blocks? What's
the matter with "Object.attribute = value"? I can see the horrific day
when Java comes blended with XML syntax...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> C coding with a basic understanding of C++ would probably be sufficient for
> many of the tasks in re-writing the code that has to be replaced. Recall that
> all the POV code was originally c, and the fundamental core of the algorithms
> and objects are still readable by a C programmer.
yes, true. I have 3.6 source here. I said C programming exactly for that:
I am yet to encounter any classes or other C++ features. Overall, it's
fairly organized and readable and well modularized over a bunch of files.
> The re-write basically involves reading and understanding an existing
> function (or group of related functions), and writing a clean version to
> replace it.
hmm, I guess it's easier to rewrite a whole module (say, colour.cpp) rather
than a single function within. Because a rewrite may be tempted to
organize things in a different way, dropping hacked functions, writing
others. I think beginning by understand the functionality provided by the
header is a better start than thinking about one function alone.
> One way to approach it (and one that I would favour) would be for one group
> of people to reverse-engineer the functionality into pseudo-code or similar,
> and for another group to then take that and write new code. This helps to
> ensure that the new code does not inadvertently copy from the old.
yes, I agree.
> Plus there's always the community and primary developers available to guide
> things. And anyone who is working on the code actively is welcome to IM me
> any time for assistance.
I may take the plunge, though there is always the real-world (like a little
daughter) in the way of my commitments. Plus, I'm on Linux and that means
testing against gcc only.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> The process we intend to follow (note this is not set in stone) is that
> once 3.7 is stable enough for an RC, we will make a public release of the
> 3.7 source. Some time after that (once the source is stable enough) we will
> release a modified version of the 3.7 source labeled 4.0, with all portions
> of the code that we cannot re-license stubbed out or otherwise removed.
What help with re-licensing do you need from those of us who have made
code contributions?
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
nemesis wrote:
> Shay <Sha### [at] cccc> wrote:
>> I don't want to start a drawn out POV vs. RIB comparison
>
> too late. ;)
>
> anyway, I was wrong about Pixie. Good to know it has native support for
> geometric primitives, CSG and the likes, without resorting to huge meshes.
> Good to know too about its SDL.
>
> It's a bad thing though that XML has f*cked up so many minds through the
> industry: you can't have anymore a good ol' little domain specific
> language to do the job without resorting to XML syntax or something quite
> the same, like Pixie's and YAFRay's. What's wrong with {} blocks? What's
> the matter with "Object.attribute = value"? I can see the horrific day
> when Java comes blended with XML syntax...
>
Well, according to Wikipedia, the first release of Renderman dates
back to 1989, whereas work on XML didn't even start until mid-1996,
so you can hardly accuse XML of having contaminated the
specification of Renderman :)
As to why these languages look like they do instead of a simple
C-like syntax, the main reason is that they were designed to be
primarily interchange formats. This means that they were meant to be
generated by a program and read by another. They were never really
intended to be generated by hand. Because of this, they have a
syntax that is *very* easy to parse for a computer (as an example,
the XML grammar fits in about 200 lines, whereas the C grammar takes
over 400 lines (and that's *without* the preprocessor!)
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)
iD8DBQFG4589d0kWM4JG3k8RAsvaAJ9y9JJsOmuCOl4LvioTd8IzmHUuoQCgq7Sw
sk2JPkOte3EeX53ozjoY7vM=
=wm02
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> I have to be realistic here and take the approach that attempting to write a
> new SDL prior to releasing the tree for folks to work on would not be
> practical. On the other hand, the existing parser has to be replaced since it
> is fairly cumbersome and hard to maintain.
> The fact is that once we are done, it will be possible to have any number of
> parsers that interface to the rendering engine; whatever we put into the tree
> for initial development will only be one of them (and most likely not the
> final). Once we've got some momentum and reasonable functionality in the re-
> development of the rendering core, I expect more attention can be paid to the
> parser.
I'm not sure I have any reason to, but what I fear is that once the
developement of POV-Ray becomes completely open, if it so happens that
nobody takes the role of strong leader ("dictator") or nobody is accepted
as such, what will happen is that there will be too many cooks spoiling
the broth and no general agreement is ever reached over which kind of
scripting language should be adopted and implemented. Even if an attempt
at designing such a language, the "too many cooks" will only stir the mud
and without that strong leadership the entire thing can become a complete
mess.
As I see it, the three most likely scenarios are:
1) A good agreement is never reached, and since nobody is "forcing" a
change, a new refactored SDL is never created and the current SDL will be
used forever regardless of its great limitations.
2) An agreement is reached (good or not) and an implementation attempt is
made, but again, without anyone "forcing" it in, too many people will protest
against the change and the new scripting language will not gain wide usage
and will never reach "gold status".
3) I would say the most likely scenario: Someone will embed an existing
scripting language (such as LUA) as an *alternative* to the existing SDL.
Again, since nobody is "forcing" the change to the new SDL only few people
will use it, and most importantly, since this existing scripting language
is not designed from scratch to support POV-Ray specifically, it will only
be half-useful. It will also look so much different from the current SDL
that not many people will be eager to change to it.
So in summary, I fear that a half-hearted attempt might be attempted,
but the result will not be as good as it could be.
> Of course, there's nothing to stop people discussing and perhaps designing a
> new SDL in advance - and perhaps even prototyping it in a stand-along app
> (e.g. perhaps something that spits out POV 3.x code).
The main reason for the need for a new scripting language is that the
current SDL is very limited (and slow). There are things which are simply
impossible to do. Thus making a prototype of a more flexible and powerful
language which is then simply converted into existing SDL would not be
possible.
Another thing which I envision is that many of the features of the new
scripting language could be used during rendering (shaders being one example)
and after rendering (for post-processing effects). It would obviously just
not be possible to simply make a converter to the existing SDL to test
these features.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Arne Kleinophorst" <kle### [at] spamdebitelnet> schreef in bericht
news:46de836a$1@news.povray.org...
>
> Is there any progress concerning Moray? Is it RIP or WIP?
>
Interestingly, I suppose that Arne's original question is indirectly
answered by the discussion in between. Am I correct in assuming that a new
Moray version can only be envisioned 'after' POV version 3.7 becomes
operational, or 'during / after' POV version 4.0 becomes available? I am not
critical about anything, I am just interested to know what the current
thoughts about Moray are at this stage.
Regards,
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot wrote:
> "Arne Kleinophorst" <kle### [at] spamdebitelnet> schreef in bericht
> news:46de836a$1@news.povray.org...
>> Is there any progress concerning Moray? Is it RIP or WIP?
>>
>
> Interestingly, I suppose that Arne's original question is indirectly
> answered by the discussion in between. Am I correct in assuming that a new
> Moray version can only be envisioned 'after' POV version 3.7 becomes
> operational, or 'during / after' POV version 4.0 becomes available? I am not
> critical about anything, I am just interested to know what the current
> thoughts about Moray are at this stage.
Looks like post-4.0 is the most realistic, though something that worries
me is this: how long, if ever, will it take after gutting non-opensource
code to regain similar level of functionality, and with a new SDL, will
all prior POV data become obsolete and useless?
From a standpoint of someone who (occasionally) uses Moray 3.5 which
necessitates use of POV 3.5 at the most, will it be worth my while to
migrate to a newer version, or will I be relegated to an
ever-more-obsolete set of tools?
--
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme M. Berger wrote:
> Because of this, they have a
> syntax that is *very* easy to parse for a computer (as an example,
> the XML grammar fits in about 200 lines, whereas the C grammar takes
> over 400 lines (and that's *without* the preprocessor!)
No XML is better discussion (not sure if that is your argument or not),
please, those lead nowhere. XML being easy to parse is not an argument for
anybody who knows something about (programming) language theory - the
complexity of a grammar* isn't defined by the name of the language after all ;-)
Thorsten
* See <http://en.wikipedia.org/wiki/Context-free_grammar>,
<http://en.wikipedia.org/wiki/LL_parser>,
<http://en.wikipedia.org/wiki/LR_parser> and all related links.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I'm not sure I have any reason to, but what I fear is that once the
> developement of POV-Ray becomes completely open, if it so happens that
> nobody takes the role of strong leader ("dictator")
Looking for a dictator? -- Hmm, I guess I should rise my hand now and
volunteer... :-P
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Cook wrote:
> Looks like post-4.0 is the most realistic, though something that worries
> me is this: how long, if ever, will it take after gutting non-opensource
> code to regain similar level of functionality, and with a new SDL, will
> all prior POV data become obsolete and useless?
About two people working full-time on it for two to three months. That is
how Chris and i created the first 3.7 beta as well. The trouble is that not
working for two to three months isn't exactly possible these days for any
POV-Team member still around :-(
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> Warp wrote:
> > I'm not sure I have any reason to, but what I fear is that once the
> > developement of POV-Ray becomes completely open, if it so happens that
> > nobody takes the role of strong leader ("dictator")
> Looking for a dictator? -- Hmm, I guess I should rise my hand now and
> volunteer... :-P
That's only half of the problem. The other half is developers actually
accepting you as the strong leader and obeying your wishes. :P
(In the industry this is easy: Either obey, or you get fired. The
paycheck is a good incentive. In the Open Source community this is
slightly more difficult to impose.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thorsten Froehlich wrote:
> Jérôme M. Berger wrote:
>> Because of this, they have a
>> syntax that is *very* easy to parse for a computer (as an example,
>> the XML grammar fits in about 200 lines, whereas the C grammar takes
>> over 400 lines (and that's *without* the preprocessor!)
>
> No XML is better discussion (not sure if that is your argument or not),
> please, those lead nowhere. XML being easy to parse is not an argument for
> anybody who knows something about (programming) language theory - the
> complexity of a grammar* isn't defined by the name of the language after all ;-)
>
I don't understand your answer so I can't really answer to it, but
I'll try to clarify my post:
- I wasn't advocating XML (although there are situations where it
is useful). Especially not for a 3D scene description language;
- Nemesis was complaining about the poor readability and
human-friendliness of languages like XML and RIB. I simply pointed
out that these languages were not intended by their creators to be
manipulated by hand. As such, human-friendliness came as a poor
second to other criteria, like the ease of implementation which is a
prerequisite to wide acceptance. Unfortunately, a lot of people have
started advocating and using XML for situations it wasn't designed
for and fits poorly;
- You say: "the complexity of a grammar isn't defined by the name
of the language". I especially don't understand what you mean by
that? I was using the number of lines of the BNF grammar as a
measurement for the complexity of the language. This shows that C is
much more complex than XML, especially if you include the
C-preprocessor in your estimation.
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)
iD4DBQFG5Bccd0kWM4JG3k8RAiTFAJj46Uf2pfqjZ4TL/M2zgGTIcqDBAKC0uECj
u9Nv9zlr0SP/4uOE48K/Dg==
=soL5
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> We are as always interested in hearing from anyone with reasonable coding
> skills who can assist, not only with the future 4.0 work but also with
> finishing 3.7.
>
> regards,
>
> -- Chris
I did C++ coding in college, only about 4 years ago. I still remember most
of the concepts related to OOP i.e. pointers datatypes stacks ques
struct/typedef, althought my syntax may have gotten a bit rusty. I use
mostly VBA now for work. I don't know if this counts as reasonable, but if
it does, let me know what I can do to help.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> I'm not sure I have any reason to, but what I fear is that once the
> developement of POV-Ray becomes completely open, if it so happens that
> nobody takes the role of strong leader ("dictator") or nobody is accepted
> as such, what will happen is that there will be too many cooks spoiling
> the broth and no general agreement is ever reached over which kind of
> scripting language should be adopted and implemented. Even if an attempt
> at designing such a language, the "too many cooks" will only stir the mud
> and without that strong leadership the entire thing can become a complete
> mess.
> As I see it, the three most likely scenarios are:
>
I wonder why you think this.
There is a sufficient large number of open source projects out there with
which it worked, and still works. OpenOffice and such come to mind.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ger wrote:
> Warp wrote:
>
>> I'm not sure I have any reason to, but what I fear is that once the
>> developement of POV-Ray becomes completely open, if it so happens that
>> nobody takes the role of strong leader ("dictator") or nobody is accepted
>> as such, what will happen is that there will be too many cooks spoiling
>> the broth and no general agreement is ever reached over which kind of
>> scripting language should be adopted and implemented. Even if an attempt
>> at designing such a language, the "too many cooks" will only stir the mud
>> and without that strong leadership the entire thing can become a complete
>> mess.
>> As I see it, the three most likely scenarios are:
>>
>
> I wonder why you think this.
>
> There is a sufficient large number of open source projects out there with
> which it worked, and still works. OpenOffice and such come to mind.
>
Probably because there is a sufficiently large number of open
source projects out there with which it didn't work, and precious
few with which it did.
OpenOffice was first developed as proprietary software and is
currently maintained by Sun. I believe that there is a strong
leadership emanating from Sun to guide the project.
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)
iD8DBQFG5DyDd0kWM4JG3k8RAuRBAJwN9fh3naf1tY0C9lJUyIumv5jfqgCgvE+T
PjKsbdyYl7bE7xWFx7M8F3w=
=zPGo
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I nominate Warp for benevolent dictator for life. ;-)
In all seriousness, I'm very excited about all this, and hope that I'll
have a chance to contribute code.
Re the idea of a demo implementation of SDL: If the main thing we can't
implement currently is post-processing, we could hack a program that
writes "classic" SDL, executes POV, and then runs some post-processing
on the output (ImageMagick comes to mind as a possible starting point).
I assume that there's other problems with this approach besides
postprocessing, though.
--
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu
You know you've been raytracing too long when you can't help thinking
that if the World was created in six days then it must have been with
anti-aliasing off and only point light sources used.
Richard Morton
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jérôme M. Berger" wrote:
>>
>> I wonder why you think this.
>>
>> There is a sufficient large number of open source projects out there with
>> which it worked, and still works. OpenOffice and such come to mind.
>>
> Probably because there is a sufficiently large number of open
> source projects out there with which it didn't work, and precious
> few with which it did.
>
> OpenOffice was first developed as proprietary software and is
> currently maintained by Sun. I believe that there is a strong
> leadership emanating from Sun to guide the project.
>
Agreed, but still.......
Just have a look around, Lazarus, Amarok, KOffice, even KDE, Gnome and Linux
itself are joint efforts. And because they are works in progress people
will come and go.
If the group of designers, developers, coders and testers is willing to work
on it then an open source version of Povray will work. It's just one of
those things that one has to be willing to do, not because one is paid to
do it.
If after a while only Thorsten and Chris are the only ones left working on
it then obviously Povray didn't have what it needs to be an open source
project, but saying from the getgo that it can't work sounds a bit defiant
to me.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy <wtr### [at] calpolyedu> wrote:
> Re the idea of a demo implementation of SDL: If the main thing we can't
> implement currently is post-processing, we could hack a program that
> writes "classic" SDL, executes POV, and then runs some post-processing
> on the output (ImageMagick comes to mind as a possible starting point).
Not possible without things like per-pixel depth and normal info.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jérôme M. Berger" <jeb### [at] freefr> wrote:
> OpenOffice was first developed as proprietary software and is
> currently maintained by Sun. I believe that there is a strong
> leadership emanating from Sun to guide the project.
Yes. Another example is Linux, which works because of strong leadership
and strict control. Likewise many FSF software.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Not possible without things like per-pixel depth and normal info.
Spit out the depth and normal info via a set of several images made with
Megapov's own postprocessing feature?
It would suck for everyday use, though. ;-)
--
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu
You know you've been raytracing too long when you can't look at any
raytraced image without thinking up ways on how to improve it.
Taps a.k.a. Tapio Vocadlo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ger wrote:
> "Jérôme M. Berger" wrote:
>
>>> I wonder why you think this.
>>>
>>> There is a sufficient large number of open source projects out there with
>>> which it worked, and still works. OpenOffice and such come to mind.
>>>
>> Probably because there is a sufficiently large number of open
>> source projects out there with which it didn't work, and precious
>> few with which it did.
>>
>> OpenOffice was first developed as proprietary software and is
>> currently maintained by Sun. I believe that there is a strong
>> leadership emanating from Sun to guide the project.
>>
>
> Agreed, but still.......
> Just have a look around, Lazarus, Amarok, KOffice, even KDE, Gnome and Linux
> itself are joint efforts. And because they are works in progress people
> will come and go.
I don't know how the Lazarus, Amarok, KOffice and KDE teams are
organized, but I do know that the Gnome and Linux teams each have a
"dictator" that steers the project.
> If the group of designers, developers, coders and testers is willing to work
> on it then an open source version of Povray will work. It's just one of
> those things that one has to be willing to do, not because one is paid to
> do it.
> If after a while only Thorsten and Chris are the only ones left working on
> it then obviously Povray didn't have what it needs to be an open source
> project, but saying from the getgo that it can't work sounds a bit defiant
> to me.
If you re-read Warp's post, you'll notice that this is *not* what
he said. What he did say is that such a project needs a strong
leader to keep the team focused and to take decisions and make them
stick. All open source projects whose management method I know fall
into three categories:
- Small projects (1 to 3 developers) which don't need much
organization, but progress slowly and often disappear when the
original team loses interest;
- Large projects which have a strong leader and succeed (Linux,
Gnome, Blender...);
- Large projects which don't have a strong leader and eventually
fail (Stampede...).
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)
iD8DBQFG5GUtd0kWM4JG3k8RAsjFAJ9LXOHUOV87PEPC66TLCCqqVUN+egCbBdKH
1ueHMmIQieB1XpiuG1lybEI=
=xidZ
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Not possible without things like per-pixel depth and normal info.
I have considered providing this in the intermediate stream info (i.e. the
.pov-state file). It's certainly possible for us to extract it from the
rendering engine, provided we put reasonable constraints on it (e.g. the
info is that of the first item hit in the path of the primary ray that is
non-100% transparent). Otherwise we may end up outputting things like the
depth/normal of a media volume, which probably isn't what's wanted. It's
not clear to me what exact criteria should be used, and it may well be that
we need a keyword for it since there may not be any one single solution
that suits everyone.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme M. Berger wrote:
> Thorsten Froehlich wrote:
>
>>Jérôme M. Berger wrote:
>>
>>>Because of this, they have a
>>>syntax that is *very* easy to parse for a computer (as an example,
>>>the XML grammar fits in about 200 lines, whereas the C grammar takes
>>>over 400 lines (and that's *without* the preprocessor!)
>>
>>No XML is better discussion (not sure if that is your argument or not),
>>please, those lead nowhere. XML being easy to parse is not an argument for
>>anybody who knows something about (programming) language theory - the
>>complexity of a grammar* isn't defined by the name of the language after all ;-)
>>
>
> I don't understand your answer so I can't really answer to it, but
> I'll try to clarify my post:
> ...
I also found Thorsten's opening sentence confusing, but I was finally
able to parse it as meaning:
No "XML is better" discussion, please...
-=- Larry -=-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I'm not sure I have any reason to, but what I fear is that once the
> developement of POV-Ray becomes completely open, if it so happens that
> nobody takes the role of strong leader ("dictator") or nobody is accepted
> as such, what will happen is that there will be too many cooks spoiling
> the broth and no general agreement is ever reached over which kind of
> scripting language should be adopted and implemented. Even if an attempt
Well, it is my hope that whatever is released as 'official' by povray.org
will be accepted as official.
I do accept (and it has been my concern for many years, hence e.g. the
requirements for '.unofficial' in non-standard SDL's) that without a
standard for the language, it will diverge into various incompatible
derivatives. Hence, I may well want to take the stance that anything that
uses the 'POV-Ray' name has to comply with certain requirements regarding
the language. Not sure exactly what these would be, it's something we can
work out later.
> 3) I would say the most likely scenario: Someone will embed an existing
> scripting language (such as LUA) as an *alternative* to the existing SDL.
I have had a look at a few embeddable languages, such as AngelCode (see
http://www.angelcode.com/angelscript/) but haven't come to any solid
conclusion yet.
I will comment however that it's probable that we would want to take an
existing library and modify it (if necessary) to suit, rather than writing
something entirely new. I would expect that whatever language we use, it
would require some modification, since expressing POV vectors and so forth
would become too cumbersome otherwise.
> The main reason for the need for a new scripting language is that the
> current SDL is very limited (and slow). There are things which are simply
> impossible to do. Thus making a prototype of a more flexible and powerful
> language which is then simply converted into existing SDL would not be
> possible.
I think it's important that any new SDL be at least P-coded, if not fully
JIT'd on platforms that support it. The latter would be handy in particular
for user-defined shaders. And also note that as a GPL'd program, we can use
portions of the GCC suite as needed.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
> What help with re-licensing do you need from those of us who have made
> code contributions?
If we can clearly identify your contribution, and it is stand-alone, then
an assignment form stating it's released under the GPL3 would be needed.
Apart from that, help in re-coding the existing code would be great ;]
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Woody wrote:
> I did C++ coding in college, only about 4 years ago. I still remember most
> of the concepts related to OOP i.e. pointers datatypes stacks ques
> struct/typedef, althought my syntax may have gotten a bit rusty. I use
> mostly VBA now for work. I don't know if this counts as reasonable, but if
> it does, let me know what I can do to help.
That's fine. As long as you can read the existing code and use the same C++
concepts as it uses in re-implementing it, then you're right.
I'll post an example of some code in a new thread shortly.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Larry Hudson wrote:
> Jérôme M. Berger wrote:
>> Thorsten Froehlich wrote:
>>
>>> Jérôme M. Berger wrote:
>>>
>>>> Because of this, they have a
>>>> syntax that is *very* easy to parse for a computer (as an example,
>>>> the XML grammar fits in about 200 lines, whereas the C grammar takes
>>>> over 400 lines (and that's *without* the preprocessor!)
>>>
>>> No XML is better discussion (not sure if that is your argument or not),
>>> please, those lead nowhere. XML being easy to parse is not an
>>> argument for
>>> anybody who knows something about (programming) language theory - the
>>> complexity of a grammar* isn't defined by the name of the language
>>> after all ;-)
>>>
>>
>> I don't understand your answer so I can't really answer to it, but
>> I'll try to clarify my post:
>> ...
> I also found Thorsten's opening sentence confusing, but I was finally
> able to parse it as meaning:
> No "XML is better" discussion, please...
>
Thanks for the translation ;) Then I can answer Thorsten: No, that
wasn't my argument. I firmly believe that XML would be a poor choice
given the goals pursued by POVRay. As I explained, XML was designed
to be an exchange format between different softwares. As such, it is
intended to be generated by a computer program, not hand-typed. This
is quite incompatible with the idea that POVray scenes are primarily
written by hand.
XML has its uses, but replacing the POV SDL most emphatically is
*not* one of them.
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)
iD8DBQFG5Ym2d0kWM4JG3k8RAoMbAJ4uiJyqloRfW8XK/Q6RYujbrG6Z+QCfcZ1v
z5Y1l4iHGh+ZDix1dzDWT4g=
=3Fwk
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> John VanSickle wrote:
>
>>What help with re-licensing do you need from those of us who have made
>>code contributions?
>
>
> If we can clearly identify your contribution, and it is stand-alone, then
> an assignment form stating it's released under the GPL3 would be needed.
>
> Apart from that, help in re-coding the existing code would be great ;]
No problem, as long as I can find the time.
By the way, I have been reading the stuff Pixar has at
http://graphics.pixar.com , and some of it suggests improvements in the
way that POV-Ray handles various kinds of anti-aliasing. How open will
the project be to changes of this nature?
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
> By the way, I have been reading the stuff Pixar has at
> http://graphics.pixar.com , and some of it suggests improvements in the
> way that POV-Ray handles various kinds of anti-aliasing. How open will
> the project be to changes of this nature?
Once the port is done and we have something stable, I'm entirely open to
playing with new ideas. We may have a 'stable' and 'testing' tree for
playing around with new ideas (with binaries released from each; probably
the testing tree would get a nightly automatic build or something).
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> I have had a look at a few embeddable languages, such as AngelCode (see
> http://www.angelcode.com/angelscript/) but haven't come to any solid
> conclusion yet.
I'm going to make a radical proposal for you to think over.
As POVRay's SDL has evolved over the years, it's become more and more
like a programming language. I think it's worth considering pushing it
into a real programming language.
These days, I do most of my work in Smalltalk. It's one of the simplest
yet most powerful programming languages around. Building a Smalltalk
compiler/interpreter is not terribly hard (I've done it before) and if
you wish, there are commercial systems (and freeware systems) which you
can already use. The commercial system have "free for non-commercial"
licenses.
A few years ago, I built a simple little raytracer in Smalltalk to see
what it would be like. Here's what the scene description code looks
like in this system (The code below is extracted directly from that
reaytracer and it renders an actual image.):
"This method renders a scene and displays it in a window"
view
self show: self renderImage
"This method renders the image"
renderImage
^(self camera)
imageSize: 640 , 480;
render: self scene
"Here is the definition of the camera"
camera
^(Camera new)
location: 0 , 2 , -10;
direction: 0 , 0 , 1;
up: 0 , 1 , 0;
right: 1.333 , 0 , 0
"And here is the scene"
scene
^(Scene new)
lightSource: self lightSource;
shape: self floor;
shape: self sphere1;
shape: self sphere2
"The definition of the light source"
lightSource
^(LightSource new)
location: 10 , 20 , -20;
color: Vector white
"Here's the floor"
floor
^(Plane new)
normal: 0 , 1 , 0;
offset: 1;
texture: self floorTexture
"We need the floorTexture"
floorTexture
^(TextureWithFinish new)
pigment: self checkerBoardPigment;
finish: self reflectingFloorFinish
"And the checkerBoardPigment"
checkerBoardPigment
^(CheckerBoardPigment new)
center: 0 , 0.1 , 0;
color1: Vector green;
color2: Vector white;
squareSize: 1
"The reflectingFloorFinish makes it reflect"
reflectingFloorFinish
^(CompoundFinish new)
finish: self floorFinish;
finish: self fullReflectionFinish
I'll leave it at that for now.
By doing this, you can make libraries of textures, shapes, finishes,
light sources, etc. which can be reused. The definition of an entire
scene could exist in one class and could re-use common textures, shapes,
etc. You have the full power of Smalltalk to build the shapes including
loops, conditions, random numbers, importing data from files, writing
out files, etc. You also have the full power of the development
environment when running including inspecting your scenes and debugging
the rendering.
I know this is coming from left field, but it's good to think about some
radical ideas every once in a while to really inspire innovation.
Discussion is welcome.
David Buck
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Buck wrote:
> Chris Cason wrote:
>> I have had a look at a few embeddable languages, such as AngelCode (see
>> http://www.angelcode.com/angelscript/) but haven't come to any solid
>> conclusion yet.
>
> I'm going to make a radical proposal for you to think over.
>
> As POVRay's SDL has evolved over the years, it's become more and more
> like a programming language. I think it's worth considering pushing it
> into a real programming language.
>
> These days, I do most of my work in Smalltalk. It's one of the simplest
> yet most powerful programming languages around. Building a Smalltalk
> compiler/interpreter is not terribly hard (I've done it before) and if
> you wish, there are commercial systems (and freeware systems) which you
> can already use. The commercial system have "free for non-commercial"
> licenses.
>
> A few years ago, I built a simple little raytracer in Smalltalk to see
> what it would be like. Here's what the scene description code looks
> like in this system (The code below is extracted directly from that
> reaytracer and it renders an actual image.):
>
> "This method renders a scene and displays it in a window"
> view
> self show: self renderImage
>
[snip rest of smalltalk code]
>
> I'll leave it at that for now.
>
> By doing this, you can make libraries of textures, shapes, finishes,
> light sources, etc. which can be reused. The definition of an entire
> scene could exist in one class and could re-use common textures, shapes,
> etc. You have the full power of Smalltalk to build the shapes including
> loops, conditions, random numbers, importing data from files, writing
> out files, etc. You also have the full power of the development
> environment when running including inspecting your scenes and debugging
> the rendering.
>
> I know this is coming from left field, but it's good to think about some
> radical ideas every once in a while to really inspire innovation.
>
> Discussion is welcome.
>
Is there any reason why your smalltalk could not automagically output
SDL and renderImage be implemented as a system call to POV?
Because that is basically the way I use it in matlab, and want to
continue to do so in POV 4.0
My suggestion for a 'new' language would be to have an as simple as
possible language (without loops and control structures) that is easy to
parse for a machine but not necessarily for a human. Plus an easy way to
integrate that with a front end, one of those should be a pov 3.6 style
language. Or perhaps as the only front end, because if everybody can
make his own language we may not be able to share our sources.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> David Buck wrote:
>> Chris Cason wrote:
>>> I have had a look at a few embeddable languages, such as AngelCode (see
>>> http://www.angelcode.com/angelscript/) but haven't come to any solid
>>> conclusion yet.
>>
>> I'm going to make a radical proposal for you to think over.
>>
>> As POVRay's SDL has evolved over the years, it's become more and more
>> like a programming language. I think it's worth considering pushing
>> it into a real programming language.
>>
> Is there any reason why your smalltalk could not automagically output
> SDL and renderImage be implemented as a system call to POV?
> Because that is basically the way I use it in matlab, and want to
> continue to do so in POV 4.0
>
> My suggestion for a 'new' language would be to have an as simple as
> possible language (without loops and control structures) that is easy to
> parse for a machine but not necessarily for a human. Plus an easy way to
> integrate that with a front end, one of those should be a pov 3.6 style
> language. Or perhaps as the only front end, because if everybody can
> make his own language we may not be able to share our sources.
>
There's no reason why we couldn't do that. The advantage we get from
the Smalltalk side, though, is being able to procedurally define new
shaders right within the SDL. With this scheme, if I wanted a variation
of Marble, I could code it in Smalltalk and have it called as needed
from the renderer. With the existing structure of POVRay, you'd have to
modify the C source and enhance the SDL accordingly in order to create a
new shader - way too much work.
David Buck
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Buck <dav### [at] simberoncom> wrote:
> These days, I do most of my work in Smalltalk. It's one of the simplest
> yet most powerful programming languages around. Building a Smalltalk
> compiler/interpreter is not terribly hard (I've done it before) and if
> you wish, there are commercial systems (and freeware systems) which you
> can already use.
While a new SDL should definitely have strong tools for abstraction
(object-orientedness being one good choice for this), it should still
retain the simple procedural approach of the current SDL. Procedural
programming is the easiest to learn quickly.
As I see it, there are two possibilities:
1) Design a scripting language fine-tuned from the ground up for use
with POV-Ray.
2) If an existing language is used instead, it makes no sense to have to
write a parser for it, but it would be a much better idea to use an
existing parser (and bytecode interpreter VM) which has been specifically
designed to be integrated in C++ programs (such as lua or angelscript).
As I see it, it makes little sense to use an existing language which
has not been designed for POV-Ray and which has not been designed for
integration with C++. It will simply cause more problems than it's worth.
If the language lacks an easily-approachable procedural programming paradigm,
all the worse. (With this I don't mean that the language should not have
OOP support.)
> The commercial system have "free for non-commercial"
> licenses.
Yet I believe POV-Ray 4.0 is still planned to be free to use even for
commercial purposes.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
