FYI: Graphisoft has not finalised the DTV MVD implementation.
@Moult thanks for the links. How did you find these. It is like to look for a needle in a haystack.
+1 to all what you said in your long post about BuildingSmart, and yes just the existance of this open forum is a huge step.
bernd
1 Like
Quite the read. Although much of your criticism is spot on, this thread is IMO not the place to discuss this.
I would not agree on the participation though. Of course there is a membership fee required to be on the boards. How else can you manage such an international organization? Especially, since there are formal structures in place to publish such standards. But let me tell you, that does not ensure that you are taken seriously. It is all politics unfortunately. 
1 Like
bSI’s politics “hope” works
Building standard is one thing, protecting it is another thing, if “companies” find that “software vendors” and “standards” don’t help them, for sure will look at another alternatives
For instance, do you know why today some companies have started to use, for instance CATIA from Dassault Systemes? Because some software vendors still talk about Information Management, when some have started to work on Knowledge Management level
Chiming in, I’ll take a look to see why these colors don’t show up in Revit. As you can imagine, our backlog of issues isn’t tiny, and color problems are … let me check … about 1% of the reports (including import and export). So when we are triaging issues, color tends to get the short end of the stick. That said, I agree with most of the comments about processes and priorities around IFC, and I’ll repeat again (and again…) this should be implemented once, not 100 times by 100 people with a 30% success rate and randomness by the other 70%. Will repost again with my observations.
1 Like
OK, looked at the file. We don’t support IfcSurfaceStyleShading or IfcSurfaceStyleRendering in Link IFC yet (see reasons above for lower priority). That said, I don’t think that IFC file is really what you’d want, anyway. You have a material (‘mass’, #36), but it has no properties at all - it’s just a name. I think what you’d really want it to apply shading/rendering to the material, and then apply the material to the mass. All you’ve really done is add a material tag to the mass, and then painted it. That’s clearly legal, but probably not the level of information you want to convey.
1 Like
Thanks for taking a look @angel.velez. To be honest, I’ve tried it by associating the color with the material and then associating the material with the product, and that has not worked on ArchiCAD or Solibri (my test platforms on the Mac), but it’s possible that it works on Revit. I’ll have to get one of my colleagues to check on Revit.
The larger problem is that there are 3 ways, if I’m counting correctly, to apply a color, and every application chooses to support a different one. According to the implementors agreements linked above, it would seem that a certified application would need to support all of the methods, with the proper fallbacks.
I’m beginning to think that the most useful thing for the developer community (before modularization or anything else) would be a set of IFC files with accompanying images from various applications to demonstrate how things should be encoded and what a developer should expect to see when that file is loaded in an application. I know @jonm has created some of these, and I used those to debug some of this color stuff, but there was only one example of an indexed mesh with colors that didn’t really apply.
2 Likes
I think you are wrong - there must be way more than 3 ways . This isn’t the only case of that - to express a line segment in IFC, there are also at least 3 ways to represent that correctly in IFC. And I think that’s my biggest concern - there are many legitimate dialects of IFC, and all of them are different in what they support, so it’s no real surprise that IFC doesn’t seem to work as a result.
Many years ago, there were some reference files sent around that showed how Revit (and other applications) weren’t supporting some advanced swept solilds in IFC. That did result in a better implementation, and they are used in regression testing. If there were reference files for “the best” implementation of color and material, that could form a baseline. As it stands now, everyone goes off and does their own interpretation, and it wasn’t a big part of any recent certification. The approach you chose I think is the one that is most “viewer” friendly, because it concentrates on paint. The material approach should be the one that’s most “BIM creation” friendly, since you want to apply materials to geometry. But who knows.
1 Like
Let vendors implement all three methods. Not just one using material. Colors have an important visual function during construction to help understand complex shapes and erections. Image as example, source Linkedin Tekla Structures use.
1 Like
@angel.velez - The below screenshot shows a file created with the BlenderBIM Add-on which has two cubes, with one cube assigned a colour by shape, and another cube assigned another colour by material. Both use IfcSurfaceStyleRendering.
The screenshot shows colours displaying when an IFC is opened as a regular file.
The screenshot shows colours displaying when an IFC is linked into a Revit model.
The sample file is here: revit-color.ifc (8.4 KB)
As you can see, Revit does support both colour assignment techniques, as well as the IfcSurfaceStyleRendering, however, there are caveats.
There are two ways to assign colour: by material and by shape, as shown in CV-2x3-131 and the documentation.
2 Likes
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
FWIW
This is a IFC to DWG conversion using BricsCAD. The color of red cube seems to be wrong.
I exported it back and attached both files.
According to information of BS Internation and based on the documentation provided by Autodesk the newest 2020 Verticals may have improved it’s IFC abilities allready (1). This is based on to information provided by @jwouellette (2). Because new efforts are being made and based on the certification in 2015 it seemd that okidoki about AutoCAD should be okidoki then. I am not able test the new 2020 version but can say from experince the older versions have some cathing up to do when it comes to IFC. It’s far from perfect. Besides the quality the speed of import and export is a major issue. (btw. Is the time to import export a criterium anyway?
(1)
(2)
revit-color.dwg.ifc (326.3 KB)
By the way - don’t use my revit-color.ifc for testing colours in other apps - it contains a non-standard tweak just for Revit so that Revit can import it. That said, if the red colour doesn’t show up, it is still relatively likely to be a sign that the software (BricsCAD in your case, @Hans_Lammerts) does not support the “by material” assignment of colours.
Thanks. I will inform my friend in Belgium.
Not supported for Link IFC. Open IFC still uses an older, internal code path that has more support for 2D objects and can create more native objects, but at the cost of speed and fidelity. We do plan to merge the two code streams and take the best of the open stuff and migrate it to open source.
Yes and no. I agree the two should be merged. But they would still be different. Link is for reference - it should be fast and not parametric. Open should be a rarely-used operation for design transfer, which prioritizes parametricity over absolute fidelty (e.g., you may need to clean up a wall join to get a real Revit wall, versus a referenceable object of category wall). If you want a link that is a design transfer, you can always Open IFC, save that file and link it in. But that’s rarely what you’d want, I think.
@angel.velez Does IFC Link or built-in IFC import support textures? I’m asking here because I’m not even going to take a run at getting that to work if your answer is no
Hi @ian,
If I may, in general, there has been no official concerted effort to develop texture support among the ISG. We’ve primarily focused on coordination and core information exchange. Visualization workflows which have more demand for texture support have been talked about, but not acted upon. It seems to be a lower priority among the vendors than IFC4 support and certification of the Reference View.
I know some people will squawk about this, but I think there are lots of other workflows that everyone is currently entangled with that will have higher value in an interoperability and information exchange sense. That’s not to say if will never be addressed, but I think we can all agree there are some larger pressing issues that must be solved for this to be worked out correctly and quickly, once initiated.
@Moult has worked a little bit on the material and texture in BlenderBIM
And I think today USD (https://graphics.pixar.com/usd/docs/index.html) has a good potential to be a reference
Autodesk works on MaterialX (https://www.materialx.org/) as well which is based on USD and mainly for Maya and 3Ds Max
We have MaterialPass in mind which is more advanced
@Hans_Lammerts: The IFC file is always converted unless the receiving system used IFC as-is as their system. Even for systems that use IFC as some sort of base, they still modify it in some case.
Furthermore, linking is not about converting or not. Linking is about maintaining associativity to the source content. Linking means that if the source content is updated, then what you see is also updated, either automatically, or because you are prompted to update.
If you think Autodesk is unusual in this case, take Tekla. When Tekla imports an IFC file, it doesn’t create a native object - it creates a proxy object that can be converted to a native object. In BIM Vision, which is IFC based, it still doesn’t use IFC for graphics generation, and it makes modifications. There’s no way to use IFC, as-is, to be a full data model for any content creation system.
But to explain more - conversion can be to different Revit objects. Take a wall. You can use the Revit Wall API class, which is fully-featured. Or you can create an in-place family with category Wall, which allows you to create extrusions and sweeps, and has some rudenmentary support for inserts, but which aren’t shared. or you can use DirectShapes, which store geometry, can be referenced, are room bounding, can be updated with a link update, etc., but have currently no geometric modification possible. The time to create the first two element types is much slower than the 3rd, because there is a lot more parametric stuff going on, which isn’t needed in a link case where you can’t modify the source file, anyway.
@ian: Nope. We don’t have texture support. We do have a more robust Material API than we used to, so it isn’t a hopeless cause, but I’d be surprised if IFC had all of the information Revit needed to create materials with proper textures. But haven’t even tried.