My current IRTC project has several characters made from unions of bezier
patches.  I used a utility to convert the beziers to meshes, thereby saving
about 4.5 megs or RAM for each character.  However, since POV-Ray converts
bicubic patches into smoothed triangles internally, it should be a simple matter
to include them in a mesh, and gain the memory-saving benefits of the latter.

The syntax would look something like this:

#declare HipBone = mesh {
  bicubic_patch { type 1 u_steps 3 v_steps 3
    P0,P1,P2,P3,
    P4,P5,P6,P7,
    P8,P9,PA,PB,
    PC,PD,PE,PF
  }
  bicubic_patch { type 1 u_steps 3 v_steps 3
   // more points here
  }

  // ten or more bicubic_patch objects here

}

And then the object HipBone could be used to build the thousand-man
skeleton army, without sending the memory usage through the roof,
as would be the case if HipBone were a union instead of a mesh.

POV Patch gurus:  Does this sound as easy to you as it does to me?

Comments?

Post a reply to this message

John VanSickle wrote:
> 
> My current IRTC project has several characters made from unions of bezier
> patches.  I used a utility to convert the beziers to meshes, thereby saving
> about 4.5 megs or RAM for each character.  However, since POV-Ray converts
> bicubic patches into smoothed triangles internally, it should be a simple matter
> to include them in a mesh, and gain the memory-saving benefits of the latter.
snip
> And then the object HipBone could be used to build the thousand-man
> skeleton army, without sending the memory usage through the roof,
> as would be the case if HipBone were a union instead of a mesh.
> 
> POV Patch gurus:  Does this sound as easy to you as it does to me?
> 
> Comments?

   I am curious as to whether it is already implemented internally. The
reason I say this is I have done a lot of experimenting with multiple
copies of the same height field which too is simply an internally generated
mesh of triangles. The memory requirements for multiple HF's seems minor
compared to the use of say multiple copies of a union of triangles leading
me to believe HF objects already have the benefit of the advanced memory
caching scheme used in the mesh object.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Have you tried the type 2 bicubic patch in the superpatch?  It only stores the
bicubic patch vertices and the tests I've done show it to be faster than converting
to triangles.  Just a thought.

I agree that a patch_mesh might be a good feature.

-Mike

Post a reply to this message

Ken: please stop answering before others have finished asking.
It is not polite.

Margus

Post a reply to this message

Margus Ramst wrote:
> 
> Ken: please stop answering before others have finished asking.
> It is not polite.
> 
> Margus
I'm sorry :(
-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

An interesting idea.  Another solution to the problem would be to have
multiple copies of the same patch reference a single copy (which is what
the triangle mesh object does).  Of course, this would necessitate an extra
inverse transformation for each ray intersection, since individual
transformations couldn't be applied directly to the control points, as is
done currently.

Anyone know if the render speed of a bicubic patch (type 1) is faster or
slower than a mesh?

-Nathan

John VanSickle wrote:
> 
> My current IRTC project has several characters made from unions of bezier
> patches.  I used a utility to convert the beziers to meshes, thereby saving
> about 4.5 megs or RAM for each character.  However, since POV-Ray converts
> bicubic patches into smoothed triangles internally, it should be a simple matter
> to include them in a mesh, and gain the memory-saving benefits of the latter.
> 
> The syntax would look something like this:
> 
> #declare HipBone = mesh {
>   bicubic_patch { type 1 u_steps 3 v_steps 3
>     P0,P1,P2,P3,
>     P4,P5,P6,P7,
>     P8,P9,PA,PB,
>     PC,PD,PE,PF
>   }
>   bicubic_patch { type 1 u_steps 3 v_steps 3
>    // more points here
>   }
> 
>   // ten or more bicubic_patch objects here
> 
> }
> 
> And then the object HipBone could be used to build the thousand-man
> skeleton army, without sending the memory usage through the roof,
> as would be the case if HipBone were a union instead of a mesh.
> 
> POV Patch gurus:  Does this sound as easy to you as it does to me?
> 
> Comments?

Post a reply to this message

