Print

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

[TiagoTiago]

Add basic lighting, like torches on the walls, or on top of sticks in the outdoors etc, and also sun and moon lighting that changes intensity, perhaps color too, and angle of insidence as the time goes by.


Lights other than the sun and the moon would have a limited range, getting dimmer quickly past the range. The sun and the moon would hit all of the open areas and might enter thru windows and doors depending which way they face.


Light would get blocked by stuff, rock, walls etc, creating shadow areas (shouldn't be hard to calculate what areas would be lit, it's just a matter of mapping where the light source could reach in a straight line in all directions without hitting any light blocking stuff), as for the sun and the moon, for terrain, it would just be a matter of checking the angle of the terrain (so if it's facing away from the sunrise it's dark) and if possible also project shadows by running a a line from each tile using the angle of the sun or the moon in the sky and see if it can reach beyond the the highest level of the map without hitting more terrain nor constructions.

Tiles next to lit tiles would get a small bit lit as well for indirect illumination and smooth penumbra areas fallout, this would also result in lit tiles being a bit brighter if they have lit neighbours helping with making it look more realistic as well.



Areas that are too dark wouldn't be included in the path calculations unless the dwarf of creature has it in direct line of sight, then instead the path algorithm will check if the agent can see a lit area on the other side of the dark area that is closer to the the intended destination than the current position. Different species would have different thresholds for what is too dark, species that can see in the dark or that "see" by means other than light (echolocation, remote vision etc) would have the threshold all the way down, so even the darkest tile would still be visible for them. Perhaps show the lightness of the map as relative to the distance weighted average of the agents near by (so you can see how they see it), but if there is no one around for a certain distance, then revert to standard lighting level.


Doors and windows when open will let some light, sun and moon as well as artificial and bounced (indirect) light, but for the sun and the moon, it wouldn't let any direct light in when they are exactly on top (noon for the sun) since the light would be going straight down, that is unless you also model different longitudes (i always mix the two, longitude is the distance from the equator, right?), then doors and windows facing the north or the south would let a bit of light thru.


If possible also have the materials of the floor/ground and any neighboring walls as well as other objects in the tile influence how much the light will bounce from that tile, things that are darker bounce less light, things that are brighter bounce more, things that are reflective will bounce even more light.



Also if possible implement things  like mirrors, light ducts etc to allow redirection of light; like for example using a mirror to bounce skylight into a duct of reflective material inside the mountain to bring natural light to deep rooms etc.


