SceneView questions/curiosities

916
2
Jump to solution
11-12-2018 04:36 AM
BjørnarSundsbø1
Occasional Contributor II

Hi,

I've recently started working with SceneView, with the intent of more or less replicating existing functionality for MapView to also work for SceneView. Except for the map being displayed in 2D vs 3D, I was thinking to make everything else look the same. During this work, I've run into a couple of limitation, and asking for advice:

Scale

I'm attempting to use scale line in the same way as before. Since SceneView does not have a MapScale property, the closest I can think of is to use GetCurrentViewPoint(CenterAndScale), and use this for the scale line. Are there any arguments against doing this? Users for this application will mostly be working at a local level, and full globe view is not required for them, so any incorrect calculation at world view shouldn't be too relevant.

Select zoom

I feel this functionality is missing in the runtime for scene view. I've gotten used to this way of zooming the MapView, and it feels strange to have to use the wheel many times to get the where I want to go. Considering the zoom animation for SceneView is so much slower than MapView, I find this somewhat tedious. Being able to control the ZoomDuration for both views through InteractionOptions would allow for a much more responsive application, as well as making both views behave more identical. I figure I can write this myself, but being part of the standard package would be great.

ViewInsets

ViewInsets is currently ignored by SceneView. Will it enter the scene soon? I had written my own code for doing the same thing for MapView way before I became aware of this property, but it seems to fail quite frequently as of now. I haven't spent time trying to fix this yet.

Label

I've tried to use the exact same code for GraphicsOverlay for MapView and SceneView, but I notice that labels are not displayed in the SceneView. Are labels not yet supported, or is there something I've missed?

Performance considerations?

I've read the Performance considerations—ArcGIS Runtime SDK for .NET | ArcGIS for Developers, and try to follow them as well as I can. Is there any reason to suspect that SceneView should require noticeable more resources than MapView? I don't have evidence to indicate this; it's just the voice in the back of my head saying that it makes sense that 3D would require more resources

0 Kudos
1 Solution

Accepted Solutions
dotMorten_esri
Esri Notable Contributor

Scale: The scale in a 3D view isn't consistent. Are you looking at the scale at the center of the screen, bottom closest to you, or at the horizon? What happens if the center of the screen is the sky? Even when looking straight down, the elevation itself causes the scale to change wildly. Scale just isn't a usable concept in 3D. (also the scale value you do get is only an approximation)

Select zoom: Again in 3D things gets a little tricky, because the box you draw could easily contain features in the front and toward the horizon, or even part of the sky, so it's rather unclear what to zoom to.

ViewInsets: This is in our backlog to support in 3D, but currently not available.

Labels: AFAIK it _should_ work in 3D if the rendering mode is Dynamic, but not entirely sure. I do know there's more work to be done there.

Performance: 3D rendering is more "advanced" so yes it could require more resources. But if you're using the same sort of data, there shouldn't be too much difference, but as you add stuff like 3D Scenes, 3D extrusion, elevation data etc it will be more data process and render, so naturally the requirements go up. But considering 3D works pretty well even on a mobile device, you'll probably be ok. Also note that certain features require better graphics hardware. For instance 2D only requires a graphics card that supports DirectX Feature Level 9.1, whereas 3D requires 9.3. You'll be hard-pressed to find hardware that doesn't have at least 9.3 (and 9.3 is also listed as the minimum requirements). If your hardware doesn't meet that level, it'll switch to software rendering to emulate 9.3 support, and that'll definitely hurt performance. Real-time shadows, viewshed and line-of-sight calculations requires level 10 or higher.

View solution in original post

0 Kudos
2 Replies
dotMorten_esri
Esri Notable Contributor

Scale: The scale in a 3D view isn't consistent. Are you looking at the scale at the center of the screen, bottom closest to you, or at the horizon? What happens if the center of the screen is the sky? Even when looking straight down, the elevation itself causes the scale to change wildly. Scale just isn't a usable concept in 3D. (also the scale value you do get is only an approximation)

Select zoom: Again in 3D things gets a little tricky, because the box you draw could easily contain features in the front and toward the horizon, or even part of the sky, so it's rather unclear what to zoom to.

ViewInsets: This is in our backlog to support in 3D, but currently not available.

Labels: AFAIK it _should_ work in 3D if the rendering mode is Dynamic, but not entirely sure. I do know there's more work to be done there.

Performance: 3D rendering is more "advanced" so yes it could require more resources. But if you're using the same sort of data, there shouldn't be too much difference, but as you add stuff like 3D Scenes, 3D extrusion, elevation data etc it will be more data process and render, so naturally the requirements go up. But considering 3D works pretty well even on a mobile device, you'll probably be ok. Also note that certain features require better graphics hardware. For instance 2D only requires a graphics card that supports DirectX Feature Level 9.1, whereas 3D requires 9.3. You'll be hard-pressed to find hardware that doesn't have at least 9.3 (and 9.3 is also listed as the minimum requirements). If your hardware doesn't meet that level, it'll switch to software rendering to emulate 9.3 support, and that'll definitely hurt performance. Real-time shadows, viewshed and line-of-sight calculations requires level 10 or higher.

0 Kudos
BjørnarSundsbø1
Occasional Contributor II

Thank you for your reply. In regards to labeling, the GraphicsOverlay does use dynamic mode. I will do some more testing when I get to it, but currently the setup of graphics overlay is identical in both views, so I'm mystified to what I need to change. I will also try with a basic application just to make sure.

When it comes to selection zoom, I always saw it as a box with factor as the relationship between the height/width of the view vs height/width of the selection box, but I understand what you mean.

One last thing I thought of before I left the office, was that using Viewpoint.ToJson() does not include Camera details. Is this something that might be included at a later point, or omitted for a reason? My objective is currently to save the camera details along with the center + scale for bookmarks, so that I get the camera angles for SceneView when going to the bookmark. For now I'm thinking of just serializing the camera information separately, but if it might be included in the json for viewpoint in the future, it would be good to be aware of that.

0 Kudos