Welcome

RELUX and DIAL present the new unified lighting data format for luminaires and sensors: GLDF. It could be used directly in RELUX and DIALux. GLDF is open and free available for everyone. Thanks to the joint forces the format is technically robust, modern, and universal. In the future it may replace other and older existing luminaire data formats, which is a huge benefit in creating of data on manufacturer side and a benefit for designers and luminaire data users in a reduced handling and an open structure. GLDF includes more capabilities as ROLF and ULD format combined.

Motivation and History

On my last LICHT 2018 proceedings and presentation in Davos, I ended with these words:

“Another potential and interesting application of the common lighting properties would be a lighting data format. A new, modern and modular lighting data format could be the result of harmonised definitions and intense tests. This new one, could replace all other current lighting data formats from simple to complex, cause of the modular structure. And it could contain much more information as today‘s exiting ones. But just a true replace could save efforts in creation and interpretation of lighting data.”

Today is the day where we can proudly announce a new modern luminaire and sensor data format will be very soon available. RELUX and DIAL have put almost two years of work into a modern data format to cover actual use cases for the BIM area. This is a big step for the lighting industry with its lighting software applications.

GLDF Technical Benefits

One advantage is obvious: luminaire manufacture members of RELUX and DIAL only have to create one format and one geometry. In addition, the format also offers these new technical features for everybody, even for non-members of the two software houses:

• several variants of a product with its own GTIN
• definition of lamps in absolute (LED) or relative (conventional) state
• embedding of pictures, geometries, documents etc. as a file or link by using a link:
  dynamic assets form a central server are possible
• geometry from eulumdat, parametric objects or as a 3D model; multiple LOD
• light emission surfaces, rotating elements, suspension points and electrical connection can be defined
• luminaires with multiple light emitters and/or sensors
• emergency lighting LDCs or Emergency Ballast Lumen Factor
• constant light output CLO and international maintenance factors
• spectrum and dimming curves
• checksum for pure data validation or detection of manipulating
• optional use of all ~350 CEN/TS 17623 - ZVEI lighting BIM properties
• use of other BIM, IFC or even custom properties

GLDF was created by RELUX and DIAL experts with decades of lighting experience for all modern BIM use cases. Everything a manufacturer could communicate about his product, can be enveloped in GLDF.

LDC and Luminaire

In the past often just the photometrics of luminaires, the LDC – Light Distribution Curve was handled and used in lighting calculation and simulation applications. For a pure lighting calculation nothing more is truly needed. But with two or more light outputs or some additional photometric information like spectrum or flicker this gets problematic. Today a designer has to deal with more than just lighting dimensioning. He needs product information like tender text, prices, GTIN numbers and more. The product qualification process depends on a lot more data and on a simple picture and 3D model. A LDC is neither a luminaire nor a product, it is just a part of the luminaire. But an import one. RELUX and DIAL invented early on the two product data formats ROLF and ULD to cover this design need. Manufactures are used to fill up product in- formation beyond the simple LDC. But ULD is closer to a binary format and could just be created with tools restricted to members. Also, the ROLF is a proprietary format and just to be used in RELUX applications and created by RELUX members. Theoreti- cally ROLF (RELUX Open Luminaire Format) is an open XML structure and could be created and used outside RELUX tooling.

GLDF Structure

GLDF is technically a (zip) container with the file ending .gldf. In this container a XML file define the product in a clear structure. Beside the XML the GLDF file contain sev- eral file assets like pictures, LDCs, geometry and documents. The core element is the XML which describes all product features and variations. The XML contains three ma- jor blocks: the header, the general definitions, and the product definitions. The header just contains technical aspects and manufacturer information. The GLDF format is open and free to use. But the usage in the software applications will still require a membership or another kind of licence. So, the software decides what and how deep it will interpret the GLDF depending on the included licences.

The second block “general definitions” contain all references to files and defines a setting of lamps, control gears, photometrics, geometries and equipment. All fundamental aspects of the luminaire are referenced with IDs. GLDF can use photometrics from Eulumdat, IES (IES LM-63) or the new IES XML (ANSI/IES TM-33 or UNI 11733). The last block “product definitions” holds all properties of the product and all variants. The single variants could have all properties separate from the product master. In each variant all reference IDs from the “general definitions” will be put together to products. This allows a large and effective creation of variants of a product. GLDF could be used in an XML scheme with all capabilities. The GLDF scheme will be available in XSD. Together with some examples it will be no problem for professionals to create GLDF files.

Somebody with BIM and data format knowledge would ask: Why are you not doing this in IFC instead of XML? IFC is open free and contain custom properties. Today IFC is just defined for buildings and not for single products or objects. Parallel to our work on the luminaire format a CEN expert group (including me) is creating the prEN 17549-1 and -2. A standard to describe single products in a customised IFC (XML) which validates to IFC4 XSD. Brilliant work but 2 years too late.

