Spotlight properties

I’m trying to render spotlight enabled scene but I’ve some trouble about fallof_angle :confused: What is fallof_angle exactly? I really look a dozen of books/web pages and not sure how to use this param. In OpenGL/GLSL cutoff angle is using to specify cone angle. But when I tried to use falloff_angle as cutoff angle then, my cone size become 2x bigger than original, when I used cut off angle = fallof_angle/2 then everythings look perfect! Any idea?

According Realtime Rendering book I guess fallof_angle is umbra angle and I found a formula in MSDN (Attenuation and Spotlight Factor (Direct3D 9) - Win32 apps | Microsoft Learn they used umbra angle / 2

Here how to I use fallof angle in my shader, vPosition and light.position are in view/camera space and direction is [0 0 -1] if there is no rotation, falloffCos is cosf(fall_of_angle):


  ...

  float spotCos;

  spotCos = dot(lights[i].direction, -normalize(lights[i].position - vPosition));
  if (spotCos < lights[i].falloffCos)
      attn = 0.0;
  else
      attn *= pow(spotCos, lights[i].falloffExp);
 
   ...

Maybe I’ve some bugs but checked multiple times everythings(posiitons, coord space…) looks valid :frowning:

EDITED: When I wrote this I had the impression that falloff_angle was a blending factor rather than the shape of the spotlight itself.

Well first of all, it’s falloff_angle (not fallof_angle) but indeed, neither it nor falloff_exponent seem to be described by the manual or the schema annotations. I think it’s wrong to go by Microsoft’s materials. It’s part of technique_common so it should have an express formula for both.

I have a similar issue here (1.5 <technique> relates to "xs:any" differently than the PDF describes. - COLLADA - Khronos Forums)

I think I want to pursue an official leadership position, beginning with correcting the manuals and improving the annotations in the existing schemas. I think those tasks would be a good way for me to adjust to the demands of such a position.

Generally the profile_COMMON stuff goes by technical papers, which are often at odds with how things are just done in the real world. I think that’s a weakness of the COMMON profile in general, but also I don’t think it was ever meant to used for anything other than the kind of display you get in a modeler with things like textures turned off. The authors thought that the FX section would see use. But I don’t know of anything that implements it that you can buy like regular consumer grade software. (And I only buy such software, so I have no clue otherwise.)

The last few days I’ve been discussing unearthing this (COLLADA Asset Manager - COLLADA Public Wiki) project with the webmaster. Ironically it probably has better FX support than any software that exists.

I may try to use my new Moderator like abilities to set up a subforum for tracking tangible issues like this one. The forum may be a bad way to do that though. I may ask about reopening the bug tracker. In my opinion though, I think most people would be more comfortable bringing the trouble up in the forum, and that it would be good to have actionable topics gathered in a subforum.

SHORT ANSWER is there is no answer. I will ask Mark * and see what happens. I don’t even see <light> in the appendix of the Sailing the Gulf book.

Well first of all, it’s falloff_angle (not fallof_angle)

Sorry it is a typo (consistently),

but indeed, neither it nor falloff_exponent seem to be described by the manual or the schema annotations. I think it’s wrong to go by Microsoft’s materials. It’s part of technique_common so it should have an express formula for both.

Yeah a formula would be really helpful, I’ve found some formulas but some of them are related to inner/outer cone, AFAIK it is DirectX term not OpenGL (maybe you can do that with shaders with extra uniform but COLLADA gives only one ANGLE!, probably other angle will be viewer/engine specific)

I think I want to pursue an official leadership position, beginning with correcting the manuals and improving the annotations in the existing schemas. I think those tasks would be a good way for me to adjust to the demands of such a position.

I may try to use my new Moderator like abilities to set up a subforum for tracking tangible issues like this one. The forum may be a bad way to do that though. I may ask about reopening the bug tracker. In my opinion though, I think most people would be more comfortable bringing the trouble up in the forum, and that it would be good to have actionable topics gathered in a subforum.

That is great! I’m not Khronos member and I would like to access membership area (if there is) to help COLLADA specs, also I can’t login bugtracker probably it requires a membership, I’m working as freelancer/part-time to spend more time on this project so I can’t apply with company for memberhip :confused: If you are not a partner you can’t help or ask somethings, that’s a mistake and death path for COLLADA (because I don’t think any partner cares about COLLADA anymore)

The last few days I’ve been discussing unearthing this (https://www.khronos.org/collada/wiki…_Asset_Manager) project with the webmaster and Mark. Ironically it probably has better FX support than any software that exists.

Dead links! I was downloaded this and it is just binary if I remember correctly, also wait for my viewer :slight_smile:

SHORT ANSWER is there is no answer. I will ask Mark and see what happens. I don’t even see <light> in the appendix of the Sailing the Gulf book.

Thank you very much, it would be very nice to get an answer from authors, I also couldn’t see anything useful for these spotlight params (falloff_angle and falloff_exp) in this book

I went to look at the other <light> properties. Maybe I am missing something, but it looks like <falloff_angle> is the only “angle” property; suggesting it is the shape of the spotlight itself, and not just an additional blending parameter?

A spotlight is a cone. So it requires an angle. The default is 180 degrees, which is probably equivalent to a directional light. EDITED: I see there is also <directional>. RE-EDITED: Also it’s not equivalent, since it would only light things in front of it.

Did you consider this reading? (Now that I reread your opening post, it seems like you are asking about the shape only. In that case, angle/2 seems the only reading.)

JUST FYI, I assumed “falloff” was an additional property before. It looks as if it is called this, just to group it with the attenuation factor. I would have made this “angle” and “angle_attenuation” myself, but I don’t see a problem really. The documentation could help to clear up this confusion. But it seems straightforward when taken together with the other properties.

EDITED: I think this is the angular shape of the spotlight, but the <falloff_exponent> if not the angle could use a formula to describe the blended enclosure of the light. Although I think it’s probably not difficult to arrive at a reasonable formula with a little bit of thought/experimentation.

but it looks like <falloff_angle> is the only “angle” property; suggesting it is the shape of the spotlight itself

Shape of spotlight is cone and cone has angle but my confusion is that is it full angle or half angle :confused: Actually in fixed OpenGL 180d is default angle for spotlight like COLLADA and angle must be between 0d and 90d. I’ve no idea what is wrong with my shader which I shared with my first post. Also I’ve checked COLLADA-DOM RT project they send the falloff_angl param directly to opengl. Actually I did the same but why my angle seems larger then?

Did you consider this reading? (Now that I reread your opening post, it seems like you are asking about the shape only. In that case, angle/2 seems the only reading.).

Yeah it is true my only issue is shape here, so do you think should I use falloff_angle/2.0 in my shader? I’ve took a look at three.js but it seems like they send full angle (fallof_angle) to core renderer, I only check parser part.

Here screenshots and dae file for spotlight: Dropbox - COLLADA-Spotlight - Simplify your life
It doesn’t matter what the light or geom position is, if I compare fallof_angle/2.0 with dot(…) then spot looks same as Blender, Apple and FBXReview

I agree, it is unclear, and since it’s open to interpretation, there is no definitive correct answer, and some of these implementations may be out of step with each other or the intention of the authors.

I think I would interpret it literally. 180 should light everything in front of the light. 360 should light things behind it, like a point light source. Mark will probably tell us this is the correct interpretation after the weekend or so.

There is a lot in this thread that I could reply to. I’m not avoiding it; I just replied early in the morning before my day was well underway, when there was not time to wander off into neighboring territories. Right now I don’t know if I should go off-topic or not…

I am working on the RT stuff these days BTW. It’s a tangled knot of chaos, so I commend you for digging through it. It will be all straightened out after I am done with it, and we can see if there’s anything there or not. I feel regardless, it’s a piece of history, and so should be given the same treatment as the core-library as a matter of principal. It’s as good a place to start as any. I did learn that Cg was pretty much the shader framework from the PlayStation 3. I don’t see any evidence that there was an alternative that ultimately eclipsed it or not. Nowadays Cg is decommissioned. I think that probably happened before the lifetime of the PS3, but I don’t know. It doesn’t seem that long ago that the PS3 was current. But Cg seems like it’s been out of the picture for a good while, perhaps even before it was officially so.

I don’t know if the Cg profile stuff can approximate HLSL or not, or if it should be removed from future COLLADA schemas. Or if COLLADA software should keep it alive either in its end of life form or in a post Nvidia form. The FX profiles are very large chunks of the schema. I think it might have been helpful if each one had been its own schema.

P.S. My underlying interests in nurturing COLLADA are basically 3 fold: 1) Something to replace the currencyless Microsoft X format. 2) A basis for a free modeler that is user-friendly and implements COLLADA with precision. 3) And this is a new one as of this week; Something to replace Microsoft’s dying Resource format, for housing cross-platform UI descriptions. These are things I need to advance my career. There are other reasons to nurture COLLADA (or something like it) but they are not so immediate or necessary as these 3.

One addition, I’ve took a look at Blender source and it seems falloff_angle is whole angle of spot shape:


  light.spot_cutoff = RAD2DEGF(la->spotsize * 0.5f);
  light.spot_exponent = 128.0f * la->spotblend;

they used falloff_angle / 2.0 to get spot cutoff, this is what I did and this matches MSDN resource because other resources just used cutoff angle term (falloff_angle/2.0f) not umbra angle

[QUOTE=recpas;41760]One addition, I’ve took a look at Blender source and it seems falloff_angle is whole angle of spot shape:


  light.spot_cutoff = RAD2DEGF(la->spotsize * 0.5f);
  light.spot_exponent = 128.0f * la->spotblend;

they used falloff_angle / 2.0 to get spot cutoff, this is what I did and this matches MSDN resource because other resources just used cutoff angle term (falloff_angle/2.0f) not umbra angle[/QUOTE]

I have a feeling there is no authoritative source. I think dividing by 2 is probably wrong. But it’s not surprising that some applications would do it and some wouldn’t without anything to go on. The Blender code isn’t much to go on. Anyway, it seems like if the angle was half of the angle, then that should be in the manual.

I had a dust up with Mark over the last few days. You can see the edits in bold above to get an idea about it. He didn’t have any advice on the subject. He gave a link to the issues-tracker (The Khronos Group · GitHub) which you may use. It’s open to the public that is. I don’t know if the link was in response to your asking about how to contribute in that way, or it was meant to say that this is an open issue and that maybe it’s already in the tracker, or that it should be added to it.

