 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> ?? 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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...
>> 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
|
|
| |
| |
|
|
|
|
| |
|
|
