You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
panda3d-sync and meshcat backends should run simultaneously to avoid having to rely on dirty hack based on pyppeteer. It makes sense since panda3d-sync is always available and is computationally very cheap since the image is only rendered when needed. meshcat is still relevant for remote display and embedded views in notebooks.
View(s) and Viewer should be separated more clearly. A view is associated with a unique robot, while the viewer is shared between them. The parent Viewer must be provided to the view. The view can only delete its own state and not the whole Viewer at it is currently the case. Both must be managed separately. It is not an issue since current simulator is already hiding the management of the viewer to the user. And for power user it is quite easy to get the distinction and handle them manually.
It must be decided if it is still relevant to enforce having a single Viewer (backend) running at the same time. It is useful for meshcat that connects to any running server since it is supposed to be unique. This way, a persistent server can be started from outside and viewers from different sessions just connect to it simultaneously. The usefulness of this feature is questionable as it seems to have no real use case.
The text was updated successfully, but these errors were encountered:
After thinking, I'm in favour of moving the management of robots inside viewers at Simulator level. Viewer would be responsible for managing an instance of the backend, which would not have to be a singleton anymore (but would be by default). It does not really make sense for the viewer to manager this content the way it is currently.
panda3d-sync
andmeshcat
backends should run simultaneously to avoid having to rely on dirty hack based onpyppeteer
. It makes sense sincepanda3d-sync
is always available and is computationally very cheap since the image is only rendered when needed.meshcat
is still relevant for remote display and embedded views in notebooks.View
(s) andViewer
should be separated more clearly. A view is associated with a unique robot, while the viewer is shared between them. The parent Viewer must be provided to the view. The view can only delete its own state and not the whole Viewer at it is currently the case. Both must be managed separately. It is not an issue since current simulator is already hiding the management of the viewer to the user. And for power user it is quite easy to get the distinction and handle them manually.It must be decided if it is still relevant to enforce having a single Viewer (backend) running at the same time. It is useful for meshcat that connects to any running server since it is supposed to be unique. This way, a persistent server can be started from outside and viewers from different sessions just connect to it simultaneously. The usefulness of this feature is questionable as it seems to have no real use case.
The text was updated successfully, but these errors were encountered: