Btw, here are some images showing the current look of all kind of 
patches (3,4,5- point and hooks) in JPatch:

http://jpatch.sourceforge.net/?page=next

There are some minor discontinuity problems with 5-point patches, but 
you won't notice them unless the surface has sharp highlights or is 
reflective - normal matte or diffuse surfaces look quite smooth...

-sascha


sascha wrote:
> You're right and I'm aware of this problem. I've taken two different 
> approaches to this problem for the next version of JPatch:
> 
> 1)
> Subdivide a 3-sided patch into 3 4-sided patches (like 5-sided patches 
> will be subdivided into 5 4-sided patches). The new patches are formed by:
> 
> * computing the center of the patch.
> * deCasteljau'ing the edges
> * Connecting the center with the mid-points of each edge
> 
> This works more or less for 5-point patches (I still have some minor 
> discontinuity problems, I think this is because the 5-point-patch is 
> somehow "overconstrained" and it's not clear to me how to exactly 
> compute the center-point - suggestions are appreciated :-)
> This works too for 3-point patches which connect only to 4-point patches 
> but causes hughe problems when two 3-point patches meet.
> 
> 2)
> sPatch places two corner-points (and their tangents) at the same 
> position - this of course makes it impossible to calculate the surface 
> normal of this corner - when triangulizing the patch two triangles will 
> have bad normals resulting in visible artifacts (REYES is more robust 
> because it will subdivide until the triangles are smaller than a pixel, 
> but POV has problems when the u/v_steps setting is too low).
> I tried to place this two corner points not on the same point but move 
> one slightly away - this seems to work well (no more discontinuities or 
> artifacts), but I'm not sure if it will make troubles with U/V mapping - 
> I haven't implemented u/v mapping yet so I have to try it later...
> 
> Your approach with triangulizing natively and exporting the 
> triangle-mesh is an option too - if you've got an implementation let me 
> know, I can easily integrate it into JPatch...
> 
> I'll do some tests with bezier-triangles too, but these will also have 
> to be exported as triangle-meshes...
> 
> -sascha
> 
> Breton Slivka wrote:
> 
>> Most of us are aware of the phenomenon when it comes to bezier 
>> patches, and programs like spatch, which produce 3 point patches.
>>
>> That is, they always have a wrinkle in one corner, because it's 
>> actually two corners scrunched together.
>>
>> Well, The situation need not be the case!
>>
>> As I understand, internally, bezier patches are converted by triangles 
>> by simply taking grid UV samples from the bicubic patch function.
>>
>> suppose, the UV samples were altered, so that instead of taking a 13 
>> by 13 grid of samples, or 17 by 17 grid of samples as is the case now, 
>> the algorithem could detect when two points touch, and if that is the 
>> case, start at the edge where the two points touch, For example, if 
>> edge*1 is actually a point, start with one sample in V=0.5 when U=0, 
>> then two samples at V=0 and V=1 when U=1/16, then 3 samples at V=0,0.5 
>> and 1 when U=2/16 etc.... until U=16..
>>
>> In the case of a 3 point patch, this should result in no wrinkles, as 
>> in this diagram I've prepared http://zenpsycho.com/wrinkle.gif
>>
>> Perhaps this could either be implemented as a patch in povray itself, 
>> or as a feature of Jpatch, the promising new patch modeller written in 
>> java, 3 point patches could simply be exported as a triangle mesh, 
>> using my UV sampling scheme.
>> Discontinuities at the edges shouldn't be more of a problem than 
>> usual, since each edge will have the same amount of samples as 
>> connecting 4 point patches.
>> I'd try and implement this stuff myself, but I'm afraid I'm not smart 
>> enough or have the time, but I figured that there should be a solution 
>> to this problem that I should share.
>> anyways, thoughts? questions?
> 
>

Post a reply to this message