Open datahead8888 opened 10 years ago
Quintus
commented
10 years ago I remember having seen something with 2D shading on HackerNews a while ago. I can’t find it right now, but it may be useful.
There are some nice possibilities with this. One could have completely dark levels only with a small light bulb around Maryo. Plays in nice for labyrinth and cave levels.
Vale, Quintus
datahead8888
commented
10 years ago Yes, being able to have lighting in dark levels offers extensive level design possibilities.
I think the lighting in the outside levels would offer some very interesting visual effects, too. A sun that can be positioned would be a good precursor for a night and day system.
datahead8888
commented
10 years ago @Luiji, @Quintus - So this is the inevitable question that I'm surprised no one brought up yet. Do we want lighting in outside levels at all or just in dark levels? If it's only in dark levels, is it possible to pull it off with textures or some other hack and not actually implement proper lighting logic? A simpler implementation would reduce the complexity of coding this and prevent all the art assets from having to have shading removed. On the other hand, a proper lighting system will look much, much better and be fully configurable.
I still like the idea of a proper lighting system but figured it's worth asking given that everyone is considering using Allegro rather than OpenGL for most things.
Quintus
commented
10 years ago I think we should aim for a proper lighting system. For outside levels, there surely is a difference in light between a level in glazing sun and one in permanent rain.
I still like the idea of a proper lighting system but figured it's worth asking given that everyone is considering using Allegro rather than OpenGL for most things.
Where appropriate, we can of course continue to use OpenGL directly. Just not for all the things it is used for now. Place a prominent comment on the code why doing it another way is not possible, and just go on.
Again, this is a big issue we can’t resolve immediately. First we will complete issue #55 when we come to a proper conclusion in #105. Prior to this we shouldn’t too much worry about how to implement the lighting system -- until we have decided on which renderer to use, the implementation would vary anyway.
Vale, Quintus
datahead8888
commented
10 years ago Again, this is a big issue we can’t resolve immediately. First we will complete issue #55 when we come to a proper conclusion in #105. Prior to this we shouldn’t too much worry about how to implement the lighting system -- until we have decided on which renderer to use, the implementation would vary anyway.Yes, this was an auxiliary question that plays into issue #105 since lighting is the most complex GLSL task we know of right now. I would like to find an example that uses Allegro combined with GLSL shading language and see exactly how much set up Allegro saves when we're forced to go to GLSL anyways for something like lighting (this may not be the only thing we go to GLSL for though). Taking a look at an example would give a lot of insight before making a final decision.
Luiji
commented
10 years ago @datahead8888 I'm a bit tired so I couldn't find example code but here's a link to the API reference and to someone having successfully used it (though they don't post the code :(). (I'm sure there's example code somewhere, probably in the Allegro distribution now).
Quintus
commented
10 years ago I don’t know where you all got the opinion that Allegro is to be used, but I will follow you on this matter. Just one thing: Allegro’s website states this:
Allegro only supports 2D graphics primitives natively, but it is perfectly reasonable to use Allegro alongside a 3D API (e.g. OpenGL, Direct3D, and higher level libraries)
I just want to be sure I didn’t misunderstand this. @Luiji, does Allegro act as an abstraction layer on OpenGL or do we still have to write this all ourselves? If so, I don’t really see the point of switching...
Vale, Quintus
Luiji
commented
10 years ago I just want to be sure I didn’t misunderstand this. @Luiji, does Allegro act as an abstraction layer on OpenGL or do we still have to write this all ourselves? If so, I don’t really see the point of switching...
It implements 2-D primitives in the form of abstract API. What they're saying is that if you want to use 3-D graphics APIs, Allegro permits direct access to the low-level API if you so desire. Technically, you can run an engine like Ogre on top of Allegro, even.
Allegro provides image and sound I/O, graphics rendering abstractions (including rendering images, drawing geometric primitives, etc.), a platform-independent file API that can optionally (but not necessarily) use PhysicsFS as a back-end, memory files, native dialogs (e.g. message box and open file), and even video streaming.
Though this is a lot of functionality, remember that Allegro is modular and that we only have to import the functions that we want, and that the general distribution size is still pretty small either way. We would likely only use the core library, image/sound codecs module, and font module. (We likely wouldn't even use the "primitives" module, which adds things like drawing polygons when all we really need is the ability to draw images as in the core function set.)
datahead8888
commented
10 years ago I don’t know where you all got the opinion that Allegro is to be usedYes, I should have said Allegro / SFML in my post, but we really shouldn't even assume that we're getting rid of most OpenGL code until Issue #105 has been closed and all final decisions are made.
I was just saying I'd like to see an example of an Allegro/SFML program that interfaces with GLSL to do something those API's don't natively support. My main question was how much VBO set up code, GLSL compilation code, etc, these API's do for you when you have to use GLSL. I'm also probably going to post a question on gamedev.net relating to GLSL in general.
Luiji
commented
10 years ago I'm also probably going to post a question on gamedev.net relating to GLSL in general.
I would recommend posting Allegro-related questions at allegro.cc, too.
Bugsbane
commented
10 years ago I would be very careful with this. Yes, dynamic shading would give some very cool possibilities, but most shading on the current art assets come from the artists having a knowledge of the three dimensional shapes that the 2d picture is representing, and creating shading accordingly. Without this knowledge, and without building all of the current 2d assets via 3d modelling, I don't see any way that a coded shading solution can actually mimic anything but the most basic shading that is currently done by hand, actually damaging the look of the game. If anyone has seen an example of the contrary, I would be fascinated to see it, but currently I don't see any technical way, even theoretically possible, for this to match a hand shaded approach.
I would suggest that we'd be better off keeping the current shading on the current art assets, and basically using lighting techniques not for shading details on current sprites, but for dynamic, lighting effects beyond general shading, such as shadows, general brightness, flares, halo's, particle effects etc.
Of course, I'd love to see a technical proof of concept, but lets not start ripping up our current art assets before seeing one. :)
datahead8888
commented
10 years ago Without this knowledge, and without building all of the current 2d assets via 3d modelling, I don't see any way that a coded shading solution can actually mimic anything but the most basic shading that is currently done by hand, actually damaging the look of the game.
No, a 2D lighting system will not be able to simulate 3D lighting effects accurately. A 3D lighting system, as you said, is impossible in this game. I would be curious to see what happens if we try combining the 2D lighting system as described above with existing 3D shading in sprites (or with modified shading on some sprites trying to compensate for the eventual 2D lighting addition). I realize the two systems will still not truly be in sync, but I'd be interested to see if we can find a way to make it look passable to the viewer.
It won't be possible for the lighting system to control visibility in dark levels if it doesn't have the ability to make entire sprites go black. I understand your concerns, @Bugsbane, but I would like to wait before shooting this down. We could also post on some graphics coding forums and see if they can offer suggestions.
but lets not start ripping up our current art assets before seeing one.
Heavens, no . . . There would be no need to start changing art assets until we started this task. We would then do it on select art assets and in a different branch in source control so that only people working with it see the changes. It would be experimental for a while.
basically using lighting techniques not for shading details on current sprites, but for dynamic, lighting effects beyond general shading, such as shadows, general brightness, flares, halo's, particle effects etc.
I'm not sure shadows would be easy to do because you would probably have to find the edges of objects on which to cast them. For complex objects or objects that should be occluding one another in 2D, this will probably have some hairy issues. I would be interested in maybe playing around with it, though, after we tackle the main lighting questions. There actually are a number of 2D lighting systems people have coded in GLSL (Open GL Shading Language) on the web, and some of them support shadows. These would be worth checking out for reference.
This task is also likely to come under fire due to the OpenGL compatibility issues we've been discussing in #105. I never said this was an easy task -- sometimes the most interesting things are difficult. I'd at least like to put something I learned at the university to use in TSC :P
Bugsbane
commented
10 years ago I'm totally open to looking at some kind of experimental demo before ruling this out. In fact, I'd be really interested to see it myself. Have you seen any examples you could point to for reference?
I'd just think long and hard about the challenges involved once we remove all shading from the current art assets to replace them with algorithm-only solutions. There are many options for doing things like having sprites to be darker in unlit areas without modifying the original assets. Just using the current assets as textures on 3d planes would accomplish this (including making entire sprites go black, if they're in unlit areas).
The closest way I can think of, of actually making this work, would be if each frame of each asset combined something like a normal map or bump map to give the renderer some kind of idea about the depths and shapes it was dealing with. These are still very crude though compared to hand shading.
datahead8888
commented
10 years ago Have you seen any examples you could point to for reference?
I'll have to do another google search when there's some time. I think some of the 2D lighting systems I found had screenshots, but I will have to check again. They may not have been built with a platformer in mind, of course.
I'd just think long and hard about the challenges involved once we remove all shading from the current art assets to replace them with algorithm-only solutions.
We can also try taking sprites with some sort of 3D shading in them and running them through the 2D lighting system. This task will have a LOT to do with experimentation and research.
Just using the current assets as textures on 3d planes would accomplish this (including making entire sprites go black, if they're in unlit areas).
If we go this route, it may affect our decision as to what API such as Allegro / SFML / SDL 2 to use for rendering. These are 2D rendering API's, and I'm not sure if they will let us set 3D z coordinates easily. Our old OpenGL code is deprecated (at least on most systems), and we likely are going to have to replace all of it in some way. Issue #105 is very technical but discusses these issues.
The closest way I can think of, of actually making this work, would be if each frame of each asset combined something like a normal map or bump map to give the renderer some kind of idea about the depths and shapes it was dealing with.
I didn't even think of that. I'd have to review these more, since I was a little bit fuzzy on them the last time I studied them or have otherwise forgotten the details. They certainly can be implemented alongside a lighting system in GLSL, though.
Bugsbane
commented
10 years ago I think some of the 2D lighting systems I found had screenshots"
These would be interesting to see.
They may not have been built with a platformer in mind, of course."
Sure.
We can also try taking sprites with some sort of 3D shading in them and running them through the 2D lighting system. This task will have a LOT to do with experimentation and research."
Sure. Sounds worth investigating though.
Re: my bump / normal map suggestion - If we were to experiment with this, the average artist would be much more likely to be able to wrap their head around use of a bump map, than a normal map. Conceptually, bump maps are a lot easier for 2d artists to understand.
datahead8888
commented
9 years ago exploit3r from the #sfgui chatroom has been working on a 2D lighting implementation already: https://github.com/eXpl0it3r/LTBL ---This one says it uses SFML.
He also suggested looking at: http://2dee-art.blogspot.ch/p/sprite-dlight.html http://www.snakehillgames.com/spritelamp/
He also said that the GLSL (OpenGL shading language) needed for lighting systems should be able to integrate with SFML.
This is something that's been discussed some in the forums and that I've thrown out some ideas on...we need to get a task by which to track it.
The idea is to create a lighting system in SMC. Two major possibilities are:
This is something that can be done at the fragment level in GLSL (Open GL shading language). I've had some experience with the old OpenGL lighting systems and with doing it in 3D in the newer GLSL, but concepts for a 3D lighting system may not all directly apply to a 2D lighting system. It should be possible, though, to develop a lighting system that works well in 2D (at least with a subset of the 3D features). We will need to consider performance on older graphics cards; if this is a concern multiple lighting configurations or display options may be an option.
It the decision is made to use an existing renderer for most/all of our rendering rather than writing OpenGL code itself, I think that renderer should have support for lighting systems or some sort of support for defining them. Thus this directly plays into the decisions to be made for Issue #55. Likewise, once we start discussing Bullet/Custom Physics and OpenGL versus renderers on an official SMC forum entry, lighting will be a part of that discussion.
Shadows are NOT planned for this task. That would be a completely separate task. It may be worth considering how we could architect lighting so that adding shadows later (if desired) will not require too much rework.
Forum Discussion: