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

feat(underground#WIP): dynamic opacity to visualize underground and add hideSkirt parameter #2108

Draft
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

AnthonyGlt
Copy link
Contributor

2nd Version of #2077
Not completely optimized.
The underground option can't be enabled by default but it can be once the view is loaded (using a button)

@@ -372,6 +373,7 @@ class PlanarControls extends THREE.EventDispatcher {
}
if (onMovement) {
this.view.dispatchEvent({ type: PLANAR_CONTROL_EVENT.MOVED });
this.view.dispatchEvent({ type: VIEW_EVENTS.CAMERA_MOVED });
Copy link
Contributor Author

@AnthonyGlt AnthonyGlt Jun 1, 2023

Choose a reason for hiding this comment

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

this could be in another PR. This event is dispatch in GlobeControls when there is movement, it should be dispatch from PlanarControls too

Copy link
Contributor

Choose a reason for hiding this comment

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

Indeed it is a good point to dispatch the same event here. However, what could be done in another PR is to dispatch the same properties as with GlobeControls here (talking about range, heading etc).
This should however be done when working on controls harmonization.

@@ -101,13 +100,6 @@ class CameraRig extends THREE.Object3D {
} else {
this.camera.matrixWorld.decompose(camera.position, camera.quaternion, camera.scale);
}
view.dispatchEvent({
Copy link
Contributor Author

@AnthonyGlt AnthonyGlt Jun 1, 2023

Choose a reason for hiding this comment

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

this is removed because it's dispatched in the controls (Planar/GlobeControls) directly
Like this, we don't dispatch the event when there is tiles loading or other updates without camera movements

Copy link
Contributor

Choose a reason for hiding this comment

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

This was dispatched here because, if I remember well, CameraUtils can move the camera without the use of Controls. Therefore, dispatching it here allows user to be aware of a camera movement if it originates from CameraUtils.
The typical use case is for the Navigation widget, which has to update its compass and 2D/3D toggle if the camera is moved through CameraUtils.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh... You're right, but this dispatch is trigger too often (like I said, when tiles are loading or event when there is no movement). I'll see how I can do

Copy link
Contributor

@mgermerie mgermerie left a comment

Choose a reason for hiding this comment

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

Thanks for the PR.
The TileLayer options are only visible while in debug mode if I'm correct. Could you therefore add a button on your example (a bit like what you did for the 3dTiles classification example) to toggle dynamic opacity so that it appears on the website (which is not in debug mode) ?

@@ -372,6 +373,7 @@ class PlanarControls extends THREE.EventDispatcher {
}
if (onMovement) {
this.view.dispatchEvent({ type: PLANAR_CONTROL_EVENT.MOVED });
this.view.dispatchEvent({ type: VIEW_EVENTS.CAMERA_MOVED });
Copy link
Contributor

Choose a reason for hiding this comment

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

Indeed it is a good point to dispatch the same event here. However, what could be done in another PR is to dispatch the same properties as with GlobeControls here (talking about range, heading etc).
This should however be done when working on controls harmonization.

setUndergroundVisualization(trigger) {
const atmo = this.getLayerById('atmosphere');
if (trigger) {
this.tileLayer.updateTiledLayerOpacity({ target: this });
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps we should add a return point if this.tileLayer is not defined (when user is not using a prefab View) ? As it is done in View.getPickingPositionFromDepth. WDYT ?

Comment on lines +117 to +121
if (config.altitudeForZeroOpacity === undefined || config.altitudeForZeroOpacity === null) {
this.altitudeForZeroOpacity = 420;
} else {
this.altitudeForZeroOpacity = config.altitudeForZeroOpacity;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you simplify with this.altitudeForZeroOpacity = config.altitudeForZeroOpacity ?? 420; ?

Comment on lines +157 to +159
if (event == null) {
return;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

As the method is called through an event listener, is it possible that event might actually be null ?

return;
}
const view = event.target;
const distance = CameraUtils.getTransformCameraLookingAtTarget(view, view.controls.camera).range;
Copy link
Contributor

Choose a reason for hiding this comment

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

I just thought about orthographic camera, for which the range has no meaning (since only the fov of the camera is changed).
@AnthonyGlt, @jailln, do you think we should work (in another PR) on adapting the dynamic opacity feature to orthographic cameras or else adapting CameraUtils so that range is computed from camera fov (which would rigorously be a wrong value but would ease development for features that must support both perspective and orthographic cameras) ?

@@ -101,13 +100,6 @@ class CameraRig extends THREE.Object3D {
} else {
this.camera.matrixWorld.decompose(camera.position, camera.quaternion, camera.scale);
}
view.dispatchEvent({
Copy link
Contributor

Choose a reason for hiding this comment

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

This was dispatched here because, if I remember well, CameraUtils can move the camera without the use of Controls. Therefore, dispatching it here allows user to be aware of a camera movement if it originates from CameraUtils.
The typical use case is for the Navigation widget, which has to update its compass and 2D/3D toggle if the camera is moved through CameraUtils.



if (atmo) {
this.scene.background = new THREE.Color(0x000000);
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need to set this ? The default value is null which already results in a black background if I'm wright. Also, if setting this here, we should set it back to null on line 1162.
Moreover, by testing on view_3d_map example, switching atmo.visible does not seem to have an effect.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In view_3d_map for example, when I don't change the background we get:
noBACK
When I don't change the atmo:
noAtmo
When I don't change anything:
noThing

With my edits:
Screenshot from 2023-07-26 17-26-45

It will be better to see the data I think.

Although, you are right about switching back to the previous value at line 1162

get: () => _hideSkirt,
set: (value) => {
_hideSkirt = value;
this.#hideExistingSkirt(value);
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps we should directly add the method's content here instead of defining a method if it is only called here. WDYT ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Short term
Development

Successfully merging this pull request may close these issues.

2 participants