Unlocking Blender’s Full Potential: Explicit Reference Modes for G/R/S

Extend Blender’s Modal Transform System with Optional Explicit Reference Modes

Summary

Blender’s G / R / S transform workflow is one of its strongest interaction concepts. It behaves almost like a small command language:

G → X → 2

means “move along X by 2”.

However, many transforms still depend on implicit UI state such as pivot point, cursor position, transform orientation, editor context, or other settings that are not expressed as part of the command itself.

I would like to propose extending Blender’s modal transform system with optional explicit reference/input modes .

The important part is that this should be purely additive.

Existing commands and existing behavior should remain exactly as they are today.

For example:

G → X → 0.5

would keep its current meaning.

An additional mode could allow something like:

G → X → A → 0.5

where A means “Absolute”, so the entered value is interpreted as an absolute target coordinate rather than a relative translation.

A is only one example. The larger proposal is to make the modal transform system extensible enough to support explicit reference modes where they are useful.

Concrete usability problem

A simple example comes from the Movie Clip Editor.

Suppose I create a rectangular mask for a split-view and want one mask point to be placed exactly at:

X = 0.5

This means exactly half the image width.

There is currently no direct numerical X/Y input for the selected mask point.

An exact workaround is:

1. Set the 2D Cursor numerically to X = 0.5.
2. Set the pivot point to 2D Cursor.
3. Select one mask point.
4. Press S .
5. Enter 0 .

This works because Blender calculates scaling relative to the pivot:

new_position = pivot + (old_position - pivot) * factor

With a factor of zero, the selected point ends up exactly at the pivot.

Mathematically this is completely correct.

The problem is semantic.

A user who wants to:

“Move this point to X = 0.5”

does not naturally think:

“Set a pivot at X = 0.5 and scale the distance between the point and that pivot to zero.”

For a single point, Scale 0 is therefore technically elegant but difficult to discover and unnecessarily abstract, especially for users who do not think in terms of transformation mathematics.

With an explicit absolute mode, the same intention could potentially be expressed directly:

G → X → A → 0.5

Meaning:

“Move on X, using an absolute target value of 0.5.”

Why this is more than an “absolute move” feature

The main idea is not the A key itself.

The larger opportunity is to make Blender’s modal transform commands capable of expressing more of their own context.

Today, many instructions depend on state that has to be prepared beforehand:

• pivot point
• cursor position
• transform orientation
• snapping state
• editor-specific settings
• selection state

Some of this state will always be necessary.

But where a reference or interpretation can reasonably be expressed as part of the transform command itself, an explicit mode could make the operation more deterministic.

A transform command could conceptually become:

operation → constraint → optional reference/input mode → value

The existing short form would remain unchanged:

G → X → 0.5

The more explicit form would only be used when required:

G → X → A → 0.5

This could make Blender’s existing modal interaction model more powerful instead of introducing a separate interaction model.

Reproducibility and communication

One major advantage would be that transform instructions could become much easier to communicate in text.

A tutorial, documentation page, forum answer or support response could say:

G X A 0.5

and the important interpretation of the value would be part of the command itself.

This is more robust than instructions such as:

“First change the pivot point, then position the cursor, then make sure the correct transform orientation is active, then perform the transform.”

Explicit commands reduce dependence on hidden UI state.

This could improve:

• tutorials
• documentation
• support instructions
• reproducible workflows
• communication between users
• discoverability
• accessibility for users who find hidden state difficult to track

Blender is already unusually good at expressing complex operations through sequences of keys. Making more of the transform context expressible through those sequences could further strengthen one of Blender’s biggest usability advantages.

Backward compatibility

This proposal should not change or replace any existing transform behavior.

In particular:

• G , R and S should continue to behave exactly as they do now.
• Existing shortcuts should remain unchanged.
• Existing tutorials should remain valid.
• Existing workflows and muscle memory should not be affected.
• S 0 should continue to work exactly as it does today.

Explicit modes would only be optional modifiers.

If the user does not enter one, Blender behaves exactly as before.

A useful general rule could be:

Explicit transform parameters override implicit UI state only for the current operation. If they are omitted, Blender uses its existing behavior unchanged.

This provides a path for improving discoverability and reproducibility without simplifying or weakening Blender’s existing transform system.

Generic design rather than editor-specific workarounds

The Mask Editor is only a concrete example.

A narrow solution would be to add a special “Selection to 2D Cursor” command or additional coordinate fields to that editor.

Those could still be useful, but they do not address the broader issue.

The more general question is:

Can Blender’s modal transform language express the intended reference or interpretation directly when the user needs it?

Absolute input is one obvious example.

Other explicit reference modes might also be useful in the future.

I do not think the proposal should prescribe exactly which modes Blender needs, which keys they should use, or how they should be implemented internally.

That is better evaluated by Blender developers and UX designers.

Likewise, not every mode necessarily needs to work with every transform type or data type.

For example, an absolute position has an obvious meaning for translation, while “absolute scale” for a group of mesh vertices may require a more careful definition.

The important architectural idea is that the system should allow optional explicit modes where their meaning is useful and well-defined.

Why this fits Blender

Blender already has a powerful modal transform language.

The proposal does not replace that design.

It extends it.

The current workflow is optimized for short commands when the user already has the correct context configured.

Optional explicit modes would add a second strength:

short commands when the context is already correct; explicit, self-contained commands when the context needs to be part of the instruction.

That could improve usability without sacrificing Blender’s efficiency or existing workflows.

The concrete example:

G → X → A → 0.5

is therefore less important as a specific syntax proposal than as an illustration of a larger possibility:

Blender’s transform system could express more of the user’s actual intent directly, instead of sometimes requiring mathematically correct but semantically indirect workarounds.