9am Pacific
1) Usd Light shapes are complex and the position of the light is the center of the light shape ( i.e. center of the sphere or rectangle ). In Unity, the position of the light is the tip of the light cone or pyramid . This means that the lights have to be offset relatively to the radius of the sphere and the spot angle. This may result in lights being incorrectly placed ( ie : ceiling light moved through the ceiling to the upper floor )
2) The cone shaping properties do not match what we have in Unity :
3) Scaling affects the size of the light in RenderMan, not in Unity.
This is not clearly documented in USD, there’s nothing that mentions how lights should behave with scaling. Moreover, non-uniform scaling or shearing can be applied which is not supported by Unity lights.
4) USD Lights intensity unit is not mentioned in the documentation but it appears to be nits like in Renderman. However it looks like DCCs don’t perform any conversion and just write whatever value they’re using.
5) USD lights don’t have a range property.
Light can be in USD in Unity but we can't move them in Unity.
How engine centric lights are? It seems they are very engine centric.
During your work, is there some other software such as Autocad that you use to import back to game engine?
In FBX, cone are supported
At Remedy, light are from now, engine lights only, because of the probes that are used. But basic properties should be transferrable into USDLux.
Infinity Ward : Some maths are needed between Omniverse and DCC. They are not believing that USDLux have the full description of lights for the engines : it is a one way trip with calculations for units.
Light are used for cinematics, etc. eg : headlight will work differently in realtime that in cinematics.
Emissive materials are not listed as lights. They are not supported in UsdShade. Basically USD is not supporting emissive for now.
There is no light asset for now in the USD assets. There should be added.
Question : how to make it good to have the correct result? Which render to use to have the source of truth?
Are units well defined? Is there a way to define Candela or Lux?
Michael indicated that there is a wider effort to add unit in USDLux.
Sebastian "spiff" Grassia mentioned there is kickstart to incorporate PhysLight. There is still a lot to do. https://github.com/wetadigital/physlight
Thoms Chollet is wondering if it would be possible to have schemas for lights.
Koen mentionned that USD Lux and USD PreviewSurface are the least common denominator.
Sebastian "spiff" Grassia (Pixar) : The idea for USDLux is to be the base line for lights. And then having schemas for lights that will support actual lights (eg the Renderman plugin)
Having a DCC set of specifications makes sense
Michael B Johnson : we could have a distinction between asset lights and shot light. For example for building : what light during day time and what light during night time?
Jeremy Cowles explained that his previous experiences with FBX and GLTF made him think that having a starting point ( position, orientation, type) is way better than nothing.
Sebastian "spiff" Grassia : a lot of work to support light is done in Renderman. They (Pixar) need people to come back to them with concerns.
Koen : Games and VFX/Movie are very diverging for lights : eg : not the same usage of Raytracing.
It would be very difficult to go in the same way for both.
Sebastian "spiff" Grassia there are applied schemas for USDLux. For example : Sphere light could be a pointLight in a game engine.
Koen : we want to be able to transfer basic information. USD needs to contains information.
Thomas Chollet Action Items:
Sebastian "spiff" Grassia unit are easier to define. The shape is more difficult.
There is a new USD LUx channel : https://academysoftwarefdn.slack.com/archives/C058Y8P0LKU
SantaMonica Studio: They are checking what they need to work with USDLux. Their plan is to have special schemas for lights. They also want to move a lot of data in USD.
Jeremy Cowles we could make the game engine the hydra delegate. At Unity they made experiment but they stopped.
Levi Biasco mentioned it could be a lot of work
Koen explained that if your game engine is an hydra delegate you can switch from Renderman to your game engine!
Jeremy Cowles suggested also that it would be the last part of the USD integration.
Michael B Johnson but if you have very talented lookDev Artist, it could be great
Koen : but it is too much effort.
There is no software that can handle large levels because of the amount of specialization and optimization we have in game engines to make it possible.
Michael B Johnson is wondering is OpenUSD could be a way to create hierarchy.
Koen replied that in games it is more what the camera is seeing.
At Remedy, USD helps creating level and the asset are created in Maya.
Ubisoft is preparing a PR for LODs (could someone link the proposal here?)
Is there an ETA for expression driven attribute?
Sebastian "spiff" Grassia : more than one year out
Koen is wondering how to use joints in UsdSkel ? How to create constraints? How to attach bones?
How to use rig at runtime? : eg how to attach a gun to an hand?
Sebastian "spiff" Grassia mentioned that is TBD : it is not explicitly designed yet. How much is part of USDSkel and how much is part of rigging?
Light follow-up:
Semantic connections