> Anyone know if the render speed of a bicubic patch (type 1) is faster or
> slower than a mesh?

Provided the mesh has the same subdivision as the patch will produce based on u and v
steps, the render time will be the same minus the time it takes the bicubic patch to
parse.

-Mike

Post a reply to this message

Not necessarily.  The bicubic patch doesn't convert directly into a mesh
object.  The mesh object uses a slightly different bounding box tree to
subdivide the mesh for fast intersections.  Because of the nature of
the triangles created by a bicubic patch, it is very easy to subdivide
them into a bounding-sphere tree (a quad-tree) for quick access.  Therefore
render time might actually be faster for the bicubic patch than for a
general triangle mesh.

-Nathan

Mike wrote:
> 
> > Anyone know if the render speed of a bicubic patch (type 1) is faster or
> > slower than a mesh?
> 
> Provided the mesh has the same subdivision as the patch will produce based on u and
v
> steps, the render time will be the same minus the time it takes the bicubic patch to
> parse.
> 
> -Mike

Post a reply to this message

I thought I'd run some tests to see how they differ.  Interesting thing I found - if
the
patches are inside a union, povray seems to default to type 1 bicubic patches even if
type
0 is specified.  The results I got were exactly the same for the two in that
situation.
Also worth noting is that both the parse and render times were shorter when a union
was
used.

I had to make the mesh files with xroads to convert dxf to pov.  I matched everything
just
like the patch versions.  I noticed the meshes using 4 polygons per patch were light
on
memory, then it occured to me that 4 u and v steps should be 16 polygons per patch.  I
think that's right.  I just included a smooth triangles version of that.  I don't even
have
time to sort through all this.  I hope this is useful to someone. :)

rabbit.pov

All at 800x600, AA 0.3

type 0 or 1 bicubic patches inside a union
u_steps 4 v_steps 4

Time For Parse: 12 seconds
Time For Trace: 37 seconds
Total Time: 49 seconds
Peak memory used: 67,108,949 bytes

type 0 bicubic patches
u_steps 4 v_steps 4

Time For Parse: 9 seconds
Time For Trace: 7 minutes 32 seconds
Total Time: 7 minutes 41 seconds seconds
Peak memory used: 35,724,760 bytes

type 1 bicubic patches
u_steps 4 v_steps 4

Time For Parse: 35 seconds
Time For Trace: 46 seconds
Total Time: 1 minute 21 seconds
Peak memory used: 181,006,624 bytes

type 2 bicubic patches (superpatch)
accuracy .01

Time For Parse: 9 seconds
Time For Trace: 38 seconds
Total Time: 47 seconds
Peak memory used: 37,254,497 bytes

Mesh using 4 polys per patch, plain triangles

Time For Parse: 4 seconds
Time For Trace: 22 seconds
Total Time: 26 seconds
Peak memory used: 3,783,826 bytes

Mesh using 4 polys per patch, smooth triangles

Time For Parse: 7 seconds
Time For Trace: 17 seconds
Total Time: 24 seconds
Peak memory used: 4,193,854 bytes

Mesh using 16 polys per patch, smooth triangles

Time For Parse: 31 seconds
Time For Trace: 19 seconds
Total Time: 50 seconds
Peak memory used: 15,950,598 bytes

Post a reply to this message

Interesting results!

I like the nice combination of memory/trace time for the superpatch type 2
bicubic patch.  Who would ever want type 0 again?  (What an awful trace
time.)  I think you should increase the triangles-per-patch, however.
From the POV-Ray Docs:

This means that you really should keep u_steps and v_steps under 4. Most
patches look just fine with u_steps 3 and v_steps 3, which translates to 64
subpatches (128 smooth triangles).

(pieces = 2^u_steps * 2^v_steps)

That means 512 smooth triangles for u_steps 4 and v_steps 4.

Doing this will hurt the parse time for the mesh, but shouldn't affect the
trace time.  On the other hand, if you output to a 'mesh2' (part of the 
superpatch), you should be able to speed up the parse time for the mesh.

-Nathan

Post a reply to this message