Spotlight properties

[Mick P.]

BTW: I apologize for drawing this out. I just couldn't see the obvious because I was thinking "divide by 2" instead of "multiply by 2." I was thinking you were dividing the COLLADA value by 2 in other words. TO BE HONEST. When I read your initial post I still cannot understand it when I try but I should've figured this out sooner. I was just stuck on the idea of dividing falloff_angle by 2.

Anyway. I think this is the answer. It seems obvious now. falloff_angle is the angle of the light itself. So falloff_angle*2 is the angle of the cone. (The light spreads out in both--technically all--directions.)

EDITED: I logged this issue here: https://www.khronos.org/bugzilla/show_bug.cgi?id=1922

[Mick P.]

Hey, I found issues for this (https://github.com/KhronosGroup/COLLADA-CTS) in the issue-tracker. You could use it in cases like this assuming there is a spotlight example.

I am downloading it now. If only to see if it has some good examples. Maybe you've mentioned it before. But I thought I'd share. Did you link to a project page for your C code base? I may have forgot to look at it (or neglected to because it's C. Still I am curious.)

[recpas]

NOTE: The OpenGL description there says it doesn't implement between 90 and 180. I guess in the "fixed-function" shader. I don't know what the math difficulties there are. If it's 180 it probably switches to POINT mode.

The dot product is negative in between 90 and 180 (http://www.mvps.org/DirectX/articles...ot/index.htm):

1. If A and B are perpendicular (at 90 degrees to each other), the result of the dot product will be zero, because cos(Θ) will be zero.
2. If the angle between A and B are less than 90 degrees, the dot product will be positive (greater than zero), as cos(Θ) will be positive, and the vector lengths are always positive values.
3. If the angle between A and B are greater than 90 degrees, the dot product will be negative (less than zero), as cos(Θ) will be negative, and the vector lengths are always positive values.

Probably fixed-OpenGL pipeline doesn't implement case 3, but it seems it is a little tricky, if acosf is used in OpenGL fixed pipeline this may cause problem because of acosf range [0-pi]. Fortunately I send cosf(angle) to shader and I'm comparing it directly with dot product, not comparing angles e.g. angle == acos(dot product)

[recpas]

BTW: I apologize for drawing this out. I just couldn't see the obvious because I was thinking "divide by 2" instead of "multiply by 2." I was thinking you were dividing the COLLADA value by 2 in other words. TO BE HONEST. When I read your initial post I still cannot understand it when I try but I should've figured this out sooner. I was just stuck on the idea of dividing falloff_angle by 2.

Anyway. I think this is the answer. It seems obvious now. falloff_angle is the angle of the light itself. So falloff_angle*2 is the angle of the cone. (The light spreads out in both--technically all--directions.)

Yes I'm dividing COLLADA value by 2 to get cutoff angle (light angle) I think falloff_angle is full angle of cone not half

EDITED: I logged this issue here: https://www.khronos.org/bugzilla/show_bug.cgi?id=1922

Thanks

[Mick P.]

^No it's half. If a cone is <| then falloff_angle is the angle of < by half.

It's possible you have COLLADA files that were generated by an application that implement the value incorrectly.

The reason it's half is the angle is measured from the ray through the middle of the cone. The behavior should match OpenGL. If you have files that don't match, or know of software that doesn't match, then you should contact the maintainers of that software and present them the OpenGL link you provided. They will see the mistake.

[recpas]

Maybe we get an answer from khronos via glTF team through this issue: https://github.com/KhronosGroup/glTF/issues/824 but they may not want to answer COLLADA issue

Blender multiplies this value by 0.5 and some js libraries. This spotlight params must be clarified in specs or if we get an authoritative answer then we must ask from khronos to pin it for other people

Maybe I do something wrong and have really big/fatal mistakes/errors/usages on shader, collada parser or OpenGL usage, it seems I'm doing right, I've shared a little shader about what I did

Cutoff angle is indeed half angle but the actual confusion is that does falloff_angle is cutoff_angle? The relationship or even usage must be clarified,
Probably these params are assumed to be known already, but the problem is that these names are not used in books, tutorials...

[Mick P.]

Yes, it's safe to assume they are the same. The COLLADA schema has 180 as the default. If they were different the default would be 360. That said Khronos's CTS (conformance test suite) project files may take the full angle position. In which case 180 as a default means a light that shines on one side of a line. That's just a weird default for a spotlight but it is what it is if so.

Anyway, when we started this discussion, I hadn't thought of the CTS project. I guess they are an authority of sort. Wrong or right. So assuming some of this software has ran the CTS gauntlet and it includes spotlights then it might be better to assume the other way around:

COLLADA-CTS-master\StandardDataSets\collada\library_lights\spo t\spot_falloff_angle_light

[recpas]

Yes, it's safe to assume they are the same. The COLLADA schema has 180 as the default. If they were different the default would be 360. That said Khronos's CTS (conformance test suite) project files may take the full angle position. In which case 180 as a default means a light that shines on one side of a line. That's just a weird default for a spotlight but it is what it is if so.

Anyway, when we started this discussion, I hadn't thought of the CTS project. I guess they are an authority of sort. Wrong or right. So assuming some of this software has ran the CTS gauntlet and it includes spotlights then it might be better to assume the other way around:

COLLADA-CTS-master\StandardDataSets\collada\library_lights\spo t\spot_falloff_angle_light

I like CTS project thanks for sharing it, there is also render results in /Blessed/png folder, this is useful for comparing our rendering results.

Also it seems my renderer has bugs when light or camera rotated First let me fix it and re-check my rendering and loading codes, maybe I'm doing wrong somewhere or just wrong math

Well, no, it seems the OpenGL interpretation matches CTS. I tried to upload the example image, but it failed. It's a somewhat large image for what it is anyway. In that case it sounds like the software you describe is incorrect, and has not tested their spotlights against CTS, if I am reading you correctly

Probably I'll create new thread for image things get complicated, image has changed with 1.5, 1.4 has surface and 1.5 has not, I need to map 1.4 to 1.5 structure

Does your rendering/viewer work to test some dae files? I was uploaded a test dae file about spotlight with screenshots: https://www.dropbox.com/sh/zaf6h1e0d...Ao5XCF1Pa?dl=0

[recpas]

I've fixed a bug related to spotlight/camera rotation and default light direction [0, 0, -1]

I'm afraid fallof_angle * 0.5 gives me right angle, here screenshots (Test 2 folder):
https://www.dropbox.com/sh/zaf6h1e0d...Ao5XCF1Pa?dl=0

CTS 10 lights: https://github.com/KhronosGroup/COLL...10_lights1.png
CTS falloff_angle: https://github.com/KhronosGroup/COLL...gle_light1.png

Probably I've another bugs about normals or common materials, bcause 10 lights seem a little dark and other one's color seems incorrect but I'm working on

Yes, it's safe to assume they are the same. The COLLADA schema has 180 as the default. If they were different the default would be 360. That said Khronos's CTS (conformance test suite) project files may take the full angle position. In which case 180 as a default means a light that shines on one side of a line. That's just a weird default for a spotlight but it is what it is if so.

So, according my tests cutoff_angle = falloff_angle * 0.5 even though colors don't match exactly for now,
OpenGL fixed func pipeline only allows angles between 0 and 90 and special val 180, maybe COLLADA allows any angle even > 90, why not?

[Mick P.]

SORRY. YOU ARE RIGHT. I don't know what I was thinking yesterday. I removed that paragraph (seen in your quotes) so not to mislead readers.

The example is <falloff_angle>80</falloff_angle> and the angle is roughly 90 degrees visibly. I don't know how I got that wrong!!!

But I think this is a case of accepting a popular misconception as fact, because 180 is the default in the schema. I actually think CTS is wrong here, but it claims to be the authority.

To be honest. I think the extant COLLADA schema are more like prototypes. Because their quality is very poor. They are nothing like a web standard in terms of their rigor. There are inconsistencies everywhere abound.

To your other question. I am working on the old COLLADA-DOM viewer code. I was told it was prepared when companies insisted on an API but I think that was the case for the DOM component, and that the viewer long predated it and was used for experimenting while the first schema was being laid out.

Something that's been driving a little nuts lately is around Cg there is some alternative format for Cg called "COLLADA FX" that the Nvidia FX Composer and also the XSI/Softimage online documentations mentions, but I can find little information on it. I think it's an alternative to the HLSL .fx format, which I don't know if is Cg related or what! There are .cg .cgfx .fx and "COLLADA FX" and I don't know if the COLLADA FX one is another .fx or if it's just a .dae file with profile_CG or something inside. Anyway I only mention it because it seems like the COLLADA viewer was being developed at the same time as Cg, perhaps as a joint effort between Sony and Nvidia, such that parts of Cg were missing and the developers were waiting for the Cg team to finish their work. So it's very strange code to work with you could say. The overall quality is not good. I don't know if that means it was a small team on the side, or if commercial code quality is just not good as a rule.