 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Shay" <Sha### [at] cc cc> 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] free fr> 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] free fr | ICQ: 238062172 |
| http://jeberger.free.fr/ | Jabber: jeb### [at] jabber fr |
+---------------------------------+------------------------------+
-----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] tag povray org> 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] 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...
>
> 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] free fr | ICQ: 238062172 |
| http://jeberger.free.fr/ | Jabber: jeb### [at] jabber fr |
+---------------------------------+------------------------------+
-----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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
> - 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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |