After playing around with the Shapediver settings for zoom, rotation and pan speed, we noticed that the setting for pan speed does not change anything in the viewport. Zoom and rotation speed works fine, although we usually have to set the rotation speed realllly low (0.02) to be usable, especially on a phone.
We had to disable panning all together as it is way too sensitive.
Could you check that panning speed actually does something please. Probably a typo somewhere. Weirdly it works in the ShapeDiver app interface, but once its embedded the pan speed is back to its default value, which is way too high.
How do you determine what the target of the camera is? It seems the target is always the same place, even if I have for example a slider that changes the size of the object. Is there a way to determine/change the target? Or at least have it always point to 0,0,0 and then I can build my GH logic so that it always moves it correctly?
Which version of the viewer are you using for embedding?
This bug should have been fixed from version 2.11.0. The current version is 2.13.0, I suggest you try to upgrade to this one and let me know if you are still experiencing the bug.
If you are trying to update the camera target using the Edit mode of the ShapeDiver app, then it is different. At the moment, you can’t set a specific target, you have instead two modes:
The target’s location is fixed, determined by the default position or where the user has panned
The target’s location is recomputed every time a parameter is changed and adjusted to the centroid of the bounding box of the scene. To activate this second mode, activate the toggle ‘Camera adjust’ in the viewer settings (in the camera tab).
The viewer has a fast release cycle and we don’t have an automatic way to update the version in the documentation yet. You can always check the latest version at shapediver.com/api, it is shown in the url. In your application, just replace the number in the dependency, for example like this: https://s3.amazonaws.com/shapediverviewer/v2/2.13.0/sdv.concat.min.js
Oh okay, yes I once again just copied it from somewhere on your website, so we were still on v2.5.0
I just changed it but now all the controls look completely different even with the same CSS file. Did you change the naming conventions or something and if yes, why?
yup, seems like a lot of names and semantics have changed since 2.5.0. Inputs are 2 elements now, all rows have different classes and that boolean toggle is somehow a label now!?
And after all that, panning is still broken on a phone. Its fine in the browser on a desktop, but using the 3-finger-pan on a mobile moves it out of view instantly, so no choice but to disable panning.
These controls don’t look like our standard controls. It seems you hacked into them when using the 2.5.0 viewer? While you are able to do this when using direct embedding of our viewer, we don’t support this. The implementation of our controls has been updated with version 2.10.0, and this will keep happening in the future. If you want to have different controls, you will have to implement them yourself, or live with the fact things will break when you update the viewer version.
Some news about the controls of our viewer in general (mouse and touch): In the next few weeks we are completely reworking them to have consistent behavior across different devices and a lot of further improvements.
I am using a few small CSS styles to change the layout a bit, mainly so its usable on a phone. I understand that with new versions you might change the classes and semantics of the code you output, but it just seemed kind of odd to me to change the class names for things. Anyways, I am aware you don’t support this I was just curious what the changes were. I got the tweaks back to where they were before now.
Eventually we will build our own UI, but since we are still in prototyping phase, we simply use your controls.
Any idea why the panning would still not work right though?
What you could do until our camera touch and mouse controls have been improved to work consistently: Try to change the scale of the output geometry of your model, e.g. change the unit system.
We are working on fixing the problem, which is twofold:
As mentioned above we are completely reworking the camera controls, which among many other things will improve the panning speed to become consistent across devices. This is likely not going to be finished before the end of this month.
We seem to have introduced a bug recently which wrongly initialises the values shown by the settings widget on loading. This will be fixed asap, probably tomorrow.
Ah yes, just noticed the second bug. When you go to Edit Model all the sliders are back to default values (but saved values are still there) when you save again you have now overwritten with defaults again, so you always need to set all sliders again to edit settings.
Please please also add the option to just update a .gh file for a model. I uploaded like 20 times and always have to adjust all the settings and set them to exactly the same values every time, just because I was testing things out. In the end all I wanted was to always just update the .gh file. It seems like such a waste of resources on your end that your server creates new models for each upload. I bet not a lot of people bother to delete all the old models so they just take up server space. Plus of course its just super frustrating. Imagine you couldn’t do a save as on a word file but would have to create a new one every time and copy paste from the old file… that would drive anyone insane
The re-upload feature is planned but it involves a few design decisions that are not trivial. Going back to your analogy with a word document, I’m sure you would like to have the option to undo changes if you made them, therefore old versions of the model shouldn’t be deleted but rather a model versioning should be implemented. We have a pretty good idea of what the feature will look like and will make sure it gets implemented in the near future, since other users are feeling the frustration as well.
I‘m not so sure about that assumption. Versioning of files should be taken care off at the user level, so if i have uploaded a wrong version i would use a previous version and reupload. If i am afraid i might break a current version on shapediver i can just still create a new model. The reupload is more handy for small incremental tweaks and updates. But i see your point - if you are going to build it, you might as well build it properly.
