Feature Request: Perspective-Locked Isometric / Engineering Mode for Image

API Feedback
, , ,
1

I tested the image generator for a real engineering-style use case:
an exploded technical view of a modular 3×3×3 cube (27 elements).

The main issue:
during iterative refinements, the model changes topology and often transforms the single center core into a multi-cube block.

This makes it difficult to use for:

  • exploded technical diagrams

  • modular systems

  • CAD-like workflows

  • digital twin concepts

  • automotive service visualization

Requested improvement:
A perspective-locked engineering / isometric mode with topology preservation and exact object count locking.

This would be extremely useful for technical and design workflows.

2

Hi Karolek,

This is fantastic feedback and highlights a crucial limitation for technical users. The idea of a “perspective-locked engineering / isometric mode” to preserve topology and lock the exact object count is brilliant.

It would genuinely unlock powerful use cases for CAD-like workflows, technical diagrams, modular systems, and digital twin concepts. I fully support this feature request—it would be extremely useful for technical and design workflows.

Best,

Grewal

3

Thanks a lot for your support :wink:

4

Hey @Karolek, this is a really strong use case, appreciate you laying it out so clearly.

What you’re seeing comes up in similar scenarios. The model doesn’t fully preserve structure between iterations, so topology or object counts can shift, which makes technical diagrams tricky.

Your idea around perspective lock + topology preservation + exact count control makes a lot of sense for engineering and design workflows.

I’ve shared this with the team so it gets logged. Super helpful input like this.

In the meantime, one thing that can help a bit is restating strict constraints each time or regenerating from a detailed prompt instead of iterating.

If you end up finding a setup that keeps things stable, definitely worth sharing here.

-Mark G.

5

Interesting follow-up experiment:

I tried prompting the image model not as an “art generator” but as a “geometric construction system” focused on topology preservation, object persistence, constraints and spatial consistency.

What surprised me is that the model started inventing concepts like:

  • topology lock

  • constraint solver

  • object persistence

  • diff checker

  • reproducible results

…which are actually very close to the kinds of systems that seem missing for engineering-grade image workflows.

This feels less like pure image generation and more like the model attempting to describe a hypothetical geometry-aware rendering pipeline.

Possibly relevant direction for:

  • CAD-like workflows

  • voxel/isometric systems

  • technical diagrams

  • topology-stable iteration

  • deterministic scene editing

ISOMETRIC_2_0
ISOMETRIC_2_01536×1024 443 KB

One interesting testcase was a Rubik’s cube structure.

The model could preserve approximate geometry, but still produced physically impossible cube states (same color appearing on logically incompatible faces), which seems to further highlight the lack of topology-aware constraints between iterations.

6

Additional observation from testing:

Using a Rubik’s Cube as a topology testcase turned out to be extremely useful because it exposes structural inconsistencies immediately.

Early generations produced visually plausible but physically impossible cube states (invalid cubie color relationships).

However, adding explicit structural rules such as:

  • edge pieces have exactly 2 colors,

  • corner pieces have exactly 3 colors,

  • center pieces have exactly 1 color,

combined with:

  • topology validation,

  • object persistence language,

  • and “physically valid” constraints,

significantly improved generation consistency.

This suggests that image generation stability may improve when the model is guided with explicit structural semantics instead of purely visual instructions.