Coder Legion - Recent posts tagged blender

Designing a High-Converting Forex Landing Page with Framer + 3D Workflow

Tue, 07 Apr 2026 06:16:58 +0000

I recently worked on a forex landing page concept—not just from a design perspective, but as a full front-end experience.

The goal wasn’t aesthetics alone.
It was performance, clarity, and conversion.

Here’s how I approached it:

– Built in Framer for rapid iteration + production-ready output
– Structured layout to guide user flow (not just visual hierarchy)
– Integrated chart-style visuals to simulate real trading context
– Used subtle motion + depth (inspired by 3D workflows like Blender) without killing performance
– Focused on clean UI + fast load (avoiding heavy embeds like Spline)

One key thing I’m learning:

The best “designs” in web today are actually engineered experiences.

It’s no longer just UI vs Dev.
The line is blurred and tools like Framer are sitting right in the middle.

I Built an ML Routing Engine for 3D Mesh Retopology — Here's How It Works

Thu, 19 Mar 2026 12:31:11 +0000

I've spent the last several months building Quadify Ultra, a Blender 5.0 addon that uses a KNN-based ML engine to automatically route meshes to the right retopology algorithm. This post is about the technical decisions behind it — the parts that were harder than expected and the approaches that actually worked.

The problem: retopology algorithm selection is a classification task

Retopology — converting triangulated meshes to clean quad topology — isn't one problem. It's five different problems depending on what kind of mesh you're dealing with:

Open curved panels (car doors, fenders) need edge-flip and greedy quad matching that preserves vertex positions
CAD imports with hard edges need boundary detection before any merging happens
Flat CAD surfaces with n-gon triangulation need dissolve passes before quadification
Closed flat meshes need field-guided remeshing (QuadriFlow)
Organic meshes and scans with broken topology need voxel rebuilding

The routing decision — which algorithm for this mesh — is something experienced artists do implicitly. I wanted to automate it.

The input features I settled on after testing:

features = [
    tri_ratio,           # fraction of triangles
    quad_ratio,          # fraction of quads  
    ngon_ratio,          # fraction of n-gons
    boundary_ratio,      # open boundary edges / total edges
    non_manifold_ratio,  # non-manifold edges / total edges
    normal_std,          # standard deviation of face normals (surface curvature proxy)
    edge_length_cv,      # coefficient of variation of edge lengths
    face_area_cv,        # coefficient of variation of face areas
    avg_valence,         # average vertex valence
    pole_ratio,          # fraction of vertices with valence != 4
    # ... 8 more geometric ratios
]

18 features total. All normalised ratios — no absolute values, so the classifier is scale-independent.

The classifier: KNN with confidence blending

I went with KNN rather than a neural net for two reasons:

Interpretability — when the engine recommends Smart mode at 73% confidence, I can inspect the k nearest neighbours and understand why
Cold start — a neural net needs hundreds of examples before it's useful. KNN with k=3 gives reasonable results from the first 10 operations

The confidence score is the fraction of the k nearest neighbours that agree on the top recommendation:

def get_confidence(neighbours, top_strategy):
    agreeing = sum(1 for n in neighbours if n['strategy'] == top_strategy)
    return agreeing / len(neighbours)

At low DB count the system blends toward a deterministic heuristic:

blend_weight = min(1.0, db_count / 30)
confidence = (ml_confidence * blend_weight) + (heuristic_confidence * (1 - blend_weight))

This means the first 30 operations use mostly heuristic routing, gradually transitioning to learned routing as the DB grows.

The hardest bug: voxel remesh freezing Blender

The original implementation used bpy.ops.object.voxel_remesh(). This is a synchronous operator — it runs on Python's main thread and blocks the entire UI. On a 39,000-face burger mesh it produced about 731,000 intermediate voxel faces and froze Blender for several minutes.

The fix came from reading Quadify Pro's source code. They use a REMESH modifier instead:

mod              = obj.modifiers.new("QP_VoxelRebuild", "REMESH")
mod.mode         = 'VOXEL'
mod.voxel_size   = max(0.0005, min(0.05, world_diag / resolution))
mod.use_smooth_shade = True
bpy.ops.object.modifier_apply(modifier=mod.name)

The modifier executes in Blender's C stack, not Python. It never blocks the UI. Same result, dramatically faster, works on any mesh size.

The voxel_size formula needed one more fix. The original code had:

voxel_size = max(
    min_dim / 20.0,      # THIS was the bug
    local_diag / voxel_resolution,
    0.0005,
)

The min_dim / 20.0 floor was designed to prevent microscopic voxels on large meshes, but it overrode the resolution setting for small objects. A burger mesh at 0.2m scale gave min_dim / 20.0 = 0.01 — 15x larger than the resolution-based target of 0.00064. With 0.01 voxels the mesh produced only 3,138 intermediate faces. QuadriFlow then got min(target_faces, 3138) = 3,138 as its target and produced a low-detail result.

Fix: remove the floor entirely, use world-space diagonal from matrix_world @ Vector(v) for scale independence, and add a 150k face cap to prevent genuinely large meshes from freezing:

bb_world = [obj.matrix_world @ Vector(v) for v in obj.bound_box]
diag = max((p - bb_world[0]).length for p in bb_world)
voxel_size = max(0.0001, min(0.05, diag / voxel_resolution))

