In the large scene I’m working on there are a lot of elevation changes (stairs, topography etc) and I’m continuously running into the issue that the “auto climb” property sets the camera height either too high or low relative to the closest floor. This most often happens when transitioning between two different floor objects (with “walk on” prop set).
This is a lesser problem on desktop (since you have the ability to adjust height), but on mobile it can result in the user getting trapped, for instance being to tall to pass through a door opening.
I was wondering if it is possible to use the Viewer API to check the camera height relative to the closest “walk on” surface? This way one might conditionally adjust the camera height to a sensible default (say 1.7m) relative to the floor if the camera gets to high or low.
I know it’s possible to get the camera height using viewer.getCameraPosition(), but this only gives height relative to the lowest point of the model, so it doesn’t really help in this regard
@eivind, would it be possible for you to share the scene link with us? It sounds like there is a bug in the “auto climb” function. If the scene isn’t public you can send us the link via PM on the forum or via email to support@shapespark.com.
To see an example of the issue click the “Inngang bygg C”-view in the nav. Here the initial height of the view is to tall to enter the front doors of the building.
I know this specific issue could be fixed by manually defining a lower starting point for the view, but manually ensuring that all views start at the correct height is very error prone.
There are also some triggers in the scene to take you to balcony views on some of the buildings. For some reason we are not getting collision detection on the ralilings (I’m suspecting this has something to do with the thickness of the railing?). This enables a user to walk of the balcony and hover high above ground. It would be nice to have the ability to pull the camera down to ground level if this scenario arises (if we’re unable to fix collision detection on the railings).
Thanks for the link and for the additional explanations.
We’ll add a setting that makes the viewer use camera height (above floor or ground) from the initial view for all the remaining views, ignoring the height configured for the remaining views. We’ll provide more details in this topic.
As for the balcony railings, you are right: a railing doesn’t stop the camera to pass through, because the camera is modeled as a small sphere. For such cases we suggest to add fully-transparent planes that block the movement. It’s good to set “Lightmap resolution” in the “Objects” tab to 0 for these planes, so they won’t take lightmap space.
Thanks so much for your response @wojtek. It will be very interesting to see this setting in effect, and it would quite possibly fix a lot of our issues
If the relative height to floor could be accessed programmatically I was also flirting with the idea of adding a script that periodically checks the camera height and adjusts it back to a default if it gets outside a given threshold. At least on mobile where it’s not possible for the user to adjust height (without adding some kind of custom controls).
Thanks for explaining how the camera is modeled. It now makes perfect sense why it doesn’t collide with the railing I tried your suggested idea of adding fully transparent planes. It works perfectly for blocking the camera, but it also introduces 2 new issues (see image):
Even though the plane is transparent, it is still visible at certain (sharp) angles
The invisible plane blocks you accessing triggers behind it
Could you post a screenshot of the Matarials tab settings for the plane? It is possible to create a completely transparent plane, likely some setting is responsible for the effect that you are seeing.
Unfortunately, such plane capture clicks and blocks them from reaching triggers behind. You need to rearrange triggers to be in front of the plane.
Worth noting that the scene is exported from Revit, by someone other than myself. So I do not know which material is picked for this plane in Revit. The material name indicates that it is a glass-texture, but I can’t see any connected texture images here in the Materials tab.
I wasn’t aware of this, but it looks that reflections are visible even if an object has Opacity 0. To disable reflections set Roughness to 1 (you need to first unlink the Roughness setting with this icon: )
To find which material an object uses, you can open the Materials tab and click on the object in the 3D preview, this will select the material used by the object.
This camera height setting, is it something that is slated for a future release? In that case does it have an ETA? I’m guessing it would be an opt-in setting?
We have this fixed camera height feature ready to roll in next release. However if you would like to access it already you can add body-end.html file with following content:
<script>
WALK.CAMERA_FIXED_HEIGHT = 2;
</script>
Note:
This will not work on self-hosted scenes until next release.
This setting will override all views to use fixed height value.
I don’t think the setting is supposed to lock the ability to adjust height manually. It only sets a default height for all views (if I’m assuming correctly).
Hey @Cob_KYU this functionality allows to set default (fixed) height for views only. (as @eivind has noticed) I believe the thing you are looking for is to disable movement keys.
The viewer doesn’t allow to disable some controls explicitly, but you can achieve this by capturing JavaScript key down events, and not propagating them further for keys that you would like to disable.
You can disable vertical movement keys by adding this code:
<script>
function onKeyDown(event) {
switch (event.keyCode) {
case 34: // page down
case 81: // e
case 33: // page up
case 69: // q
event.stopPropagation();
break;
}
}
document.addEventListener('keydown', onKeyDown, true);
</script>
)
)
