Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The main purpose is two-fold -- being able to visualize the URDF hierarchy using standard tools, and as a showcase of the flexibility of
SceneData
custom fields, which preserve everything including the URDF-specific physics properties.Originally just a fun exercise of "how far can I get with implementing a parser for a format I know nothing about in under 3 hours", but because I got quite far it'd be bad to just throw it away now. Things left to do because yes everything always explodes into 100+ tasks in the end:
MAGNUM_
, especially the static build etcmesh & material import -- delegating tonot handled here, will be a high-level utility inAnySceneImporter
for these, joining the nested hierarchies somehowSceneTools
insteadSceneData
(string)ExternalModel
field with their filenamehave ahave aMeshMaterial
field alone, without anyMesh
? or store the color as a custom scene field in that case instead?ExternalModelMaterial
field tied toExternalModel
, same as isMeshMaterial
tied toMesh
SceneData
bit field, or maybe have a string "type" field?)SceneData
nested scene joiningnested model referencesFindMagnumPlugins.cmake