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

[SPIKE] DYN-2473: Use light-weight geometry primitives lib for direct manipulation geometry #14973

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

aparajit-pratap
Copy link
Contributor

@aparajit-pratap aparajit-pratap commented Feb 26, 2024

Purpose

Use lightweight geometry primitives lib for direct manipulation geometry.

Note: This PR still uses a mix of ProtoGeo and geometry primitive types as the Geometry primitives library doesn't support any geometric operations or calculations. This PR doesn't replace the following more complex operations on ProtoGeometry Curve with corresponding functions for geometry primitive types using in PointOnCurveManipulator.

  • Curve.PointAtParameter
  • Curve.TangentAtParameter
  • Curve.ParameterAtPoint
  • Curve.ClosesPointTo

TODO:

  • The above methods need to be implemented for all Protogeo curve types. These could be implemented by hand in C# using references to common Math and computational geometry algorithms.
  • The gizmo seems to jump to a new position on a camera changed event, for example, when orbiting - this needs some debugging
  • The gizmo isn't redrawn while dragging to intermediate points, it's redrawn only at the final position on a mouse up event - this too is a deviation from the old behavior and needs to be fixed

Declarations

Check these if you believe they are true

  • The codebase is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning and are documented in the API Changes document.
  • This PR modifies some build requirements and the readme is updated
  • This PR contains no files larger than 50 MB

Copy link

github-actions bot commented Feb 26, 2024

UI Smoke Tests

Test: success. 2 passed, 0 failed.
TestComplete Test Result
Workflow Run: UI Smoke Tests
Check: UI Smoke Tests - net8.0


private TranslationGizmo gizmo;

// Holds manipulator axis and input node pair for each input port.
// This collection is accessed from multiple threads
private ConcurrentDictionary<int, Tuple<Vector, NodeModel>> indexedAxisNodePairs = new ConcurrentDictionary<int, Tuple<Vector, NodeModel>>();
private readonly ConcurrentDictionary<int, Tuple<Vector, NodeModel>> indexedAxisNodePairs
Copy link
Member

Choose a reason for hiding this comment

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

in general which threads access this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's been a while but as far as I remember this could be accessed by scheduler and UI threads.

}
if (Math.Abs(amount) > MIN_OFFSET_VAL)
{
dynamic uiNode = item.Value.Item2;
Copy link
Member

Choose a reason for hiding this comment

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

I know this is existing code, but do we really need dynamic here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this was dynamic since it was originally intended to be applicable to different types of input nodes, not just sliders. In the next line, it uses the Value property, which isn't defined on the NodeModel class, but which is the common base class for all nodes (input nodes in this case).

Copy link
Member

Choose a reason for hiding this comment

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

so it sounds like you don't need dynamic you need to use the common base class or an interface etc?

I think using the dlr has significant performance implications.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I guess we could introduce a new interface with a single Value member.

Copy link
Member

Choose a reason for hiding this comment

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

I actually think that @twastvedt wanted a similar interface for accessing input nodes in player without referencing the actual NodeModel types.

Copy link
Member

Choose a reason for hiding this comment

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

}
}

// TODO: Implement this method
Copy link
Member

Choose a reason for hiding this comment

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

you mean implement this method without relying on LibG?

Copy link
Member

@mjkkirschner mjkkirschner Feb 27, 2024

Choose a reason for hiding this comment

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

I am wondering if it makes more sense to implement these methods in LibG or in the Primitives lib so they can be tested against the same curve tests we run on LibG geo? (rather than implementing them here?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it's about implementing it without relying on LibG. I was thinking to create a new geometry primitives project and move these functions into that but it could make more sense to make it part of LibG.

@avidit avidit changed the title [SPIKE] Dyn 2473: Use light-weight geometry primitives lib for direct manipulation geometry [SPIKE] DYN-2473: Use light-weight geometry primitives lib for direct manipulation geometry Apr 29, 2024
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.

2 participants