Ogre Forums

I've got one. I think it classifies as a paper cut.

A few months back I was writing a lightmapper, the idea was to use Ogre's dynamic light system to place lights around the scene and then bake lightmaps to textures. Pretty standard stuff for a lightmapper. However, I was surprised to find that the Ogre::Light class doesn't have the functionality to help calculate the intensity of light at a given point in space.

I'm not sure how difficult it would be to implement but I figured that the functionality probably already exists internally for calculating the colours of the vertices so it makes sense to have it exposed to the user to for there own use. For example, a function like this would be very useful:
Ouch! Papercut

Thanks for the suggestion. Can you add it to the tracker, please?

My guess is that Ogre does not have this feature because this is what the hardware is for. IOW, what you are describing in the comment line is exactly what the lighting pipeline in the FF hardware does (except for range -- AFAIK that's only so Ogre can cull far objects that should not be affected by a light).

It's also not as straightforward as it sounds -- if you've ever seen the shader code for a Warn spotlight, for example, you know what I mean.

I'm not sure what you meant by this part?

but I figured that the functionality probably already exists internally for calculating the colours of the vertices

FWIW, what you are asking for is almost exactly the majority of what a software renderer (i.e. mental ray, PRMan) does.

CABAListic wrote:Thanks for the suggestion. Can you add it to the tracker, please?

I'll add it soon, after we've discussed it a little more on the forums. Based on what xavier is saying it might not even be possible.

xavier wrote:My guess is that Ogre does not have this feature because this is what the hardware is for. IOW, what you are describing in the comment line is exactly what the lighting pipeline in the FF hardware does (except for range -- AFAIK that's only so Ogre can cull far objects that should not be affected by a light).

Is that a guess? If what your saying is true I suppose it might not be possible, but it doesn't make sense to jump to that conclusion without some investigation first.
In any case, even if the hardware does these calculations, is it not possible to get the result for a single point in space?
Also, what does the FF stand for?

xavier wrote:It's also not as straightforward as it sounds -- if you've ever seen the shader code for a Warn spotlight, for example, you know what I mean.

Nope, I've never seen the shader code but just because something is difficult doesn't mean it's not useful. Wouldn't it be better to have a simplified version of a feature than to exclude it completely?

xavier wrote:I'm not sure what you meant by this part?

zarfius wrote:but I figured that the functionality probably already exists internally for calculating the colours of the vertices

The way I understand it the properties of an Ogre::Light are used to calculate the colour of the vertices on a mesh in real-time before rendering. Therefore, it stands to reason that somewhere in the Ogre code there must be a way to get the resulting colour of a single vertex? And more to the point any arbitrary point?

xavier wrote:FWIW, what you are asking for is almost exactly the majority of what a software renderer (i.e. mental ray, PRMan) does.

I realise that there are applications that do this, but they don't help when your trying to develop your own applications using Ogre. Also, I'm not expecting the results to be photo-realistic. I'm just trying to estimate the resulting light from a light source and save it to a texture for light-mapping later. There's nothing overly complicated about this, it's a technique that's been used for years to produce better looking static lighting effects in games.

FWIW, I've already completed my lightmapper and it works okay. The problem is that the lighting produced from the lightmapper is inconsistent with the dynamic lighting produced by Ogre. There's nothing really bad about this except that it takes lots of tweaking to get something that looks reasonable. I'm just suggesting the idea because I know it's something I've had to deal with in the past, other people might find it useful and I'd certainly update my project as well

I guess the question is what you expect the function to do. Lighting calculations can be very simple or very complicated; what could be done is a simple dot product between the given normal and the light direction paired with a distance drop-off to the given point. No occlusion checks. Anything more complicated is quite likely out of scope.

(OTOH, above functionality is relatively simple to implement. It warrants the quesion whether Ogre would benefit from offering it, since end users might need more sophisticated calculations for their own use cases.)

xavier wrote:My guess is that Ogre does not have this feature because this is what the hardware is for.

So that essentially means that Ogre grows smaller and smaller, since most things are done in hardware these days?
IMO, a small utility function - with the option to do it yourself - wouldn't hurt.
After all, that's (also) what's Ogre is about.

zarfius wrote:Also, what does the FF stand for?

Fixed Function (the standard vertices processing method if you don't use shaders which would then overwrite parts of these fixed function pileline since the shaders would handle some things that previously were done automatically [space transformations, colour calculations, ...]).

CABAListic wrote:I guess the question is what you expect the function to do. Lighting calculations can be very simple or very complicated; what could be done is a simple dot product between the given normal and the light direction paired with a distance drop-off to the given point. No occlusion checks. Anything more complicated is quite likely out of scope.

Sound reasonable to me.

CABAListic wrote:I guess the question is what you expect the function to do. Lighting calculations can be very simple or very complicated; what could be done is a simple dot product between the given normal and the light direction paired with a distance drop-off to the given point. No occlusion checks. Anything more complicated is quite likely out of scope.

Yep, that's exactly what I had in mind. In fact, that's pretty much how I do it now. The difference is I'm not sure how to use the properties of an Ogre::Light in my calculation to get the same (or similar) result for the colour of each pixel as you would get on the vertices of a highly tessellated mesh.

CABAListic wrote:(OTOH, above functionality is relatively simple to implement. It warrants the quesion whether Ogre would benefit from offering it, since end users might need more sophisticated calculations for their own use cases.)

The simplicity of a function is not a reason to exclude it. That's like saying that all functions should be complicated. To determine if Ogre should offer it, ask yourself the following.

Is it related to rendering graphics?
Does it belong in a different library (e.g. Physics, Sound, Networking)?
Should end-users have to Google it to figure out the calculation themselves?

I think the answers to these questions are fairly obvious. Sure, this function won't be used directly in the rendering pipeline but it's closely related to the scene rendered by Ogre.

Nah, what I meant is that I wonder how often such a function would be used, given that more modern lighting setups are more complicated (and diverse) than what this function could provide. Essentially I don't want to introduce "dead" code, that's all

The way I understand it the properties of an Ogre::Light are used to calculate the colour of the vertices on a mesh in real-time before rendering.

Nope. The properties of an Ogre light exist solely to hand over to directx (D3DLight9) or opengl (glLightf), which is where the light calculation is done. Gpus have had hardware lighting calculation since the geforce 256 days (1999).

That's why ogre only has point, spot and directional lights, because that's all directx and opengl have. It's also why ogre is limited to 8 lights affecting a single mesh (when not using shaders), because 8 lights is the hardware limit for gpus in the fixed function pipeline.

However, assuming you aren't using shaders (since there's no way of knowing what freaky lighting algorithms are in use there), the standard fixed function lighting equation is really easy and would take very little ogre code. We only have 4 lighting attenuation values (constant, linear, quadratic and one as a simple range cutoff), diffuse colour, ambient colour. We don't need emmissive or specular colour, since those are not properties of light at a point in space (they need surface info like normals).

Off the top of my head (and it's 4:38am), the algorithm would roughly be (for a point light):
distance = (point - lightpos).length()
if(distance<range)
light = ambient + diffuse / (attenConstant + attenLinear * distance + attenQuad * distance * distance)

If you did give it a normal as well, you could do the lambert shading of the diffuse light and add the specular calculation in, which isn't hard.
Spot lights are a little trickier, but not by much.

I think having a lighting query like this could be handy, think of stealth games which need to know if a character is in light. Ok, it's not going to know about shadows (but Moc could be used for that), but sampling the light from the environment rather than looking up a baked texture (the way quake did it) could be useful. You could use it to calculate spherical harmonics of the light at a point in space too, back when I did my SH test in ogre I had to calculate how much each light affected a model so I could generate the SH coefficients to simulate the lights.

It would then make sense to also have a light query function in the scene manager which calculates the light at a point using all lights in the scene (since the scene manager has all the lights, plus it probably knows which are the 8 closest which will be used for rendering).

"Handy" is a term that is often used to justify scope creep.

I would argue that functions like this do not belong in Ogre, but in a layer that might exist on top of Ogre. Think of the way that GL is set up: GL core API, glu, and glut. Similar for D3D. A function like this would belong in an outer layer. Would anyone argue that SH and PRT should be moved into D3D core because it might be useful? No, you leave it in D3DX: http://msdn.microsoft.com/en-us/library ... 85%29.aspx


This all said -- this isn't really a "papercut", it's more of a "feature request".


FWIW, here's how D3D handles lighting at the FF level:

http://msdn.microsoft.com/en-us/library/aa915183.aspx

xavier wrote:"Handy" is a term that is often used to justify scope creep. I would argue that functions like this do not belong in Ogre, but in a layer that might exist on top of Ogre.

It really depends on how you define the scope of Ogre. DirectX and OpenGL are low level rendering API's but Ogre sits on top of them to provide extra "handy" functionality. The whole point of Ogre as a graphics engine is to provide all that extra functionality you often need like materials, meshes, animations, scene management and so on. They all fit into the scope of Ogre so what makes you draw the line here? I would argue that it fits nicely into scene management between lighting and shadows

xavier wrote:This all said -- this isn't really a "papercut", it's more of a "feature request".

How do you define the difference between a papercut and a feature request?

http://www.ogre3d.org/2011/01/02/papercut-initiative wrote: What is a papercut?
A papercut is a minor issue with the Ogre API, like a missing function that you were expecting, an inconsistently named function, misleading or incorrect documentation, etc. Basically anything that slightly annoyed you at the time you had to figure it out, but not such a major issue that it kept you from doing what you wanted to do. A papercut should be trivial to fix.

Take a look at this quote from the Ogre::Light documentation.

http://www.ogre3d.org/docs/api/html/classOgre_1_1Light.html#_details wrote: Remember also that dynamic lights rely on modifying the colour of vertices based on the position of the light compared to an object's vertex normals. Dynamic lighting will only look good if the object being lit has a fair level of tessellation and the normals are properly set. This is particularly true for the spotlight which will only look right on highly tessellated models. In the future OGRE may be extended for certain scene types so an alternative to the standard dynamic lighting may be used, such as dynamic lightmaps.

This paragraph really points out the reason this function would be so "handy". A clearly defined limitation of dynamic lighting is the requirement for models to be highly tessellated and an alternative approach is dynamic lightmaps (or static lightmaps).

We are talking about the future of Ogre right now. It is important to prevent feature creep but there's a fine line between preventing features that are clearly out of scope and limiting Ogre's potential as a great graphics engine.

zarfius wrote:

xavier wrote:"Handy" is a term that is often used to justify scope creep. I would argue that functions like this do not belong in Ogre, but in a layer that might exist on top of Ogre.

It really depends on how you define the scope of Ogre. DirectX and OpenGL are low level rendering API's but Ogre sits on top of them to provide extra "handy" functionality. The whole point of Ogre as a graphics engine is to provide all that extra functionality you often need like materials, meshes, animations, scene management and so on. They all fit into the scope of Ogre so what makes you draw the line here? I would argue that it fits nicely into scene management between lighting and shadows

I already think (and have thought so for some years) that Ogre is far too bloated as is. I was kinda looking forward to 2.0 when ideally a lot of this cruft would be (hopefully) put where it belongs, but alas, that's unlikely now.

How do you define the difference between a papercut and a feature request?

http://www.ogre3d.org/2011/01/02/papercut-initiative wrote: What is a papercut?
A papercut is a minor issue with the Ogre API, like a missing function that you were expecting, an inconsistently named function, misleading or incorrect documentation, etc. Basically anything that slightly annoyed you at the time you had to figure it out, but not such a major issue that it kept you from doing what you wanted to do. A papercut should be trivial to fix.

To me, that paragraph is self-explanatory. You are requesting a new feature. A "missing function you were expecting" would be along the lines of "there is a destroy() function for Entity, but not for Camera".

http://www.ogre3d.org/docs/api/html/classOgre_1_1Light.html#_details wrote: Remember also that dynamic lights rely on modifying the colour of vertices based on the position of the light compared to an object's vertex normals. Dynamic lighting will only look good if the object being lit has a fair level of tessellation and the normals are properly set. This is particularly true for the spotlight which will only look right on highly tessellated models. In the future OGRE may be extended for certain scene types so an alternative to the standard dynamic lighting may be used, such as dynamic lightmaps.

This paragraph really points out the reason this function would be so "handy". A clearly defined limitation of dynamic lighting is the requirement for models to be highly tessellated and an alternative approach is dynamic lightmaps (or static lightmaps).

You're reading into that statement what you want it to say, not what it actually says. Indeed, you added what you want it to say, in parens, at the end.

The reason this distinction is important, is because dynamic lightmaps utilize the rendering hardware for, well, rendering. Static lightmaps absolutely would require Ogre to take on substantial portions of offline rendering, which is clearly outside its scope. It's one thing to know how much a light would have attenuated at a given point from it in space; it's another thing entirely to take on lightmapping, which would require consideration for occluders and everything else you need to render a scene.

Understand I am not saying it would not be useful; I am stating my opinion that it's outside Ogre's scope (at least once you get beyond the naive distance attenuation calculations).

xavier wrote:I already think (and have thought so for some years) that Ogre is far too bloated as is. I was kinda looking forward to 2.0 when ideally a lot of this cruft would be (hopefully) put where it belongs, but alas, that's unlikely now.

The fact that Ogre is bloated is a considerably different issue to what we are talking about here. Your probably right that Ogre could be split up into a bunch of smaller libraries instead of having it in one giant DLL. However, it's off-topic and not really a reason to stop adding features. Maybe you should start a new thread and raise it as a separate issue.

xavier wrote:To me, that paragraph is self-explanatory. You are requesting a new feature. A "missing function you were expecting" would be along the lines of "there is a destroy() function for Entity, but not for Camera".

Now that you put it that way I can see the idea behind papercuts. I don't think I'm the only one who found the definition misleading. Sorry about that.

xavier wrote:The reason this distinction is important, is because dynamic lightmaps utilize the rendering hardware for, well, rendering. Static lightmaps absolutely would require Ogre to take on substantial portions of offline rendering, which is clearly outside its scope. It's one thing to know how much a light would have attenuated at a given point from it in space; it's another thing entirely to take on lightmapping, which would require consideration for occluders and everything else you need to render a scene.

You've obviously misunderstood my intentions here. I'm not asking for static lightmapping to be added as a feature to Ogre, not at all. All I asked for, was a single function that helps to calculate the light at a given point in space. The fact that it would help with static lightmap generation is just an example of a use case.

xavier wrote:You're reading into that statement what you want it to say, not what it actually says. Indeed, you added what you want it to say, in parens, at the end.

I wasn't reading anything more into that statement. I was simply pointing out that this could lead to another feature in the future that has already been mentioned in the Ogre documentation (i.e. dynamic lightmaps). The reason I added static lightmaps in parens is because it's a different approach to the same problem. I know the basic difference between dynamic and static lightmaps but I admit I don't know the finer details of implementation. I just assumed that this function *might* be useful in both.

For simple light math, I wrote a TnL back when I was 16
The interesting bit of code you're after is here.
SSE assembly version here

Supports point, spot and directional lights.
It was designed to work around an array of vertices so that you would apply lighting equations to the vertices of your meshes.
But it can be quickly modified (the C version of course) to accept a single point and normal.

Nowadays, we do all that in shaders, per pixel rather than per vertex.