# Cap to prevent freeze on large meshes
estimated_faces = (diag / voxel_size) ** 2
if estimated_faces > 150000:
    voxel_size = diag / math.sqrt(150000)

The community telemetry system

Each opted-in operation sends 18 geometry ratios and the algorithm result to Supabase:

payload = {
    'version':   1,
    'features':  [float(f) for f in features],  # 18 ratios only
    'strategy':  strategy,
    'quad_pct':  quad_pct,
    'corrected': corrected,
}

No mesh geometry. No vertex positions. No filenames. Just the feature vector and outcome.

The fetch uses only apikey header — no Authorization: Bearer — because the new Supabase sb_publishable_* key format explicitly rejects the Authorization header:

req = urllib.request.Request(url, headers={
    'apikey':  SUPABASE_KEY,
    'Accept':  'application/json',
})

Applying the update merges remote records into the local KNN experience DB, with deduplication and Postgres array format handling ({0.1,0.2,...} → Python list).

The callback uses bpy.app.timers to write results back to Blender properties on the main thread — background threads cannot write to Blender properties directly:

def apply_result():
    if _result[0] is None:
        return 0.5  # check again in 0.5s
    success, data = _result[0]
    scene.quadify_ultra.ml_update_status = f"Updated — {total:,} operations"
    return None  # stop timer

bpy.app.timers.register(apply_result, first_interval=0.5)

numpy boolean ambiguity in batch processing

One subtle bug that cost time: MeshFeatureExtractor.extract() returns a numpy array. In the batch loop:

normal_std = features[5] if features else 0.3  # WRONG

if features on a numpy array raises ValueError: The truth value of an array is ambiguous. The fix:

normal_std = float(features[5]) if features is not None else 0.3

The float() wrapper also prevents numpy scalar type issues downstream in JSON serialisation.

What's live

Quadify Ultra is available on Superhive: https://superhivemarket.com/products/quadify

$200 one-time, Blender 5.0+, MIT licensed. The ML model improves as the community database grows — currently ~160+ operations from early testers.

Happy to go deeper on any part of the implementation.

I Built a Batch Asset Validator for Blender in Python — Here's What I Learned

Mon, 16 Mar 2026 13:58:07 +0000

I Built a Batch Asset Validator for Blender in Python — Here's What I Learned

Game developers and 3D artists deal with a problem that doesn't get talked about enough: you find out your assets are broken after you've already submitted them.

Wrong scale. Tri count way over budget. Missing textures. Unapplied transforms. Negative scale that makes your mesh flip inside-out in Unity. These issues are obvious in hindsight, but catching them manually across a folder of 50 FBX files before every export is the kind of tedious work that either doesn't happen, or happens inconsistently.

So I built AssetSentinel — a Blender addon that batch validates FBX and glTF assets against a target platform profile before they leave your machine. Here's the technical breakdown of how it works, what I ran into building it, and a full demo video at the end.

The Core Problem: Validation Belongs Before Export, Not After

Most 3D pipelines look like this:

Model → Export FBX/glTF → Import to Engine → Discover problem → Go back to Blender

The discovery step is the expensive one. If you're submitting to a marketplace like Fab or CGTrader, a rejection costs you review time. If you're a studio delivering to a client, it costs credibility. The fix is moving validation to before the export step:

Model → Validate → Fix → Export FBX/glTF → Import to Engine

That's what AssetSentinel does.

How It Works: Temp Scene Import Loop

The core mechanism is a modal operator that imports each file into a temporary Blender scene, runs a series of checks, then destroys the scene and moves to the next file. This keeps the user's working scene completely untouched.

def _evaluate_in_temp_scene(context, path: str, profile: dict) -> dict:
    win = context.window
    orig_scene = win.scene
    temp_scene = bpy.data.scenes.new(name="ASSETSENTINEL_TEMP")
    win.scene = temp_scene
    try:
        _import_file(path)
        # run all checks here
        tris, verts = _tri_vert_counts()
        ngons = _ngon_count()
        # ... more checks
    except Exception:
        # classify the import failure
        detail = _tb_last_meaningful_line(traceback.format_exc())
        ftype, suggestion = _classify_import_failure(detail)
    finally:
        win.scene = orig_scene
        bpy.data.scenes.remove(temp_scene)
        bpy.ops.outliner.orphans_purge(do_recursive=True)

The finally block is non-negotiable. You have to restore the original scene and purge orphan data whether the import succeeded or failed — otherwise you accumulate stale mesh data across every file in the batch.

Blender's UI locks up if you run long operations on the main thread. The solution is a modal operator driven by a timer event. Each tick of the timer processes one file, then yields back to Blender so the UI stays responsive and the user can cancel with ESC.

def modal(self, context, event):
    wm = context.window_manager
    if event.type == "ESC":
        wm.assetsentinel_cancel_requested = True
    if event.type != "TIMER":
        return {"PASS_THROUGH"}
    if self._idx >= len(self._files):
        wm.assetsentinel_status = "Done"
        return self._finish(context, cancelled=False)
    # process one file per tick
    path = self._files[self._idx]
    res = _evaluate_in_temp_scene(context, path, prof)
    self._results.append(res)
    self._idx += 1
    wm.assetsentinel_progress = int((self._idx / len(self._files)) * 100)
    return {"RUNNING_MODAL"}

