I have a Mesh Class that handles loading, rendering. Inside the Mesh Class I have a PointLight struct. In Rastertek's tutorials he has the shader doing the rendering of the primatives. In most of the DirectX books I've bought the mesh loader does the rendering. This is what bothers me about tutorials some times because one site this is the way and the other site does this.

But no one ever talks about multiple point lights or multple lights inside a level and how it is rendered. Does all the lights go into the constant buffer inside the mesh loader class or is it completely seperate? Or should the multiple lights be inside the shader class that renders the models.

How does handling mutple light sources get managed inside a game is the bottom question,

On today’s hardware you can’t render anything but solid-colored screens without a shader, so yes, technically the shader is doing all the rendering.
But not the shader class. That’s absurd.

However by having a PointLight structure as part of your mesh class you aren’t doing much better. Lights might be part of a model file, but they’re only there to hand off that light data to the scene manager upon loading. The scene graph will keep your headlights attached to your bones and the scene manager will make sure the light’s shadows get generated and that objects not affected by it are culled from its rendering influence—you don’t need any part of the mesh class dedicated to managing the light at all.

It’s a common mistake to assume that meshes are the source of all renderings in a game. They aren’t. Procedural skies, terrain, foliage, water, volumetric fog, etc., are not “meshes”. So to say that a light has any special relationship to meshes is also to somehow imply that they don’t have relationships with terrain or water or grass.
It should become clear that anything your mesh class is doing with lights would have to be duplicated for your ocean class and your terrain class, and that kind of duplication is always a clue that something is wrong with your design.

How does handling mutple light sources get managed inside a game is the bottom question,

After the scene files have been loaded and all the lights (from the terrain files, the model files, the scene files, etc.) are registered with the scene manager, the scene manager can then decide during the rendering process which lights to activate (which works the same way as in Direct3D or OpenGL—your graphics module has light settings that you can activate to enable a light, change its color, etc., which will be sent to the shader during the actual render) based on closeness to the player, influence on objects (don’t draw an object with a light activated if that light does not affect that object (this applies to forward rendering; deferred rendering has a different set of culling optimizations to be performed)), etc.


L. Spiro

Thanks L. Spiro the PointLight struct is seperate and the mesh class shares the point light struct. I haven't created the scene manager fully yet - partially. I was thinking the scene manager was the part that handles what objects get drawn based on culling and what lights get activated when the object is visible within the octree or frustum.

So I believe I was heading in the right direction just got confused. Let me clearify though:

//-- Pointlight.h

struct PointLight {
   float3 position;
   float padding;
   float3 direction;
   float Range;
   float3 att;
   float padding2;
   float4 diffuseColor;
   float4 ambientColor;
};

//-- Mesh.h

class Mesh {
private:
public:
   PointLight Light;
   CBPerObject cbPerObject; //-- this is constant buffer per object that has the PointLight for shader.

};

void Mesh::Render(...) {
     cbPerObject.pointLight = Light; //-- Hand off the Light to the cbPerObject for shader.
}

I'll get working on the scene manager today or this week and I'll have a clear picture. However, the sample code is what I have it set up to now. Is this what you're mentioning? I don't have the scene manager in yet because I'm revising the entire engine SDK.

Here's what I do in my engine (high over):

- scene manager has one or more scene class objects
- scene manager has one shadermanager class object
- scene manager knows which scene is active
- scene class has x mesh instance class objects and y instance point light class objects
- mesh instance class has pointer to unique mesh
- mesh instance has x objects of renderable class
- renderable class objects have a int vector keeping track of which positional lighs currently affect the renderable (this is used by the scene manager/ during updating to set the shader constants/ parameters for the positional lights)
- renderable has its own orientation (matrix) related to it's parent (= mesh instance)
- renderable has an id of the scene material it uses

- scene manager class updates all shader constants/ parameters based on the current state of the scene (culling, lights visible, lights affecting objects etc,)

- renderqeue get it's data from the scene manager (pointing to the current scene)
- d3d renderer class takes the renderqueue data (basically indices and pointers)

So basically the renderer in my case takes renderqueue indices and a data source containing the actual vertex/ index data, materials etc.

Hope this helps.

Note; this is/ there's no right way to do it, I believe it's best to see other options and find the hybrid that suits best for your own needs