Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added commands for object transforming (translate, rotate and scale) #441

Merged
merged 13 commits into from
Jan 8, 2025

Conversation

benjamaan476
Copy link
Contributor

@benjamaan476 benjamaan476 commented Aug 8, 2024

Added Commands to transform objects:

  • SetObject(Position/Rotation/Scale) will set the specified local value to the passed in argument
  • (Translate/Rotate/Scale)Object is a relative change based on the current local value. E.g. translate({5, 0, 0}) will move the object 5 units along the x-axis from say {11, 0, 0} to {16, 0, 0}. SetObjectPosition({5, 0, 0}) will set the position to {5, 0, 0}
  • SetObjectParent will set the parent object of an object. The object (child) will inherit its parent's local values and its values will be applied on top of those values

@benjamaan476
Copy link
Contributor Author

benjamaan476 commented Aug 8, 2024

Don't merge - testing against the engine

Copy link

codecov bot commented Aug 8, 2024

Codecov Report

Attention: Patch coverage is 0% with 8 lines in your changes missing coverage. Please review.

Please upload report for BASE (main@d87e394). Learn more about missing BASE report.

Files with missing lines Patch % Lines
modeling-cmds/src/shared.rs 0.00% 2 Missing ⚠️
modeling-cmds/src/def_enum.rs 0.00% 1 Missing ⚠️
modeling-cmds/src/format/obj.rs 0.00% 1 Missing ⚠️
modeling-cmds/src/format/ply.rs 0.00% 1 Missing ⚠️
modeling-cmds/src/format/sldprt.rs 0.00% 1 Missing ⚠️
modeling-cmds/src/format/step.rs 0.00% 1 Missing ⚠️
modeling-cmds/src/format/stl.rs 0.00% 1 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #441   +/-   ##
=======================================
  Coverage        ?   25.33%           
=======================================
  Files           ?       35           
  Lines           ?     2096           
  Branches        ?        0           
=======================================
  Hits            ?      531           
  Misses          ?     1565           
  Partials        ?        0           
Flag Coverage Δ
unittests 25.33% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Comment on lines 1077 to 1100
#[derive(Clone, Debug, Deserialize, JsonSchema, Serialize)]
struct TransformBy<T> {
/// The scale, or rotation, or translation.
property: T,
/// If true, overwrite the previous value with this.
/// If false, the object will be scaled, or translated, or rotated, etc.
set: bool,
}

///Set the transform of an object.
#[derive(
Clone, Debug, Deserialize, JsonSchema, Serialize, ModelingCmdVariantEmpty,
)]
pub struct SetObjectTransform
{
///Id of the object whose transform is to be set
pub object_id: Uuid,
#[serde(default)]
translate: Option<TransformBy<Point3d>>,
#[serde(default)]
rotate: Option<TransformBy<Point3d>>,
#[serde(default)]
scale: Option<TransformBy<Point3d>>,
}
Copy link
Contributor

@lf94 lf94 Aug 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following is just a suggestion/idea. We can further reduce bandwidth by instead sending a list of transforms. Otherwise looks great!

Suggested change
#[derive(Clone, Debug, Deserialize, JsonSchema, Serialize)]
struct TransformBy<T> {
/// The scale, or rotation, or translation.
property: T,
/// If true, overwrite the previous value with this.
/// If false, the object will be scaled, or translated, or rotated, etc.
set: bool,
}
///Set the transform of an object.
#[derive(
Clone, Debug, Deserialize, JsonSchema, Serialize, ModelingCmdVariantEmpty,
)]
pub struct SetObjectTransform
{
///Id of the object whose transform is to be set
pub object_id: Uuid,
#[serde(default)]
translate: Option<TransformBy<Point3d>>,
#[serde(default)]
rotate: Option<TransformBy<Point3d>>,
#[serde(default)]
scale: Option<TransformBy<Point3d>>,
}
enum TransformOperation {
Translate,
Rotate,
Scale
}
struct Transform<T> {
operation: TransformOperation,
value: T,
set: bool,
}
///Set the transform of an object.
#[derive(
Clone, Debug, Deserialize, JsonSchema, Serialize, ModelingCmdVariantEmpty,
)]
pub struct SetObjectTransform
{
///Id of the object whose transform is to be set
pub object_id: Uuid,
transforms: Vec<Transform<Point3D>>
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about this, but this allows you to send multiple transforms that overwrite each other, e.g. [(Translate, <0,0,0>), (Translate, <1,1,1>)]. So I think the current approach is better -- it limits you to sending at most one transform for a given property and the given project.

Copy link
Contributor

@lf94 lf94 Aug 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be desirable from a programmer or mathematician point of view to compose transforms in various ways, ways I cannot imagine - for example [(Translate, <0,0,0>), (Translate, <1,1,1>)] could be desirable if they are composing (have set: false). Otherwise I agree with you.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are knocking on the door of a transform stack here. Which is where you specify a chain of transforms one after the other that get applied in that order. Typically comes along with the ability to push and pop transforms to a stack that lets you get pretty flexible

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're now agreed that Transform endpoint should take a list of transforms.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So these transforms will get applied one by one if more than one is provided? Is it up to the user to handle the complexity of the list? E.g. if two translates are side by side that could have just been one aggregate transform.

/// If false, the previous value will be modified.
/// E.g. when translating, `set=true` will set a new location,
/// and `set=false` will translate the current location by the given X/Y/Z.
pub set: bool,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this not the same as relative? If it is then should we not call this relative for consistency?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having said that, if the intention is for relative to be the default then maybe absolute is a better name.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

relative, absolute, override. There are many ways of describing this

@alteous
Copy link
Contributor

alteous commented Jan 6, 2025

I'll assume the formatting changes in the format specific modules are a result of automated checks.

@jtran
Copy link
Contributor

jtran commented Jan 6, 2025

Please add PartialEq and ts-rs derives like in #708 before merging.

@benjamaan476
Copy link
Contributor Author

I'll assume the formatting changes in the format specific modules are a result of automated checks.

Yeah I don't know why my cargo fmt hits those files. I usually check that before a commit but I must have missed it

@benjamaan476 benjamaan476 requested review from alteous and lf94 January 7, 2025 20:39
modeling-cmds/src/def_enum.rs Outdated Show resolved Hide resolved
@benjamaan476 benjamaan476 merged commit d316d5d into main Jan 8, 2025
7 checks passed
@benjamaan476 benjamaan476 deleted the ben/transform branch January 8, 2025 16:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants