#Terraria specifically is using a light
1 messages · Page 1 of 1 (latest)
As you mention blurring the RT texture, if the texture only includes light from the empty space you could use that to allow light to "spill" over to solid tiles when the blurry texture is overlayed to them
But it wouldn't prevent your light from passing through "under" the blocks
I would rather look into a flood fill algorithm to do it properly
Yeah, that is something I've accepted as being a problem that is nearly impossible to effectively solve.
Starbound doesn't even fix it.
It certainly does?
Light can fully travel through blocks it is just very rare which a situation like that looks bad since the cave walls are so many tiles thick.
what specifically are you referring to?
In your case the cone of your flashlight would illuminate areas up to its maximum range as long as there's empty space on the path
mhm
I never tested flashlights in game, but torch lighting can certainly illuminate "through" walls
In Starbound light propagation intentionally allows light through solid objects, but intensity is lost
ah, yeah.
I guess I never really accounted for intensity being lost
so you suggest they use raycasting?
For flash lights and spot lights they do
This is an alpha screenshot back from when torches used raycasting also
But now they and other light emissive tiles use the same type of light propagation as Terraria
hmm, strange idea to get that same effect.
How plausible would it be to have an invisible 3d pillar, and cast light that way?
for example where the blocks are surrounding the torch, a 3d example could very easily get that result.
One sec, I'll try to draw an example.
not necessarily, I could technically get a 2d effect in 3d no?
if it'd be easier that is.
There's various option I suppose
But none of them are precisely the flood fill light propagation you're looking for
3D is quite different in many ways
Starbound and Terraria allow light to spill through thin walls because even if that's not what would happen in reality or even in 3D it looks better
In 3D we would not see any light on the solid walls because they're occluded from the light
Yeah, I'm really not sure. It's just a shot in the dark honestly.
I'm quite desperate for a working and good looking system.
I had the initial idea of using a different shader on the "Background" tilemap, so it allows more light through, and have my "wall" tilemap absorb a significantly larger amount of light, but that seems to not be possible in unity.
No such thing as "absorption" in this context, unless you're talking about how the existing light is blended on the wall
Desperate enough to learn the tried and true "right" way to do what you're asking?
Yeah, sorry I do understand that now but just to get the general "pseudocode" approach I was going for.
Yeah, for sure!
But I don't think there is full documentation to the "right" way, because I am fairly certain they don't use light values for each individual tile as Terraria does. (Which is VERY slow famously)
that could also be true, again Starbound uses a fully custom engine whereas Terraria is run on a modified and old version of Godot.
To my knowledge.
So they could very possibly have a system in place to dissipate lights / fake light dissipation that I'd need to create myself, but that's just a theory I have.
The first version of Godot is newer than Terraria, which is built from what used to be XNA Framework
That's all irrelevant though
I believe they moved over to Godot in version 1.4
very true.
There's a whole lot contributing to Terraria's hiccups besides the choice of engine, as tehree's a whole lot it does
And you can make something optimized or unoptimized regardless of engine
Very true
It's a donation
Yeah, I am sort of inferring that they use the engine based on donations. But it could just be a publicity thing.
That makes no sense
They're not using FNA either
Anyway, where and how you store the lighting information is something to plan for
Which is not FNA
FNA is used for macos ports of the game
along with linux and their modding platform TModLoader
again we are getting pretty off topic which I apologize for
You probably don't want to store the lighting in tile data directly, to avoid having to load information unnecessarily
I was thinking that
Since lights often need to be calculated after the tiles anyway
my current approach is using render textures for lighting and using that to gather "light" values, and in separate shaders for both the background and "wall" tilemaps deal with those values differently.
But I really don't know if that's even a possibility using Render Textures as I've never tried in the past.
You'll want to read up on flood fill algorithms
Searching for "flood fill light propagation" may give you more relevant examples but note that there are many different ways to do that so some examples could turn to be totally irrelevant
would this algorithm only apply to the background, or would it also achieve that "fake dissipation" on the foreground?
It's just an algorithm, it can do that if you give it the means to do that
Hmm, alright!
Which would be to reduce the value to fill with when iterating solid tiles
You can do it simply in a simple C# script, especially when practicing, but I foresee you may need to optimize it heavily
Usually these kinds of operations will need to since you're reading and writing so many tiles / texture pixels
Yeah, I'm watching a few videos explaining it and it seems extremely heavy.
yeah, I am really trying to avoid tile-specific data and instead use a distance calculation if possible.
I really don't know how Unity renders 2D at all, so I am not sure if it is a separate action per pixel or if it somehow works as a whole.
Working with tiles is way faster if that's the case I would assume.
You can't get around the need to read and write tiles if you want tiles to block the light in any way
couldn't I just reference the tilemap which all the tiles are hosted on?
When I say that you don't want to store lighting in tile data, I just mean you have the data separately, like in a texture
The tilemap acts as a large "sprite" that works as a whole unit
ahh.
Whether you have an array of tiles (a tilemap) or an array of pixels (a texture) doesn't make a difference for this purpose
wouldn't referencing the entire tilemap using world position allow me to apply lighting on let's say an unlit shader dynamically?
similarly to how you'd light something like a 2d character?
Unity's 2D lighting is a compute shader that blends light textures (and distance functions for textureless lights) into one shared light texture that matches the display dimensions, it is then sampled by Lit Sprite shaders for blending
I see, is there a way to reference the "post blended" texture matching the display dimensions?
I don't see how sampling the tilemap alone would let you "apply lighting"
Yes
It will not help you with light propagation though
well if I sample both the light texture as-well as the tilemap texture separately in the same shader, and work with it that way?
I would handle light propagation separately on the "background" tilemap's shader referencing the same light texture
I am not expecting to get a perfect lighting system with one operation, but if I can just get the effect starbound has with just the foreground, that would be perfect.
This is a supported workflow for doing your own light blending
https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@14.0/manual/2d-customlit.html
Oh! This seems quite promising.
I doubt it
does this allow the referencing of the blended lighting?
That is what the article explains
a "2D Light Texture" is only usable in built-in to my knowledge.
a customlit shader graph "does not sample the Light Textures but it does have a Normal pass and a fallback Forward pass for use in non 2D Renderer."
This is all specific URP 2D
I went down this rabbithole once before, I think it is a documentation mistake unless I am missing something critical, I'll show an example.
This is when using URP 2D Renderer and with Custom Lit Sprite Graph?
I've used it before for custom 2D emissive blending
I was trying to use this before, and it was giving that error so I kind of assumed the documentation was wrong.
This sentence seems catastrophically worded but as far as I can tell it talks about using Custom Lit without the 2D Renderer
Without the 2D Renderer there is no 2D Light Texture to sample
hmm, should I try swapping the render pipeline to just universal 2D?
I believe I am using the 2D render pipeline
Let me double check haha.
There isn't really such a thing
That looks correct, assuming it's in use
should it state it is a "2D" Universal Render Pipeline Asset?
It is connected to one, so I'm guessing not. But it's good to be safe.
The Quality tab of project settings can have multiple quality levels with different URP Assets
an URP Asset can have an "URP Renderer" or an "URP 2D Renderer"
That does look like a potential issue
Shaders alone even with the light texture will still not let you do propagation though
I am glad that is the issue all along.
do you know where I can find example of what the texture would look like?
"look like"?
I don't think I can display it in the shader as it's not in runtime.
does it provide a black background with all visible scene lights?
Basically yes
I'm still confused on how this Light texture actually works.
that's amazing!
If you have a 2D light illuminating a pure white Lit Sprite, the lighting you see is the same as on the Light Texture
Yea
Okay, this is definitely the best news I've gotten the past 12 hours or so of working on this haha.
I really appreciate it, I wrote this off as being a documentation issue.
I don't know what the "Quality" render asset wasn't propagated but I'm glad I can use this now.
I'll try to get a couple ideas working with this and I'll send screenshots here if I get anything I was looking to get ahah.
Also, thank you very much for the insight. It will definitely help a ton!
I'm still quite convinced this will not do what you asked for, but I'd like to be proved wrong!
haha, honestly any "breakthrough" is kind of a blessing so I'm just glad I am able to try something new, even if it doesn't work out.