Or at least, things that haven’t worked yet. As a more concrete follow up to yesterday’s post, these are a few things I’ve spent time on recently and that I don’t have much expectation of being ready any time soon.
Small Polygon Reconnection (SPR)
I’ve discussed SPR a couple times before. Essentially it is a way of improving local connectivity to reduce the number of irregular vertices in a quad mesh.
Although the basic SPR algorithm is simple enough, getting it to work quickly enough to be practical is quite challenging. There is a huge space of possibilities to search, so it needs aggressive pruning to get the times down. I wasn’t able to find a solution that gave both good and quick results.
My primary interest in SPR was to improve the output of the remesh modifier. Consider this example:
The remesh modifier often gives results like those on the left with curves surfaces. The mesh at right was hand-edited to encourage a more regular grid. In theory SPR should be able to do this, but given its speed problems a better solution might be to hard-code fixes for some common patterns in remesh’s output. Even a simple collapose on the diamond pattern that shows up a lot could be very helpful.
Projection Quad Coverage (PQC)
After I decided that SPR wasn’t going to work, I spent some time on an alternative idea called Projection Quad Coverage. This experiment was a bit of a departure for me because it wasn’t based on any particular research paper (although the general concept of parameterization has been well studied). Of course, it wouldn’t surprise me much if their is a paper describing this idea, but I have not found one — so I just came up with a nice TLA (three-letter acronym) and carried on.
The basic algorithm for PQC is:
- Partition the mesh’s polygons into groups (called charts in this context) such that the chart is connected (i.e. not a collection of islands), and all polygons’ normals are within X degrees of some common vector.
- For each chart, project its component vertices onto the plane whose normal is the chart’s “common vector” mentioned earlier.
- Overlay a 2D quadrilateral grid onto that plane, with grid squares having some user-defined side length.
- Assign Z values to each grid vertex by finding the mesh polygon that vertex lies within, and interpolating between the mesh polygon’s projected coordinates. If a grid vertex does not lie within a mesh polygon (note that this a 2D test), just mark the vertex.
- For each grid square, test if its vertices are unmarked (i.e. have valid Z coordinates). If so, unproject the grid square’s corners back into the mesh’s 3D coordinate space and add the square as a quadrilateral in the output mesh.
- Connect the boundary edges of charts to adjacent charts.
I’ve glossed over some things in that description… where the common vector comes from, how to efficiently calculate the grid projection, etc. The real trick though is my incredibly unspecific step six. The rest I got working pretty well, and that’s what is shown in the screenshot below. Note how large contiguous sections of the remeshed Suzanne have really nice regular quad distribution, with precisely zero irregular vertices (other than the borders).
Filling in those cracks between charts turns out to be quite hard. A couple “obvious” approaches are apparent: merging close boundary vertices or filling in the cracks with new quads and triangles. The devil is of course in the details though, and I didn’t find a good way to implement either of these high-level ideas. Unfortunately I only have that one screenshot of PQC handy, or I’d demonstrate better the issues that came up.
I had one more involved concept for filling cracks: build an edge network between all adjacent charts using the same projection/division/interpolation approach. When remeshing each chart, it could then greedily fill in quads between the chart edge and the global edge network (though using just those portions of the edge net that it borders). I still think this idea could work, but at that point I’d already spent a week or more on PQC and felt it was time to get back to more “practical” projects.
Unlimited clay’s concepts for dynamic topology
I noted recently that I would be looking into Farthary’s unlimited clay paper to see if it could be used for the dynamic topology project. Unfortunately, the paper is not quite detailed enough for me to reproduce his results. I had to make some guesses about the intended implementation, and quite likely I got some things wrong. I should note also that I probably need to code up a better version of local mesh relaxation to really test his algorithm properly.
On a more positive note, most of the work needed for dynamic topology sculpting is fairly generic. If I get it working well, and if at some future point Farsthary regains Internet access and is still interested in working on Blender, it should be much easier for him to work on this code. Recall that his original attempt at putting unlimited clay into Blender was pre-BMesh, so it used a somewhat slow hack for integrating EditMesh into the PBVH. That whole issue is now nicely avoidable.
So that’s three recent examples of things that haven’t worked yet. There are others, for example I’ve experimented a bit with getting MyPaint brushes in Blender, but not much of interest to say there. For now I will continue to focus on dynamic topology and the related BMesh-undo project, as well as some general bug fixing for 2.64.
10 thoughts on “Things that didn’t work”
+1 ,my paint brushes in Blender! :)
But why? MyPaint engine is good for… MyPaint, but it even doesn’t have Opacity option. It’s calling the Flow parameter as Opacity, but this is serious limitation…
omg, soooo cool :D
are there any news about ptex?
My understanding is that the ptex work is largely done. However, without a renderer that supports ptex files or the ability to bake ptex data to uv maps, ptex is on hold.
I am not aware of anyone planning to or actively adding ptex support to BI or Cycles.
Thanks you for all the hard work !
This kind of post is really appreciated.
Your PQC technique strongly reminds me of Geometry Images, which are completely regular. There are several interesting papers on generating them from (sometimes restricted) source meshes. Perhaps useful to you, the original Geometry Image paper includes some details on finding good topological ‘cuts’ of the original mesh and reconnecting these cuts properly in rendering the generated geometry image.
See http://research.microsoft.com/en-us/um/people/hoppe/gim.pdf for starters; there’s more out there. In particular, http://research.microsoft.com/en-us/um/people/hoppe/mcgim.pdf would seem (from it’s abstract) to directly address your chart-stitching process.
Thanks Jim. I was aware of the Geometry Images paper, but had not seen the Multi-Chart Geometry Images paper. Its section on zippering indeed looks quite relevant.