Conjure is a Signed Distance Field editor for Blender. Instead of triangles, it uses Signed Distance Functions of primitive shapes together with Boolean operations to create complex objects. It is essentially Blender’s native Metaballs, but on steroids. By raymarching this mathematical representation, a watertight flawless object can be rendered.
Features
custom rendering engine, raymarching SDFs directly
with matcaps
fully non-destructive boolean workflow with blending
My pre-alpha testers:
Aaron Smith, Andres Stephens (Draise/Trinumedia),
Ben Henry, Danielle Villacorte, Emiliano Colantoni, Hubert Krzykalski, Jakub Mularski, Joe Seabuhr, Jordan Cain, Jordan “Mossy” Moss, Josh J Beck, Katja Linssen (rHebKa), Kevin Anderson, Luís Cherubini, MACHIN3, Mean Goreng, Michalina “Miszla” Gąsienica-Laskowy, NightHawk (https://x.com/NightHawk664), Oskar Edlund (https://www.artstation.com/osed), Parawerke (https://www.artstation.com/para_werke), Robin Chyo, Sabrina Garcia, Thomas Roy William Butters (https://x.com/ArtOfPilgrim) and Till Freitag
To commemorate exactly 6 months of working on this massive project, I put together a little compilation of all the short videos I posted over the course of development. (and it also serves as a nice way of getting the BA people here up to speed)
I’ve been following your work on Twitter for a while, and first off, this is a really interesting tool! Congratulations!
I was wondering if you plan to incorporate the use of mesh data from the primitives?
I imagine it might be possible to use vertex/edge bevel/crease data to modulate the blending strength. That said, this could be tricky, especially since it would require resampling the data into some spatial structure. However, even if it’s just a bounding box with 8 floats for the corners and interpolation using a customizable curve, the enhanced control over the shape would be worthwhile.
From the samples I’ve seen here and on Twitter, this appears to be one of the biggest limiting factors. It also contributes to the distinctive look that nearly all the outputs share.
But I don’t mean to be overly critical – it’s an awesome tool!
(Ps.: if there is another alpha, please sign me up!)
Indeed one of the biggest limitations of SDF modellers is limited control over the blending strength between primitives. It either blends everywhere or nowhere, etc.
Worked on a little test asset to check for bugs/other issues on the newest pre-alpha. Some kind of electronic warfare tank turret (I didn’t think too much about it) Done in 2-3 hours
Should be going out to the current testers soon
Improvements include:
-primitives can ignore the world mirroring
-multiple primitives can be moved up/down the stack
-move prims to top/bottom of stack
I really wish this would work in Blender macOS too. It would ease my decision to return to Mac, as there’s virtually no SDF tool for macOS yet, as far as I know, not in or outside of Blender.
There’s Unbound (in closed beta at the moment), but that will be a game engine featuring SDF modeling, but isn’t dedicated to sculpting and rendering.
Considering Blender macOS support will probably get you a nice ConjureSDF sales boost.
As much as I wish I could support macOS. It’s really sad that they no longer support openGL in favor of their own Metal API.
Based on these numbers, I personally don’t see it affecting sales that much though. (a lot can change in 3 years however, I wish there was more recent data on windows/linux/macOS userbase distribution)
While I do plan to move the rendering engine to a separate cpp/openGL system, or even eventually to Vulkan (which should work on macOS/metal via moltenVK) It is just not a priority for any time soon. And regardless macOS support is simply not a major factor in moving away from python and bgl/openGL.
The move to cpp is >6 months away. And Vulkan is easily 1-2 years away, if ever. As a busy sole delevoper I have time constraints and priorities I must consider. It is sad to say but macOS support is unlikely to happen any time soon
With sufficient funding I could employ other people, etc. true. But I want to work on Conjure, not manage it. My only focus right now is conversion to mesh and other core features.
I believe this might be the kind of revolution that modeling needs. Some people turn towards tools like MOI or Fusion360 to avoid having to care about topology or properly working booleans but that always felt like another huge workaround to me…
I am curious - are you using the bgl module for ConjureSDF? I thought its going away soon? I am still learning the blender api - and using the gpu module for my current project - havent even looked at bgl as it has warnings all over the api doc - so i figured gpu is the way to go…
If so, that is the reason for not having macOS support? As far as i understand it now, the gpu module would have no problem there, but i guess is lacks the features necessary?
Ah thank you Francis, I’ve been waiting for new data for ages
But as I suspected the macOS share of the userbase hasn’t changed much relatively speaking.
11% certainly isn’t nothing (especially when compared to Linux ) But it doesn’t justify the time/effort it would take to support macOS right now. Perhaps after v1 launch.
Conjure is running on bgl for the time being. This does limit the Blender versions it can run on (4.0 and beyond is not supported) Which is why I want to move away from bgl in the near future of course.
Indeed for most applications (such as custom UI/gizmo drawing, etc.) the gpu module should be used and is more than sufficient. But with it being essentially an abstraction layer between python and openGL/Vulkan/Metal, you lose some control and performance. Which is not great for a realtime renderer. (But on the flip side, you can support macOS easily)
bgl’s docs were not perfect, and there aren’t too many complex examples out there for it. But this was still managable to work with, as it mirrors the cpp implementations of openGL rather closely.
The GPU module however? While not technically new, I think a lot of people are only now making the switch to it in their python addons.
This coupled with once again less than ideal documentation. Means I would rather not switch to it for a rendering engine
Switching to cpp/openGL (or Vulkan eventually) just gives a lot more low level access and freedom. Which is very welcome when writing your own rendering engine.
But this also means that it all takes a bit longer ‘If you want something done right, do it yourself’
I’ve slowly been working on conversion to mesh. And finally had a big breakthrough today.
Marching Cubes algorithm implemented as a compute shader for the GPU via modernGL.
Churns through 2Mill voxels (128^3) in <5 seconds.
Will need a bit more time to fully integrate into Conjure, but we’re very close to a full asset pipeline.