The timer interval is 0.1 seconds. Fast enough to feel responsive, slow enough not to hammer the CPU.

Profile-Based Validation

Rather than hardcoding limits, AssetSentinel uses JSON profiles — one per target platform. Each profile defines the limits that matter for that destination:

{
  "UNITY_MOBILE": {
    "label": "Unity - Mobile",
    "max_tris": 20000,
    "max_texture_res": 2048,
    "max_material_slots": 4,
    "lod_required": true,
    "no_spaces": true,
    "min_bbox_m": 0.05,
    "max_bbox_m": 10.0,
    "tri_over_is_error": true,
    "lod_missing_is_error": false
  }
}

The _is_error flags per rule let you configure severity independently. A tri count violation might be a hard error on mobile, but only a warning on desktop. The profile system auto-merges on load — if a user has an older profiles.json, new keys from the defaults get added without losing their custom values.

The Checks

Here's what runs on every imported asset:

Geometry:

Triangle and vertex count via me.calc_loop_triangles() — falls back to bmesh triangulate if that fails
Ngon detection by checking p.loop_total > 4 on every polygon
Negative scale on any axis
Unapplied transforms (scale/rotation not at identity)

Textures:

Total image count from bpy.data.images
External file resolution — whether the filepath exists on disk
Max texture resolution from img.size[0] and img.size[1]
Missing external textures list

Naming:

Regex match against allowed_name_chars from the profile
Space detection in object and material names

Scale:

World-space bounding box via evaluated_get(depsgraph).bound_box
Compared against min_bbox_m and max_bbox_m in the profile

LOD:

Name-based detection — checks for _LOD0, _LOD1, _LOD2, _LOD3 substrings

Import Failure Classification

One of the more useful features: when an import fails, it doesn't just say "import error." It classifies the failure and suggests a fix:

def _classify_import_failure(detail_line: str) -> tuple[str, str]:
    s = (detail_line or "").lower()
    if "khr_texture_basisu" in s:
        return (
            "UNSUPPORTED_EXTENSION",
            "Re-export without BasisU/KHR_texture_basisu and try again."
        )
    if "bad gltf" in s and "json error" in s:
        return (
            "INVALID_GLTF",
            "The glTF/GLB appears corrupted. Re-export from your DCC."
        )
    return ("UNKNOWN", "Try re-exporting and verify the file opens in Blender.")

This is genuinely useful in practice. KHR_texture_basisu failures come up frequently with AI-generated GLB files and photogrammetry exports. The error message from Blender's importer isn't helpful on its own — this surfaces the actual fix.

The HTML Report

After the scan, results are exported as an HTML report with a CSV alongside it. The report uses a dark theme, shows per-asset pass/warning/fail status with a triangle count bar against the profile limit, and includes filter controls to show only failed or warning assets.

The report also surfaces "top violations" — which checks failed most frequently across the batch. On a folder of 26 game assets, the most common failures were tri count overages and suspicious bounding box scales. Both are things that would have caused problems in the engine.

Watch the Full Demo

