Is there a model corresponding to KHR_lights_punctual somewhere?

[cx20]

I would like to test the model corresponding to KHR_lights_punctual.
I found a model below.

https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_lights_punctual/schema/examples
https://github.com/mrdoob/three.js/tree/dev/examples/models/gltf/Monster/glTF-lights

I do not know who to ask for, but if you do not have a problem with rights, I would like you to donate to the glTF-Sample-Models repository.

[donmccurdy]

I made a couple others here: KhronosGroup/glTF#1223 (comment). They may require some cleanup, it's currently a bit fuzzy for all of these examples what counts as a passing test.

[emackey]

A new PR has shown up, KhronosGroup/glTF-Sample-Models#210

[DRx3D]

There have been no comments in almost the last 5 years. The PR (#210) was closed without merging. It could be transferred to Sample-Assets if the initial request is still relevant or just closed. Do you have a preference @cx20 ?

The default operation is to transfer this issue to glTF-Sample-Assets

[emackey]

We still need a better sample model for KHR_lights_punctual, ideally one that somehow tests the various light sources, their influence and strength, to visually inspect conformance to spec.

[javagl]

That 'visual inspection' may be a bit difficult. Regarding the one from KhronosGroup/glTF-Sample-Models#210 , there was the comment by @emackey at KhronosGroup/glTF-Sample-Models#210 (comment) with some concerns. These might, at the core, be the same concerns that I have when it comes to these 'simple test models', where the goal is not to "look cool", but to easily understand what the model contains. The models from KhronosGroup/glTF#1223 (comment) might be closer to this goal, because they have a very plain structure and 'documentation' (via these labels).

I've also been playing with some options here, but it may be necessary to sort out what should be combined in a single model (or whether there should be dedicated models for point/spot lights, for example), and what the 'parameter space' is that should be covered. This one only covers 'different point light intensities' (and the aspect of mixing lights, even though I got a bit carried away in the 'looking cool' direction here...)

[donmccurdy]

I would just note that matching physically-based units in lighting also requires matching up the image formation step. Even if you do the unit conversion correctly when exporting from Blender, it doesn't look nearly the same in three.js (or other tools) without adjusting exposure, at the minimum. Probably there is some way to derive the correct exposure in each tool, but I don't have that conversion.

[javagl]

Even if you do the unit conversion correctly when exporting from Blender

The last example was not created in Blender. It was generated purely programmatically (with ... some cool library that you might know). Doing stuff like this in Blender sounds... daunting:

The exact settings for the light handling in the final application have to be taken into account. Some of the "formal background work" (i.e. the maths, energy conservation aspects and whatnot) may already have been done in https://modelviewer.dev/fidelity/ . But ... these settings are ... somewhat independent of the model itself.

[DRx3D]

This issue will be transferred by 29 Nov unless there is a comment to do differently

[javagl]

To get this off the plate: If someone has a strong preference for what such a model should actually contain, then drop a note here.

Otherwise, I'd create a PR for this model, which just shows a bunch of point lights with different colors and intensities:

This is created with a utility class from input data like

const height = 1.0;

type LightInfo = {
  color: vec3;
  intensity: number;
};

function createLightInfo(color: vec3, intensity: number): LightInfo {
  return {
    color: color,
    intensity: intensity,
  };
}

const lightInfosLists: LightInfo[][] = [];
lightInfosLists.push([
  createLightInfo([0.75, 0.75, 0.75], 1.0),
  createLightInfo([0.75, 0.75, 0.75], 5.0),
  createLightInfo([0.75, 0.75, 0.75], 10.0),
]);
lightInfosLists.push([
  createLightInfo([1, 0.75, 0.75], 5.0),
  createLightInfo([1, 1, 0.75], 5.0),
  createLightInfo([0.75, 1, 0.75], 5.0),
  createLightInfo([0.75, 1, 1], 5.0),
  createLightInfo([0.75, 0.75, 1], 5.0),
  createLightInfo([1, 0.75, 1], 5.0),
]);
lightInfosLists.push([
  createLightInfo([1, 0, 0], 5.0),
  createLightInfo([1, 1, 0], 5.0),
  createLightInfo([0, 1, 0], 5.0),
  createLightInfo([0, 1, 1], 5.0),
  createLightInfo([0, 0, 1], 5.0),
  createLightInfo([1, 0, 1], 5.0),
]);
lightInfosLists.push([
  createLightInfo([0.75, 0.25, 0.25], 5.0),
  createLightInfo([0.75, 0.75, 0.25], 5.0),
  createLightInfo([0.25, 0.75, 0.25], 5.0),
  createLightInfo([0.25, 0.75, 0.75], 5.0),
  createLightInfo([0.25, 0.25, 0.75], 5.0),
  createLightInfo([0.75, 0.25, 0.75], 5.0),
]);
lightInfosLists.push([
  createLightInfo([0.25, 0.25, 0.25], 1.0),
  createLightInfo([0.25, 0.25, 0.25], 5.0),
  createLightInfo([0.25, 0.25, 0.25], 10.0),
]);

---

We could also go full disco mode with

const lightInfosLists: LightInfo[][] = [];
const random = seedrandom("0");
for (let r=0; r<12; r++) {
  const row : LightInfo[] = [];
  for (let c=0; c<12; c++) {
    const r = random();
    const g = random();
    const b = random();
    const intensity = 1.0 + random() * 20;
    row.push(createLightInfo([r, g, b], intensity));
  }
  lightInfosLists.push(row);
}

to create

😁

---

Creating ~"something similar" for directional lights will have a few more degrees of freedom, but I'll post a suggestion when it's ready.

[lexaknyazev]

Here's yet another stress test: max number of light sources.

[javagl]

I had accidentally hit a limit here: For that "disco" (random lights) I originally created 16x16 lights, which caused Three.js to bail out with

Program Info Log: FRAGMENT shader uniforms count exceeds MAX_FRAGMENT_UNIFORM_VECTORS(1024)

With 12x12 lights, it still works.

Babylon.js seems to limit the number of lights to 4 (four!) to begin with, so... even the "serious" test model doesn't look that great...

[deltakosh]

@javagl: The limit is just a constant you can change (https://doc.babylonjs.com/features/featuresDeepDive/lights/lights_introduction#limitations)

[javagl]

@deltakosh I only used the sandbox at https://sandbox.babylonjs.com/ for that test, but it's good to know that this is configurable on the library level.

[deltakosh]

@javagl No worries! We are thinking with @bghgary to change that option when loading a glTF with more than 4 lights.
Also for the fun, here is a PG where I generate 160lights:)
https://playground.babylonjs.com/#7MK6JN