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.

I tried something similar, and I still got a hang in inside of glGetQueryObjectuiv(g_query_state.queries[i], GL_QUERY_RESULT, &result). It might be a good idea to check for results with GL_QUERY_RESULT_AVAILABLE first and then call it with GL_QUERY_RESULT.

Okay, looks like the problem is with the undo system; if you manually exit editmode then push the understack, e.g.:

In D4993#114932, @Juan Gea (juang3d) wrote:

Looks great,

What are the benefits of this over the @Lukas Stockner (lukasstockner97) dithered sobol implementation?

• Added an option to ignore coherency setting in non-bluenoise mode.
• Added a 128x128 blue noise mask.
• Updated defaults. Seems the setting of coherency that leads to quickest convergence differs from scene to scene.

I can confirm rB27d5d3c2f8b fixed it (I've been testing pretty much the exact same code for the past half hour, and there's been no crashes).

In D1522#32553, @Antonis Ryakiotakis (psy-fi) wrote:

This fix only takes care of mapping for the texture for the final compositing on the screen, however the shaders need calculation fixes as well. All the position reconstruction code in particular relies on the fact that uv coordinates are in the 0-1 range.
This is fixable but adds complexity in the code. In the case of, for instance, depth of field or any algorithm that requires downscaling, this scaling will have to be propagated to downscaled textures as well, and tracking this becomes quite annoying.
I'm a bit sceptical too if we really need to support this. Probably the best would be to just disable compositing for cards not supporting npo2 and remove the card from the blacklist.

Layered Weights is now a different normalize mode. It uses method in previous comment.

Hardware has NPOT support, but is being blacklisted (there's a comment in gpu_extensions.c that certain API chipsets have issues, or something like that).

My graphics card has non power of 2 support. It's just being blacklisted (there's a comment in gpu_extensions.c about how certain API chipsets are problematic). I can try disabling the blacklisting and see what happens.

So, from the looks of it we still need to normalize if there are more than one groups affecting a vertex.

Reworked patch. Now, if new option 'layered weights' is enabled, vertices only affected by one deform group will not be normalized.

Remove code that kept verts affected by single weight groups from being normalized, as this breaks existing rigs.