[embed: https://www.youtube.com/watch?v=64qQiMLCSD0]

The video walks through a real batch scan of 26 assets against the Unreal Desktop profile — showing the scan running, reading the HTML report, and interpreting the results.

Get the Addon

AssetSentinel is available on Superhive (Blender Market): https://superhivemarket.com/products/assetsentinel

Supports Blender 3.6 and above. No external dependencies — pure Python, no PyPI packages.

What I'd Do Differently

A few things I'd approach differently if I started over:

Results storage. I'm serialising the results to JSON and storing them in a WindowManager property string. It works but it's awkward — a proper addon-level data store would be cleaner.

The modal pattern. The timer-based modal is the right approach for Blender, but the 0.1s interval is a guess. A smarter approach would adapt the interval based on file size or import time.

Profile UI. Right now profiles are JSON files edited externally. An in-panel profile editor would make this accessible to artists who don't want to touch JSON.

Happy to answer questions about any part of the implementation — drop them in the comments.

ThreeDimensions Version-1.0.0 is here !

Sun, 08 Mar 2026 05:38:07 +0000

ThreeDimensions

Version-1.0.0 Repo - https://github.com/LegedsDaD/ThreeDimensions-v1.1.1

ThreeDimensions is a programmable 3D modeling library for Python, backed by a C++ geometry kernel for heavy mesh operations.

Do check out Main Repository

Send your creations using ThreeDimensions in Models by filling in the Form. The best models will be added to the examples of ThreeDimensions. Others will be added to the models groups. See current submissions in Submissions. Do participate !

Version: 1.0.0

Overview

Python-first API (import threedimensions as td)
C++ core for mesh math/topology/modifiers when available
Pure-Python fallback so the package remains usable without compiling native code
Half-edge/topology-oriented editing workflow with sculpt, modifiers, curves, nodes, UV tools, and export

Feature Highlights

Transform system: move/rotate/scale, pivot modes, snapping, mirror transform, proportional falloff
Selection: vertex/edge/face, loop/ring, box/circle/lasso, select similar
Editing: extrude, inset, bevel, bridge, fill, grid fill, subdivide, loop cut, spin, screw, solidify, wireframe
Deformation: bend, twist, taper, stretch, shear, warp
Symmetry: mirror and symmetrize helpers
Sculpt: draw/clay/inflate/smooth/grab/pinch/crease/mask style brush workflow + filters
Remesh/reduction: voxel remesh, quad remesh, decimate
Primitives: cube, sphere, UV sphere, icosphere, cylinder, cone, torus, plane, grid
Curves: Bezier, NURBS-style fallback, lathe, curve-to-mesh
UV: unwrap, smart UV project, project from view, seams
Retopo helpers: shrinkwrap, poly build, relax topology
Modifier stack: subdivision, mirror, array, solidify, boolean, decimate, lattice
Procedural NodeGraph API
Optional OpenGL viewer (td.viewer(mesh) or with td.viewer() as scene)

Installation

pip install pip install threedimensions==1.1.1

Optional viewer dependencies:

pip install glfw PyOpenGL

Quick Start

import threedimensions as td

mesh = td.create_cube(1.0)
mesh.extrude(distance=0.2)
mesh.bevel(width=0.05)
mesh.subdivide(1)
mesh.save("model.obj")

Geometry Nodes (Programmable)

import threedimensions as td

graph = td.NodeGraph()
cube = graph.node("Cube", size=1.0)
subdiv = graph.node("Subdivision", levels=2)
extrude = graph.node("Extrude", distance=0.25)

graph.connect(cube, subdiv)
graph.connect(subdiv, extrude)

mesh = graph.evaluate()
mesh.save("graph.obj")

Viewer

import threedimensions as td

mesh = td.create_torus()
td.viewer(mesh)  # blocking preview

with td.viewer() as scene:
    scene.update(mesh)
    scene.run()

Architecture

python/threedimensions/: high-level Python API wrappers, fallback implementations, procedural nodes, viewer

License

MIT

Why We Built a Deterministic Render Gate for Blender (and Why “Final” Is a Lie Without One)

Mon, 02 Feb 2026 08:32:55 +0000

Most render failures don’t come from bugs.
They come from assumptions.

Assumptions that a scene hasn’t changed.
That a render engine behaves “close enough.”
That “Final” actually means final.

After watching too many late-stage renders slip through with subtle but expensive problems, we started asking a different question:

What would a render system look like if it treated “FINAL” as a contract instead of a label?

That question eventually became RenderForge.

The Problem With Traditional Render Validation

Most render checks are advisory:

warnings in the console

notes in a checklist

tribal knowledge passed between artists and TDs

None of that is enforceable.
None of it is auditable.
And none of it survives a late-night change.

In practice, “Final” usually means:

“We hope nothing important changed.”

That’s not good enough in production.

A Different Approach: Deterministic Gates

RenderForge was built around a simple principle:

If a render is allowed, the system must be able to explain why.

That means:

Extracting stable scene facts

Resolving all validation through a single failure taxonomy

Treating intent (PREVIEW / LOOKDEV / FINAL) as a first-class input

Blocking renders when assumptions are violated

Recording exactly what was approved and under what risk

No heuristics. No silent overrides.

Hard vs Soft Failures (and Why This Matters)

One of the biggest mistakes in tooling is treating all warnings equally.

RenderForge separates failures into:

HARD: delivery is invalid (blocked)

SOFT: delivery is allowed only with explicit acknowledgement

This distinction lets the system be strict without being dogmatic.

For example:

Eevee FINAL isn’t banned outright

It’s allowed only under defended constraints

Any remaining approximation risk must be acknowledged

Nothing is hidden. Nothing is implied.

Approval as a Contract, Not a Button

In RenderForge, approval isn’t a snapshot — it’s a contract.

Approval records:

the exact scene fingerprint

the declared intent

the render engine

the policy version

Which risks were acknowledged

Change anything meaningful, and approval becomes stale automatically.

No one has to remember to re-check.
The system refuses to forget.

Why This Is Interesting (Even If You Never Use the Tool)

Even if you never install RenderForge, the idea is transferable:

Deterministic validation beats best-effort checks

Explicit risk acceptance beats silent warnings

Systems should explain themselves when they block work

“Final” should mean something measurable.

Curious how others are handling render approval and late-stage drift. How do you keep ‘final’ honest in your pipeline?

Quadify Base, Premium, & Pro

Thu, 29 Jan 2026 15:54:44 +0000

I’ve just released three variants of Quadify on Superhive: Base, Premium, and Pro.

Quadify is a Blender toolset built around one idea:
mesh cleanup and quad generation should be deterministic, intentional, and fast — not a guessing game.

This isn’t a replacement for manual retopology tools. It’s designed to be used before them, when you’re dealing with messy geometry and trying to decide how much work is actually worth doing.

Here’s how the three variants are intentionally scoped:

Quadify Base
Focused on safe, predictable tri-to-quad conversion.
It handles the obvious cleanup first, preserves seams and materials, and clearly shows what still needs manual attention.
Built for speed and transparency, not magic.

Quadify Premium
Adds manual quadification and region-based control.
You decide where topology is rebuilt and what stays untouched.
This turns quad cleanup into a deterministic decision process instead of a global operation you hope works.

Quadify Pro
Built for production pipelines and scale.
Includes pipeline workflows, automation recipes, LOD generation, texel density tools, validation, and reporting.
The focus here is repeatability and trust — knowing an asset is actually ready for downstream use.

All three share the same core philosophy:

deterministic behavior

visibility before action

control before commitment

If you work with scans, AI-generated meshes, imported assets, or production pipelines where cleanup keeps breaking things, Quadify is meant to remove the mechanical, repeatable pain — not replace artistic judgment.

The full release is live here on Superhive:
https://superhivemarket.com/products/quadify

Happy to answer questions about design decisions, scope tradeoffs, or why certain things are intentionally not automated.

I build Blender automation tools. What repetitive production task should not exist anymore?

Thu, 29 Jan 2026 15:46:17 +0000

I build Blender tools with a focus on automation and production speed, primarily for game art workflows.

Before deciding what to build next, I want to hear directly from people who use Blender seriously and run into the same problems over and over—the kind where you think “this should not be manual in 2026.”

I’m not looking for abstract feature ideas or wishlist items. I’m looking for concrete, repeatable pain points that:

You hit frequently (daily or weekly)

Are tedious, mechanical, or error-prone

Feel like they should be solvable with a tool or add-on

Aren’t already cleanly solved by an existing addon

If you respond, please be specific. Context matters more than volume.

Helpful examples:

“When doing X, I always have to manually do A → B → C because Blender doesn’t expose Y.”

“This part of my pipeline breaks unless I double-check Z every time.”

“I waste time fixing the same class of mistake over and over.”

Less helpful:

“Blender’s UI is bad”

“I want Maya feature X”

“Everything should be procedural”

If it helps, you can include:

Your role (environment artist, character artist, tech artist, etc.)

The kind of assets you work on

Where the friction shows up (modeling, UVs, baking, export, scene management, cleanup, validation, etc.)

I can’t promise I’ll build everything that’s mentioned, but I will prioritize problems that show up across multiple workflows and can be solved cleanly.

If you’ve ever thought “I should script this, but I don’t have time,” that’s exactly the kind of problem I want to hear about.

PS: Anyone whose suggestion I build will get a free copy with long-term support.

Demo video of smart uv tool at work

Tue, 06 Jan 2026 09:10:35 +0000

UV unwrapping shouldn’t feel like punishment.
Smart UV Tool analyzes your mesh and unwraps it clean, fast, and distortion-free in one click.
No stretching.
No messy islands.
No “why does this look like that?” moments.
Built for artists who value speed, precision, and sanity.
You can get this addon here https://superhivemarket.com/products/smart-uv-tool

Scene cleanup wizard

Tue, 30 Dec 2025 21:06:37 +0000

Ever opened a Blender file and instantly regretted it?
Unused data, messy meshes, broken transforms, random names everywhere.
Scene Cleanup Wizard fixes all of that in one click.
Clean scene. Smooth workflow. Less stress.

Quadify

Mon, 22 Dec 2025 16:10:47 +0000

Quadify: Manual Selective Quadification for Real Production Assets

Quadify is a Blender-based quadification tool designed around a simple observation:

Most production meshes do not benefit from global quadification.

Real assets are mixed by nature — hard-surface and organic elements, deforming and static parts, scanned and authored geometry — often combined in a single model. Treating all of that geometry as a uniform problem leads to unnecessary topology damage, cleanup work, and loss of author intent.

Quadify introduces a manual selective quadification workflow that allows artists to decide where quadification should be applied and where it should not.

The Problem Quadify Is Addressing

Manual Selective Quadification: Taking Back Control of Retopology

Mon, 22 Dec 2025 15:53:13 +0000

Quadification is often discussed as if it were a single operation: press a button, convert triangles to quads, and move on.

In real production environments, that framing is misleading.

Meshes used in games, VFX, visualization, and technical pipelines are rarely uniform. They are layered artifacts—built over time, modified by different tools, combined from scans, CAD data, or kitbashed parts. Expecting a single global quadification pass to treat all of that geometry appropriately is not only unrealistic, it is often counterproductive.

This update introduces Manual Selective Quadification, a workflow designed around how assets are actually built and used. Rather than attempting to “solve” topology everywhere, it allows artists to decide where quadification is appropriate, where it is unnecessary, and where it should be avoided entirely.

This article explains the reasoning behind that design, how to use it effectively, and why selective quadification is often the most technically correct approach.

What Quadification Is Really For

Quadification is not an aesthetic goal.
It is a functional intervention.

Quads are valuable because they:

Deform predictably during animation

Subdivide cleanly

Support sculpting and surface refinement

Produce more stable shading under certain workflows

But not all geometry needs these properties.

Many real-world assets include:

Rigid mechanical components

Flat or planar surfaces

Boolean-heavy CAD geometry

Already-acceptable triangulation

Non-deforming or secondary elements

Applying quadification indiscriminately to these areas does not improve the asset. In many cases, it actively degrades it by introducing unnecessary edge flow, breaking hard edges, or increasing cleanup time.

The mistake is treating quadification as a requirement rather than a tool.

Why Global Quadification Breaks Down

Global quadification workflows implicitly assume three things:

All parts of a mesh have the same topology needs

A single algorithmic strategy is suitable everywhere

Artistic intent can be inferred from geometry alone

These assumptions do not hold in production.

Consider a vehicle model:

Tires benefit from controlled quad flow

Body panels may already be clean

Interior parts may never deform

Bolts, trims, and small details often should remain untouched

A global quadification pass treats all of these regions as equivalent problems. The result is predictable: some areas improve, others degrade, and the overall cleanup cost increases.

Manual Selective Quadification exists to break this pattern.

The Core Idea: Apply Automation Only Where It Helps

Selective quadification is built on a simple premise:

The artist already knows which parts of the mesh are problematic.

Instead of forcing automation to guess, the workflow allows the artist to explicitly declare intent.

This shifts the role of automation:

From decision-maker → to execution engine

From global transformer → to localized operator

Automation still does the heavy lifting—but only where it has been invited to do so.

Selection as a Technical Signal

In this workflow, selection is not just a UI convenience.
It is a semantic input.

When you select specific meshes and set the target mode to Selected, you are providing information that no algorithm can reliably infer:

These areas deform

These areas will be subdivided

These areas currently have poor topology

These areas justify restructuring

Everything not selected implicitly communicates the opposite:

Preserve existing structure

Do not reinterpret intent

Avoid unnecessary changes

This is a far stronger signal than curvature analysis or density heuristics alone.

Practical Workflow Breakdown

Evaluate the Asset in Regions

Instead of treating the mesh as a single unit, identify regions with different requirements:

Deforming vs static

Organic vs mechanical

High-density vs low-density

Legacy/problematic vs acceptable

This is already how experienced artists think—the tool simply aligns with that mental model.

Select Only What Needs Quadification

Using viewport selection or the outliner:

Select meshes or parts that genuinely benefit from quadification

Leave stable or intentional topology untouched

The goal is precision, not completeness.

Set Target Mode to “Selected”

This constrains quadification strictly to the selected elements:

No global reinterpretation

No accidental topology damage elsewhere

No unnecessary processing

Run Quadify

Quadification is applied only where specified, producing a hybrid result:

Automated quad flow where useful

Original topology preserved elsewhere

Predictable outcomes with less cleanup

Why This Matters in Real Production

Selective quadification is not just a quality-of-life feature—it is a production safeguard.

It helps:

Reduce unintended topology changes

Preserve authored edge flow

Minimize downstream cleanup

Maintain consistency across iterations

Most importantly, it acknowledges a reality often ignored by automation tools: artists already understand their assets better than any heuristic.

Broader Design Philosophy

This update reflects a broader shift in tool design:

Automation should amplify judgment, not replace it.

Instead of pursuing a mythical one-click solution, Manual Selective Quadification embraces constraint, intent, and context. It allows automation to work with artistic decision-making rather than against it.

This philosophy underpins the continued development of Quadify as a production tool rather than a novelty feature set. For those interested in exploring the tool in more depth, Quadify is available as part of its ongoing development and update cycle:
Quadify

Docs
https://quadify3d.com

The emphasis, however, remains on workflow clarity rather than feature accumulation.

When Selective Quadification Is (and Isn’t) Appropriate

Use it when:

Only parts of a mesh have poor topology

Assets combine hard-surface and organic elements

You want predictable, low-risk automation

Avoid it when:

You are in the early blockout stages

The entire mesh clearly needs uniform restructuring

Manual retopology is intentionally required everywhere

Like any effective tool, it is about choosing the right moment.

Final Thoughts

Quadification should not be an act of faith.
It should be an informed decision.

Manual Selective Quadification reframes quadification as a targeted operation rather than a blanket transformation. By allowing artists to control where automation applies, it reduces risk, preserves intent, and aligns topology changes with real production needs.

It does not attempt to outthink the artist.
It simply executes when the artist decides it should.

That shift—subtle as it may seem—makes a meaningful difference.

The Blender ↔ Unity Axis & Scale Problem: A Complete Technical Guide

Wed, 03 Dec 2025 21:45:56 +0000

The Blender ↔ Unity Axis & Scale Problem: A Complete Technical Guide

(and How Unit & Scale Doctor Pro Solves It Reliably)

1. Introduction — The Silent Production Killer

Every 3D developer eventually encounters the classic trap:

“It looked correct in Blender… but Unity imported it wrong.”
Rotations are flipped.
Objects appear microscopic or gigantic.
Animations distort.
Rig orientations break.
Prefabs drift or rotate 90°.
Root bones flip forward.

This is not user error—it’s the unavoidable result of two unrelated coordinate systems colliding.

Unity and Blender simply do not speak the same native “3D language.”

This article is a deep dive into:

Why scale & axis mismatches occur
The real mathematical and pipeline causes
Why attempting to ‘just apply transforms’ is unreliable
How to manually fix models in a production-safe, deterministic way
How to automate everything with Unit & Scale Doctor Pro

If you build technical art pipelines, maintain game studios' asset workflows, or run multi-DCC pipelines, this is essential knowledge.

2. The Root Cause — Two Worlds, Two Coordinate Systems

Blender uses:

Unit: Meters by default, but functionally unitless
Axis: +Z up, +Y forward
Object default scale: (1,1,1)

Unity uses:

Unit: Meters but 1 Blender meter ≠ 1 Unity meter without context
Axis: +Y up, +Z forward
FBX importer behavior: secretly compensates, inconsistently

The Fundamental Conflict

Blender’s Z-up means the “world up” vector is different.
Unity’s Y-up means the “world up” vector is different.

This leads to the classic 90° rotation offset, often around X or sometimes Z, depending on export settings.

The scale mismatch is even worse:

Blender’s grid scale ≠ the FBX exporter’s unit scale
Unity’s FBX importer applies hidden conversions
Blender’s “Apply Scale” resets object-level scaling but alters animation meaning
Armatures store rest pose matrices relative to Blender’s coordinate system

If you think this sounds messy—you’re correct.
And every studio spends hundreds of hours per year fighting it.

3. The Axis Dichotomy — Why Objects Rotate Wrong

Case 1: Blender to Unity Rotation

Blender’s +Y forward is Unity’s +Z forward.

Converting between the two requires:

Rotation = Rotate -90° around X

But this is only correct for static meshes.

For rigs, bones, animation curves, constraints, and IK solvers:

The armature object must rotate
Every bone’s roll must be corrected
Animation keyframes must be reinterpreted

If you simply “apply” the rotation:

IK chains break
Pose orientation becomes invalid
Animation curves produce different results
Bone roll becomes inconsistent (critical for weapons, fingers, mechanical rigs)

This is why the internet is full of contradictory advice—
because most of it works for simple meshes, but destroys complex rigs.

4. The Scale Dichotomy — Why Objects Import Too Small or Too Large

Key misconception:

“Blender units = meters = Unity meters.”

This is only theoretically true.

Here’s the reality:

Blender's Exporters

FBX exporter has hidden unit scaling
glTF uses meters but assumes Z-up needs conversion
OBJ has no unit semantics
CAD imports often come in cm/mm

Unity’s Importers

FBX importer has a Scale Factor (sometimes 0.01)
Legacy FBX workflows still assume Maya’s centimeter world
glTF importer assumes meters
CAD importers assume millimeters
Custom pipelines override scale silently

In practice, you see:

Assets 100× too small
Assets 1/100th expected size
Rigs where animation offsets are scaled differently
Physics collider mismatches
Prefabs with broken child offsets

Scaling is not universal.
Scaling is hierarchical, order-dependent, and context-dependent.

“Apply Scale (Ctrl+A)” solves nearly nothing reliably across a full production pipeline.

5. Why "Apply All Transforms" Is a Pipeline Trap

Applying rotation & scale at the object level seems tempting—but it is destructive:

It breaks:

Animation tracks
Rig rest pose data
IK constraints
Bone hierarchy matrices
Driver-based rigs
Constraints that assume world vs local transforms
Any rig authored for Blender’s Z-up world

Studios often apply transforms to fix one asset, but create inconsistencies with others.

This leads to asset drift, where each mesh slowly becomes different from others in the pipeline.

This is how productions collapse under their own asset inconsistency.

6. The Correct Manual Approach (If You Must Do It Manually)

Step 1 — Choose a Pipeline Convention

Examples:

Unity: Y-up, meters, 1:1 scale
Unity (Maya-style): centimeters, 0.01 scale
glTF: meters, Z-up → Y-up conversion

Step 2 — Standardize Blender Scene

World's unit scale
Scene orientation
Grid scale
Import scale adjustments

Step 3 — Fix Object Transforms Without Breaking Rigs

Convert orientation using matrix math, not rotations
Rebuild bone rolls in correct order
Resample animation curves
Normalize scale hierarchies

Step 4 — Validate

Every object must be:

Scale: (1,1,1)
Rotation: correct forward/up axes
Location: zeroed or pipeline-safe
Bone rest pose: consistent
Animations: stable after conversion

This is why studios use specialized tools—
because doing this manually for hundreds of assets is not feasible.

7. Why You Need an Automated System (Not a Manual Workflow)

A studio pipeline must guarantee:

Every asset is export-safe
Every file uses identical conventions
Transforms are mathematically correct
Rigs are preserved
No artist “accidentally breaks scale”
No asset slowly deviates from conventions over time

This is the reason tools like Unit & Scale Doctor Pro exist—
to solve a problem that is mathematically deterministic but tedious and error-prone for humans.

8. Unit & Scale Doctor Pro — What It Actually Does

Based on the README and source files in your package, the tool provides:

✔ Multi-Engine Profile System

Switch an entire Blender scene to:

Unity (meters / centimeters / millimeters workflows)
Unreal
glTF
CAD pipelines
Custom studio conventions

✔ Object, Mesh, and Armature Correction

It rewrites:

Object matrices
Mesh local → world conversions
Armature rest pose matrices
Bone roll normalization
Animation data curve remapping

✔ Non-Destructive Fixing

The tool ensures:

No rig is lost
No animation is destroyed
No mesh is warped
No parenting hierarchy breaks

✔ A Full Validation System

It detects inconsistencies such as:

Wrong scale
Hidden object scale offsets
Negative scaling
Axis flips
Bone roll inconsistencies
Meshes containing multiple transform spaces

✔ One-Click Scene Standardization

A complete “reset” that makes the entire project engine-ready.

This is exactly what large studios build internally—
but you have it packaged and production-ready.

9. How It Fixes Everything Automatically

Here’s what a typical Unit & Scale Doctor Pro pipeline does under the hood:

Step A — Scene Fingerprinting

It scans every object:

Type
Transform
Parent hierarchy
Mesh data
Armature bind poses
Animation data

Step B — Determine Required Conversions

Using the selected profile, it derives:

Required world up axis
Forward direction
Unit scale multiplier
Mesh shrinkwrap conversions
Armature remapping rules

Step C — Apply Matrix-Level Transform Fixes

It rewrites transforms directly in matrix form:

M_corrected = ConversionMatrix * M_original

This preserves:

Bone rest pose
Animation curves
Rig constraints

Step D — Clean / Bake / Normalize

Zero object scales
Fix bone rolls deterministically
Rebuild animation curves
Validate length units
Normalize mesh normals

Step E — Pipeline Safe Export

FBX-safe rotation
glTF-safe unit scale
Unity-ready hierarchy
Unreal-ready orientation

The entire process becomes deterministic and repeatable.

10. Practical Example — Blender to Unity (Correct Workflow)

Without Unit & Scale Doctor Pro

Export FBX
Import into Unity
Fix rotation manually
Fix scale manually
Fix animation drift
Fix rig orientations
Re-export when something breaks

Every asset becomes a small crisis.

With Unit & Scale Doctor Pro

Choose Unity profile
Click Fix Scene
Export FBX normally
Import into Unity and it “just works”

This eliminates rotational offsets, scale mismatches, and animation distortions.

11. Receipts for Technical Artists — Why This Matters

A good TA knows:

Scale drift kills animation pipelines
Hand-authored fixes destroy determinism
Rig rest poses must be mathematically preserved
Axis conversion is matrix math, not rotation

Unit & Scale Doctor Pro fills the gap Blender never will:

A consistent, safe, automated transformation pipeline.

12. Conclusion — The Right Way to Handle Axis & Scale Forever

The Blender ↔ Unity scale/axis mismatch is unavoidable.
But the chaos surrounding it is optional.

At a high level:

Blender uses Z-up
Unity uses Y-up
Scale semantics are inconsistent
Animations and rigs magnify errors
Manual fixes are destructive
Studio pipelines require determinism

The fix:

Understand the math
Fix transforms non-destructively
Use deterministic conversion methods
Rely on a tool built specifically for this problem

This is exactly what Unit & Scale Doctor Pro provides:
A complete, automated, studio-safe solution to a 20-year-old industry headache.

Get it on Superhive Marketplace via this link: https://superhivemarket.com/products/unit--scale-doctor

Coder Legion - Recent posts tagged blender

Designing a High-Converting Forex Landing Page with Framer + 3D Workflow

I Built an ML Routing Engine for 3D Mesh Retopology — Here's How It Works

The problem: retopology algorithm selection is a classification task

The classifier: KNN with confidence blending

The hardest bug: voxel remesh freezing Blender

The community telemetry system

numpy boolean ambiguity in batch processing

What's live

I Built a Batch Asset Validator for Blender in Python — Here's What I Learned

I Built a Batch Asset Validator for Blender in Python — Here's What I Learned

The Core Problem: Validation Belongs Before Export, Not After

How It Works: Temp Scene Import Loop

The Modal Operator Pattern

Profile-Based Validation

The Checks

Import Failure Classification

The HTML Report

Watch the Full Demo

Get the Addon

What I'd Do Differently

ThreeDimensions Version-1.0.0 is here !

ThreeDimensions

Send your creations using ThreeDimensions in Models by filling in the Form. The best models will be added to the examples of ThreeDimensions. Others will be added to the models groups. See current submissions in Submissions. Do participate !

Overview

Feature Highlights

Installation

Quick Start

Geometry Nodes (Programmable)

Viewer

Architecture

License

Why We Built a Deterministic Render Gate for Blender (and Why “Final” Is a Lie Without One)

Quadify Base, Premium, & Pro

I build Blender automation tools. What repetitive production task should not exist anymore?

Demo video of smart uv tool at work

Scene cleanup wizard

Quadify

Manual Selective Quadification: Taking Back Control of Retopology

The Blender ↔ Unity Axis & Scale Problem: A Complete Technical Guide

The Blender ↔ Unity Axis & Scale Problem: A Complete Technical Guide

1. Introduction — The Silent Production Killer

2. The Root Cause — Two Worlds, Two Coordinate Systems

Blender uses:

Unity uses:

The Fundamental Conflict

3. The Axis Dichotomy — Why Objects Rotate Wrong

Case 1: Blender to Unity Rotation

4. The Scale Dichotomy — Why Objects Import Too Small or Too Large

Key misconception:

Blender's Exporters

Unity’s Importers

5. Why "Apply All Transforms" Is a Pipeline Trap

It breaks:

6. The Correct Manual Approach (If You Must Do It Manually)

Step 1 — Choose a Pipeline Convention

Step 2 — Standardize Blender Scene

Step 3 — Fix Object Transforms Without Breaking Rigs

Step 4 — Validate

7. Why You Need an Automated System (Not a Manual Workflow)

8. Unit & Scale Doctor Pro — What It Actually Does

✔ Multi-Engine Profile System

✔ Object, Mesh, and Armature Correction

✔ Non-Destructive Fixing

✔ A Full Validation System

✔ One-Click Scene Standardization

9. How It Fixes Everything Automatically

Step A — Scene Fingerprinting

Step B — Determine Required Conversions

Step C — Apply Matrix-Level Transform Fixes

Step D — Clean / Bake / Normalize

Step E — Pipeline Safe Export

10. Practical Example — Blender to Unity (Correct Workflow)

Without Unit & Scale Doctor Pro

With Unit & Scale Doctor Pro

11. Receipts for Technical Artists — Why This Matters

12. Conclusion — The Right Way to Handle Axis & Scale Forever

At a high level:

The fix: