Jupiter's Lighting
Jupiter may be designed for indoor scene at the first place. Since there were supposed to have plenty of lights in the indoor scene, Jupiter carefully divided the lights into static lights and dynamic lights. For static lights, it performs ray casting technique to compute the final light strength and shadows.
The point is that Jupiter save the ray casting result not only to the lightmaps conventionally, but also to the vertex color, if the user think the lightmap texture will overwhelm the graphics card. It could be take as simple and cheap way of avioding the hardware lighting's limitaion to pre-compute the lighting/shadow result and blend it with the vertex color. However, since the indoor scene's appearance is famous for texture dependable, this trick doesn't help a lot comparing to the hardware light, think about it, many indoor lights may just cover several vertices, if we really want to reach the effect which had been done by the lights, use lightmap. Whatever, we can use as many lights as we want, what a good thing! Plus, this seems not work for instance objects...
I heard that some engines uses light grouping technique, which assign the lights only to the objects where the lights take effects. So there are rare objects which will be contained by over than 8 lights. And each object will be lit by hardware. It seems no problem since nowadays hardware lighting is really fast, but how about those big mesh, such as floor or terrain? assign the lights after clipping? or just disable the lighting? This method is kinda expensive, but more flexible, even when you are using a lot of instance object.
Jupiter may be designed for indoor scene at the first place. Since there were supposed to have plenty of lights in the indoor scene, Jupiter carefully divided the lights into static lights and dynamic lights. For static lights, it performs ray casting technique to compute the final light strength and shadows.
The point is that Jupiter save the ray casting result not only to the lightmaps conventionally, but also to the vertex color, if the user think the lightmap texture will overwhelm the graphics card. It could be take as simple and cheap way of avioding the hardware lighting's limitaion to pre-compute the lighting/shadow result and blend it with the vertex color. However, since the indoor scene's appearance is famous for texture dependable, this trick doesn't help a lot comparing to the hardware light, think about it, many indoor lights may just cover several vertices, if we really want to reach the effect which had been done by the lights, use lightmap. Whatever, we can use as many lights as we want, what a good thing! Plus, this seems not work for instance objects...
I heard that some engines uses light grouping technique, which assign the lights only to the objects where the lights take effects. So there are rare objects which will be contained by over than 8 lights. And each object will be lit by hardware. It seems no problem since nowadays hardware lighting is really fast, but how about those big mesh, such as floor or terrain? assign the lights after clipping? or just disable the lighting? This method is kinda expensive, but more flexible, even when you are using a lot of instance object.
