Adding Bezier patch for geometric smoothing

[paco]

I've been working on geometric smoothing for a while now as a way to overcome terminator artefact (viewtopic.php?f=8&t=5211) and have come up with a method that works - basically convert the mesh element (tri OR quad) to a bezier patch for rendering. Below are some examples with the input mesh at the top and the resulting surface below. It also takes a smoothing parameter - the effect of which is illustrated on a slab.

My plan was to implement a BezierTriangle and BezierQuad class as geometric primitives and during the pre-rendering phase convert the input mesh to the appropriate bezier patch. From an exporter point of you would simple attach a "geometric smoothing" bool to the mesh and a smoothing parameter and lux would do the rest.

The benefit (vs subdivision) is that it should be a lot less memory intensive, and produce a surface that is physically accurate - so no terminator or polygon artefact. The downside is the speed.

Anyway, before I get working on the code I wanted to open it up for comments/suggestions.

[Dade]

Are you writing a "true" BezierTriangle/BezierQuad primitive (i.e. something that can be directly ray intersected) ? Or BezierTriangle/BezierQuad are than tessellated back to a triangle mesh ?

P.S. you will loose any GPU acceleration benefit from a "true" BezierTriangle/BezierQuad primitive.

[paco]

It is a true primitive. The intersection routine I've tested is basically a recursive bound/subdivision scheme down to a set accuracy.

Regarding GPU acceleration - I'm not familiar with the GPU code so not sure how much you can do regarding intersections there. It would be nice to make it GPU compatible.

You're the expert though Dade - is it possible in theory? I'm happy to work on that part of it at some point.

[paco]

Another test (thanks to Inlite for the model):

[jeanphi]

Hi,

It would be nice to integrate that with microdisplacement. Nice results, but what about the speed hit?

Jeanphi

[paco]

The problem with microdisplacement is that you have to choose the level of subdivision whereas I wanted to create something that was perfectly smooth.

Not sure what the speed hit will be. The recursive subdivision seems to converge quite quickly, but no doubt there are more efficient algorithms. I'd be hoping for it to be slightly faster than MD (?currently 2-3x slower than tessellation). Hopefully reducing the number of triangles by a factor of 10-100 will also help speed things up.

My current approach guarantees a G0 surface and approaches a G1 surface - with the error in the latter dependent upon how divergent the mesh normals are. There is scope to make that C1( and C2...) rather than G1 but might work on that later. The original mesh vertices are preserved - ie the new smooth surface passes through all the original mesh points.

An added benefit is that quads could be treated as quads, rather than triangulated which can introduce artefacts.

Also, I wasn't planning to expose the bezier primitive to the scene file - ie, not planning to import bezier control points, but rather import a mesh and then convert that to a bezier. The bezier class will be a standalone primitive though so if anyone was keen it should be easy to implement later.

[Dade]

Regarding GPU acceleration - I'm not familiar with the GPU code so not sure how much you can do regarding intersections there. It would be nice to make it GPU compatible.

You're the expert though Dade - is it possible in theory? I'm happy to work on that part of it at some point.

It would be possible (indeed, the recursive algorithm would have to be converted to iterative). I was just wondering if you were using the "Refine" mechanic and ending with a triangle mesh anyway or just a native ray intersection approach.

[syndaryl]

cube_mvalues.jpg

The way your cube starts bulging out is interesting. It reminds me of the results of the Poser "smoothing" parameter, which has always mystified me as to what was going on under-the-hood, and now you provide me with something to think about.

Can you test something for me? A long cylinder with no edge loops along the length - just one loop for each end. In poser, this develops a very distinct and really quite alarming bulge, making it very difficult to smooth things like pencils, flag poles, bars, etc. I suspect this approach will have the same issue.

[paco]

syndaryl:

I did indeed try a cylinder primitive with 5 verts for the circles at each end - and it does bulge out and look very odd indeed. One way around that is to place a second loop of verts just before the end - that should at least help with the shaft of the pencil. Won't change the buldging at the caps - you may need to bevel that slightly to get around it.

Alternatively you could just make it a hollow cylinder with no end faces and that should work just fine. When i get a working lux version up i'll have a look and see.

[jeanphi]

Hi,

I really think we should rearchitect the mesh storage and handling. The current scheme doesn't really work with subdivision or bezier patches. There are lots of papers on efficient mesh handling, there are also lots of OpenSource 3D applications with efficient data handling, maybe someone should have a look at it and come up with a proper scheme to handle meshes with triangles, quads, bezier patches, subdivided or not, deformable, with multiple UV sets, ...
It's not mandatory, it just looks like a nice point in time to have a look at it. It might be better to do it after the integration of the bezier patches so that we have a better view of what will be needed.

Jeanphi