1. ## Spotlight properties

I'm trying to render spotlight enabled scene but I've some trouble about fallof_angle :/ 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 (https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx 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):
Code :
```  ...

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

2. 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 (https://forums.khronos.org/showthrea...-PDF-describes)

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 (https://www.khronos.org/collada/wiki..._Asset_Manager) 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.

3. 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 :/ 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.

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

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

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.

5. 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 :/ 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?

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: https://www.dropbox.com/sh/zaf6h1e0d...Ao5XCF1Pa?dl=0
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

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

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

Code :
```  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

8. Originally Posted by recpas
One addition, I've took a look at Blender source and it seems falloff_angle is whole angle of spot shape:

Code :
```  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
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.

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.

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 (https://www.opengl.org/sdk/docs/man2/xhtml/glLight.xml) 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 AFAIK the purpose of dividing by 2 is getting angle between light direction and cone border (http://www.ozone3d.net/tutorials/gls...g_phong_p3.php) 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

10. Okay. This makes sense.

Originally Posted by https://www.opengl.org/sdk/docs/man2/xhtml/glLight.xml
GL_SPOT_EXPONENT
params is a single integer or floating-point value that specifies
the intensity distribution of the light.
Integer and floating-point values are mapped directly.
Only values in the range 0-128 are accepted.
Effective light intensity is attenuated by the cosine of the angle between
the direction of the light and the direction from the light to the vertex
being lighted, raised to the power of the spot exponent.
Thus, higher spot exponents result in a more focused light source,
regardless of the spot cutoff angle (see GL_SPOT_CUTOFF, next paragraph).
The initial spot exponent is 0, resulting in uniform light distribution.

GL_SPOT_CUTOFF
params is a single integer or floating-point value that specifies
the maximum spread angle of a light source.
Integer and floating-point values are mapped directly.
Only values in the range 0-90 and the special value 180 are accepted.
If the angle between the direction of the light and the direction from the
light to the vertex being lighted is greater than the spot cutoff angle,
Otherwise, its intensity is controlled by the spot exponent and the
attenuation factors. The initial spot cutoff is 180, resulting in uniform light distribution.
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

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.

Page 1 of 3 123 Last

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•