Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[dree12]

While we're on the topic of light, I figured I'd give my suggestion out now.

Basically, a tile's lighting consists not of a number, but many, many numbers. These numbers don't represent the "lighting" of the square, but rather the rays of light passing through. A single tile would have up to 27 possible entries in the lighting, one for each direction and one for light originating from the tile. Each direction would then have a mixture of light from different wavelengths; to simplify this, microwave, far infared, infared, red, green, blue, UV, and X-ray can be used as an approximation of the common range (there are 8, so the numbering can be simple). Each wavelength would then have an intensity, which can be packed into a 2 or 3 bit value. For example, at midday the sun's lighting on an aboveground tile may be as follows:

Code: [Select]

null,null,null,null,
[1,4,6,7,7,7,3,0],
null,null,null,null,
null,null,null,null,
null,
null,null,null,null,
null,null,null,null,
null,
null,null,null,null,

As the moon shines in the west and a nearby campfire radiates from below:

Code: [Select]

null,null,null,
[0,0,0,2,2,2,0,0],null,null,
null,null,null,
null,null,null,
null,null,null,
null,null,null,
null,null,null,
null,null,null,
[0,1,2,2,0,0,0,0],null,null

And when a firefly lights up some beautiful blue light while the stars shine with the lack of clouds:

Code: [Select]

[0,0,0,1,1,1,0,0],[0,0,0,1,1,1,0,0],[0,0,0,1,1,1,0,0],
[0,0,0,1,1,1,0,0],[0,0,0,1,1,1,0,0],[0,0,0,1,1,1,0,0],
[0,0,0,1,1,1,0,0],[0,0,0,1,1,1,0,0],[0,0,0,1,1,1,0,0],
null,null,null,
null,[0,0,0,0,0,3,0,0],null,
null,null,[0,0,0,0,0,1,0,0],null
null,null,null,
null,null,null,
null,null,null

While it may be straining on FPS, this system allows for gigantic mirrors focused on enemies, fireflies with varying colours, etc. Imagine lighting a campfire and setting up black screens with the sole purpose of producing shadow puppets on a wall. Or, imagine fort mode after a terrible lack of clouds has persisted for a few days, and the grass is on the verge of igniting, while your firefighting dwarf squad is in the hospital because of UV-related sunburns. The system even allows for severe solar ejections that produce huge amounts of microwaves that are absorbed into most things, but cause dielectric heating in the poor woodcutter, heating his bodily fluids to the point of exaustion.

And, deep inside, I've always wanted to take X-rays of the dwarves.

[NW_Kohaku]

Yeah, that sounds like gross overkill in Fortress Mode, and it would probably nuke FPS. 

If you put that data on every single tile, that's 27 more pointers per tile, of which a single embark can have theoretically as many as 80 million tiles.  There's a reason Toady compresses the map data to the greatest extent that he can.

[slothen]

anything is possible if DF becomes magically multi-threaded and 64-bit-whatever.

allofmymoney.jpg

[dree12]

The thing with lighting is that if it is done with rays instead of "light", it would be easily multi-threadable because each ray is independent of the others.

[Draco18s]

The thing with lighting is that if it is done with rays instead of "light", it would be easily multi-threadable because each ray is independent of the others.

...only in an application that is already set up to be multithreaded.

[dree12]

The thing with lighting is that if it is done with rays instead of "light", it would be easily multi-threadable because each ray is independent of the others.

...only in an application that is already set up to be multithreaded.

It's fairly simple to spawn a few extra threads at the beginning and have them process only light.

[Draco18s]

The thing with lighting is that if it is done with rays instead of "light", it would be easily multi-threadable because each ray is independent of the others.

...only in an application that is already set up to be multithreaded.

It's fairly simple to spawn a few extra threads at the beginning and have them process only light.

Do you have experience to back this up, or are you talking out of your ass? (As so frequently happens when people discuss this topic)

[NW_Kohaku]

Okaaaaay...

Why don't we move on to talking about ways that light could actually work in a way that would be meaningful to fortress mode?

I seriously doubt we're going to see dwarves get the ability to create x-ray lasers in this game any time soon, so maybe we should work on other means of incorporating light into the game.

One of the things Toady was talking about was alchemy and "gem lights", and lights of different colors, so hypothetically, there could be some sort of light-based mechanism.  Combined with directional gem light lamps and possibly rotatable mirrors, that could allow us to have more fortress mechanics, as well as allowing Adventurers to have light color-based puzzles to deal with in dungeons.

[Elone]

I would say that 1bit lightmaps would be the best balance between function and looks. A tile is either lit or it is not. Perhaps 2 bits if one would handle the revealed tag in the same go.

Every time a dwarf makes a step, the radius of is vision +1 would be darkened (no questions) and the radius +0 would be lit up, based on the occluding objects like walls and trees. The situation is a lot more demanding and complex if there are other dwarves intersecting their LOS with others, which is why adventurer LOS was easy to implement, but the Fort LOS was not.

This simple models ensures that the tiles are darkened without checking the conditions, which eat FPS (contrary to the popular belief, every last one of them counts). It also ensures that the whole map is not constantly checked for lighting, which would be disastrous for any computer, not to mention if each tile had the aforementioned 27 checks. This would include even currently the strongest ones that so many people waves around as their e-length. I'm not calling any names though.

For static lights, it would be best not to refresh it every frame, and have it static as pathing data which recalculates only when the map's pathing is changed. Every time that a light is changed, like a torch being set or taken, the whole map would be blackened, then lit from each light. This is of course an expensive action, but not more expensive than pathing recalculation during mining or bridge operation.

If you wished to combine dynamic and static light, the situation gets even more complex and demanding. You would have to find a way to calculate dynamic light without overwriting the static light data, but you cannot properly do that without recalculating the statics lights once per frame, which whoah, makes them dynamic. You cant have dynamic environment lights because that means roughly 8.000.000 additional calculations PER FRAME on a default 4x4 embark. If you wish to maintain 100 fps, this means 800.000.000 such calculations PER SECOND, which is a lot, but now imagine doing 27 of those suggested calculation PER TILE, PER FRAME. That would be 21.600.000.000 calculations PER SECOND. With a 1bit light system. Now imagine combining their hues, and then multiply it by intensities/shades of light. Not dizzy yet? Look at the original post and imagine implementing each of those suggestions, a check for each, per tile, per second. That should do you in.

Have you ever wondered why the Minecraft character does not carry a torch in his hand that lights his way while he walks? Thats why.

[Draco18s]

Have you ever wondered why the Minecraft character does not carry a torch in his hand that lights his way while he walks? Thats why.

There's a mod that spawns a glowstone block above your head when you're holding a torch active.  It's actually not that lag-inducing.
(Thought it has other problems, such as sometimes forgetting to turn OFF....and once we* managed to get glowstone dust out of it)

*My friend, I was on the server at the time