Ambiera ForumDiscussions, Help and Support. |
|
|
|||||
|
Apparently, I got tired of setting up hitboxes again and again every time I did certain changes to models (for example: changes in animations, where it's easier to remove model and import it again after engine restart instead of rewriting animation timings by hand because all of them are now shifted). Thing is, there are hitboxes that may already be on model, and setting them up after they got deleted is just pain. So, I made a plugin for engine to "copy" hitboxes from one animated model onto another with the same bone attachment hierarchy. And by "copy" I mean make a new cube and apply all the needed parameters on it, because, guess what, for some reason "ccbCloneSceneNode" doesn't work in editor! Wow! Problem here is that I could not find a way to switch "Lighting" from "Static (Lightmaps)" to "None", which is... kind of bad? I mean, sure, hitboxes are fully transparent, but having about 16 more objects to calculate lightmaps for, I guess it might be a bit bad? If it's not, then, guess I'll just go on with what I have right now, everything else works fine. So, is it possible to switch it with code? Or this doesn't matter all that much? Edit: oh well, forum did its thing with thread names again...
|
||||
|
I may be wrong but I think it's automatic - ie:I think it will only calculate the static-lightmaps when you click "calculate" in the editor, or if you add a normal-map with the material/texture - otherwise I think it assumes "none" for the material lighting. |
||||
|
Well, it's not like that, VP, if I understand you correctly. When a cube mesh is created, it has lighting set to "Static". However, all I could find about lighting (with "ccbSetSceneNodeMaterialProperty") is irrEdit material property, boolean type. But, it controls wether you are going to use dynamic (if true) or static (if guess what?) lighting. There is no difference between "Static" and "None" in irrEdit properties, I guess that marking it "None" in materials tab just removes it from the list of objects to be calculated when baking lights. So, as I said, I couldn't find any way to set lighting mode to "None". |
||||
|
Like I say, I think it's automatically set to "none", even when it says "static". |
||||
|
Oh, yes,I misunderstood you. I see what you mean now.You want to be able to set it to "none", using code so it doesn't get included when someone calculates lighting. |
||||
|
...but,even so - if it's set to "static" lighting, it wont have any lighting aplied unless you add a normal-map to the material - even if you calculate the lighting. |
||||
|
So,essentially "Static" is the same as "none", until you add a normalmap to thematerial. If you have a normalmap, setting to "none", as you said, will exclude it from the light-mapping calculations. I assume the hitboxes don;t have normal maps if they;re transparent alphas, so it shouldn;t make any difference if it says static or normal for lighting, |
||||
|
Why do you need to set lighting to none? if you are working in the editor and don't want your nodes to be get's caclulated while baking lightmaps, then you can simply use Dynamic lighting on them, so that they won't be taken into account while baking LightMaps. You can easily do that with scripting as well. Once you are done with calculating lightmaps, then you can switch the lighting back to Static if you want. The above method is recommended to use, but if you have calculated lightmaps for your object and want to remove them, then you can also change their material type back to Solid this will remove the lighting from it, also make sure to remove the internal lightmap texture from the second material slot, otherwise it will just hog up extra memory for those textures. so, simply use the dynamic light for the nodes that you want to exclude from lightmapping, and once done, if you want you can switch them back to static. No need to set the lighting to "None" at all and you will get the same result as you wanted. Hope this helps 
|
||||
|
Well... Fine, I'll see what this leads to. After all, I'm not entirely sure how 16 different "calculations" of dynamic lighting will affect performance. I mean, these are typical cubes with a transparent 1 pixel texture, but I really have no idea how it all functions internally to make assumptions, so, maybe I will stick to this way. Thanks, just_in_case. |
||||
|
|
){kind=link}