Better built-in lighting [example.]

Page: 1 2 3 4 5
Sep 28 2010, 10:58 pm
In response to Schnitzelnagler
How about different settings for shadow casting. Maybe have it so you set it separately for each individual object/mob or all of them as a whole.

One option that fixes the problem in Forum_account's example could be where Byond assumes the bottom most pixels in an object is the bottom(where the object touches the ground) and casts the shadows from there by skewing a shadow copy of the original object.

As shown in this example: http://i56.tinypic.com/2wn5ssg.png


Of course that would bring up other issues if you wanted to have your objects flying or jumping.. Also the shadow lacks depth like a 3D object would have. If there was a way to factor in its side views as well it might fix that.
Sep 29 2010, 4:11 am (Edited on Sep 29 2010, 4:54 am)
In response to Schnitzelnagler
BlackKingX wrote:
One option that fixes the problem in Forum_account's example could be where Byond assumes the bottom most pixels in an object is the bottom(where the object touches the ground) and casts the shadows from there by skewing a shadow copy of the original object.

As shown in this example: http://i56.tinypic.com/2wn5ssg.png

Not sure if Shadowcasting is the right word for this, because there happens to be a FoV algorithm (that I use in my lighting library for occlusion-related calculations) called Shadowcasting.


Anyway, the problem with this is that it's difficult to really capture the proper shape of the shadows if you simply have a shadow sprite to work with; This thing has to be rotated and distorted (trapezoidally), and it's not guaranteed to capture the proper shape of the shadow even if you do this, similarly to what Forum_Account's example shows. It gets even more complex if you want to capture the shadow's penumbra, umbra, and antumbra.

