| 
|  |  |  
|  |  |  |  |  |  |  |  |  |  |  
|  |  |  |  |  |  |  |  |  |  |  
|  |  | "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
 |  |  |  |  |  |  |  |  
|  |  |  |  |  |  |  |  |  |