CAD Like transform

In order to change view use

  • middle mouse alone to rotate
  • middle mouse + hold SHIFT to pan
  • mouse wheel to zoom in / out

CAD Transform rely on ALT and CTRL while running to allow small steps and “snap to units”

Hello @stephen_leger this is a great addon you have made! Coming from SolidWorks I greatly miss things like mating and aligning in just a click or two.

I have come across a snapping issue and am wondering if your addon can help do what I am trying to achieve here:

I got some great help from @sizzler on how to do this, and was just wondering if your addon can do this in a few less steps? I watched the video of a user demoing the addon, it looks great, but I wasn’t able to get the objects lined up how I wanted.

It seems that the snapping isn’t happening as I want due to the “hole” (imagine lining up/snapping a washer to a bolt and a nut) in the geometry. Another obstacle may be that the objects are not in standard orientation, they come in (from SolidWorks) at odd angles based on the design.

Thank you for any input.

-Punker

Dear Stephen, it works for default Blender keymap only. But there are a lot of people, who have experience in such packages like Modo, Maya etc. And they prefer using Industry Compatible keymap with Alt+LMB/MMB/RMB navigation. For this part of blender people your addon works only partially (I described its behavior above).

In MESHmachine it was solved just by adding the following:

“or (event.alt and event.type in {‘LEFTMOUSE’, ‘MIDDLEMOUSE’, ‘RIGHTMOUSE’})”

Hi Antony,

Under blender 3.0, you may replace this file in folder addon, in “industry compatible” keymap, you are able to use ctrl instead of alt for snap to small values, so alt remains available for viewport navigation.

slcad_transform.py (126.5 KB)

1 Like

Viewport navigation works charmingly well now(tested in 2.93.5)! :partying_face:
Thank you so much, Stephen! :clap:

Pardon me if this was already discussed, but there is a small inconvenience when using this addon, that is:
Snap settings don’t get saved with Blender file, like the native snap settings do.
When I use CAD Transform on Blender 3.0, I always start with only vertex snap turned on, and have to pick other snaps manually, even if I previously saved and closed my file with other CAD Transform snaps turned on.
It would be very useful to have those snap settings saved.
There could also be a setting set in addon preferences, to choose default snaps for every new model.
Please, consider implementing this for the next release.
Thank you and have a Merry Christmas!

1 Like

Hello again,
I’ve encountered an extremely strange behaviour.
I’m trying to move some connected faces along an axis. They are disconnected from the remaining geometry of the object. As long as I move geometry without constraining axis, it goes fine, but when I tap X/Y/Z to constrain an axis and then move my geometry forth and back for a while, it literally gets massacred - some vertices get moved randomly, and faces get stuck together, before I even confirm transformation.
It’s really hard to explain, so please see the attachments:

CAD transform issue.blend (1.0 MB)

Before transformation:

After:

Same video on google drive and wetransfer:
https://drive.google.com/file/d/1ZrqTqzm02F6-eLyvwpy5JMCXFxz-Fvh2/view?usp=sharing

This problem doesn’t occur with Blender’s native transformations.

The same issue persists across Blender 2.92 and 3.0.

Can you tell if it’s a bug or I am doing something wrong?

Getting an error in Blender 2.93 LTS using the latest version on gumroad. Happens after pressing “G” while the tool is active:

Error: Python: Traceback (most recent call last):
File “C:\Users\testure\AppData\Roaming\Blender Foundation\Blender\2.93\scripts\addons\slcad_transform\slcad_transform.py”, line 3192, in invoke
self.action = self.default_action
File “C:\Users\testure\AppData\Roaming\Blender Foundation\Blender\2.93\scripts\addons\slcad_transform\slcad_transform.py”, line 3105, in init
local = context.active_object.matrix_world.normalized()
File “C:\Users\testure\AppData\Roaming\Blender Foundation\Blender\2.93\scripts\addons\slcad_transform\slcad_snap.py”, line 223, in start
self.update_gl_snap()
File “C:\Users\testure\AppData\Roaming\Blender Foundation\Blender\2.93\scripts\addons\slcad_transform\slcad_snap.py”, line 697, in update_gl_snap
self.gl_stack.set_snap_mode(self.snap_mode)
File "C:\Users\testure\AppData\Roaming\Blender Foundation\Blender\2.93\scripts\addons\slcad_transform\snap_context_init
.py", line 235, in set_snap_mode
def update_drawn_snap_object(self, snap_obj):
File "C:\Users\testure\AppData\Roaming\Blender Foundation\Blender\2.93\scripts\addons\slcad_transform\snap_context_init
.py", line 223, in update_all
if not self.freed:
AttributeError: ‘GPUOffScreen’ object has no attribute ‘texture_color’

Pay attention at downloading the right version !
This error means you setup CAD Transform for blender 3.0

Looks strange, i’m unable to repro this behaviour. Basically in “Grab” mode, CAD Transform apply the exact same transform matrix to every vertex, so there should never be any deformation.
The only reason i can see for such error is a projection to near “infinite” distance with a “parallel to edge” or another setting like that., or an issue with “from” snap point.

slcad_transform_0.93.2.beta.3 says it is compatible with Blender 3.0, it doesn’t say anything about being explicitly incompatible with 2.93. Thanks for the info.

for what it’s worth, you should consider version checking in your module to avoid maintaining two separate forks of your addon (unless of course your plan is to deprecate 2.93 entirely and focus on 3.0)

1 Like

If I got you right, this means that the error happens when selected transformed geometry “jumps” to infinity or near infinity before picking the target location, right?
I don’t know, is there anything I can do to get you closer to reproducing this error?

This post was flagged by the community and is temporarily hidden.

I must do something wrong.
Sometimes when I scale object with vertex snapping turn on, I got weird rotation information.

Any idea how to fix it?

Nothing wrong on your side, this is a precision / rounding issue and is expected in single precision context.
The value represent misalignment of 3cm at 100km, so you will still reach the moon but maybe miss the right crater if you try to land on mars using single precision math.

Got it!
Thanks for your work.