Additionally... What happens when you have multiple overlapping shadow sprites? If there is any ambient light (as in there is light reflecting off of the sky/local environment, a shadow will only get so dark. If you're familiar with it, think of ambient occlusion), the lighting solution becomes that much more complicated.




I propose that if there are going to be shadows, each graphic would need a corresponding opacity map.
like http://i56.tinypic.com/29pojv6.png
Sep 29 2010, 4:36 am
In response to Schnitzelnagler
Not all modern PC games have shadows. Of those that do, not all have proper shadows (penumbra and all). I'm not sure why we're even talking about how to implement shadows in BYOND that rival modern commercial PC games when BYOND has so many other obvious graphical limitations.

Even with dynamic lighting and shadows BYOND is still in the stone age in terms of graphics. It would be a better use of time to add dynamic lighting (without shadows) and then work on other graphical improvements. Shadows require too much work.
Sep 29 2010, 7:58 am
In response to Schnitzelnagler
Lummox JR, you mention a couple of ideas and problems. Could you elaborate on your ideas in detail, so that we know what you were looking for and where exactly you ran into trouble?
Maybe even a rough estimate on how much time and effort you'd be willing to invest on the project and if you'd be using OpenGL or DirectX, maybe even which sort of algorithm you're looking for (are you considering somewhat slow raytracing)?

As for how to determine shadow-casting, would you consider an opacity map like Darke suggested too much trouble?
Sep 29 2010, 8:12 am
In response to Schnitzelnagler
Schnitzelnagler wrote:
As for how to determine shadow-casting, would you consider an opacity map like Darke suggested too much trouble?

A 2D opacity map is not sufficient for creating shadows. Imagine a chain link fence. What would its shadow look like? What would the opacity map look like?

Objects have height too. Even though we're using a 2D top-down view we'd need to consider lighting as 3D to get proper shadows.
Sep 29 2010, 10:30 am
In response to Schnitzelnagler
At this point I've conceded that this is 2D and that perfect shadows are out of the question. That's why I suggested an opacity map, which would be one hell of an improvement over what's available right now.

I also really like the lighting solution that Snagler just linked to. Sure, it assumes that objects to be lit are cylindrical, but it looks good and works well.
Sep 29 2010, 11:12 am
In response to Schnitzelnagler
Here's another reason why we shouldn't worry too much about shadows:

If BYOND will ever have 3D graphics, here are two paths BYOND could take:

Present  -->  2D w/ lighting
               and shadows
   |
   |                |
   V                V

Full 3D  -->  Full 3D w/ lighting
               and shadows


It's a million times easier to make the shift to full 3D then add lighting and shadows than it would be to add lighting and shadows to 2D then move to full 3D.
Sep 29 2010, 11:14 am (Edited on Sep 29 2010, 1:08 pm)
In response to Schnitzelnagler
A. BYOND will never be 3D
B. Its a million times easier to setup lighting/shadows, especially basic ones, than it is to do 3D
EDIT: And as for a "2D opacity map" for a chain link fence, there would need to be various shadow options. The image he originally posted showed both a basic one and an "opacity map", there could also be one for a drop/cast shadow, which does something like what BlackKingX posted with the robot - a cast off version of the same icon as the fence.
Sep 29 2010, 1:52 pm
In response to Schnitzelnagler
Falacy wrote:
A. BYOND will never be 3D

If the staff spends massive amounts of time implementing shadows in 2D then there's a good chance they'll never get to implement full 3D graphics. My point is that implementing 3D graphics gives you a lot of things for free (or close to it), shadows being one of the free things. Implementing shadows in 2D is a huge hassle and doesn't give you anything else.

B. Its a million times easier to setup lighting/shadows, especially basic ones, than it is to do 3D
EDIT: And as for a "2D opacity map" for a chain link fence, there would need to be various shadow options. The image he originally posted showed both a basic one and an "opacity map", there could also be one for a drop/cast shadow, which does something like what BlackKingX posted with the robot - a cast off version of the same icon as the fence.

I don't think you understand how opacity maps would work. An opacity map would tell you which parts of an icon were opaque so that opacity (and therefore shadows) could be handled per pixel instead of per tile. Here is an example of the problem it fixes.

The opacity map of the mob in the earlier example wouldn't be handled how you'd hope because BYOND doesn't understand that the mob is standing up. It would actually look like this: http://files.byondhome.com/Forumaccount/ opacity-map-problem.png
Sep 29 2010, 2:49 pm
In response to Schnitzelnagler
Forum_account wrote:
The opacity map of the mob in the earlier example wouldn't be handled how you'd hope because BYOND doesn't understand that the mob is standing up. It would actually look like this: http://files.byondhome.com/Forumaccount/ opacity-map-problem.png

Well, that's why I said:
"could be where Byond assumes the bottom most pixels in an object is the bottom(where the object touches the ground) and casts the shadows from there"

I pretty much meant Byond would have to assume all objects/mobs are standing up, and turfs aren't standing up.


Maybe a cast_shadow = 0 or cast_shadow = 1 var for each object/mob.
Sep 29 2010, 6:27 pm (Edited on Sep 29 2010, 6:40 pm)
In response to Schnitzelnagler
BlackKingX wrote:
Well, that's why I said:
"could be where Byond assumes the bottom most pixels in an object is the bottom(where the object touches the ground) and casts the shadows from there"

But that's what the whole point of the opacity map is... To tell BYOND which pixels are opaque.
The "bottom area" of a graphic doesn't necessarily reflect the shape or size of shadows casted by the object.

Come on, look at the example I provided...

http://i56.tinypic.com/29pojv6.png
Sep 29 2010, 7:40 pm
In response to Schnitzelnagler
That example still looks a bit silly because the shadows have infinite length.

The biggest problem with the traditional 2D top-down view is that you can use it to represent different perspectives. Consider these two screenshots:

http://www.coolrom.com/screenshots/nes/ Dragon%20Warrior%204%20(2).gif
http://pocketmedia.ign.com/media/previews/image/gta/ gta_3_640w.jpg

The first shows the front and top of walls while the second is a pure top-down view. How could a lighting model accommodate both? Using an isometric view enforces a particular perspective and it would better accommodate shadows (but it's still a waste of time).

Perspective issues aside, there are many ways you could handle it but very few of these implementations would be general purpose enough to satisfy most users. This is similar to the reason why BYOND doesn't have built-in support for autojoining tiles. There are many different ways it could work, BYOND can't implement them all. The difference here is that we're talking about client-side stuff, so the "implement it yourself" solution doesn't really apply.

Dynamic lighting without shadows is feasible, but still much more complicated than most feature requests. I'm not sure why people are so determined to make the issue more complicated by including shadows.
Sep 29 2010, 8:12 pm
In response to Schnitzelnagler
Lighting without shadows looks silly.

You'd have lights bleeding through solid walls. Night time in any city sort of environment would look silly. Nothing would look like it has depth, and ultimately, the lack of shadows would probably detract from the level-design of the game.


http://i52.tinypic.com/wtysug.png

:/

Sep 29 2010, 8:35 pm
In response to Schnitzelnagler
 
                            Colored Dynamic Lighting

                       Without Shadows        With Shadows

 Better than what           Yes                   Yes
BYOND currently has

    Feasible              Possibly                No


This is not about making the best lighting model possible, it's about adding a glitzy feature. Even without shadows lighting effects would be useful.
Sep 29 2010, 8:39 pm
In response to Schnitzelnagler
I think it's entirely feasible to have shadows and colored lighting.

Colored lighting, instead of a single luminosity value per cell it's three luminosity values for each channel per cell. Big deal.

Shadows via Shadowcasting isn't difficult at all. Even if it's per-pixel cells and opacity maps, like I had suggested. The Shadowcasting algorithm (no penumbra/antumbra; not necessary anyway) is damned simple and fast.
Sep 29 2010, 8:49 pm
In response to Schnitzelnagler
The method you're suggesting has very limited applications. You wouldn't be able to illuminate a scene like this because of how the walls are drawn.

Not many games use a purely top-down view and not all of those games would benefit from having shadows. This is what makes it be infeasible: You're asking for the BYOND staff to do a lot of work and very few games will ever benefit from it.
Sep 29 2010, 8:54 pm
In response to Schnitzelnagler
Forum_account wrote:
The method you're suggesting has very limited applications. You wouldn't be able to illuminate a scene like this because of how the walls are drawn.

Not many games use a purely top-down view and not all of those games would benefit from having shadows. This is what makes it be infeasible: You're asking for the BYOND staff to do a lot of work and very few games will ever benefit from it.


You can illuminate a scene like that with my method.
Sep 29 2010, 9:15 pm
In response to Schnitzelnagler
What would the opacity map look like and what would the resulting shadows be?

The problem is the wall tiles where the top half is the top of the wall and the bottom half is the side of the wall. For any opacity map there will be situations where the shadows don't look right.
Sep 30 2010, 12:18 am (Edited on Sep 30 2010, 12:24 am)
In response to Schnitzelnagler
Forum_account wrote:
My point is that implementing 3D graphics gives you a lot of things for free (or close to it), shadows being one of the free things.

3D doesn't guarantee dynamic lighting or shadows, both of which are rather new additions to gaming, and require somewhat high end systems/engines to even run. Most PS2 game don't even offer them. And BYOND will never make the jump to 3D, so its a somewhat moot point anyway.
Several people have built various lighting systems on/for BYOND, only one has ever accomplished anything even close to 3D, and that was just infantile ray casting.

I don't think you understand how opacity maps would work. An opacity map would tell you which parts of an icon were opaque so that opacity (and therefore shadows) could be handled per pixel instead of per tile. Here is an example of the problem it fixes.

I was suggesting 3 entirely separate methods of casting shadow. In this case, one based on the exact icon, modifying it, and then casting it - which would result in something like the original robot posted. Completely unrelated to opacity maps. Also, though I'm not exactly versed in 2D opacity maps, I'm pretty sure that example you posted wouldn't at all yield results like you displayed.

A search for 2D Lighting on youtube turns up this, though I'm pretty sure that's built in a 3D environment.
Sep 30 2010, 5:47 am
In response to Schnitzelnagler
I don't understand the emphasis on doing lighting without shadows, because the concept makes little to no sense. Without any concept of unlit areas, lighting boils down to just plopping down areas of brightness on the map and darkening the rest. I don't see that being very useful for most games. It might be helpful for some, but not many.

With unlit areas involved I think we could come up with something much more useful, but to be reasonable I think we'd have to always assume every opaque pixel corresponded to a full-height column. Dealing with fence shadows just wouldn't be worth messing with, and most games wouldn't want or need that anyway.

Still of course either way leaves open a big question as to how to handle isometric.
Page: 1 2 3 4 5