Le_Forgeron <jgr### [at] freefr> wrote:

>
> there is bicubic_patch.
>
> http://povray.org/documentation/view/3.6.1/64/
> http://wiki.povray.org/content/Reference:Bicubic_Patch
> http://www.povray.org/documentation/view/3.6.1/290/
>
> It's a Bezier patch.
>
> > Badly. It strongly limits possibilities of data transmission from
> > the Blender to Povray.
>
> Most nurbs rendering transforms them in mesh anyway. (I recommend
> mesh2 format for them).
>
> It's not a concept (to refuse nurbs), it's just that solving the
> intersection of a ray with a nurbs is not something that can be easily
> solved mathematically (I would say: at once, without iterations or
> approximation).
>
> Now, if you can solve it (a nurbs, a ray, return the list of
> intersection points) (as well as "a nurbs, a 3D point, return a
> boolean for the point being inside the volume delimited by the nurbs),
> without generating a mesh under the cover, it can be considered for
> addition.
>
> But beware, even bicubic_patch has a cheating method (type 1), as
> solving pure (type 0) bezier is slow. (but memory effective)
>


Sorry!
No,no!
Before export I can convert all models in mesh.
No problem.
Problem with Constructive Solid Geometry
Not with all converted objects the blender correctly considers boolean.
Your(Povray) algorithms it is better!
Perhaps, it is connected with use by the Blender of quads.(Povray use tris)

And use while - problem.
I could set a cycle:
//Array =
//while (I < %s)
//translate Array%s[I]
but is compelled to calculate:
object {One translate<x1,y1,z1>}
...............................
object {Thousand  translate<x1000,y1000,z1000>}

And, for whom it is now easy? :):):)

The best wishes!

Post a reply to this message