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
|**[Effects Manager](v6.0/effects-manager-rfc.md)**|@1chandu@ibgreen| Draft | Official support for effects (shadows, reflections, better lighting, postprocessing, framebuffer composition etc). |
38
+
|**[Render Layer to Texture](v6.0/render-layer-to-texture-rfc.md)**| TBD | Proposed | Allow layers to render to texture and then use texture in subsequent layers. |
34
39
35
40
36
41
## v6.0 RFCs
37
42
38
-
Current direction for [deck.gl v6.0](https://github.com/uber/deck.gl/projects/3) is to focus on **animation** and **visual effects**, so we want to prioritize related RFCs. In particular, the topic of animation is big, and it has been broken down into a number of separete RFCs that should all move us in the right direction.
43
+
Current direction for [deck.gl v6.0](https://github.com/uber/deck.gl/projects/3) is to focus on **animation** and TBA...
44
+
45
+
So we want to prioritize related RFCs. In particular, the topic of animation is big, and it has been broken down into a number of separete RFCs that should all move us in the right direction.
46
+
47
+
Also see luma.gl RFCs
39
48
40
49
| RFC | Author | Status | Description |
41
50
| --- | --- | --- | --- |
42
51
|**Animation**||||
52
+
|[**PropTypes**](v6.0/prop-types-rfc.md)| ? | Draft | Validate e.g ranges for numeric attributes, support animation/auto-interpolation. |
43
53
|[**Property Animation**](v6.0/property-animation-rfc.md)|@ibgreen| Draft | Allow Layer props and GL parameters to accept functions in addition to values and call these on every render to update values |
44
54
|[**Attribute Animation**](v6.0/attribute-animation-rfc.md)|@pessimistress| Proposed | Automatically interpolate between two copies of a vertex attributes |
45
-
|[**PropTypes**](v6.0/prop-types-rfc.md)| ? | Draft | Validate e.g ranges for numeric attributes, support animation/auto-interpolation. |
46
55
|[**Expose Layer AttributeManager**](v6.0/expose-attribute-manager.md)|@ibgreen|**Review**| simplifies pregenerating attributes in apps for fast animation. |
47
56
|||||
48
-
|**Effects**||||
49
-
|**[Effects Manager](v6.0/effects-manager-rfc.md)**|@1chandu@ibgreen| Draft | Official support for effects (shadows, reflections, better lighting, postprocessing, framebuffer composition etc). |
50
-
|**[Render Layer to Texture](v6.0/render-layer-to-texture-rfc.md)**| TBD | Proposed | Allow layers to render to texture and then use texture in subsequent layers. |
51
-
|||||
52
57
|**Ease-of-Use**||||
53
58
|[**dataUrl**](v6.0/data-url-rfc.md)|@pessimistress & @ibgreen| Draft |**Ease-of-Use** Allow deck.gl layers to specify a URL and asynchronously download the resulting data |
54
59
|||||
60
+
|**Finalize Multi-Viewport API**||||
61
+
|[**New View Class**](v6.0/view-class-rfc.md)|@ibgreen|**Draft**| Proposed Official API for multi-view(port) support, replacing the v5.0 experimental API |
62
+
|[**Per-View Controllers**](v6.0/per-view-controllers-rfc.md)|@ibgreen|**Draft**| Support one controller per view in multi-view apps |
63
+
|[**Unified ViewState**](v6.0/view-state-rfc.md)|@ibgreen|**Draft**| Highly controversial proposal for an even more Unified View/Controller Architecture. Will likely be deferred. Review again after other related RFCs have been approved/implemented |
64
+
|||||
55
65
|**Internals**||||
56
66
|[**Reduce Distribution Size**](v6.0/reduce-distribution-size-rfc.md)|@ibgreen|**Review**|**Hygiene** Reduce size of distribution and the bundle size of apps consuming deck.gl |
57
67
|[**Reduce Repository Size**](v6.0/reduce-repo-size-rfc.md)|@ibgreen|**Draft**|**Hygiene** Reduce size of deck.gl github repository |
@@ -62,39 +72,37 @@ Possible other animation related RFCs:
62
72
63
73
## v5.0 RFCs
64
74
65
-
These RFCs are being implemented (fully or partially) in v5.0.
75
+
These RFCs were implemented in v5.0. Also see luma.gl RFCs.
66
76
67
77
| RFC | Author | Status | Description |
68
78
| --- | --- | --- | --- |
69
79
|**Animation**||||
70
80
|[**Auto Highlighting**](v5.0/auto-highlighting-rfc.md)|@ibgreen@1chandu|**Implemented**| Auto highlight hovered object via `picking` module |
71
-
|[**Viewport interpolation**](v5.0/viewport-animation-rfc.md)|@1chandu|Proposed| This should build on the new Viewport system in the First Person RFC. Also needs to consider react-map-gl. |
81
+
|[**Viewport interpolation**](v5.0/viewport-animation-rfc.md)|@1chandu|**Experimental**| This should build on the new Viewport system in the First Person RFC. Also needs to consider react-map-gl. |
72
82
|||||
73
83
|**Viewports and Controllers**||||
74
-
|[**First Person Viewport**](v5.0/first-person-mercator-viewport-rfc.md)|@ibgreen|**Pre-Approved**| Geospatially enable all viewports |
75
-
|[**Multiple Viewports**](v5.0/multi-viewport-rfc.md)|@ibgreen|**Pre-Approved**| Supoort for multiple viewports, synchronized or unsynchronized |
76
-
|[**Controller Architecture**](v5.0/controller-architecture-rfc.md)|@ibgreen|**Draft**| Generalize and Freeze experimental Controller Architecture from v4.1 |
84
+
|[**First Person Geospatial Viewport**](v5.0/first-person-mercator-viewport-rfc.md)|@ibgreen|**Experimental**| Geospatially enable all viewports, add FirstPersonViewport for hybrid apps. |
85
+
|[**Multiple Viewports**](v5.0/multi-viewport-rfc.md)|@ibgreen|**Experimental**| Support for multiple viewports |
77
86
|||||
78
87
|**General**||||
79
-
|[**Break out EventManager**](v5.0/break-out-event-manager-rfc.md)|@ibgreen|**Draft**|**Hygiene** Break out shared event manager code |
80
-
|[**Break out Math Module**](v5.0/break-out-math-module-rfc.md)|@ibgreen|**Draft**|**Hygiene** Break out luma.gl math module |
88
+
|[**Break out EventManager**](v5.0/break-out-event-manager-rfc.md)|@ibgreen|**Implemented**|**Hygiene** Break out event manager module |
81
89
82
90
83
91
## v4.1 RFCs
84
92
85
-
These RFCs that have been implemented (fully or partially) in v4.1.
93
+
These RFCs were implemented in v4.1.
86
94
87
95
| RFC | Author | Status | Description |
88
96
| --- | --- | --- | --- |
89
97
|[**Picking Improvements**](v4.1/picking-improvements-rfc.md)|@shaojingli| "Direction" RFC | Outlines a number of improvements to picking |
90
-
|[**Event Handling**](v4.1/event-handling-rfc.md)| Many authors |**Approved** & Implemented| Attempt to define enduring event handling architecture |
98
+
|[**Event Handling**](v4.1/event-handling-rfc.md)| Many authors |**Implemented**| Attempt to define enduring event handling architecture |
91
99
92
100
93
101
## v4.0 RFCs
94
102
95
-
These RFCs that have been implemented (fully or partially) in v4.0.
103
+
These RFCs were implemented in v4.0.
96
104
97
105
| RFC | Author | Status | Description |
98
106
| --- | --- | --- | --- |
99
-
|[**Non-Geospatial Viewports**](v4.0/non-geospatial-viewports-rfc.md)|@ibgreen@gnavvy|**Approved** & Implemented| Support for non-geospatial viewports |
* Initial review in [PR](https://github.com/uber/deck.gl/pull/838)
11
+
12
+
13
+
## Overview
14
+
15
+
This RFC proposes:
16
+
* An "extended" Viewport hierarchy that adds subclasses based on "differences in view matrix" in addition to differences in projection matrix.
17
+
* The new hierarchy includes a "FirstPersonViewport" class that allows the application to specify eye position directly.
18
+
* All Viewports are "geospatially enabled", i.e. they can take a lng/lat anchor in addition to their normal coordinates.
19
+
* Viewports support the same options as layers, including model matrices so that apps can use their data coordinates to place FirstPersonViewports.
13
20
14
21
15
22
## Motivation
@@ -36,19 +43,20 @@ However, to synchronize our 3D data with external perspective-enabled map system
36
43
The map system typically locks in FoV (Field of view), viewing angle (always pitched downward) and altitude (camera height over the “ground”).
37
44
When rendering 3D environments on top of pre-rendered video (e.g. overlaying perception data on top of vehicle log cameras)
38
45
39
-
Note: There are subtleties around the positioning of the camera which is handled in the next proposal.
46
+
## Proposed Features
40
47
41
-
42
-
## Proposal Part 1: Geospatially Enable all Viewports
48
+
### Proposed: Geospatially Enable all Viewports
43
49
44
50
In deck.gl 4.1 only the WebMercatorViewport can handle layers with geospatial coordinates: it is the only viewport that can produce the uniforms required by the project module. But moving some properties from the `WebMercatorViewport` class into the base viewport, it is possible to extend cartographic projection to all viewpott.
45
51
46
52
The key insight is that through the addition of the "meters mode", we have already addedthe general capability of overlaying an arbitrary linear coordinate system (which is what all non-geospatial viewports use) on top of a geospatial coordinate system using an anchor point.
47
53
48
54
While METER_OFFSETS mode was initially introduced to solve a narrow use-case, the technique is actually very general, and there is no reason why we would not support geospatial anchoring and linear coordinates for all viewports (in addition to layers), including first person and orbit (i.e. third person) viewports.
49
55
56
+
Note: There are subtleties around the positioning of the camera which is handled in the next proposal.
57
+
50
58
51
-
##Proposal Part 2: An Alternative Viewport Hierarchy
59
+
### Proposed: An Alternative Viewport Hierarchy
52
60
53
61
In deck.gl v4.0, a viewport class hierarchy was introduced to support non-geospatial viewports. It separates between `Perspective` and `Orthographic` cameras (inspired by common WebGL frameworks).
54
62
@@ -59,12 +67,11 @@ As an alternative to the `Perspective`/`Orthographic` camera class, this RFC rec
59
67
Also, since the majority viewports will be used with a perspective projection matrix, if the `projectionMatrix` prop is not supplied, `Viewport` will try to create a perspective projection matrix using new `fov`, `near` and `far` props (note that `aspect` is automatically calculated from `width` and `height`).
60
68
61
69
62
-
## Summary of Proposed Changes
70
+
## Proposed API Changes
63
71
64
-
### Viewport
72
+
### New `Viewport` Properties and Methods
65
73
66
74
New properties:
67
-
68
75
-`longitude` - (optional) anchor
69
76
-`latitude` - (optional) anchor
70
77
-`zoom` scale - This will be hardcoded to meter = unity scale by `FirstPersonViewport`
@@ -76,27 +83,25 @@ New properties:
76
83
-`far`
77
84
78
85
New Methods:
79
-
80
86
*`Viewport.isGeospatial()` can be called to check if a viewport is geospatially "enabled". If longitude, latitude and zoom are supplied to a viewport, then that viewport is considered geospatial.
81
87
*`Viewport.isMapSynched()` offers an easy way for the app to determine if a base map can be displayed under the viewport.
82
88
*`Viewport.getMercatorParameters()` offers a way to get map props that include offsets etc.
83
89
84
-
85
90
Remarks:
86
91
*`modelMatrix` - A convenience to make the viewport API more similar to the `Layer` props. When positioning the camera in a scene with `Layer`s using a certain `modelMatrix` it is nice to be able to use the same coordinates and the same `modelMatrix` with the viewport.
87
92
*`projectionMatrix` - When supplied, the projectionMatrix parameter allows for complete application control of all **projection** matrix parameters - including field-of-view, near/far clipping planes, aspect ratios etc, e.g. using `new Matrix4().projection(...)` or `new Matrix4().ortho(...)` etc..
88
93
89
94
90
-
### FirstPersonViewport
95
+
### Proposed: New `FirstPersonViewport` Class
91
96
92
97
Extends `Viewport`. Creates a `Viewport` with a view matrix that is placed in the player's position, with a controllable direction and orientation:
93
98
-`direction` (`Vector3`) - player direction
94
99
-`up` (`Vector3`, `[0, 0, 1]`): specifies the camera up direction
95
100
96
101
97
-
### ThirdPersonViewport
102
+
### Proposed: New `ThirdPersonViewport` Class
98
103
99
-
This prototyping behind this proposal has so far not focused on `ThirdPersonViewport`. It is expected to extend `Viewport`, possibly with props such as:
104
+
`ThirdPersonViewport` is expected to extend `Viewport`, possibly with props such as:
100
105
- player `direction`
101
106
- camera `direction`, relative to player direction (additive to player `direction`)
102
107
- camera `distance,` from player
@@ -106,7 +111,7 @@ The idea here with two directions being that one might want a third person camer
106
111
See comments under `OrbitViewport` below.
107
112
108
113
109
-
### WebMercatorViewport
114
+
### Proposed: `WebMercatorViewport` Changes
110
115
111
116
Creates a viewport with a special perspective projection matrix with a FOV that works with mapbox-gl, and a view matrix that follows mapbox-gl's undocumented internal bearing/pitch/altitude conventions.
112
117
@@ -122,9 +127,9 @@ inherits from `Viewport`, setting parameters as follows
122
127
123
128
`isMapSynched()` would return false for a `Viewport` (Note: not a `Layer`):
124
129
* If `position` is specified
125
-
* If `modelMatrix is specified
126
-
* If `altitude is !== 0.5
127
-
* If `pitch > 60 degrees
130
+
* If `modelMatrix` is specified
131
+
* If `altitude` is !== 0.5
132
+
* If `pitch` > 60 degrees
128
133
129
134
We could also check zoom levels etc, potentially moving all mapbox limit checks into the `WebMercatorViewport` viewport.
0 commit comments