|
POST
|
> We've seen performance benefits from using 512x512 tile sizes over 256x256 on high-res or large screens. Oh that's interesting! Would it be possible to share some more specific details (either here or DM if you prefer)? What particular improvements? Improved FPS? Faster loading of data? Definitely something we'd like to hear more about. I assume a 512 tile cover the same area as 4 256 tiles (and not the same area at 4x resolution)? AFAICT this reduces the number of network requests to 1/4, which could indeed help with certain aspects of performance. The whole terrain is then split less granular (again 1/4 tiles), I wonder if this comes with any downsides. > If supporting mixed tile sizes (even limited to 256 and 512) in 3D is complex Mixing arbitrary tiling schemes is tough: Tiling is at the core of the terrain logic and controls a lot of both internal and user-facing behavior. Mixing 256 and 512 would definitely be less tricky but still not a freebie.
... View more
11-02-2023
11:18 AM
|
0
|
1
|
3266
|
|
POST
|
> Raster API tiles only work when all other layers have same tiling size. Correct. In SceneView tiling scheme of all (tiled) layers must match. First layer that is loaded determines the scheme (typically the first basemap layer). FYI: This limitation in SceneView stems from the fact that in contrast to top-down-only MapView, oblique views in SceneView requires tiles to be displayed in different scales (different distance to camera). Mixing different tiling schemes would require the current single-tiling-pattern of the ground surface to be extended to support multiple overlayed tiling patterns. > I think ESRI ArcGIS Maps SDK for JavaScript maps require a basemap layer right? No, a basemap layer is not required (was the case in older versions but not anymore). If you do not need the basemap, maybe removing it is the quickest "fix" for your case?
... View more
10-31-2023
07:49 AM
|
1
|
0
|
3290
|
|
POST
|
Assumption confirmed: Data is the same in older versions (e.g. 10.6.1): The same "steps" can be seen on the grid when basemap is disabled. In older versions those steps were not or barely noticeable due to the flat shading where surface normals were ignored. With the new terrain shading (think dynamic relief) these terrain details become visible. So the problem lies in the data / the DEM, or the way it was created. I'm not an expert on DEMs, I would say though that the data resolution is lower than the resolution of the DEM, and that could create these step-like artefacts. I'm also not clear if there are additional interpolation options which allow to control this behavior. I would try to create the DEM with a lower resolution, which matches the resolution of the source data. For more detailed help I recommend to ask again in the ArcGIS Pro section, or whichever product is used to create the DEM.
... View more
10-09-2023
09:56 AM
|
0
|
0
|
1543
|
|
POST
|
Thanks Maxime We were able to read the service and reproduce the reported behavior. We'll do some more investigations and get back to you.
... View more
10-06-2023
07:59 AM
|
0
|
0
|
1560
|
|
POST
|
Thanks for the service link. Unfortunately it is not working for me. https://cartes.ville.sherbrooke.qc.ca/arcgis/rest/services/DEM_3857/ImageServer Browser reports "connection has timed out" / "took too long to respond". * Can you doublecheck the url, and check if it still works for you? * Confirm that it is indeed publicly available, not limited to your intranet, and no credentials are needed to access it?
... View more
10-02-2023
04:47 PM
|
0
|
1
|
1570
|
|
POST
|
ArcGIS Online enabled terrain shading in a recent release: https://developers.arcgis.com/javascript/latest/4.26/#improved-terrain 10.6.1 did not have terrain shading yet. Our assumption is that the terrain data is actually the same, i.e. already not smooth 10.6.1, but the steps are not visible without terrain shading. To doublecheck this assumption we'd need some more info: * is this a custom DEM? Or the default world elevation service provided by Esri? * if custom, is it possible to share a url to the layer / the service? * if not custom: please share the exact location where the problem occurs so we can investigate further. You can do this in SceneViewer Share Dialog, Share link, which will include viewpoint in the url.
... View more
10-02-2023
06:05 AM
|
1
|
0
|
1586
|
|
POST
|
Hi Despite the (impressive) analysis we unfortunately can't see an obvious culprit. We would need to have access to the service in question to do deeper performance investigations. Hence the question: is it possible to share the service with us? If so please DM me for details.
... View more
09-05-2023
04:11 PM
|
0
|
1
|
1156
|
|
IDEA
|
Did a test of this scenario now, and can confirm it works for me. * If elevation comes from z-values: use Arcade expression Geometry($feature).z * factor * if elevation comes from attributes: use Arcade expression $feature.attributename * factor In my test in both cases the published webscene has the correct expression set, and point features display on the expected exaggerated elevation in Scene Viewer (same elevation as in Pro). See also: https://developers.arcgis.com/javascript/latest/arcade/#z-values ---- In case this still does not work for you we'd need to see the problematic webscene, and the version of Pro used to track this down further.
... View more
09-05-2023
04:01 PM
|
0
|
0
|
1773
|
|
IDEA
|
Hmm this is unexpected. Would it be possible to share the published webscene / the published layer with us (i.e. make it public and share the link)? This would allow us to track down if the problem is in Scene Viewer (when consuming the scene / layer) or in Pro (when publishing the layer). > If the scene viewer can handle the expression, wouldn't it be more or less easy to implement this capability in the scene viewer in the future? Yes it is correct that the underlying ArcGIS Maps SDK for JS supports this already. Adding UI to Scene Viewer for features supported in the underlying SDK is not always a trivial change though unfortunately. In this case for example new UI for editing arbitrary expressions is needed. As mentioned we understand this is an important feature and is on our roadmap, but without a specific date yet.
... View more
09-01-2023
02:48 AM
|
0
|
0
|
1796
|
|
IDEA
|
I stand corrected: Completely forgot we actually have support for this case: using featureExpressionInfo one can exaggerate vertical position of point features using expressions, see this sample. There is currently no UX to set this in Scene Viewer. However when such an expression is set in ArcGIS Pro and exported to a webscene it is supposed to come over and display as expected (as in Pro). In SceneViewer UI elevationMode will show as `<<custom>>`. Could you try if this is working for you?
... View more
08-28-2023
08:40 AM
|
0
|
0
|
1833
|
|
IDEA
|
Vertical exaggeration in scenes has been requested often, and is a candidate on our roadmap. No specific plans yet, but we can hopefully tackle this in the near future. For now the only workaround I can think of is to export the data with hardocded exaggerated z values for display (and maybe store the original z value in a field for reference if needed). Would that be a doable workaround for you?
... View more
08-28-2023
04:18 AM
|
0
|
0
|
1841
|
|
POST
|
In SceneViewer, can you check the quality settings? Having the slider on quality could help. However the screenshot of SceneViewer looks definitely worse than it should be. Is it possible to share the webscene, or the layer so we can have a closer look?
... View more
08-25-2023
06:07 AM
|
1
|
0
|
5620
|
|
POST
|
Not a Pro expert, but AFAIK the publishing process will not add these, they must be there before publishing already. Check data in Pro before publishing, pretty sure they show up there as well (though might not be underground). My assumption is your data contains these footprints. Or they get added somehow in the creation process.
... View more
08-03-2023
02:25 PM
|
0
|
6
|
2823
|
|
POST
|
After hiding the Lidar Point Cloud, and making ground transparent (in basemap widget) we can see that all buildings indeed have an underground "footprint" polygon (or rather a polygon outline). All parts of a feature get selected and highlighted, i.e. the behavior you see is expected. There is no option to selectively control the highlighting within a feature. Can you recreate the features (the Building SceneLayer) to not include the underground footprint part?
... View more
08-03-2023
10:11 AM
|
0
|
8
|
2831
|
|
POST
|
Selection highlight has a "shine-through" effect to make it visible even if (partially) occluded. This is by design. In your specific case, it looks like the building has a single bottom plane underground. Can you check if this is the case (e.g. by hiding terrain/ground, or lifting up buildings with elevation offset)? If that's the case then the highlighting behavior would be as expected. If there isn't a bottom plane I cannot see an obvious other issue just from the picture. Would it be possible to share this scene (or a reduced subset that shows the problem) publicly so we can have a look? So far we were not able to reproduce this case, and we might need to have a closer look at the actual scene / actual data to be able to track this down further.
... View more
08-03-2023
09:46 AM
|
0
|
1
|
2841
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 05-08-2025 12:51 PM | |
| 1 | 08-14-2024 06:55 AM | |
| 2 | 08-08-2024 04:29 AM | |
| 1 | 04-19-2024 07:31 AM | |
| 1 | 03-21-2024 11:41 AM |
| Online Status |
Offline
|
| Date Last Visited |
10-27-2025
07:53 AM
|