Blender 5.2: Speeding up ImBuf access

In Blender 5.2, the ImBuf object now features a method that can be used as a context manager, yielding a Python memoryview object. This opens up a fast and convenient way to use an ImBuf to draw things using the blf module, and then copy the result to a Blender Image object's pixels attribute.

However, we cannot simply write:

with myimbuf.with_buffer() as mv:
    myimage.pixels[:] = mv[:]

This fails because Python's memoryview slice assignments have limitations when working with non-flat array configurations, which is what an Imbuf always is (width x height x color channels).  Instead, we have to cast the memoryview to a flat array. 

Furthermore, because either the source or the destination needs to be in a compatible byte format, we cannot cast a multidimensional float view directly to a flat float view in one go. We must resort to a rather inelegant double cast coupled with the foreach_set method:

myimage.pixels.foreach_set(mv.cast("b").cast("f"))

This first casts everything to a flat array of bytes, then to a flat array of floats, what is what foreach_set expects.

It works, and both cast() and foreach_set() are highly performant (cast() does not even touch the data, just the metadata), but it does feel a bit clunky. This isn't Blender's fault, though—it has been a long-standing behavior regarding multidimensional array manipulation discussed on the Python Core Development Issue Tracker.

Note that we now have a fast way to move data from an ImBuf to an Image, but ImBuf objects aren't all that common: we can create one and write text into it with the functions in the blf module, but as far as I can tell the is currently no way to copy a framebuffer to an Image or an ImBuf, nor is there a way to use the gpu module directly to draw into an ImBuf, so quickly creating an Image still requires a laborious route that involves copying the data from the framebuffer pixel-by-pixel to the Image.

Hopefully framebuffers will get buffer protocol support in the future, but that's probably not an easy task as there the actual data lives on the GPU and needs to be transferred. So let's keep an eye on the dev logs. 😀

US Road Sign Generator

After publishing a few sets of US road signs, I went back a created a geometry nodes based road sign generator that can be used to generate the iconic green signs you see along highways in the US.

Configurable to up to three lines, will all sort of options and three different materials. All lightweight (both geometry and texture) and of course utilizing the common 'Highway Gothic' typeface.

Its available on Superhive (formerly BlenderMarket). Check it out if you want to give your drivers some directions!

US Road Signs - Warning Signs Roadwork

After publishing a set of general US road signs, I thought why not publish one with signs commonly seen around road works?

The set is conveniently organized as an asset library and available on Superhive (formerly BlenderMarket). Check it out if you want to keep your rendered road crews and passing driver safe!

US Road Signs - Urban Essentials

I thought I'd quit, but I guess working with Blender is too much fun 😀.

In the past I created some collections with Dutch and German road signs but I thought some US road signs would be a nice addition. There seems to be a bewildering variety of those, much more than their European counterparts, so I limited myself to some of the more common ones seen in (sub)urban setting. If there is some demand for it I might add some other sets. 

The set is conveniently organized as an asset library and available on Superhive (formerly BlenderMarket). Check it out if you want to add some details to your rendered neighborhood!

Visualizing spur gear cutting in Blender

 To get a feeling on how spur gear teeth get their particular shape, I created a short visualizer:

The whole process of emulating the action of the cutter on the rotating blank was done in Blender, this time not using a add-on for once, but a simple script that runs from the text editor.

The script renders a frame, then applies the boolean difference modifier that the spur gear object (the 'blank') has, moves both the blank and the cutter and adds again a boolean modifier and repeats this as many times as desired.

I am not yet sure if I will write a small article explaining the code, it isn´t all that complicated, but in the meanwhile you can download the .blend file from my GitHub repository (click on the 'download raw file' icon in the upper right corner to download). 

Hexagonal patterns in Blender's geometry nodes

 I have been experimenting a bit with geometry nodes lately and I thought I´d share this one

The .blend file is available from my GitHub repository. (Click the 'download raw file' button in the upper right corner to download it; Inside is a sample scene, and the geometry node itself is called 'Hexagon pattern')

Tips

The input mesh is simply repeated across the pattern and nothing fancy is done to it. If the repeated meshes are butted up to each other you may want to remove any coinciding vertices, and I could have done that in the geometry nodes itself but that is unnecessary as you can easily apply a weld modifier to achieve the exact same effect. And other modifier too of course, like a solidify modifier perhaps, to give the grid some thickness.

If you just want a quick hexagonal pattern in a shader, you may want to have a look at this post.

Some details

The node setup is pretty straight forward:

We get the bounding box of the object we want to repeat, scale it a bit so we can add a gap if we like, and the repeat the mesh for a set number of iterations along the x-axis. Then we replicate the result along the y-direction and end with applying a material index.

If we look at the repeat x section, we see that there isn´t much to it:

We simply join a shifted version of the input for a set number of times. The offset in the x-direction is twice the maximum of x dimension of the bounding box, i.e. we assume that the input mesh is symmetrical around the origin.

The repeat y section isn´t all that much different, except for a little detail:

That detail is that we move the new mesh up in the y-direction by a configurable scaling factor, where the default is fit for a six sided cylinder, a.k.a. a hexagon, but you can change that to something else if needed.

We also move the row either to the right or the left, depending on whether we are in an odd or even row. We determine this odd/evenness by taking the iteration number module 2 and using a switch node to provide a multiplication factor of -1 or 1 respectively that we apply to our x offset. If we wouldn´t alternate this move in the x-direction we would get a skewed grid, which might be find, but I prefer to work with a square grid.

New blog: On the back of an envelope

 

I'm interested in more than just Blender 😀 so I started a new blog. It might interest some readers of this blog as well as it has a bit of a mathematical focus, just like quite a few articles here.

It is all about assumptions and questions that may pop up in everyday life and that may be solved with a bit of thinking and pen and paper, hence the title "On the back of an envelope".

Focus is on doing our own research up, backed up by proper references to articles by real people, and no easy AI slop.