![[us]](/mwf/flags/us.png "United States")
In that case, we would have to update the ambient light map whenever the light range is changed (at the moment the ambient brightness is simply a single shader parameter). That's possible, but generating the ambient map for the whole landscape can take 0.1-0.2s or so depending on the landscape size, so it is something that should not be done every frame.
![[de]](/mwf/flags/de.png "Germany")
Then we'd have to re-generate a lot of stuff when the player scrolls?Maybe we could split the landscape into blocks, keep a map of whether blocks are "dirty" and a list of dirty blocks. The engine then updates a max of N blocks per frame from the list and if large updates happen, they will be calculated sequentially. Could even add some complexity and ensure that visible blocks are first in the list.
Never more than fits on a screen. So if we get it efficient enough that we can fit a screen-sized update into a frame - which we have to if we want to do a fade - it's enough for whatever we throw at it. We can still cache as a performance optimisation.
Also I'm pretty sure we could optimise
Also I'm pretty sure we could optimise
AmbientForPix a bit if needed.
>I actually thought about reducing the light intensity for Clonks... Wouldn't it be nice if you could really see everything being brighter in your well-lit cave?
Sounds very nice to me. For me it's weird that the clonk emits light like a lightbulb, although he obviously doesn't have a lightsource. A clonk alone should have a hard time to see in a dark cave without any gadgets that emit light.
If he would carry a torch around, or wear a mining hat with a candle attached to it, it would make more sense that the clonk is so bright.
Anyways if there would be a scenario property for clonk lights, then in my scenarios I'd make sure that all clonk lights in them are really dark. And give the players the opportunity to attach a seperate bright lightsource torch/hat to their clonks. Or just plaster torches everywhere. :>
Light is blocked by tunnel material. Is there a way to make objects block light, too? I am thinking about either a mesh or .png graphics with non-transparent pixels blocking light in the .png.
You mean like blocking light or just like not producing ambient light?Either of the two could be done by adding some extra functionality to SolidMask code.
Not sure what you mean by "blocked by tunnel material", but yes, making extra light blockers should be relatively easy, see Sven2. Given that most light updates are relatively local, we wouldn't even have to traverse the whole object list to do it.
Oh, so you would want to add object traversal to the beam checking code? Or extend SolidMask to contain other materials and then add a light-blocking non-solid material?
Having an object block the actual light beams would be pretty cool!I think Marky was only talking about ambient light, though
If you have too much tunnel material in one area, then the light emitted by the sky does not pass and FoW is generated in these areas, because it is dark. I want objects that block "sun rays" in the same way, so that they get covered in FoW. This is cool for various reasons, one of them is that you can have e.g. walls with tiny cracks that have light come through. Or Zappers smoke screen idea.
> one of them is that you can have e.g. walls with tiny cracks that have light come through
But that is the opposite of what you asked for. You can already have stuff that normally blocks ambient light emit it by drawing it with sky background in the map.
Ok, another example. Take the castle site in "Raid". It has windows and arches. In my example the castle site could block light beams, but they would shine through the windows. Does that make more sense?
Yes. Well, that would be possible if we just deined a material to block light and then let the castle site draw that in its background on placement. But it might look weird if some objects block light and some do not (they're all "behind" the clonks anyway).
What if the site is removed for example? Would the material remain? As an alternative we could have objects block light if they are behind the landscape.
Another question: Do I have to invert the normal map here? It gives me strange behavior, as visible in the screenshot. The object is covered in shadows, but standing above it illuminates it.
Is that a sprite object with a normal map? It's strange that it looks totally black on the right hand side. If you upload the object I'll take a look.
It's a mesh with normal map. In the attached file, if you make the whole normal map "flat" (use the background color), then the behaviour becomes even weirder.
Attachment: HutStone.zip (278k)
Ah okay. Normal maps for meshes are not very well tested yet, it's likely there is a mistake in the shader or somewhere else. I'll have a look.
I didn't forget about this, but haven't gotten around to this yet. Sorry, but it's still on my list.
The primary problem is that there are two different coordinate frames at play here. There is what I call the "Clonk" coordinate frame with x axis=right, y axis=down, z axis=inside, and the "OGRE" coordinate frame with different conventions. Models are typically created in the "OGRE" coordinate frame, but your normal map is in the Clonk coordinate frame. Basically I introduced this convention when I started working on mesh support in the engine, and the first model that I was using to test the functionality was aligned in this "OGRE" coordinate frame.
Ideally, we would just drop the OGRE coordinate frame, and directly align all models in Clonk coordinates in the model files. This would avoid some unnecessary coordinate transformations in the engine, and avoid one step of complexity, but would require changing all the models, and I'm not sure how convenient it would be for creating/modifying models.
For now, I have committed a small change to the shader such that, for the normal map, it corrects for the different coordinate frames. It's a bit inconsistent now in the sense that the normal map is given in different coordinates than the model itself, but the stone hut is working with this, and I think that everybody would expect the normal map to work this way, because then it has the usua" blue-ish appearance.
Overall, some feedback in general on this topic would be much appreciated.
Ideally, we would just drop the OGRE coordinate frame, and directly align all models in Clonk coordinates in the model files. This would avoid some unnecessary coordinate transformations in the engine, and avoid one step of complexity, but would require changing all the models, and I'm not sure how convenient it would be for creating/modifying models.
For now, I have committed a small change to the shader such that, for the normal map, it corrects for the different coordinate frames. It's a bit inconsistent now in the sense that the normal map is given in different coordinates than the model itself, but the stone hut is working with this, and I think that everybody would expect the normal map to work this way, because then it has the usua" blue-ish appearance.
Overall, some feedback in general on this topic would be much appreciated.
Wouldn't it make sense to transform everything during/after loading? That way there won't be data from two different coordinate systems in the engine.Either that or switch to the OGRE coordinate system in the engine.
Yeah, this sounds reasonable. I might try it out, but mostly it would be a "change under the hood". It would still mean that we have meshes and normal maps in different coordinate frames.
Changing the coordinate system in the engine now would mean that all MeshTransforms and PictureTransforms would have to be updated...
Changing the coordinate system in the engine now would mean that all MeshTransforms and PictureTransforms would have to be updated...
I wanted to create an ambient light that does not have the default color, but for example blue or green. Is this possible at the moment? If so I had a hard time finding it in the docu. If not, then I'd try implementing it. In any case I'd update the docu accordingly.
No, ambient light has only intensity, but not color. It should not be hard to enhance the code so that it stores three intensities for R/G/B separately instead of only one, and specifying different light colors/intensities for different materials. The code for that is here.
If all you want is a global factor to be applied on all ambient light throughout the map, a simpler approach might be to enhance the SetAmbientBrightness() script function so that it accepts an RGB triplet instead of a single value. That should require only very few code changes.
If all you want is a global factor to be applied on all ambient light throughout the map, a simpler approach might be to enhance the SetAmbientBrightness() script function so that it accepts an RGB triplet instead of a single value. That should require only very few code changes.
Yes, I'll have a look at it in the weekend. As far as I understood your link that is just the code for generating the lightmap. Differently colored ambient light could be interesting, too. What I had in mind was light sources that emit light, such as a blue lamp.
On a side note, I think the functionality of attached meshes could be improved. I tried playing an animation in an attached mesh (object is contained and mesh is attached), the animation is not rendered on the attached mesh. Probably because the attached mesh is a separate instance of the object's mesh? Furthermore it would be useful if one could attach particles to the bones of an attached mesh. Imagine guns having a bone where the muzzle is, or a line of bones on a sword so that you can have a burning sword.
On a side note, I think the functionality of attached meshes could be improved. I tried playing an animation in an attached mesh (object is contained and mesh is attached), the animation is not rendered on the attached mesh. Probably because the attached mesh is a separate instance of the object's mesh? Furthermore it would be useful if one could attach particles to the bones of an attached mesh. Imagine guns having a bone where the muzzle is, or a line of bones on a sword so that you can have a burning sword.
Coloured non-ambient light sources will be hard. We also save the normal into the lights texture, so there's only one component free for extra data.
How about saving the intensity as the length of the normal vector, or store only the x coordinate of the normal in the texture and the y coordinate is then given by sqrt(1-x^2)?
> or store only the x coordinate of the normal in the texture and the y coordinate is then given by sqrt(1-x^2)?
This only works if there is just one light source, but there can be several next to each other.
After digging through the code a little I found something that might help me. I think that the C4FoWLight class could be expanded so that it emits a colored light. At least that is the point where I would start, since you can set the light range/reach in that class.
Absolutely. The question is where to put the color in the light texture. Don't forget that the color component needs to be blendable when the light of multiple differently colored light sources is added up to another. For this reason, to have a 256-color palette (to have the color fit into one byte) will not be possible easily.
> ...will not be possible easily.
But possible, I think. After all, of HSL you only need HS, lightness is already the light intensity. Here is one suggestion: Together with the light intensity, you have 2 byte for HSL. So you could take those 16bit for HSL: Light intensity gets 6 bits, Hue 5 and Saturation 5. This way you can have 32 hue and 32 saturation levels. This should be enough for smooth blending.
Or,... you have an adaptive palette that is dynamically created depending on the colors of the actual light sources. This will be more brainwork though. ;-)
Where is the brightness of the light actually applied to something? The texture information is constructed in C4FoWDrawLightTextureStrategy::DrawVertex(float x, float y, bool shadow), right? All that I understand is, that this saves an RGB value with the brightness in the A channel and normal information in G and B. I added an alpha channel and set its value to 0 - scenarios still work normally, as intended. However, I do not understand where the information of the texture map is used to draw objects or the landscape.
Considering that we are attempting to replace the gamma stuff of the day-night-cycle with actual ambient light it could be better to have a second light texture that contains the color information only.
Considering that we are attempting to replace the gamma stuff of the day-night-cycle with actual ambient light it could be better to have a second light texture that contains the color information only.
> Considering that we are attempting to replace the gamma stuff of the day-night-cycle with actual ambient light it could be better to have a second light texture that contains the color information only.
To replace SetGamma, it would be sufficient to just recolor all lights in the same manner. For that, a few modulation parameters in the shader would suffice and it doesn't need a new texture.
Of course it might be cool if you had a blue-ish moonlight outside and warm reddish torches coming out of the cave.
> Where is the brightness of the light actually applied to something?
In the shader in planet/Graphics.ocg/LightShader.glsl
Date 2015-05-03 17:28
![[ba]](/mwf/flags/ba.png "Bosnia and Herzegovina")
Working with a hue value won't work with multiple lights - I can't imagine additive blending making a lot of sense. Doubly so if you play tricks with bits. If you are willing to go to that length, I would *really* suggest just doubling the lights texture instead.
Do we need to save the color information in the light texture at all? So far I understand that we use the texture for brightness. The color information could come from somewhere else?
>Furthermore it would be useful if one could attach particles to the bones of an attached mesh. Imagine guns having a bone where the muzzle is, or a line of bones on a sword so that you can have a burning sword.
CreateParticleAtBone :)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
