-
Notifications
You must be signed in to change notification settings - Fork 269
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
Examples and tutorial on using rendering API from plugins #596
Conversation
Signed-off-by: Louise Poubel <[email protected]>
Signed-off-by: Louise Poubel <[email protected]>
Signed-off-by: Louise Poubel <[email protected]>
Signed-off-by: Louise Poubel <[email protected]>
Signed-off-by: Louise Poubel <[email protected]>
@osrf-jenkins run tests please |
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.
The tutorial itself is great, thanks for doing this! One main question/concern I have is that the tutorial doesn't seem to discuss when or why one should use server/GUI rendering plugins instead of adding to SceneManager
, RenderUtils
, or Scene3D
. Perhaps we can add comments about this to the tutorial? I am assuming that the reasons for using server/GUI rendering plugins are along the lines of the following:
- Performance (users only use what they need)
- Maintenance/code cleanliness/testability
Signed-off-by: Louise Poubel <[email protected]>
Signed-off-by: Louise Poubel <[email protected]>
I'm giving this some thought. The short answer is that we don't need to mention this to external users, because they can't modify those classes from their code. We've been doing this as maintainers, but that doesn't scale, because we can't support every use case in the same plugin at the same time. That's why we have a plugin architecture, so users can implement functionality that's specific to their needs without modifying the core code. This to me is the biggest reason to keep everything in separate plugins, a lot of the functionality we ship should be as optional as user's plugins. |
Agreed; perhaps we should consider refactoring |
Signed-off-by: Louise Poubel <[email protected]>
Codecov Report
@@ Coverage Diff @@
## main #596 +/- ##
==========================================
- Coverage 77.43% 77.38% -0.05%
==========================================
Files 212 212
Lines 12016 12016
==========================================
- Hits 9304 9299 -5
- Misses 2712 2717 +5
Continue to review full report at Codecov.
|
Signed-off-by: Louise Poubel <[email protected]>
Signed-off-by: Louise Poubel <[email protected]> Edifice to Citadel (#945) Signed-off-by: Louise Poubel <[email protected]>
Signed-off-by: Louise Poubel <[email protected]> Edifice to Citadel (#945) Signed-off-by: Louise Poubel <[email protected]>
Signed-off-by: Louise Poubel <[email protected]> Edifice to Citadel (#945) Signed-off-by: Louise Poubel <[email protected]>
Signed-off-by: Louise Poubel <[email protected]> Edifice to Citadel (#945) Signed-off-by: Louise Poubel <[email protected]>
Builds on top of #595
Add 2 example plugins and a tutorial explaining how they work. See tutorial for more context.
I had to link to some Dome APIs because we don't have Edifice APIs deployed yet.
Here are the example plugins at work, the server one sets a random color every 2 simulation seconds, and the GUI one sets a new random color when the button is clicked.