 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Maybe some people will consider this OT, but I think it fits better here
then anywhere else.
Is there any progress concerning Moray? Is it RIP or WIP?
Regards
Arne
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Arne Kleinophorst" <kle### [at] spam debitelnet> a écrit dans le message
de news: 46de836a$1@news.povray.org...
> Maybe some people will consider this OT, but I think it fits better here
> then anywhere else.
There is Moray.win :-)
>
> Is there any progress concerning Moray? Is it RIP or WIP?
I'm asking the same question.
There is a big potential in Moray, even more if it is better oriented on POV
features (handedness please!, better path management and above all better
comunication with last versions of POV)
Shall I go farther in my wish list?
Marc
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
M_a_r_c schrieb:
> "Arne Kleinophorst" <kle### [at] spamdebitelnet> a écrit dans le message
> de news: 46de836a$1@news.povray.org...
>> Maybe some people will consider this OT, but I think it fits better here
>> then anywhere else.
> There is Moray.win :-)
I know that but I'm asking the Povray-part since they took over :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Arne Kleinophorst" <kle### [at] spamdebitelnet> schreef in bericht
news:46de8fd2$1@news.povray.org...
> M_a_r_c schrieb:
>> "Arne Kleinophorst" <kle### [at] spamdebitelnet> a écrit dans le
>> message de news: 46de836a$1@news.povray.org...
>>> Maybe some people will consider this OT, but I think it fits better here
>>> then anywhere else.
>> There is Moray.win :-)
>
> I know that but I'm asking the Povray-part since they took over :)
I suppose Real Life has got in the way.... :-(
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Arne Kleinophorst wrote:
> Maybe some people will consider this OT, but I think it fits better here
> then anywhere else.
>
> Is there any progress concerning Moray? Is it RIP or WIP?
>
> Regards
> Arne
I add my voice to Arne's... any news, Pov Team?
--
Stefan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Arne Kleinophorst wrote:
> Maybe some people will consider this OT, but I think it fits better here
> then anywhere else.
>
> Is there any progress concerning Moray? Is it RIP or WIP?
Dead, I think yes. Officially dead? ???
Entire ray-tracers have been written since the release of POV 3.6.
We've been talking about POV 4.0 since 1999!
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 05 Sep 2007 14:29:25 +0200, Thomas de Groot wrote:
> "Arne Kleinophorst" <kle### [at] spamdebitelnet> schreef in bericht
> news:46de8fd2$1@news.povray.org...
>> M_a_r_c schrieb:
>>> "Arne Kleinophorst" <kle### [at] spamdebitelnet> a écrit dans le
>>> message de news: 46de836a$1@news.povray.org...
>>>> Maybe some people will consider this OT, but I think it fits better
>>>> here then anywhere else.
>>> There is Moray.win :-)
>>
>> I know that but I'm asking the Povray-part since they took over :)
>
>
> I suppose Real Life has got in the way.... :-(
Or POVray 3.7 - which I think was indicated when the ownership transfer
took place - that more work on Moray would be post-3.7.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot wrote:
> "Arne Kleinophorst" <kle### [at] spamdebitelnet> schreef in bericht
> news:46de8fd2$1@news.povray.org...
>> M_a_r_c schrieb:
>>> "Arne Kleinophorst" <kle### [at] spamdebitelnet> a écrit dans le
>>> message de news: 46de836a$1@news.povray.org...
>>>> Maybe some people will consider this OT, but I think it fits better here
>>>> then anywhere else.
>>> There is Moray.win :-)
>> I know that but I'm asking the Povray-part since they took over :)
>
>
> I suppose Real Life has got in the way.... :-(
That and other things ... I will see if I can move things along a little,
partly my fault as I've been snowed under with other stuff.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay wrote:
> Arne Kleinophorst wrote:
>> Maybe some people will consider this OT, but I think it fits better here
>> then anywhere else.
>>
>> Is there any progress concerning Moray? Is it RIP or WIP?
>
> Dead, I think yes. Officially dead? ???
>
> Entire ray-tracers have been written since the release of POV 3.6.
>
> We've been talking about POV 4.0 since 1999!
I wasn't aware that frequency of releases had become a software quality metric.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Shay wrote:
> > Arne Kleinophorst wrote:
> >> Maybe some people will consider this OT, but I think it fits better here
> >> then anywhere else.
> >>
> >> Is there any progress concerning Moray? Is it RIP or WIP?
> >
> > Dead, I think yes. Officially dead? ???
> >
> > Entire ray-tracers have been written since the release of POV 3.6.
> >
> > We've been talking about POV 4.0 since 1999!
>
> I wasn't aware that frequency of releases had become a software quality metric.
Well you live and learn :-)
In this ipod age if you don’t have “change” there are a lot of consultants
out of a job.
More seriously, it is a sign of the times.
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen nous apporta ses lumieres en ce 2007/09/06 04:12:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> Shay wrote:
>>> Arne Kleinophorst wrote:
>>>> Maybe some people will consider this OT, but I think it fits better here
>>>> then anywhere else.
>>>>
>>>> Is there any progress concerning Moray? Is it RIP or WIP?
>>> Dead, I think yes. Officially dead? ???
>>>
>>> Entire ray-tracers have been written since the release of POV 3.6.
>>>
>>> We've been talking about POV 4.0 since 1999!
>> I wasn't aware that frequency of releases had become a software quality metric.
>
> Well you live and learn :-)
> In this ipod age if you don’t have “change” there are a lot of consultants
> out of a job.
> More seriously, it is a sign of the times.
>
>
> Stephen
>
>
>
On the other hand, I have some programms that date back from 1995 and even
earlier that I still regularly use.
--
Alain
-------------------------------------------------
I can read your mind, and you should be ashamed of yourself.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
>
> I wasn't aware that frequency of releases had become a software quality metric.
>
It has not for me. I believe POV-Ray to be very high quality, which is
why I'm still here. I believe this even more after having recently been
forced[1] to use another renderer to get a descent image of a model I
had created.
I would describe POV-Ray as, "The DOCUMENTED free renderer without the
overly pedantic text interface."
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 love POV-Ray, but I feel like an IE user - the
problems the program does have[2] are GOING to be there for the
foreseeable future. Meanwhile, others are steadily marching towards
greater speed, integration with modelers, and other things about which I
don't care a lot, but others do.
-Shay
[1] By my own mistake or a bug in POV-Ray. I'm not 100% certain yet, but
I'm leaning towards bug. Pixie rendered the model without problems.
[2] ie "Pass by reference" bug.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Shay" <Sha### [at] cccc> wrote in message news:46e01141$1@news.povray.org...
> [1] By my own mistake or a bug in POV-Ray. I'm not 100% certain yet, but
> I'm leaning towards bug. Pixie rendered the model without problems.
>
> [2] ie "Pass by reference" bug.
that's a bug? I thought it was a feature. I recently discovered that
macro-arguments are passed by reference, and a whole new world of
possibilities unveiled itself!
(I have to stop using difficult words however, 'cause I don't know how to
spell "unveiled" :) and I'm not even sure it is a word)
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 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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 love POV-Ray, but I feel like an IE user - the
I share some frustration; the original developers of POV (i.e. ones who
were around in the 1.0 days) have mostly gotten somewhat older, married,
kids, mortgage, in other words 'real life'. So one by one they've become
inactive; I'm the only one left now.
In the process, we haven't picked up as many new developers as those who
have left. And our development model simply does not fit in with the way
things are done in most open software projects these days, which doesn't help.
Rather than change development model mid-stream, we have decided to make
the switch when we go to 4.0. That will have a more typical 'open' plan
with a public code repository and so forth (the exact details have not been
decided, but it will be along those lines).
As for the delay for 4.0, the main issue has really been finding a suitable
license. Up until recently there was no OSI-approved license that we found
to be suitable, and we were very disinclined to attempt to come up with a
new one and submit that for approval. So we decided to wait for the outcome
of the GPL3 process.
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.]
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.
Basically this means gutting much of the functionality. However the basic
infrastructure should survive since it has been extensively re-written for
3.7, and the new code can be re-licensed under the GPL3. This tree will at
least be able to compile and render a sphere-on-plane image, forming a
working framework for the following work.
We will then depend on public participation (along with our own efforts) to
re-implement the removed code using the 3.7 source as a reference.
Basically any code that we cannot bring across has to be re-written and
submitted under the GPL3 and later by the developer concerned.
While this is a big job, having the original source as a reference reduces
the difficulty. While it wouldn't be possible to copy the code, new code
with the same functionality can be written and, moreover, compared with the
original by feeding the same data through it, thus easing testing and
integration.
Of course we would also want to take the opportunity to clean up some older
parts of the code so I am not claiming it will be a 1:1 re-creation of 3.7;
I would expect significant changes in the parser for example, and there may
even be a version of the renderer that can be complied to a library with an
ABI and no parser (if we don't do it, someone else surely will).
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.
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> (I have to stop using difficult words however, 'cause I don't know how to
> spell "unveiled" :) and I'm not even sure it is a word)
Well, I reckon you do, and it is! :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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...
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
