OK, time for some updates. Based in part of some useful feedback on BlenderArtists, I’ve spent the past week experimenting with various approaches to the topological update step. I think it’s now getting much closer to what people want to see; in particular the subdivision is localized to the area directly around the brush.

Until now, the topological updates were based on the paper “Freestyle: Sculpting meshes with self-adaptive topology”. This paper assumes that the entire mesh will have a consistent detail size. Note that since the algorithm collapses short edges, you can lose detail if you change your brush to a coarser detail size.
In contrast, the approach I am using now is to only do edge splits. If you create very dense topology and then set a coarse detail size, the dense topology will remain and not be collapsed. To handle situations where you want to make the topology less dense, a separate simplify brush will be added. (I haven’t done that yet, but the code is largely already written.)
In order to get a good boundary between a dense portion of the mesh and larger polygons, I used a trick that Farsthary described in his unlimited clay research: identify nearby pole vertices (in this case, defined as having nine or more adjacent edges) and split the adjacent edges. This isolates the pole vertex and prevents it from distorting the mesh. This wasn’t an issue with edge collapses, which implicitly force triangles to be relatively regular, but in a subdivision-only approach it turns out this is a really critical step. Without it the mesh quickly develops degenerate triangles that can’t be smoothed away.
Some other changes: the topology update now occurs before each sculpt step, so the result should match the brush shape a bit better. The brush also avoids the accumulation problem now, so repeatedly brushing over an area won’t continually build the surface up (unless the brush accumulate option is on, of course.)
I’m still looking into surface relaxation; I suspect a smoother result can be achieved while still maintaining detail, but haven’t found a good way to do it yet. My current short-term goal is to do some brush work: add the reduce/simplify mentioned earlier and fix the guaranteed-crash brushes like grab.
As usual, the code is available from the dyntopo branch on Github.
Brilliant. I want a build :)
Yes, generally much better.
But in some instances (like terrain sculpting for the bge) You might actually want consistent detail size… So a possibility to choose between the algorithms would be nice (a checkbox for turning on ‘consistent detail size’).
You can pretty much achieve this by just setting a single detail size and sticking with it. You can also just stroke over the entire mesh with a zero-strength brush to update the topology everywhere.
The upcoming simplify brush will also be a simple way to do this.
It looks like you’re progressing well. Good work!
I’ve noticed that the level of detail is independent of the brush radius. The polygon density is the same for large and small brushes. Sure, this can be an advantage if the user wants to impose an upper limit on the mesh density. Given the behavior of the current implementation of dynamic topology, one might say that the detail slider governs the mesh resolution.
I suggest that you approach clay-like sculpting from the perspective that the detail slider should govern the brush dab resolution. As such, at a higher level of detail, a brush stroke appears smoother, regardless of the brush radius. Consider the goal of clay-like sculpting: the user should have no concern for the mesh. The user should feel like the object is digital clay. If it is intended for the user to be insulated from the mesh construction, the inability to sculpt effectively with a small brush, resulting from an upper limit on the overall mesh density, contradicts clay-like sculpting.
There are clear advantages for both paradigms. Perhaps, you could add a toggle option, allowing the user to fix the level of detail to the brush. Just to clarity, I mean polygons per dab, not polygons per brush area, which would be no different from polygons per mesh surface area.
A possibility to set a cap on ‘polygons per mesh surface area’ would do for BGE terrain sculpting… It’s just to set the cap very low… (then possibly duplicate the mesh, higher the cap and add some detail on a visible mesh and use the original mesh as collision mesh).
Anyway – A cap may be much simpler then two completely different algorithms.
And I kind of agree that ‘resolution’ should be relative to the brush for most ‘clay like’ sculpting… But a cap on the other hand should be relative to mesh surface area to make any sense.
Chaining the detail size to brush size is indeed something to look at. It was also suggested on BA that detail size could change with the zoom level (i.e the detail size would be relative to pixels rather than 3D units.)
One issue with using brush size is that a brush can have a finer level of detail than its radius would suggest due to textures and the brush curve. If a procedural brush texture is used, such as perlin noise, there’s a potentially infinite amount of detail. So perhaps density should relate to brush size, further multiplied by some user-controlled factor.
Clearly at this point I don’t have a firm opinion on this, we’ll probably just need to try some things and find what works. I do aim to keep the controls as simple as possible though.
I don’t think brush density would need to be multiplied by an additional user defined feature that doesn’t already exist in the UI. Essentially, instead of the “detail size” slider under sculpt options controlling the mesh density, as it currently does, it would affect the density of polygons per brush dab. If the user wants more visual fidelity when using a texture, she need only crank up the resolution. One would expect, by this method, that a texture stamp would appear the same regardless of brush radius.
The method I describe really frees the artist from a lot of the technical aspects. For example, I pick a detail level that gives a nice look to the stroke then start sculpting. There’s really no reason to fiddle with the detail slider until the detailing phase when more resolution is needed to better accomodate the information within a texture. This is how Sculptris works and, from what I can discern in some of Farsthary’s videos, how Unlimited Clay was designed. I suggest that you watch some Sculptris timelapse sculpts on YouTube. You will notice that the artists rarely choose to adjust the “detail” slider.
With the current method, I could see approaching a sculpt in a similar way one would using a multires modifier. Unlike multires, I would not have to worry about topology. However, I could work in stages of increasing detail, periodically adjusting the “detail size”, similar to adding an additional subdivision level from the modifier panel.
For either method, controls would remain as simple as possible since the UI would be identical. And, if you decide to allow the user to toggle between the current method and the one I describe, it could be as minimal as an icon-only button (presumable corresponding to a boolean property to get the shaded effect) row aligned to the existing slider.
I hope that you don’t get the impression that I am displeased with your work. Actually, it’s quite the opposite; I am amazed by the progress you make between each post. This is such an important addition to Blender.
I only want to impress upon you one thing. It is reasonable to expect that the way an artist uses the current method is significantly different than the way she would use the method I describe. It is up to you to decide what method is best or if both are worthy of inclusion in Blender.
updated windows builds at graphicall
Windows x64 http://graphicall.org/962
Windows x32 http://graphicall.org/963
keep up great work, Nicholas!
Hi Nicholas, thank you for your great work. I hope dyntopo will be soon available for sculpting in Blender.
I don’t know if it could be interesting for you but I found this video in YouTube…
http://www.youtube.com/watch?v=G4LqU8Cvntc
I forgot to say the developer has opened the source code…if it could help…
Not really. You can buy the code at binpress:
http://www.binpress.com/app/dynamic-mesh/976
DynTopo works pretty much the same at the moment
They appear to be using a combination of edge splits and collapses (as well as flips, but I don’t see that as too important), so it’s pretty much the same approach as I’m using.