This is a good idea. However I think it would be best to have a LT_CUSTOM entry just to keep the enums predefined and the logic simple for identifying non-standard lights, and then have an additional 'customID' flag which users can use to subclassify their custom lights if they want to. The render queues had a valid reason for needing values between the standard values, since lights don't I ...
Thread: A 4th Light Type  |
|||||||||||||
|
Started 1 month, 3 weeks ago by Praetor
What I'm proposing is some way of classifying lights beyond point, spot, and directional. These light types surely are created through tricky shader magic. One of the easiest ways to mix and match and combine lights is to use a material which iterates on lights, but selects out specific light types. This way we can have one shader that handles point light, one that handles spotlights, etc. What ...
|
|
||||||||||||
|
|||||||||||||
Other posts in this thread:
Praetor replied 1 month, 3 weeks ago
Custom parameters already exist on lights. We did talk about it and it is committed in HEAD. It works great. I'll look into making the changes for the lights. It'll probably take a few revisions to get it right. I'm not sure if I'll need to pretend the custom lights are like any of the standard light types during the scene rendering though. During rendering, do we do any processing based on the ...
Size: 778 bytes
Customize: 
Nir Hasson replied 1 month, 3 weeks ago
When I implemented the lighting model of the RTSS I had to deal with some related issues - the main were how to generate consistent shader code while the effective light list might change from time to time. I added the RenderObjectListener interface that you can implement and it is called before rendering single object. One of the parameters it gets is the current light list - and at this ...
Size: 1,344 bytes
Customize:
Praetor replied 1 month, 3 weeks ago
The goal isn't really to set custom parameters or anything. The real goal here is that I want different light types to be handled by different shaders. So, for instance, I can have shaders that handle the standard light types in one shader, an area light shader, etc. And then in my material file I want to be able to iterate my passes on the different light types. To do this I need to be able to ...
Size: 463 bytes
Customize:
Nir Hasson replied 1 month, 3 weeks ago
Ok - I guess I missed the point - So you suggest that a pass could declare which light types it can accept and than during the rendering stage the scene manager would execute it only with the light types it support ? This kind of change would help simplifing shaders and will be great thing to have
Size: 393 bytes
Customize:
Praetor replied 1 month, 3 weeks ago
I'm saying it already does this with the basic types. When you do multipass lighting you can already have one pass handle spotlights and another handle point lights, effectively funneling them into separate shaders if you wanted. But say I have a shader which handles 3 simple spot lights per pass, and another that handles only 1 very complex spot light per pass. I'd like to specify which ...
Size: 703 bytes
Customize:
sinbad replied 1 month, 2 weeks ago
Praetor wrote: Custom parameters already exist on lights. We did talk about it and it is committed in HEAD. It works great. Doh. During rendering, do we do any processing based on the assumed "light model" of the light? For instance do we do anything special knowing the nature of directional lights? Because I won't be able to assume anything about custom light models. My area lights ...
Size: 1,538 bytes
Customize:
Praetor replied 1 month, 2 weeks ago
Yes I think that's a good idea. For instance I might have a special spotlight I want processed in a separate pass from other spotlights but I still want shadows calculated for it as normal. The most general models can based themselves on point lights since I assume they are the most general and don't have much processing happen to them. The only thing is how to refer to these lights in materials...
Size: 1,286 bytes
Customize:
sinbad replied 1 month, 2 weeks ago
How about: Code: Select all iteration once_per_light custom#0 Just to make the division more explicit? Also kinda CSS-y. It would also work better if you wanted to make it work with existing types, e.g. Code: Select all iteration once_per_light spotlight#5 Becuase you have an explicit delimiter character so splitting is trivial regardless of the type name.
Size: 703 bytes
Customize:
Praetor replied 1 month, 2 weeks ago
Is using the base type any more meaningful though? Perhaps it is handy for remembering it, but if custom#5 is defined by you as a customized spotlight model, then using spotlight#5 doesn't add anything. Specifying the base light type is done in the app and so it isn't really important to know the base light type in the scripts.
Size: 329 bytes
Customize:
|
Top contributing authorsRelated threads on other sites: |
||||||||||||
Thread profile page for "A 4th Light Type" on http://www.ogre3d.org.
This report page is a snippet summary view from a single thread "A 4th Light Type", located on the Message Board at http://www.ogre3d.org.
This thread profile page shows the thread statistics for: Total Authors, Total Thread Posts, and Thread Activity
Home |
About Us |
Submit Your Site |
Update Your Site |
Get Search For Your Site |
Partners |
Contact |
Search Plugin |
Blog |
 |
Last Searches | Top Searches |
Designated brands and trademarks are property of their respective owners.
Use of this website constitutes acceptance of BoardReader's User Agreement and Privacy Policy.