This will not be a technical question. I would like to have a discussion about product configurators in the context of furniture/kitchen purchase.
The reason I want to have this discussion is because I think that ShapeDiver even with its’ limitation of visual fidelity and calculation speeds is still the way to go if your priority is to have a flexible platform and be independant from the developers (relatively) in the long run.
Currently, we just started our partnership with the developers that will create a front end for our furniture/kitchen configurator. The problem is that after showing their portfolio made in Unity game engine the conversation swayed towards how pretty and realistic the visuals should be so now I want to build better case to convince my manager(again) to go shapediver way.
I think we could maybe share our experiences and leard something here. What do you think guys?
Is realism really necessary? Is it necessary if your biggest target group is females, over 30 years old?
Making product configurator in game engine might make it look really good and distinquish you from the competition, but it puts your platform in mobile only environment (because almost nobody would install a program on their pc/mac for the purpose of buying a kitchen or install a Unity plugin on their browser) Do you guys think that in the era of mobile devices most of people would use their phone/tablet to configure and purchase a kitchen or use laptop for it?
Is there a way to synchronise parametric model of a furniture in unity with parametric grasshopper model without building 2 versions of the same design? What I mean is that a model in front end that is used for display and interaction is then needs to be manufactured (cnc) and data for manufacturing/part labeling is generated in grasshopper.
Do you have any stories to share when working with developers? What to be aware of?
It’s refreshing to get a non-technical round of questions. I think you are in contact with our team, but I will post some answers here as I think they are relevant to all ShapeDiver users.
About realism:
Technically, I think visual fidelity in ShapeDiver is only limited in the sense that we did not build a flexible interface for setting rendering and material properties yet. I don’t think Unity gives superior results to WebGL, provided that all rendering settings are optimized. Other online viewers (WebGL or Unity) often come with advanced PBR and lighting settings, which help users improve dramatically the visual results. We have it on our roadmap for later this year, but we are still playing with different ways to give this type of control. In addition to the traditional “in viewer” options, we also want to allow users to define scene parameters from Grasshopper, which is more convenient and would also allow to define parametric scene settings (think moving lights, variable intensities, etc…). One thing we will already roll out shortly is the possibility to easily upload custom hdri maps, which have a significant impact.
Now to the more specific question of whether realism is necessary, it’s not black and white. There is a sort of uncanny valley in which models with a poor level of realism tend to look worse than schematic renderings. Actually, many first generation 3d configurators on the web suffer from this problem and possibly delayed the adoption of the technology on a widespread scale. Sometimes, going for the schematic configurator (like Munson Furniture) is a safe bet. I think this issue will become less and less relevant, at least for some types of products. Textiles will remain problematic unless some physics are added to the 3d view to give them a bit of life.
About Unity/WebGL pros and cons:
As I said above, I don’t think there is such a significant difference in terms of rendering anymore between those two technologies. In that sense, I really don’t see the benefit or using Unity to build an e-commerce application, for the reasons you are describing yourself. At ShapeDiver, we are betting on native web technologies which can be run with a browser, period. The only reason to go for an app in this context is to get Augmented Reality features. We will likely develop an app for viewing ShapeDiver models in AR, but also realize it is a temporary solution until AR becomes supported by web browsers, which will happen in the not so distant future.
That being said, outside of pure e-commerce use cases, having an app is not such a dealbreaker in case of B2B sales or whenever a salesman can mediate and help the customer through the configuration process.
About synchronising a Unity app and a Grasshopper model:
ShapeDiver provides a backend API, but it’s only available to Enterprise customers. With it, you can communicate directly with the servers, send parameters and receive geometry and data which can then be used without the ShapeDiver viewer, for example in a different Unity viewer. If you choose to go for the Unity app, contact us to learn more about this feature.
About working with developers:
I’d say that the most common issue is for everyone working on a project (web developer, Grasshopper designer, UI/UX designer, etc…) to start working on their own tasks without communicating beforehand, discuss the workflow of the app and the user’s journey. ShapeDiver makes it possible to delegate critical parts of 3d web applications to designers, which significantly cuts time and costs. However, it means that the inputs and outputs of both the Grasshopper model and the online interface need to be mapped carefully before the work starts. Those topics are covered in the documentation, so make sure everyone spends some time there before jumping in.