Besides the timing native IFC is a quite complex way to describe luminaires. IFC could transport a luminaire in a building with 48 properties, rigid geometry and LDC properly. But it is far more complex as our GLDF. To integrate our requirements on a modern data set of a luminaire and sensors (colors, rotatable joints, spectrum, variants, etc.) it would grow dramatically in complexity. I doubt that this luminaire enhanced IFC would validate against the IFC XSD anymore. And there is no benefit in having forced GLDF into IFC; no BIM authoring system would understand it and would therefore just display parts of it. And it would be much harder to create and to interpret the format. Maybe we could check again the IFC relation of GLDF in a couple of years.

Geometry Options

GLDF has three geometry options

• No geometry. Just the Eulumdat primitive.
• A parametric geometry with simple objects.
• A full 3D model based on the new L3D format.

Geometry is technically not necessary. The format could be created just with a name and a Eulumdat. The box or cylinder of Eulumdat will be taken as basic geometry. Of cause, it would make absolute sense to put a real 3D model into the GLDF. There will be a new mesh-based 3D model format with the name L3D for this purpose. A way in between are the parametric geometry models. Here it is possible to describe basic luminaire shapes with alphanumerical values. It is also possible to do both or all three options in one file for the benefit of a multi LOD luminaire geometry.

Parametric Geometry

The idea is simple: a set of basic luminaire geometry shapes could be altered with some parameters to hit the real luminaire shape as good as possible. There is no need of 3D modelling, an expert or modelling software. All parameters can be entered in a simple table and the 3D shape will be finished. RELUX started with a first set of basic shapes and provide this idea to the ZVEI. At ZVEI the BIM project group finalised and tested the parametric geometry concept. We created an XML schema to transport the parametric geometry inside the GLDF as separate XML file.

Today there are 51 basic shapes which can be used. But this amount may change with the time. Depending on the basic shape up to 46 parameters could be used to cus- tomise the basic shape. All parametric geometries have luminous surfaces and light emitters. Optional it is also possible to describe the electrical connector position. With this description, especially of the LDC position, it is easily possible for a lighting design software to build up an exact and full operatable luminaire model.

With this system geometry could be created, processed, and transferred in a PIM system. Almost everybody could create luminaire geometry. We will interpret and visualise the parametric geometry. There are also ideas for some interesting helping and creating tools.

At the moment this concept is not compatible with the similar ETIM MC model. The MC classes has a different approach of a pure 3D object visualisation and could not contain LDC or electrical connector positions. But ZVEI, DIAL, RELUX and ETIM working on a mapping of both concepts. Ideally it should be compatible or a least simple to convert.

Geometry Format L3D

The 3D geometry took a lot of efforts in the GLDF project group and probably also later at manufacturer side. On the other side is a unified geometry a huge cost saving for the manufacturers.

Sadly, it is not possible to take an existing 3D format and just add some properties for the lighting usage. For a long time, we focused Collada as open XML basement for our GLDF geometry. The 3D model authoring systems could not provide this custom lighting properties (e.g., light emitter) in a unified way.

So, we stick to what RELUX and DIAL had done quite well separately in the past and created an own new data format for geometry similar to the today exiting r3d and m3d (m4d, m3d+). But this time together and open for everybody.

The new L3D geometry format is also a zipped container format which includes a descripting XML and OBJ 3D objects. OBJ is a simple open ascii based mesh format. It is quite common and could be exported from the most 3D modelling applications. OBJ could also handle textures and surface material. This is an edge over to the old r3d and m3d. The XML stores the relation and rotation behaviour between the different OBJ objects and create in this way the full luminaire object. In the XML also all light emitting objects, the luminous surfaces, the pendulum- and the electrical connector are defined.

Since the L3D is a new creation, it has to been created manually with OBJ files and the XML today. We will work on tool(s) to create L3D geometry files with a graphical editor. It would be technically possible to create L3D addons in AutoCAD, Revit, Sketchup, Solidworks or Blender. It is “just” an effort. Since the L3D format is open and public available it should be possible that someone create a nice tool or addon. Of cause, it would be even better if someone made it publicly available too.

L3D files could be used in GLDF: as file in the container and as file reference in the XML. The name of the light emitters, which are defined in the L3D, will be referenced in the GLDF. All Light emitter properties like offsets, sizes, rotations, etc. are set in the L3D file. We will interpret and visualise L3D via GLDF.

How to create GLDF?

The best way is the creation of the GLDF right out of the PIM system. It is just an XML file where all files and properties are written in. If you were able to create ROLF directly out of your systems, then you almost certainly get GLDF created. The container aspect is maybe technically new. But this is just a zip event and a renaming of the file suffix. We have a lot of tools in mind to support the creation of GLDF in a similar way the RELUX member tools supported the ROLF creation. There are a lot of options, from Excel template to database tool. The specification of GLDF and L3D is public available. The public could develop free and open tools too.