Feature Suggestions

I’ll admit these are pretty minor suggestions but I thought I’d throw them out there while they are still fresh to my newbie status with SD. They all relate to the viewer setup page:

Change the way the title box on the upload page works so they are always in numerical order not most used order. When reiterating tests it easy to click the wrong name because it moves.
Be able to hide the Material Colour option on the setup page.
Add Disable Rotate
Add Pan Speed
Make Zoom Factor easier to control (jumps).
Add more inside building environments (homes, showrooms, etc).
Add a auto reposition option so the object is re-centred after panning, zooming or object scaling (some API examples seem to do this).
Add section headers for the built-in controller.
Add radio boxes as input (as an option to the check boxes).
Add limits to the pan, rotate and zoom so that non-CAD-experienced users don’t get disoriented. Would also allow for a 2D representation.

Thanks for those, let’s break down your feedback.

Are you talking about those?

I guess it would be possible to suggest the latest ones. We’ll look at this when rolling out the new website.

This is actually a small display bug: if you click on the hide button for colour parameters (and a few other types as well) it doesn’t get blurred but the state is actually saved and it will not show up in the public view. The display bug is already fixed and will be shipped with the new website.

Yes, that makes sense, i added those to the backlog.

I’d suggest decreasing the zoom speed for achieving better control. This type of details is difficult to caliber since different devices and configurations tend to produce different user experiences. We could add an ease-in step when zooming starts, we will look at this.

Did you notice that you can user your own environments? There is a (little documented) custom environment option in the viewer settings. You could use any of the cube maps from this website: http://www.humus.name/index.php?page=Textures or create your own from hdri files: https://matheowis.github.io/HDRI-to-CubeMap/

This option indeed exists in embedded mode but it does make sense as a standard viewer setting. Added to the backlog as well.

Could you develop this suggestion? I am not sure I understand what you are referring to.

I think for our default controls we will stick to replicating the Grasshopper parameter types. The checkboxes correspond to the Grasshopper checklist, but there are no radio buttons there. Radio buttons would get you the same functionality as dropdown or sequences, which we do support. As usual, when embedding externally, any type of controls can be created and used to control the viewer.

This is possible through the API when embedding the viewer. The idea is that in the future it can be controlled through custom ShapeDiver components directly in Grasshopper (as well as camera positions and other interactivity otions).

Hi Mathieu,

I’m not clever enough to quote your quotes neatly so here’s my abbreviated response:

  1. Yes, that’s the title section. My problem with the way it works right now is that if I am iterating the same code and maybe updating the title every so often (test1, test2…test6) the latest title moves up the list as it becomes the more saved. But as I am repeatedly saving the same title I am expecting it to be in the same place. I end up saving the latest with an older title because of the habit of always selecting the last title in the list. It’s a trivial thing, feel free to ignore it! :slight_smile: But it would be nice to be able to simplify or bypass the configuration process when you are just reiterating and testing.

  2. OK :slight_smile:

  3. Great!

  4. Understood.

  5. I’ll look into that. Thanks for the links, I did wonder about that. But as I suspect most models will more focussed on indoor or building environments I think it makes sense for your easy-use environments to feature more office, home and so on than Piazza San Marco’s and Subway Entrances. Not a big deal, just something for the bottom of the list.

  6. Some users are going to be like me, not so comfortable with coding, even simple Javascript. I intend to try it out but I like the no-code approach. I look forward to that coming. ALSO, on that subject, maybe you could add a Javascript framework builder in the same way you parse the GH file to find the inputs. Then a user could cut and paste that into their web page and tweak the css and layout without worrying too much about the JS.

  7. In HTML the user could/would add section headings to complicated interfaces (Colours, Sizes, Materials, Etc). But it would be nice to be able to do that in a simple way in the config page while shuffling the order and visibility of inputs.

  8. Understood. I just found it odd that I could choose check boxes but only for multiple input options. Dropdowns or sequential input works OK.

  9. Excellent! I look forward to that :slight_smile:

First of all, congratulations for the great improvement with the the new texture options, image sampler and input geometry/texture from URL! I would like to add few more things that could significantly improve functionality for the users in the field of architecture.

  1. Camera- walkthrough navigation
  2. Collision objects ( e.g. for room wall collision)
  3. Switching viewport (eg. from plan view to camera walkthrough)
  4. Placing lights in Grasshopper
  5. Adding Heightmap (displacement map) for advanced texturing
  6. Adding Ambient Occlusion map for advanced texturing

All the best

Thanks for the suggestions, it’s always important for us to get those and prioritize the next features. Let me break down your points below:

  1. and 2. I am assuming those go together (as in being able to have walkthrough navigation without flying or going through walls). This makes sense, but it’s not in the roadmap yet, but depending on the effort we will brainstorm it.
  2. We are currently adding viewport management features to the viewer, they will become available soon.
  3. The API already has an interface to manage light sources in the scene, but of course it’s not easy to do programmatically and we plan to bind these commands with grasshopper components (which would then allow parametric positioning of the lights in the scene). I can’t give you a release date for these, but they are coming.
  4. and 6. We are considering those, although the rendering logic of our viewer might make it difficult to fully support them.