[AO migration] ArticulatedObject API#1312
Conversation
| template <> | ||
| inline bool readMember(const JsonGenericValue& d, | ||
| const char* tag, | ||
| std::map<std::string, float>& val) { | ||
| if (d.HasMember(tag)) { | ||
| if (d[tag].IsObject()) { | ||
| const auto& jCell = d[tag]; | ||
| for (rapidjson::Value::ConstMemberIterator it = jCell.MemberBegin(); | ||
| it != jCell.MemberEnd(); ++it) { | ||
| const std::string key = it->name.GetString(); | ||
| if (it->value.IsFloat()) { | ||
| val.emplace(key, it->value.GetFloat()); | ||
| } else { | ||
| LOG(ERROR) << "Invalid float value specified in JSON config " << tag | ||
| << " at " << key << ". Skipping."; | ||
| } | ||
| } // for each value | ||
| return true; | ||
| } else { // if member is object | ||
| LOG(ERROR) << "Invalid JSON Object value specified in JSON config at " | ||
| << tag << "; Unable to populate std::map."; | ||
| } | ||
| } // if has tag | ||
| return false; | ||
| } // readMember<std::map<std::string, float>> |
There was a problem hiding this comment.
Something to note about this function - the 2 other container-based specializations of readMember will return true even if the value is not found in the json (they return false if some format error occurs while reading a tag), although this one does not (and it is expected that this one does not). The non-container versions return false if the tag is not present.
@eundersander and I have been discussing potentially changing this behavior for the container-based readMember, and their matching addMember methods. Just wanting to leave a note here about this.
|
|
||
| if (info.type == AssetType::FRL_PTEX_MESH) { | ||
| if (info.type == AssetType::PRIMITIVE) { | ||
| buildPrimitiveAssetData(info.filepath); |
There was a problem hiding this comment.
Note: this assumes the AssetAttributesManager has already registered a primitive asset with this name. As such, this won't support RenderReplay currently.
There was a problem hiding this comment.
A possible solution to this would be the string-based construction of primitives. Since primitive attributes names encode their structure, and do not allow for renaming, we could reverse engineer the required attributes if it is missing by using the name.
There was a problem hiding this comment.
I was thinking this might be a viable option also.
There was a problem hiding this comment.
Note that PR #1314 addresses this gap, thanks @jturner65!
Skylion007
left a comment
There was a problem hiding this comment.
A bunch of performance / style nits
bigbike
left a comment
There was a problem hiding this comment.
Really a big diff.
Not so sure if it can be further divided into even smaller ones.
Just reviewed part of it.
| std::shared_ptr<io::URDF::Material> material = | ||
| visual.m_geometry.m_localMaterial; | ||
| if (material) { | ||
| visualMeshInfo.overridePhongMaterial = assets::PhongMaterialColor(); |
There was a problem hiding this comment.
are these models glbs? It is supposed to use Pbr instead of Phong. Where does it override such a choice (using Phong not Pbr)? Would you show me the a code pointer?
There was a problem hiding this comment.
FYI: in Pbr, now I coded it up the shadows. So in the future, if we would like to leverage it, we need to use Pbr shader + Pbr drawables.
There was a problem hiding this comment.
Good point. All of our test models define a 4d color. We've been treating them as Phong, but we could instead treat them as PBR with no textures.
There was a problem hiding this comment.
There was a problem hiding this comment.
Here is where this override material color is consumed to register a new Phong material and cache the custom LoadedAssetInfo.
| if (it->value.IsFloat()) { | ||
| val.emplace(key, it->value.GetFloat()); | ||
| } else { | ||
| LOG(ERROR) << "Invalid float value specified in JSON config " << tag |
There was a problem hiding this comment.
It would be buried easily in the screen output.
would this error lead to fatal error in the future? If yes, use CORRADE_ASSERT here to stop it.
There was a problem hiding this comment.
Counterpoint: LOG(ERROR) fits with our existing JSON-reading convention. An assert isn't appropriate because this is a runtime validation of data, whereas asserts are to catch programmer errors in code. Also, treating the error as fatal is inappropriate (it's up to the calling JSON code to decide the severity of a failed parse; some callers may want to just have the error logged but then keep going).
| explicit SceneObjectInstanceAttributes(const std::string& handle); | ||
| explicit SceneObjectInstanceAttributes( | ||
| const std::string& handle, | ||
| const std::string& type = "SceneObjectInstanceAttributes"); |
There was a problem hiding this comment.
Just predict by the variable name: type.
I would define an enum for a type instead of using a string simply because a string can be random.
But I guess no chance to change it now (otherwise it requires a lot of code refactoring.)
There was a problem hiding this comment.
Good point, agreed it seems like a later refactor.
eundersander
left a comment
There was a problem hiding this comment.
I left comments. Looks like just some straightforward code cleanup remaining.
| template <> | ||
| inline bool readMember(const JsonGenericValue& d, | ||
| const char* tag, | ||
| std::map<std::string, float>& val) { |
There was a problem hiding this comment.
This approach of implementing map<string, float> isn't going to scale very well to other types (you'll be copy-pasting a lot of code). For comparison, see our version of readMember for std::vector in this file.
Consider re-writing this to work for a map from string to a generic value type (templated on value type).
You can make this version more generic and still do error-handling here to detect and report a failed parse of a value.
There was a problem hiding this comment.
Yep, I was planning on that refactor eventually, when time permitted.
| if (it->value.IsFloat()) { | ||
| val.emplace(key, it->value.GetFloat()); | ||
| } else { | ||
| LOG(ERROR) << "Invalid float value specified in JSON config " << tag |
There was a problem hiding this comment.
Counterpoint: LOG(ERROR) fits with our existing JSON-reading convention. An assert isn't appropriate because this is a runtime validation of data, whereas asserts are to catch programmer errors in code. Also, treating the error as fatal is inappropriate (it's up to the calling JSON code to decide the severity of a failed parse; some callers may want to just have the error logged but then keep going).
| */ | ||
|
|
||
| template <> | ||
| inline bool readMember(const JsonGenericValue& d, |
There was a problem hiding this comment.
How about a comment showing what the expected JSON looks like? This will help when someone needs to come along later and write an addMember (writer) for maps.
Motivation and Context
This PR migrates base ArticulatedObject functionality from the prototype branch #1273.
Changes include:
ArticulatedObjectbase class withBulletArticulatedObjectderived implementation.URDFImporterbase class andBulletURDFImporterderived implementation (constructBulletArticulatedObjectfromio::URDF::Model)How Has This Been Tested
New tests for MetaDataMediator, AttributesManagers, and ArticulatedObject API.
Types of changes
Checklist