Dividing by 2 just doesn’t make sense to me. If 180 is the default, that means the default shape is 90 degrees? Or are you dividing by 2 and then giving it to an API that then multiplies by 2? Anyway, if the convention was to divide by 2, then an omni directional spotlight (which is pointless because that’s a point source) would be specified by 720, and that just doesn’t make any sense. Or am I missing something?

P.S. The new item in the issue tracker from last year, I think is spam. I took it up with the webmaster. The other issues are dated to 2014, but I have a feeling that is the date they were imported into a new system, because if you look they are all the same date, and that’s far too recent. My keyboard isn’t working right because of Windows 10 update. I have to reboot. TTYL.

EDIT: Never mind about the edits. Seems we are having an edit war or something. People are so ridiculous. Life could be so much simpler if only. Ciao.

I had a dust up with Mark over the last few days. You can see the edits in bold above to get an idea about it. He didn’t have any advice on the subject. He gave a link to the issues-tracker (The Khronos Group · GitHub) which you may use. It’s open to the public that is. I don’t know if the link was in response to your asking about how to contribute in that way, or it was meant to say that this is an open issue and that maybe it’s already in the tracker, or that it should be added to it.

Yeah I saw, sorry to hear that!

Dividing by 2 just doesn’t make sense to me. If 180 is the default, that means the default shape is 90 degrees? Or are you dividing by 2 and then giving it to an API that then multiplies by 2? Anyway, if the convention was to divide by 2, then an omni directional spotlight (which is pointless because that’s a point source) would be specified by 720, and that just doesn’t make any sense. Or am I missing something?

According to OpenGL fixed pipeline specs (glLight) 180 is special case, probably for disable spotlight as default

Anyway that is good point, I should find corresponding angle between 0-360 then divide by 2 :slight_smile: AFAIK the purpose of dividing by 2 is getting angle between light direction and cone border (oZone3D.Net Tutorials - Phong Lighting with GLSL - OpenGL Shading Language - Point Light - Spot Light - Attenuation) because we have only cone direction and light direction, we need to divide full angle by 2 to get spot attenuation on surface

Since glTF has same attrib, I asked same question to glTF team on Github maybe they give us authoritative an answer about falloff_angle is full angle or half

Okay. This makes sense.

So 180 is a point light source under OpenGL, and it’s fair to say that profile-common conventions broadly adhere to OpenGL conventions. The entire schema more or less does.

I don’t know what that means to your dilemma, but I’m confident in that interpretation. The angle is not the angle of the cone. It’s the angle as measured by the direction with respect to the delta from the point being lit and the light source.

OpenGL doesn’t consider 180 special. It just degenerates to a point light source. 0 would disable it. So yeah, if you want a 90 degree cone, use 45 :slight_smile:

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.

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 :slight_smile: 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: The Khronos Group · GitHub

Hey, I found issues for this (GitHub - KhronosGroup/COLLADA-CTS: Welcome to the COLLADA Conformance Test Suite) 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.)

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 (Understanding the Dot Product):

  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)

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) :slight_smile: I think falloff_angle is full angle of cone not half

EDITED: I logged this issue here: The Khronos Group · GitHub

Thanks

^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.

Maybe we get an answer from khronos via glTF team through this issue: Spotlight falloff_angle · Issue #824 · KhronosGroup/glTF · GitHub 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 :slight_smile: 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 :slight_smile: 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…

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\spot\spot_falloff_angle_light

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 :frowning: First let me fix it and re-check my rendering and loading codes, maybe I’m doing wrong somewhere or just wrong math :frowning:

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: Dropbox - COLLADA-Spotlight - Simplify your life

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):

CTS 10 lights: COLLADA-CTS/StandardDataSets/collada/library_lights/spot/spot_10_lights/Blessed/png/spot_10_lights1.png at master · KhronosGroup/COLLADA-CTS · GitHub
CTS falloff_angle: COLLADA-CTS/StandardDataSets/collada/library_lights/spot/spot_falloff_angle_light/Blessed/png/spot_falloff_angle_light1.png at master · KhronosGroup/COLLADA-CTS · GitHub

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?

[b]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!!![/b]:?:

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.