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

TweakPlug : Possible way to expose functionality needed by PrimitiveVariableTweaks #6154

Open
wants to merge 2 commits into
base: 1.5_maintenance
Choose a base branch
from

Conversation

danieldresser-ie
Copy link
Contributor

PrimitiveVariableTweaks will need to apply tweaks to array elements, which are not Data. I'm exploring ways to expose this functionality in TweakPlug without duplicating code.

This appears to work somewhat decently ( all the tests are passing ). My concerns are: what should this public function be called, and would it be better not to expose vectorAwareMin/vectorAwareMax ( these functions are only called in one place, so just pasting them in is totally an option ).

Any better ideas for an interface?

Copy link
Member

@johnhaddon johnhaddon left a comment

Choose a reason for hiding this comment

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

Looks pretty reasonable to me - I've made a few suggestions inline...

@@ -123,6 +123,15 @@ class GAFFER_API TweakPlug : public Gaffer::ValuePlug
MissingMode missingMode = MissingMode::Error
) const;

template< typename T >
static void applyNumericTweakValue(
Copy link
Member

Choose a reason for hiding this comment

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

Maybe just applyNumericTweak(), and return the result rather than pass dest by reference?

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've done this, though I didn't like using the same name for this and the other function named applyNumericTweak. I realized the other function is private though, so I've just renamed it applyNumericDataTweak ... is that reasonable?

@@ -179,4 +181,95 @@ bool TweaksPlug::applyTweaks(
return tweakApplied;
}

template<typename T>
T vectorAwareMin( const T &v1, const T &v2 )
Copy link
Member

Choose a reason for hiding this comment

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

Seems a bit odd for this to be in a public namespace. Could either put it in a Detail sub-namespace, or make it a private static method of TweakPlug?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Made private.

Comment on lines 258 to 261
// These cases are unused - we handle them outside of numericTweak.
// But the compiler gets unhappy if we don't handle some cases.
assert( false );
break;
Copy link
Member

Choose a reason for hiding this comment

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

I think this warrants an exception - now its in the public API, we can't make the same guarantee.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed.

throw IECore::Exception(
fmt::format(
"Cannot apply tweak with mode {} to \"{}\" : Data type {} not supported.",
modeToString( mode ), tweakName, "foo" //sourceData->typeName()
Copy link
Member

Choose a reason for hiding this comment

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

Some strangeness here we'll need to tidy up.

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've gone with staticTypeName, with a comment about the downsides, maybe this should have been a TODO.

@danieldresser-ie danieldresser-ie marked this pull request as ready for review November 26, 2024 02:24
@danieldresser-ie
Copy link
Contributor Author

Addressed feedback.

Added one more commit where I made modeToString public, since that's pretty useful for primvar handling where we can't use applyTweaks.

I've hit the "ready for review" button rather than leaving this as draft, since I guess it could be merged now. Though it would also be fine to leave it until I put up PrimitiveVariableTweaks for review, since nothing else is affected by this, and it's possible I'll find more things that need changes along the way.

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