[x3d-public] Model Profile: Lights or Not

[Roy Walmsley]

Leonard,

 

Thank you for this posting. A very interesting discussion.

 

First, let me say I am not contesting your view. I just want to be sure I understand the common practice.

 

I fully appreciate that development of 3D scenes “in-house” might easily mean that a modeller only generates the geometry, and textures, and any lighting, are added at later stages.

 

Now, choosing a ship as an example model that might contain lights,   where the purpose is not so much that they illuminate the model or any potential surroundings, but are simply there as identifies to be seen by others. And here I am thinking of the red and greed marker lights. If a ship model is developed for sale to, shall we say, the public, will the model creator simply put these coloured markers on as coloured materials, perhaps using emissive properties? And not as a “light source” in the sense of something that illuminates other content?

 

So, if this is the case, when we say “you don’t have lights”, what we mean is that “you don’t have light sources, that participate in the lighting equations”.

 

Taking this one step further, a model creator, even for selling models, would “never” add “light sources that participate in the lighting equations” to a model that might be distributed to the public. It would be up to the user of the model to add any “light sources that participate in lighting equations”, even if they were internal to the 3D model.

 

Thanks again,

 

Roy

 

From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of Leonard Daly
Sent: 31 January 2018 18:46
To: X3D Public <x3d-public at web3d.org>
Subject: [x3d-public] Model Profile: Lights or Not

 

In the X3D WG call today there was a discussion of usefulness of lights with models. Some participants contend that certain models have lights and those need to be included with the model. An example of this would be building lights, running lights on vehicles, or emergency lights.

Summary: Including lighting in models is not the way the topic is taught in artistic educational institutions throughout the world. Model lights reduces the models usefulness -- it cannot be printed and take additional work to use in other applications/environments.

 

It is my contention that lighting is not the purview of the completed (static or animated) model. This position is explained and justified below based on industry development, limitations of use, and alternatives.

First I wish to define a few terms:

1.	Geometry - the collection of quads, triangles, lines, points, and other surfaces that comprise all of the geometry elements of the object. 
2.	Textures - the collection of all surface or volume coloring. This include (flat) material, image and volume textures, physically-based rendering (PBR), and specialty materials usually expressed as shaders
3.	Rigging - the process of defining a skeleton and attaching the surface to the skeleton for animation
4.	Animation - The process of defining all motions and positions that the object may assume. This includes predefined motions (such as walking, running, etc.) and procedural ones. 

In the Model profile I explicitly excluded lighting because lights are part of the scene. A light interacts with multiple models and the scene environment. The scene environment also interacts with lights (e.g., fog or mirrors). It might be argued that certain lights that only interact with the model could be used. Those lights would not interact with anything else -- either another model or the scene environment. All of the examples listed in the start of this post could interact with the scene -- building lights with other buildings, running lights on wet pavement, emergency lights with everything within range.

Note that even small dim lighting like dash lights would interact with anyone who gets in the vehicle, and the result would be different depending on the texture of the person.

Keeping lights out of models allow models to be used in many different situations. The WG looked at the TurboSquid site. None of the models that were examined included (model) lights. One person brought up the page on 11 Helpful Do's and Don'ts (https://blog.turbosquid.com/2017/07/13/selling-3d-models-online/). #2 on that list is saying "DO" prepare your file (model) with lights and cameras. These are referring to external lighting and static viewpoints, especially those used to construct the model previews; these are not lights intrinsic to the model.

A (static) model with lights cannot be printed. The lighting changes how various parts of the surface appear and needs to include other changes to the environment, none of which is available to the printer. If the interior of a model needs to be lit, just bake the lighting into the texture. This goes for selective/localized lights (e.g., spot lights) or diffuse/panel lights (building windows).

Existing lighting equations are just approximations to what happens in the real world. Different types of systems (ray trace, Phong reflection, sub-surface scattering, etc.) are used for different levels of results. The closer to "reality" one needs, the more complex (and time-consuming) the processing. In nearly every situation, the lighting equation is out of control of the modeler. An assumption of a particular kind of lighting system for rendering can severely limit the use of the model.

Lighting is baked into the texture. This can be accomplished in several different ways depending on the model requirement. It can be done as a material with flat geometry and vertex colors, an image texture applied to the surface, PBR (if available), or highly-specialized materials implemented with shader code. I have not encountered a single example where a model absolutely must contain lights.

 

-- 
Leonard Daly
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Past Chair
President, Daly Realism - Creating the Future 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180131/d50b0e3e/attachment.html>