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

Ugh, I don't even want to think about using 64 subpatches for creating the
mesh!  That's 4X the size of the largest mesh I used.  I would think that could
be very painful in terms of parsing and memory.

I'm going to move this topic over to programming, since there's some other
things I've been wanting to discuss about bicubic patches.

-Mike

Post a reply to this message

hehe, I remember one image I did... the entire thing was made with bicubics
(all 4x4 steps)... and there were LOTS of them :)

Take a look here if you want...
http://members.xoom.com/_XOOM/lancebirch/thezone/pov_rose.jpg

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://listen.to/colorblind
Nathan Kopp wrote in message <3782E64D.784138D6@Kopp.com>...
>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

> Take a look here if you want...
> http://members.xoom.com/_XOOM/lancebirch/thezone/pov_rose.jpg

nothing there but a rotating XOOM logo called tosviol.gif...


Uwe.

Post a reply to this message

Worked fine for me... I notice that Netscape doesn't like you to click on
the address if you did it that way... you may have to copy-paste it in.

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://listen.to/colorblind
Uwe Zimmermann wrote in message <378344AF.732B83F7@ele.kth.se>...
>> Take a look here if you want...
>> http://members.xoom.com/_XOOM/lancebirch/thezone/pov_rose.jpg
>
>nothing there but a rotating XOOM logo called tosviol.gif...
>
>
>Uwe.

Post a reply to this message