Skip to content
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

Do not reset the grid and axe when the scene is empty #83

Merged
merged 10 commits into from
Jan 10, 2023

Conversation

hbcarlos
Copy link
Contributor

@hbcarlos hbcarlos commented Dec 23, 2022

Fixes #66

Should we stop re-setting the camera too? See the screencast:

Grabacion.de.pantalla.2022-12-23.a.las.12.46.37.mov

@hbcarlos hbcarlos added the bug Something isn't working label Dec 23, 2022
@hbcarlos hbcarlos self-assigned this Dec 23, 2022
@github-actions
Copy link
Contributor

Binder 👈 Launch a Binder on branch hbcarlos/jupytercad/fix_66

@hbcarlos hbcarlos requested review from martinRenou and trungleduc and removed request for martinRenou December 23, 2022 11:52
@martinRenou
Copy link
Member

I think there are two cases to consider here when there is only one object left:

  • when we hide the last object: we should not reset any of the camera/grid/axes settings
  • when we remove the last object: we should reset the camera/grid and axes settings

The problem in the current implementation is that you cannot spot in which of those two cases you are under the _shapeToMesh method.

One way to fix it would be to change the behavior when hiding an object. I believe hiding an object should not trigger a call to _shapeToMesh. Instead, it should simply take the ThreeJS Object3D(s) it refers to and set object.visible = false (see this). This way we don't go through this _shapeToMesh logic of recreating all the THREE.BufferGeometry object (which is far from being ideal because we recreate buffers and re-send them to the GPU while it was actually not needed 😢) and resetting the camera/grid/axes when hiding/showing objects: problem fixed!

@trungleduc
Copy link
Member

I think there are two cases to consider here when there is only one object left:

  • when we hide the last object: we should not reset any of the camera/grid/axes settings
  • when we remove the last object: we should reset the camera/grid and axes settings

The problem in the current implementation is that you cannot spot in which of those two cases you are under the _shapeToMesh method.

While working with the 2D editor, I realize that we should have a unit system for the length and stick with it. Users need to handle by themself the camera in case of creating something too big. In this case, we can have a static grid/axes.

One way to fix it would be to change the behavior when hiding an object. I believe hiding an object should not trigger a call to _shapeToMesh. Instead, it should simply take the ThreeJS Object3D(s) it refers to and set object.visible = false (see this). This way we don't go through this _shapeToMesh logic of recreating all the THREE.BufferGeometry object (which is far from being ideal because we recreate buffers and re-send them to the GPU while it was actually not needed 😢) and resetting the camera/grid/axes when hiding/showing objects: problem fixed!

I thought about showing and hiding objects by using threejs at the start. But since visible is a property of the document model and we need to update it on the FCStd file, I decide to treat it as other cases of modifying the document. So we might need to add some logic to filer out the update of visible property from the shared model change signal.

@hbcarlos
Copy link
Contributor Author

hbcarlos commented Jan 9, 2023

One way to fix it would be to change the behavior when hiding an object. I believe hiding an object should not trigger a call to _shapeToMesh.

So we might need to add some logic to filer out the update of visible property from the shared model change signal.

I added the logic to filter the object visibility change and modify the view instead of re-rendering everything.

@trungleduc
Copy link
Member

Thanks @hbcarlos, could you rebase this PR to pick up the new project structure? We should not commit the output of the opencascade build

@martinRenou
Copy link
Member

The CI failure might be legit?

@hbcarlos
Copy link
Contributor Author

The CI failure might be legit?

No, is not. The extension is not activated

@trungleduc
Copy link
Member

The CI failure might be legit?

No, is not. The extension is not activated

so we need your fix on ydoc?

Comment on lines +792 to +800
if (!visible) {
this._postMessage({
action: WorkerAction.LOAD_FILE,
payload: {
fileName: this._context.path,
content: this._model.getContent()
}
});
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand this part. What is it doing?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the variable visible should be named visibleChanged.
But I'm wondering what is the behavior of this function if I have both visible and other keys in the change.objectChange list. We should send the message to the worker to re-render the scene in this case.

Copy link
Member

@martinRenou martinRenou Jan 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure it matters much. I'm currently working on the guidata options and having the visible property there. So this method will actually be triggered on an sharedOptionChange event, not an object change, I'm rebasing my PR against Carlos's branch to implement this.

Copy link
Member

@trungleduc trungleduc Jan 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have both visible properties in the document and the GUI document. When users click on the visibility icon in the tree view, which visible property we should update? If it's both, then the viewer will get both sharedOptionChange and sharedObjectChange events.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it should be the visible property from the GUI data that we should change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it can :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So let's get #91 in first then we will adapt this PR?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer merging #83 first actually, because I already rebased my work on this locally

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I will try to fix the integration tests before merging this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I'm wondering what is the behavior of this function if I have both visible and other keys in the change.objectChange list. We should send the message to the worker to re-render the scene in this case.

When changing the visibility of the object from the tree view the transaction has only one change, the visible key. I think is not possible to have an event that changes multiple keys when changing the visibility.

@martinRenou
Copy link
Member

martinRenou commented Jan 10, 2023

With this PR, the grid helper is too small for big objects, making it useless (it's barely visible on this screenshot):

Screenshot from 2023-01-10 15-01-54

I feel like we should remove the grid helper completely and display 3D axes that are not bound to the 3D world projection like freecad does:

Screenshot from 2023-01-10 15-00-04

This way the 3D axes are always of the same size/position and don't depend on the camera position

@martinRenou
Copy link
Member

So maybe this PR should actually remove the grid helper?

@trungleduc
Copy link
Member

So maybe this PR should actually remove the grid helper?

I'm in favor of removing the grid too. and for the camera, I think we should only scale it once when users open the document.

@hbcarlos
Copy link
Contributor Author

@martinRenou @trungleduc I will open a new PR to make the grid configurable by the user.

The test in this PR fail because of the grid, I would like to move on and fix the grid in another PR.

@trungleduc trungleduc merged commit 900ab4c into jupytercad:main Jan 10, 2023
@trungleduc
Copy link
Member

Thanks @hbcarlos !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
3 participants