It is not uncommon to add entourage elements to the model in certain projects - things like people and cars, and also to go back and forth with CG archviz. What is the IFC attitude towards this? There is currently no support for high resolution geometry proxies, no support for the arch viz workflows like shader materials … what is the view on this?
If there isn’t much of a view, I would like to start a discussion in potentially storing some URIs to proxy models. The proxy model can then refer to whatever CG shaders, textures, and additional entourage are attached to that BIM element.
One potential solution would be to create a new type of geometry representation that is merely a proxy URI to an external library. That external library can then handle the rest of the geometric, rendering, compositing, material, texturing, etc details, in a similar way that document reference URIs work. This is essentially a similar proposal to IfcExternallyDefinedSurfaceStyle, except that it is for the shape representation.
A related issue is that I believe the current set of IfcSurfaceStyleLighting needs a few extensions to allow archviz to do their work. I would expect a property for RMS facet slope of the surface, or “roughness” in short. I would also expect whether the material is metallic or nonmetallic to be defined as an enum, as that greatly changes the rendering simulation results. This should cover the majority of basic cases I believe. The rest can be covered by IfcExternallyDefinedSurfaceStyle.
But of course, geometry and materials only make up a small aspect of archviz. Is the BIM model to include metadata about marketing shots? Or view corridors that the architect promised them they would see? Or if there are privacy requirements in the BIM model? Or line-of-sight requirements? This opens up the debate about storing IfcProject associated camera angles, etc? Maybe too much to chew on right now.
There has been a similar discussion before, but frankly, it hasn’t been a priority to implement visualization workflows using IFC as there is still a LOT of other work related to lifecyle workflows (Design, Procurement, Construction, and Operations). Detailed visualization workflows and requirements seem to be handled very well by software platforms that might receive BIMs from modeling/authoring packages and create further embellishments that really only matter for the specific visualization and are not of lifecycle BIM value.
But, to move such an idea forward, you really need to create a larger consensus among a diverse group of stakeholders to make the case and take it to the next level with a funded bSI project.
I see, visualisation workflows are one aspect which I understand your argument that it is not the priority at the moment (even though the fix seems to be relatively straightforward of an external URI).
Lighting, however is another matter. These are of lifecycle BIM value. For example the proposal of the addition of “roughness” and material type. Without the data, a lighting simulation is incomplete.
I will raise this issue with the Radiance lighting developers, so that I can get a more detailed understanding of how to improve the state of lighting data in IFC. I trust this counts as a “diverse group of stakeholders” as they are the world experts in light simulation.
What do you mean by a “funded bSI project”? Who funds this? What is the procedure?
Typically, any idea that requires changes to the schema or the creation of an MVD should have a project wrapped around it. Projects are executed within the governance of bSI, but funded by project sponsors (typically interested end users).
I am marking this thread as solved, as now there is support for multiple shaders and proxy objects in BlenderBIM using IfcExternallyDefinedSurfaceStyle and IfcRelAssociatesDocuments. This allows artists to have workflows using standard shader languages like OSL and RSL, and high poly proxy objects, whilst still working with IFC as a native BIM format!
