-
Notifications
You must be signed in to change notification settings - Fork 4
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
Arnold Material Creation Improvements #58
Conversation
we only need the shading engine name to re-use a material
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please avoid mixing renaming changes with changes to the logic (last commit aed5e0e)
Apart from the minor things mentioned in the inline commits, this is looking very good. I did a small functional test and the deduplication worked.
bfc29b3
to
20a4ed5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only some small stuff left, can be merged directly afterwards
I especially like the changes for letting Maya uniqueify node names 👍
continue; | ||
|
||
adsk::Data::Stream* matStream = matChannel->findDataStream(gPRTMatStream); | ||
if ((matStream == nullptr) || (matStream->elementCount() == 0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't this be matStream->elementCount() != 1
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
|
||
const std::wstring MATERIAL_BASE_NAME(L"serlioGeneratedArnoldMaterial"); | ||
|
||
void synchronouslyCreateShadingEngine(std::wstring& shadingEngineName) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
consider returning the definite shading engine name separately instead of using an in-out parameter for better readability
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
|
||
class MaterialColor; | ||
class PRTContext; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be struct PRTContext;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
src/serlio/util/Utilities.h
Outdated
auto getCachedValue(M& cache, const typename M::key_type& key, F valueFunc, ARGS&&... valueFuncArgs) { | ||
auto p = cache.find(key); | ||
if (p == cache.end()) { | ||
auto value = valueFunc(std::forward<ARGS&&...>(valueFuncArgs)...); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be std::forward<ARGS>(valueFuncArgs)...
, ARGS
should be expanded with the outer expansion, since std::forward
only takes a single template parameter. This only compiled because getCachedValue
is so far only used with a single value for valueFuncArgs
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oopsie, obviously wrong... fixed.
src/serlio/util/Utilities.h
Outdated
template <typename M, typename F, typename... ARGS> | ||
auto getCachedValue(M& cache, const typename M::key_type& key, F valueFunc, ARGS&&... valueFuncArgs) { | ||
auto p = cache.find(key); | ||
if (p == cache.end()) { | ||
auto value = valueFunc(std::forward<ARGS&&...>(valueFuncArgs)...); | ||
p = cache.emplace(key, value).first; | ||
} | ||
return p->second; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking a bit further about this function, two more optimization opportunities come to mind:
- perfect forwarding of the value returned by
valueFunc
:the two lines above should simply be the more readable version of:auto value = valueFunc(std::forward<ARGS>(valueFuncArgs)...); p = cache.emplace(key, value).first;
but unfortunately, they're not, because they make an lvalue out of an rvalue. The equivalent would be:p = cache.emplace(key, valueFunc(std::forward<ARGS>(valueFuncArgs)...)).first;
auto&& value = valueFunc(std::forward<ARGS>(valueFuncArgs)...); p = cache.emplace(key, std::forward<decltype(value)>(value)).first;
- perfect forwarding of
key
:
Unfortunately, we need to rely on SFINAE for the type constraint onkey
to be able to use a forwarding reference.
Full code:
template <typename M, typename K, typename F, typename... ARGS,
typename = typename std::enable_if_t<std::is_convertible<typename std::decay_t<K>, typename M::key_type>::value>>
auto getCachedValue(M& cache, K&& key, F valueFunc, ARGS&&... valueFuncArgs) {
auto p = cache.find(key);
if (p == cache.end()) {
auto&& value = valueFunc(std::forward<ARGS>(valueFuncArgs)...);
p = cache.emplace(std::forward<K>(key), std::forward<decltype(value)>(value)).first;
}
return p->second;
}
you just have to admire the beauty of generic C++ code 😃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good stuff, done
note: some of the commits are a bit evolutionary/overlapping