IDMapper ported to Blender 3.6 LTS

IDMapper has been ported to Blender 3.6 LTS

I am happy to announce that I have updated IDMapper to work with Blender 3.6.

It sports a few bug-fixes and internal changes to work with the newer Blender versions, and also has two bits of new functionality:

• you can change the color of the help text shown in face paint mode, to better adapt it to your theme (in the add-on preferences), and
• the IDMapper operator is now applied to all selected objects, instead of just to the active object. This ensures that assigned colors are unique across those objects. If you prefer the old behavior you can select that in the add-on preferences

I have also created a new demo video that shows the basic workflow when using the add-on in Blender 3.6

IDMapper simplifies creation and editing of vertex color layers that can be used as ID-maps in texturing software like Substance Painter or Quixel. It aims to reduce the time it takes to create an ID-map significantly, especially for complex hard surface models. It uses powerful heuristics to create an ID-map from scratch and lets you interactively adjust the results. It offers options to use existing information, like uv-seams, but can also intelligently assign the same color to similar mesh parts. 

The new version is available on BlenderMarket.

Prometheus metrics for Blender: Demo video

In the video I showcase the add-on presented in the previous two blog posts (1, 2) and show how to install and configure it.

The video is a bit too detailed perhaps for something that is basically a simple install and doesn't go into detail on how to install Prometheus or Grafana itself, but I was learning to use OBS and wanted to try some stuff out, so I decided to have some fun with it 😀

If you have questions or suggestions, consider opening an issue in the GitHub repository.

Prometheus metrics for Blender: New repo

The add-on introduced in the previous post has moved to its own repository

That repository also includes installation and build instructions
We moved it to its own repo to facilitate rapid development and also because that way we can easily incorporate the prometheus client library as a git submodule.

Donations welcome

You are more than welcome to use this add-on: It is completely free and open source.
But if you would like to show your appreciation and you can afford it, consider following the sponsor button at the top of the repo, or directly via this Paypal link.

Prometheus metrics for Blender

Exposes Prometheus metrics on port 8000 when enabled.

In particular, it exposes a Gauge, Blender_Render, that is 1 when the Blender instance is rendering, and 0 when it is not. The standard metrics, like cpu usage are also exposed.

Building the add-on

Currently we use an embedded and slightly modified version of the prometheus_client for Python, which is in the subdirectory. That is not ideal and might change once I have figured out how to monkey path the server instead of hacking the source, but i don´t like to depend on external Python packages because that makes it difficult to distribute and add-on. Copying is also very far from ideal, so a git sub-repository is probably the way to go.

git clone https://github.com/varkenvarken/blenderaddons.git
cd blenderaddons
zip -urv prometheus.zip prometheus

Then install prometheus.zip in the usual way and enable the add-on.

You can inspect the published metrics on http://localhost:8000.

Scraping this with a Prometheus container and creating a Grafana dashboard is something you'll have to figure out yourself.

Source code

Available on Github.

The code is extremely simple: when the add-on is enabled we create a Gauge metric and start the prometheus http server. We then register a Blender timer that checks every 10 seconds if we are rendering or not with the is_app_running() function and sets the Gauge accordingly.

The timer is made persistent, so it will keep running even if we load another .blend file. The Prometheus server is running in a separate (daemon) thread and will only end if we exit Blender or if we invoke our custom stop_http_server() function, and that's where the ugly hack comes in: the start_http-server() function does not return the server it creates, so w e have no way to call its shutdown() function (which is present, because it is a subclass of http.server) or call close() on the socket it is listening on, and this would prevent us from disabling and then enabling the add-on again, because we would get an address in use exception.

Same goes for the Gauge: If we want o be able to reenable the add-on we have to make sure to remove it from the registry in the unregister() function.

import bpy  # type: ignore
from .prometheus_client import Gauge, start_http_server, stop_http_server, REGISTRY

def every_10_seconds():
    global g
    r = bpy.app.is_job_running("RENDER")
    if r:
        g.set(1.0)
    else:
        g.set(0.0)
    return 10.0

def register():
    global g
    g = Gauge("Blender_Render", "Rendering processes")
    start_http_server(8000)
    bpy.app.timers.register(every_10_seconds, persistent=True)

def unregister():
    global g
    bpy.app.timers.unregister(every_10_seconds)
    REGISTRY.unregister(g)
    stop_http_server()