Powerful variable system needed please

Hi, dear Shapr3D team:

I’ve just been playing around with Shapr3D for a few hours, and this powerful modeling platform deeply attracts me.

Here are some ideas from me after trying out what Shapr3D provides. Hope you like them.

The problems that these features will solve:

  • When complex expressions are needed, allow unit changing or make functions accept more units.

  • Optionally make a constraint or a feature be the provider of the value of a certain variable.

  • Provide some variables based on some tool effects.

More flexible units in expressions:

I’m facing some failures when trying to achieve some calculations in expressions. I guess they all involve some unit issues.

Example one: function floor refuses a length variable as the parameter.

Say there is a length variable LengthLimit = 3.76 mm. The parser complains when I try to create a variable with expression Length = floor(LengthLimit) mm.

If there is already some way to make that possible, please help me.

Example two: calculate the length of the third side of a right triangle.

Say we have the length of the first two sides: A = ... & B = .... It is not possible to get the third side like this: C = sqrt(A*A + B*B).

There is a workaround expression: C = A / sin( arctan( A / B ) ) though…

All problems above are triggered by unit checking:

  • Length cannot be used as Number.

  • Area cannot be used as Length.

Maybe this is by design, but I’m not aware of the reason why that is. Please tell me some design rules about this if you’d like to.

Variable provider:

Shapr3D allows me to create a variable from the value of a constraint. That is awesome! And soon an idea came to my mind: what if we can drag around a feature in sketch or model to modify a variable directly?

Provide an icon around the constraint or feature that references a variable. Click on the icon to switch this constraint or feature into the provider of this variable or back into the consumer of this variable.

There may be more than one provider for a variable. Display an element list below the variable definition in the history bar to show providers and consumers of this variable.

Actions like add, remove, or switch the role of an element could be done with this list.

The variable could be locked or unlocked. When it is locked, the only way to change its value is the input box on the definition card. When it is unlocked, dragging any of its provider constraints or features could change its value. Those provider constraints or features should lose the count of the freedom limit when the variable is unlocked.

Tool-based variables:

This feature, if we have it, will reduce the complexity of working with patterns.

Imagine that we have a long face, and we want to make a sequence of holes on it. The diameter of these holes changes by a small factor from the first one to the last one.

The work will be hard if we have to set the diameter of each hole one by one.

We can introduce a kind of variable, created by pattern tools, that applies differently to each item of this pattern.

For instance, let’s introduce a variable named __repeat_index which is a number indicating the number of the element in the linear sequence. This variable is different in each element of the linear sequence, varying from 1 to n.

Variables like this use reserved names so that they won’t confuse users.

Consider that multiple patterns are applied; we could add the tool history name or layer number to the variable name to make it unique.

__repeat_index_0

__repeat_index_important_history

Items outside of any pattern could reference this kind of variables too, and those variables hold a zero-value of the correct unit.

Recommend some variables:

__repeat_index

__linear_total_dist

__rotation_angle

Thank you for reading.

I ended up using the number type for every variable. It can be converted to any other type without any problems.

1 Like