Augmented Reality Mixed Reality Virtual Reality
Smart3D Episode #20 – 50 Shades of Black
Guest Contribution
There’re many shades of Gray, but can there be more Blacks than one?
Today’s CPQ solutions are typically client-server based. Depending on some user interactions, the back-end does something and sends something back to the front-end, typically via the Internet. Easy as it can be… but the more content comes into play, the more round-trip optimizations might be required, because it’s all about the User Experience, isn’t?
For our heavy-weight 3D stuff we thus should think about incremental ways to reduce the data traffic after each configuration step. This becomes even more relevant in case of configuring multiple articles at once. One way is to transfer delta updates (structure, geometries, textures, etc.) to the client. This however requires a strong connection of server- and client-side states, a certain intelligence?—?both on the server and the client?—?and is probably hard to be implemented in today’s asynchronous Web worlds.
We follow a different approach by providing a specific round-trip for model updates that can be fully implemented at the client side. Playing with different materials, aka colours, fabrics, textures etc. is one of the major CPQ use cases and it makes complete sense to support this as best as possible… (once again, remember the need of simultaneous configuration of?—?let’s say?—?a dozen articles at once). But then we need to clearly identify the components of the products. The material itself, such as Black, is not sufficient for this because two components that can be controlled independently by ERP characteristics, can have the same material at some time, of course. That’s where Material Categories appear on stage!
A Material Category is simply an indirection that is bound to any component (and inherited recursively), which always links to a Material (see Episode #3). Similar to Materials, Material Categories are fully scoped (to avoid ambiguities) and can be shared among all product lines of a manufacturer if that is wanted.
Material Categories can be declared directly on characteristics coming from the ERP/CPQ including a Default material in case there’s no initial value for that characteristics. We typically use an emissive red color for this.
As easy this sounds, as amazing is the speed on the client side! No difference to local applications I would say…
Does it mean, one always needs to have a Material Category?—?even for fixed Material assignments, which never ever change later on?! Nope, there’s a little trick here: If the Material Category starts with an @ then it’s a so-called implicit category pointing to a fix material. For instance, @Scope.SubScope.Chrome links to directly to chrome.
Sometimes, material-bound characteristics are a little bit troublesome and partially require geometrical updates (UV mappings, etc.). We solve this by auxiliary properties as part of the CPQ-3D mapping layer. This increases the number of geometrical roundtrips but is still very efficient compared to full roundtrips all the time! But even for full geometric roundtrips there’re ways to optimize them, and we’ll come back to this in a later Episode.
For now, enjoy the Material Categories and keep in mind, that Black parts may not just be Black but from different Material Categories.
Powered by WPeMatico
