[Feature Request] Worksession Instance Transform

Rhino Rhino for Windows
, ,
1

[Feature Request]

Worksession Instance Transform
Decoupling Model Space from Assembly Space

(Like XREF / Instances)

Problem

Worksessions assume all files are already aligned in world space.

That forces:

  • Modeling far from origin (bad precision)

  • Manual pre-alignment (fragile)

  • Editing source files just to reposition (breaks modularity)

What’s Missing

A transform layer per attached file

Right now:

  • :cross_mark: No position

  • :cross_mark: No rotation

  • :cross_mark: No scale

Worksessions = reference only, no placement

Proposal

Each attached .3dm gets a non-destructive transform:

  • Position (X,Y,Z)

  • Rotation

  • Scale

Stored in the Worksession .rws , and not in the .3dm file.

Why

All modern systems do this:

  • AutoCAD → XREF insertion

  • Autodesk Revit → linked models

  • Blender → linked collections

  • Unity / Unreal Engine → transforms

Model locally. Assemble globally.

Why Not Blocks?

Blocks work, but:

  • Not file-level

  • Add hierarchy overhead

  • Not ideal for large multi-file workflows

Impact

  • Keep the active open geometry near the origin :white_check_mark:

  • True modular workflow :white_check_mark:

  • Clean collaboration :white_check_mark:

  • Massive improvement for large projects :white_check_mark:

Simple UI

Right-click file → Edit Transform…

Simple Implementation

Important: Must also remember previous transforms

Cons

FBX can’t export .rws transforms properties

Closing

This is a small feature, simple to implement with a huge impact.

Worksessions need placement, not just visibility.

image
image1807×1072 125 KB

2

Assume much?

3

I use linked block a lot with reference layer style and it works really much like worksession.
Did you tried? What’s the cons?

4

Yes, my presumption is as big as my hope for Rhino.

In the software world, it seems simple on the surface, but if you have “fragile” spaghetti code, implementation becomes a nightmare, or worse, impossible.

I like the Open-Closed code Principle with Test-Driven Development (TDD), for designing small components that do one thing responsability, using one script as clear interface. This keeps the software easy to extend, simple to keep it clean and maintain without slow you down