Lighting & Other

Kitty|Owl

Hello,

I figured instead of just lurking and posting in discussions (trying to keep some anonymity from my less than well thought out thoughts), I'd actually contribute something. So here is the first part of ongoing research into methods for lighting (from the beginning of the year).

This will be an ongoing thing with updates as and when I finish research or write-ups, or when people point out obvious flaws. In advance I apologies for my terrible writing style.

https://goo.gl/N1Cl4k
(it's a shortened URL so I can see if this is stuff anyone is interested in via stats  )

I've not decided what the next part will be on. Probably a short thing on pfx (grain, CA, flares etc), however perhaps colour design, colour psychology or grading & exposure.
let me know what you would prefer (or if you have any other topics you would like I can't think of all potential ones off the top of my head), I need to find a suitable test file for examples/images (since most of the time I work with stuff under NDA). 

For me its not just about sharing information, it is also about crowd-sourcing corrections to the information and also hopefully expanding into areas of research I haven't considered yet. It also forces me to correlate all the information into documents instead of relying on my own terrible memory  .


Notes:

photometric viewer link broken here is the correct one:
http://www.visual-3d.com/tools/photometricviewer/

fmnoor

I think you're really undermining the role of lighting artists and work that goes into lighting with your opening statement:

"the art behind Lighting has generally been a case of throwing arbitrarynumbers & colours around to create contrast and the ‘look’ desired in the scene. This is all wel and good (see fun), however with the increasing advances in rendering and technology it is no longer an acceptable pipeline. specifically in the case of exposure & tonemapping, a lighting artpipeline now needs to move towards a more consistent method of creation..."

 You are also forgetting the performance costs of dynamic lights and why exactly things are sometimes fudged to create results. The link to chromaticity is interesting to read, however I'm not sure how useful it is in film / games since a lot of times visual development doesn't follow reality - and you need to break the rules to create a look (while still grounding the scene in realism)

RN

Hello. Thank you for sharing, that is a lot of information.
The link to the "photometric viewer" seems dead (expired domain).

You mentioned at the end that decisions on light type and location aren't relevant, but let me tell you, I'd love to know more about how lights are chosen, placed etc. so that you not only light the scene looking for beauty but also consistency with how a real architect would do it. That snippet about the recommended height for a public light was enlightening, so a full article on that would grab my attention.

Unreal 4 seems to use lumen units for point and spot lamps:
https://docs.unrealengine.com/latest/INT/Engine/Rendering/LightingAndShadows/Basics/index.html#intensity

But Maya and Blender just use some vague intensity value, which needs to be adjusted perceptually I guess:
- https://www.blender.org/manual/render/blender_render/lighting/lights/light_properties.html
- http://download.autodesk.com/global/docs/maya2014/en_us/files/Lighting_nodes_Directional_Light_Attributes.htm#WS1A9193826455F5FF-29C43AA6117B26F372E2629

EDIT: To correct myself, some software offer photometric lights:
- http://marktomlinson.com/2012/11/14/maya-photometric-lights-mental-ray/

- https://knowledge.autodesk.com/support/3ds-max/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/3DSMax/files/GUID-96E37398-613E-495A-A80B-9C5D398982F9-htm.html

Kitty|Owl

@fmnoor
Just to clarify, I work in Lighting which is partly why I am writing up this & researching. I do not think I am necessarily undermining the lighting role, as in the past it has generally been a case of arbitrary numbers & colours to create the desired look. This no longer works in modern day pipelines, hence the statement at the end.

"a lighting art pipeline now needs to move towards a more consistent method of creation..."

performance cost isn't really an issue with using more realistic numerical data as a method for consistency in lighting production, most engines now have fall-off controls or methods to naturally fall-off towards the edge of a lights radii. you also have to design the lighting sensibly and account for the cost of what you are doing/aiming for. Fudging light radii and intensity to fit in a certain space will probably result in more issues than lighting in a sensible manner so you do not have to do that in the first place.

As for visual development and reality, I would tend to disagree. With the case of this data it is based on specific real world lamp types, which no matter what reality, would be the same/similar in most situations as a colour guide/rule.
For realistic world design following real-world colour and lighting data-sets actually gives you more flexibility. This is because end results remain consistent to the visual 'look'/style when grading (something which I will be covering at some point) that brings all the elements of a scene together.

You also have to consider what you are lighting and what type of light best fits the scene/mood, be that discharge lighting, tungsten, candlelight, LED etc.
what works well for the type of environment you are lighting? Because at the end of the day that sort-of decides the colour palette for the lights (I would classify magic fx as LED or black-body temperatures personally).

There are other reasons for following such a lighting pipeline, such as consistency in lighting as part of a team, prefab lighting solutions for large scale environments and day/night transitions.
The idea was/is to present a more consistent pipeline of creation and introduce/reinforce the idea of consistency in the way we light (regarding the use of intensity and colour). That doesn't mean you have to follow the exact intensity/colour from a real world light source, but use a range in a realistic manner relating to it. as mentioned below with regards to engines that do not support lumens or use basic unit values, you can take realistic data and multiply/divide to fit any scale you want, it makes the whole process easier regardless.

@Kryzon

http://www.visual-3d.com/tools/photometricviewer/

that should work, will add it to the first post.

For the location of lights, it would be a very long list of where and when, for architecture you would probably refer to lighting design guides (a lot of guides relate to lux recommendations for specific areas such as workstations, corridors, industrial warehouses...) for instance: http://www.healthandsafetyatwork.com/hsw/content/making-light-work
However many engines do not have some kind of lux meter implemented making lux a difficult idea to comprehend.
https://www.theilp.org.uk/documents/crime/
most public light choice in the real world is down to cost&visibility, which isn't always the best thing for art style. As mentioned above, consider what type of lighting works for the scene/mood. For architecture you normally have a location and can get reference from that location.

Photometric units aren't used that much in games (and as you found not all renderers support them), UE4 has lumens implemented in some light types but not all (so directional/skylight use multipliers instead). That said the idea of using lumen values from real world lighting is because lighting in the real world is setup with rules & guidelines on what is in acceptable light levels (therefore consistent).
With that in mind even if the particular software you are using uses 0-1 units you can take say 10,000 lumens and divide by 100 or 1000 (what value makes sense to what you are seeing onscreen), so 10,000 lumens becomes 10 or 1 respectively in that engine/renderer. this still means you can use more consistent values for the lighting.
you will always still need to expose and tonemap your scene at the end of the day anyway, but the practical setup of the lights between environments will be better.


I hope that clears some stuff up,

leleuxart

After experimenting with CryEngine's implementation for Luminance and Lux measuring, and EV controls, understanding and using real-world values has been an interest of mine as well. Unfortunately, it seems like Crytek's and Epic's tools for physically-based lighting are still a little early. One thing in particular that I don't like is how the tonemapper is split from the luminance measurement. You can easily get something plausible with the base values, but once you toggle the luminance debugger in CE, the tonemapper is disabled. I'd like to be able to measure it with and without actually. 

I'm not too fond of the reliance on cubemaps for ambient lighting either. Luckily, you can measure the scene luminance with those active, but any changes to the probe would probably require a change to the tonemapper again. Hopefully SVOGI and other real-time GI solutions are improved performance wise in the near future.

I'm looking forward to going through the document later on tonight