Perhaps offer  the option of having adaptive pseudo HDR for the Look mode (k), where lighting level of everything in the screen gets increased or decreased by the amount required to make the tile where the cursor is be lighted in a regular brightness (not too dark, nor too bright, just enough to show it's colors unchanged)m , tiles too bright would get closer and closer to being white, and darker tiles would go black.



Another interesting addition, but that would use up a bit more processing power would be to have magma, fire and portable torches and perhaps some other moving/changing light sources (a crystal that emits light when under a certain temperature range, perhaps the horn of the Unicorn would emit light while the unicorn is alive (so people can't use it if they kill the unicorn or try to saw it off a live one), lightning during storms etc).


Perhaps for a later moment, improve the light model to work in RGB, so colored light sources and colored light reflected from objects would be possible. So when light from two or more light sources combine you add them together, and then the resulting color is multiplied by the color of the object/surface (with each color component expressed as a value between 0.0 and 1.0) to get the color the object/surface will look like, and also the hue of the light bouncing off it to neighboring tiles.

[TiagoTiago]

also, for the terrain, evaluate the direction and steepness so tiles facing the light directly will get more lit than one that is almost parallel to the light rays, and tiles on the opposite side of the mountain to the sunrise wouldn't even need to check if it can reach the sky

[Capntastic]

Light is already in adventure mode, and having day cycles in Fort mode where time is like a day a minute would be horrible.

[TiagoTiago]

hm, days are too fast? Perhaps do a temporal moire pattern instead (like showing the sun position one hour later on each consecutive day or even more than one day step between different sun positions if necessary, or at least move the sun with the seasons  keeping it always at a fixed time)

[Capntastic]

Also, calculating light rays in Fort mode would be incredibly super expensive, resource-wise.

[NW_Kohaku]

A day is 1200 steps, where the average dwarf takes 10 steps to move one tile.  How fast that goes in real time is up to the player's computer, and the FPS of the game, but with something like 50 FPS, I've seen dwarves move several tiles in a second, so a day can easily be less than a minute, yes.

Also, is there any sort of estimate on the amount of damage to the game's FPS tracing vectors from every single light source to nearby tiles would cause checking for occlusion every single frame would do... And you want this to be done with three colors, including reflecting it off of mirrors...

Ultimately, I don't even see what this would add to the game, either...  Is this even a serious suggestion?  It almost seems like a satiric joke about people who demand ultra-realism in everything...  Why would we want to map the sun's position in the sky for tracing the angle of ambient light when the game is still in ASCII, and you wouldn't be able to detect any of this, anyway?

[TiagoTiago]

Some of the lights can be processed one time and then have it's effects not change until the surroundings change (like wall torches)


The colors part can be left for a future version

As for the the sun light, it would help get a better feel of the shape of the terrain with all the different shades and the shadows


There are color tilesets, i assumed that even though  by default it currently just uses text and doesn't have a wide variety of colors used, it still did things in graphic mode, it would just be a matter of doing the color tinting it already does but with a greater range of colors.

[Capntastic]

Some of the lights can be processed one time and then have it's effects not change until the surroundings change (like wall torches)

A dwarf walking in front of it.  A miasma floating down a hallway obscuring it.  Etc.   If you're going to have realistic light, like you suggest, you need to realize that it's expensive and will be changing constantly.   You can't just make a suggestion that light behaves realistically and casts shadows and then say "except when it doesn't".

[TiagoTiago]

if shadows for moving things takes too much processing power have only static structures cause shadows

[Darbuk.Ubildolush]

Ya know, I was just thinking about this today.  But all I'd really want would be a day/night cycle.  I'd suggest an extension of the already long year.  This was based on thoughts that as more and more complexity gets added, we might need more time in a year to accomplish things.  A combination of increasing the number of steps per day, and perhaps cutting the single step FPS back from 10 to ? would be a good way of doing that.  If this direction took place, then day/night cycles could be done naturally with little 'flicker'.  Mind you, all I want is a general on/off thing for lighting.  Either it's daytime and light is shining in the windows and on the ground, or it's night time and everything is lit by artificial light.  (Perhaps with some variation for moon cycles).

However, I like the idea of using a kind of pseudo time where the sun increments every day, rather than doing a full cycle.  It's a clever solution that still gives us night/day, without having things flicker like time-lapse photography.

[NW_Kohaku]

There is no guarantee that we're going to get any sort of GUI upgrade right now, aside from probably getting an ability to make everything into a graphics tileset.  Even if we did suddenly get dynamic shading (in an ASCII game?!), there's no real reason to actually change what the player sees (except maybe in a slight way, just to be able to know when something is dark or not), especially based on three seperate colors and dynamic shadow-casting. 

Players already grumble about being unable to see things, except by blind groping with the k button when you have miasma (which is theoretically just a smell, not a literal opaque purple cloud).  If lighting has an effect, it should be on the dwarves, not an Interface Screw on the player.

[TiagoTiago]

Have you played ASCII Portal? The way the seeing thru portals works there, at least visually, is kinda similar to how light coming thru a door or cave entrance could work.

[NW_Kohaku]

Have you played ASCII Portal? The way the seeing thru portals works there, at least visually, is kinda similar to how light coming thru a door or cave entrance could work.

No, I haven't.  Still, Portal was a game essentially dedicated to odd physics quirks and things like, well, portals.  It didn't have much else running under the hood.  It doesn't have to care about light sources you don't see right at the moment.

God help you when you have a game with 30,000 individual objects being tracked in memory at all times, each one casting a shadow, which must also be tracked in memory, for how they interact with what will almost certainly be hundreds of light sources, if not thousands, because every individual room in a fort is going to need at least one lamp or sconce or torch.

A simple set of code that tracks a mere line where corners of walls prevent areas behind said corners from recieving light being performed for every light source among hundreds of light sources in a fortress will already significantly increase the CPU load and memory load of the game, even if there is nothing but a boolean "lit" and "unlit" tag applied to any given tile, with a given light source simply lighting X number of tiles in any given direction.

If we do get lighting, I hope it works essentially off the same code that gives us room designations - it makes a five/ten/fifteen-tile radius "room", and gets stopped by walls, which only gets checked once when the item is designated, and when a new construction is built in the area.

[TiagoTiago]

there is so much already being done all the time anyway, i don't think lighting would be much more than what already is there; but i dunno for sure, i don't have enough knowledge about how everything works in the engine and how much processing power can be spared for additional stuff

[NW_Kohaku]

As it stands, the game is overburdened already, to the point where players who care about framerates will limit the number of their dwarves, refuse to allow pets, or even just outright kill anyone who brings a cat as a pet with them to their fortress, and abandon when a fortress gets too large.

Hopefully, pathing code will be re-examined, and made much more efficient, (and maybe after that, liquid flow code) which should allow for what we have now to run well.

If we get that, we might have processor power to spare, provided better AI code doesn't get too intensive, and off-site calculations are kept to a minimum when things like the caravan arc get implimented.

Even then, to have any of the sort of visual effects that you're talking about, we would need the GUI overhauled, which seems to be very pointedly a low priority of Toady.  As such, we're probably talking about a light source that simply affects dwarves, and not what the players actually see.

With all that, however, we're still talking about a day-night cycle of around thirty seconds, which probably wouldn't matter much in most forts, as people tend to like building almost completely underground, anyway.  We could do month-long days or nights, but given the realism bent of the rest of the gamers, that seems like it would be controversial, and, again, day and night aren't terribly important to a subterranean fortress, anyway.  (Especially when dwarves only eat, drink, or sleep a few times a year.)

As such, what we're realistically talking about is trying to find a resource-efficient way of handling something that is notoriously processor-heavy in most 3D modeling, while still giving it some kind of meaning for in-game play.

Aside from suggesting that Grues occasionally eat dwarves that dare venture into hallways that have no lighting, I would think that completely shutting pathing off in a darkened area would be problematic, unless miners carried their own torches with them... and you would likely then need to micromanage which professions carried lamps or torches. 

It could behave as a defacto traffic designation (although those add cost to pathing calculations), making them less desirable paths, with chances for bumbling and tripping, or even falling into pits.

I would say things like having to code the reflective/refractive properties of every single material in the game are... well, OK, it almost DOES sound like the sort of absurdly specific thing Toady would care about.

Regardless, I would expect either a boolean "lit/unlit" based on distance from a source, with varying types of sources providing varying types of light radius, or else possibly using another #/7 method, so that every tile's illumination takes a single byte of data.