[SPIKE] DYN-2473: Use light-weight geometry primitives lib for direct manipulation geometry #14973
Conversation
UI Smoke TestsTest: success. 2 passed, 0 failed. |
|
|
||
| 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 |
There was a problem hiding this comment.
in general which threads access this?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
I know this is existing code, but do we really need dynamic here?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I guess we could introduce a new interface with a single Value member.
There was a problem hiding this comment.
I actually think that @twastvedt wanted a similar interface for accessing input nodes in player without referencing the actual NodeModel types.
There was a problem hiding this comment.
| } | ||
| } | ||
|
|
||
| // TODO: Implement this method |
There was a problem hiding this comment.
you mean implement this method without relying on LibG?
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
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
changed the title
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
Curvewith corresponding functions for geometry primitive types using inPointOnCurveManipulator.TODO:
Declarations
Check these if you believe they are true
*.resxfiles