In T82421#1054606, @Nicholas Rishel (nicholas_rishel) wrote:

@Joseph Eagar (joeedh) can can you run this build and paste the console log at this link?

On the point about mapping middle mouse to a tablet pen button, I actually find I get less hand strain using emulate numpad and ALT.

In T82121#1044181, @Brecht Van Lommel (brecht) wrote:

In T82121#1044178, @Joseph Eagar (joeedh) wrote:

Certain popular commercial software that shall not be named appears to do this.

Please don't bring up such things in design discussions on developer.blender.org at all, not naming the software is not some kind of legal protection. Argue why a particular behavior is good for Blender.

In T82121#1043071, @Metin Seven (MetinSeven) wrote:

I'm wondering: looking at the tri-topology of the demo video, the triangulation structure seems to be less neatly distributed than the current Dyntopo. Does the improved Dyntopo use the same topology algorithm (maybe Delaunay or Voronoi) as Decimate modifier?

This is what I like to use the array modifier for:

Okay, why does it say I removed a subscriber. Let's try that again.

Adding OPTYPE_UNDO to ot->flag in MESH_OT_paint_mask_extract in editmesh_mask_extract.c seems to fix this bug. Should all the operators in that file have that flag set?

We could have a new CustomData instance in meshes for multires grids, e.g. mesh->gdata or mesh->mdata. We could then allocate customdata layers as blocks in MDisps, similar to how bmesh does it. So, Mdisps might look something like:

You don't really need triangle/triangle testing per se. IIRC you only need triangle/point and edge/edge, you can build triangle/triangle out of those.

Okay, I have written a small set of slides introducing continuous collision detection.

Btw, is the cloth code not doing continuous collision detection?

IIRC, isn't this how the cloth code originally worked? I know researchers disagree on whether it's a good idea or not; the consensus seems to be that it is (or at least, is unavoidable), I think? Impulse collisions are tricky in general. IIRC some papers combine the two approaches along with a third one:

I've configured my IDE for clang-format. Anyway, like I said the NaNs were produced by buggy multires code in bmesh. I'm just about ready to submit a patch to fix that. I still think we should handle NaNs gracefully; it's not the fault of artists when buggy code produces them.

Here's some history of what happened. So, ten or eleven years ago I wrote code to reproject multires grids when topology changes in edit mode. However, the function I wrote to convert multires displacements didn't work if the multires level wasn't set at its maximum. Consequently, when Campbell merged in the bmesh branch he disabled it, and I guess at some point someone modified the reprojection code to try and work in tangent space. But that doesn't really work since "tangent space" for multires depends on the underlying subdivision surface.

I meant the reprojection that happens in edit mode within bmesh, not anything to do with sculpt. I've committed a new branch for this; I thought it would be small enough to just submit a patch, but it looks like I'll need to clean up the multires code a bit. It shouldn't be too big of a change, just need to prune some old direct usages of CCGSubsurf (which shouldn't be used for multires as it's not compatible with what OpenSubdiv gives us).

I guess 'enter' submits comments if you're not careful. Anyway, here are the other papers:

For the leaf nodes, how much smaller are we talking about? The dyntopo code had a pretty significant performance degradation from ->leaf_limit being left at 100. Like Pablo said, this is due to traversing the entire tree in order to get anything done (there are other performance degradations tied to multiple per-vertex uses of GHash, but leaf_limit being 100 was pretty significant in itself).

What you want is the symmetrize tool (embarrassingly I just learned about it a few days ago myself). Quite handy.

So, my initial motivation was a bug with Strip hair. The problem with rendering with billboards like Strip mode does is that it doesn't work if the camera is looking down the hair; you get lots of nasty twisting artifacts. This isn't a big deal for fine hair strands but is for anime style hair where the strands are really thick. Once I realized this was unsolvable I noticed Clement's comments on planned support for cylinder hair, and I figured I'd implement it.

In D7284#174711, @Dalai Felinto (dfelinto) wrote:

Hi @Joseph Eagar (joeedh) can you elaborate further (and update the patch description) on the feature, why this is needed? If we are to add a hair type which is not compatible with Cycles we need a good reason to do so. Thank you.

In T68888#888884, @Paul Kotelevets (1D_Inc) wrote:

@Joseph Eagar (joeedh)
Well, we are architects, and we have many faces to perforate)
But Blender have pretty much wide range of use. How about the behavior of such ngons with modifiers, UVs unwrap, visualization engines, normals baking, rigging/vertext paint, simulations, import/export formats?
They will influence almost everything.

Hi @Dalai Felinto (dfelinto), they do complicate things like dissolve and face splitting. From what I remember from the work I did in AllShape five years ago the hardest part was implementing a decent CDT tessellator, which Blender already has. I remember for subdivision surfaces I literally would triangulate the faces and then run a triangle to quad algorithm; it was "good enough" for a use case that should never happen anyway (why would you use holes in faces with subsurf?).

Woo! I always regretted my decision not to add holes in faces to the bmesh project; if 3d printers had taken off just a bit sooner I would have. At one point I actually started coding support within the core bmesh data structures but removed it later. It seemed like too big of a change for too niche of a use case.

Updated to apply to latest head

It's definitely a bug, here's an example image.

It's a bug.

For anyone who tries the shader, you have to bake in "Combined" with "View Transform" under Color Management set to "Raw."

Here's the normal map osl shader.