Shadows/Lights example?

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
User avatar
bbmario
DCEmu Freak
DCEmu Freak
Posts: 65
Joined: Wed Feb 05, 2014 5:58 am
Has liked: 0
Been liked: 0

Shadows/Lights example?

Post by bbmario » Fri May 19, 2017 3:37 pm

Is there a shadow mapping example in KOS or from any opensource project in the community? I'm having a hard time trying to render lights in my scenes. I'm not looking for fancy stuff, just something like this:

http://www.opengl-tutorial.org/intermed ... w-mapping/

Or:

http://www.3dcpptutorials.sk/index.php?id=27
User avatar
bogglez
Moderator
Moderator
Posts: 576
Joined: Sun Apr 20, 2014 9:45 am
Has liked: 0
Been liked: 0

Re: Shadows/Lights example?

Post by bogglez » Sat May 20, 2017 7:18 pm

Are you working with the PVR API?

shadow mapping can't be used effectively on the PVR graphics chip, because it doesn't have shader support.
What you need to do in shadow mapping is render from a light's viewpoint to a depth texture (which the DC already can't do), then use this texture from your camera's perspective and reconstruct position information from the depth information plus transformation matrix of the light. This is a complex operation that takes shader support as it's not covered by the generic fixed pipeline features etc of the PVR.

What you can use is shadow volumes that trace the outline of an object and extrapolate it away from the light to have a volume of shadow. You can then use this to test whether objects are in this volume and light them differently.

It also turns out that the PVR has support for this, I think it was polygon volumes? Probably a little different. With those you draw a 3d object and everything inside of it will have it's vertex attributes changed (e.g. gray color). There's also a limited version of this called cheap shadows. There should be an example in the examples PVR folder.
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
park
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Tue Jun 24, 2008 10:46 am
Has liked: 0
Been liked: 0

Re: Shadows/Lights example?

Post by park » Sat May 27, 2017 6:45 pm

bogglez wrote:Are you working with the PVR API?

shadow mapping can't be used effectively on the PVR graphics chip, because it doesn't have shader support.
What you need to do in shadow mapping is render from a light's viewpoint to a depth texture (which the DC already can't do), then use this texture from your camera's perspective and reconstruct position information from the depth information plus transformation matrix of the light. This is a complex operation that takes shader support as it's not covered by the generic fixed pipeline features etc of the PVR.
Iam not a programmer( I just read a lot of stuff here to kill time.) but I think some dreamcast games have done those texture based shadows in the past, not many though.One that comes to mind is matt hoffmans bmx. Another I remember the dev for tony hawk pro skater talking about the dreamcast version in a gamasutra post mortem interview doing something like what you described but more cut down and basic.For both games the shadows arent polygon/silhouette based. Heres a excerpt of the interview:
We appropriated that code, made it work on the Dreamcast, but discovered that it looked terrible due to Z-buffer poke-through. We then switched to rendering to a texture and then projecting that texture into the world. We tried to find a good way to render that texture dynamically using light sources and projecting it on the nearest surfaces. And after a lot of passable results Wade and Sean came up with the idea of rendering everything near the skater in two passes: one for the geometry, and another to project the shadow texture on the geometry
Heres a shot of matt hoffmans pro bmx which seems to be more advanced:

Image Image

So maybe with a lot of work it can take a similar approach/result?
User avatar
GyroVorbis
Elysian Shadows Developer
Elysian Shadows Developer
Posts: 1808
Joined: Mon Mar 22, 2004 4:55 pm
Location: #%^&*!!!11one Super Sonic
Has liked: 0
Been liked: 0
Contact:

Re: Shadows/Lights example?

Post by GyroVorbis » Sun May 28, 2017 1:50 am

Iiiiiinteresting... They are probably doing a separate render-to-texture and are just drawing the biker's untextured polygons onto a texture as the "shadow map" then are rendering that texture to the scene to imitate shadow mapping... I need to check that game out and look into this. It's pretty clever, but surely it has some pretty serious limitations... like the amount of geometry that can cast shadows, where they can be cast, static light directions, etc...

edit: Wait, in that second picture, is he casting shadows from two different directions because there are two different light sources in the scene?! Because that's pretty fucking advanced then. :o

You know, I was always wondering what the performance of render-to-texture even was on the DC, and if it was something that could realistically even happen at run-time... But Jesus, I guess it is.
bogglez wrote:It also turns out that the PVR has support for this, I think it was polygon volumes?
Modifier volumes.

I just know the name, and basic theory, though. Never actually used them, so don't look at me. :lol:

But yeah, OP, shadow mapping is not going to happen on the Dreamcast. That whole generation of DC, Gamecube, PS2, and Xbox did not generally use shadow-mapping. I do believe that a few of them may have actually supported it in hardware (GC and Xbox if so), but I believe most games around this era used projection-based shadow mapping as Bogglez is suggesting. Like what Doom 3 did on the original Xbox. Carmack has some papers out on this, but it's not very simple.

I think you are better off looking into the modifier volume approach. It may be more advanced, but it's the "preferred" way for the DC's hardware.

EDIT: Damn, park, I know a lot of non-programmer "graphics enthusiasts" who love to weigh in on this kind of stuff, and they usually have no idea what the fuck they're talking about. What you just posted was genuinely awesome and helpful. Good job on seriously knowing what the fuck you're talking about, even though you aren't a programmer. I hope you don't ever hesitate to weigh in on things like this. This is something that should TOTALLY be looked into. I am going to have to look into implementing shadows in the DC build of ES, and I hadn't really considered using render-to-texture. :o
Elysian Shadows - "Next-Gen" 2D/3D RPG coming to Sega Dreamcast, Steam, OUYA, and Smartphones
Image
http://www.elysianshadows.com
User avatar
bbmario
DCEmu Freak
DCEmu Freak
Posts: 65
Joined: Wed Feb 05, 2014 5:58 am
Has liked: 0
Been liked: 0

Re: Shadows/Lights example?

Post by bbmario » Sat Jun 03, 2017 9:42 pm

Thank you for the info! :grin:
111
DCEmu Junior
DCEmu Junior
Posts: 37
Joined: Thu Jul 07, 2016 7:11 pm
Has liked: 0
Been liked: 0

Re: Shadows/Lights example?

Post by 111 » Thu Jun 15, 2017 7:08 pm

Shadows/Lights example?
Image
("shadow" is a modifier volume in "cheap shadow" mode)

I'll probably write some PVR tutorials eventually (if nobody else will), once I finish my game (not gonna happen soon)
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 115
Joined: Sun Nov 01, 2015 8:25 pm
Has liked: 0
Been liked: 0

Re: Shadows/Lights example?

Post by lerabot » Sat Jun 17, 2017 10:26 am

Loooking goood!
park
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Tue Jun 24, 2008 10:46 am
Has liked: 0
Been liked: 0

Re: Shadows/Lights example?

Post by park » Sun Jun 03, 2018 10:04 pm

Seems Matt hoffman bmx did indeed use shadow mapping for the bikers shadow. I managed to extract that texture from the emulator. Seems to be a strange resolution of 512x256. Like I said Iam not a programmer but none the less tried to find an explanation and it seems because consoles have fast access to vram they can do things that would require shaders on pc.I also saw a tutorial stating it can be done without shaders on opengl so I guess the dreamcast could do it too.

Image
kazade
Insane DCEmu
Insane DCEmu
Posts: 120
Joined: Tue May 02, 2017 3:11 pm
Has liked: 0
Been liked: 0

Re: Shadows/Lights example?

Post by kazade » Mon Jun 04, 2018 1:25 am

Presumably they simply render the player model once per light to a texture then render an additional pass of the scene with that texture bound.

The one thing that puzzles me though is the resolution. The KOS docs say this: "This function currently only supports outputting at the same size as the actual screen."

It then goes on to say that the destination texture must be the next power of two size up. But presumably this game supports a higher resolution than 512x256. So is KOS more limited than the official SDK here?
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5372
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 0
Been liked: 0
Contact:

Re: Shadows/Lights example?

Post by BlueCrab » Mon Jun 04, 2018 11:20 am

The render-to-texture stuff is sorta unfinished. There are some loose ends that still need to be tied up at some point.

When I added it to KOS, I really had very little idea what I was doing in messing with the PVR stuff -- I was basically just trying to restore what limited render-to-texture functionality that KOS had from a long time ago (before the major rewrite of the PVR code that took place around KOS 1.1.8 or so?).
park
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Tue Jun 24, 2008 10:46 am
Has liked: 0
Been liked: 0

Re: Shadows/Lights example?

Post by park » Mon Jun 04, 2018 4:03 pm

kazade wrote:
Mon Jun 04, 2018 1:25 am
Presumably they simply render the player model once per light to a texture then render an additional pass of the scene with that texture bound.
If it is only rendered once woudnt it be static? In the game it seems to interact with the light source and moves to match the player. Not to mention it seems to change opacity.Also if its just the player mesh rendered to a texture how does it seem to react to distance in lighting? Iam not trying to hassle just very interested in understanding how its done. Also makes me wonder
if more games would have used these type of shadows if the dreamcast had lasted. The only other game that uses this style it urban chaos and it tops out I think on 4 shadows.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5372
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 0
Been liked: 0
Contact:

Re: Shadows/Lights example?

Post by BlueCrab » Mon Jun 04, 2018 7:54 pm

I think that what kazade meant is that it is rendered once per frame, per light -- which obviously gets quite expensive as you have more models with shadows and more light sources (which is probably also what Urban Chaos did, based on your description there).
kazade
Insane DCEmu
Insane DCEmu
Posts: 120
Joined: Tue May 02, 2017 3:11 pm
Has liked: 0
Been liked: 0

Re: Shadows/Lights example?

Post by kazade » Tue Jun 05, 2018 10:03 am

Yeah that's what I meant :)

BlueCrab, is it theoretically possible to render to any power-of-two texture size with the PVR (if KOS was extended to support it)? Or is it a limitation of the hardware that it must render at the screen resolution (to a texture at the next power-of-two)
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5372
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 0
Been liked: 0
Contact:

Re: Shadows/Lights example?

Post by BlueCrab » Tue Jun 05, 2018 9:17 pm

As far as I know, you could render at just about any size you want (down to a one-tile sized target, probably), presuming you set up the PVR's registers to do so. Of course, I've never tested that theory at all.

Screen sized output is obviously the easiest thing to do, as it doesn't really involve messing with anything but the render target and stride registers, if I recall correctly.
park
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Tue Jun 24, 2008 10:46 am
Has liked: 0
Been liked: 0

Re: Shadows/Lights example?

Post by park » Wed Jun 12, 2019 4:31 pm

GyroVorbis wrote:
Sun May 28, 2017 1:50 am
Iiiiiinteresting... They are probably doing a separate render-to-texture and are just drawing the biker's untextured polygons onto a texture as the "shadow map" then are rendering that texture to the scene to imitate shadow mapping... I need to check that game out and look into this. It's pretty clever, but surely it has some pretty serious limitations... like the amount of geometry that can cast shadows, where they can be cast, static light directions, etc...

You know, I was always wondering what the performance of render-to-texture even was on the DC, and if it was something that could realistically even happen at run-time... But Jesus, I guess it is.
Hey heres a heads up someone released dreamcast sdk examples @ dreamt-talk. Thats not the point though, the point was that the examples contained two methods of how to achieve real time shadow mapping that I thought you would be interested. The demos have on screen in depth explanations I thought you would be interested. SAw them and immediately thought of this thread. Just in case you were still interested in this topic I took screen shots.

Edit: they also released urban chaos source code with out game assets on git hub and it contains dreamcast source code/windows ce. Some of the source files go into detail how the shadow mapping for that game was done.

example: The shadow-mapper.
// First initialise the shadow mapper by giving it the direction of
// the parallel light you want to shadow and the bitmap the shadow
// map is going to be drawn into.
Projects the last shadow map created onto a poly in world-space. The poly
// should be given in clockwise order. This function returns NULL if the poly
// is facing away from the light, or if the poly is on the 'wrong side' of
// the shadow map. The polygon linked list is valid until the next call
// to the function.

First method/standard method :
Image

Second method/( iam not a programmer so I am just guess that it means the quad is disorted and only looks correct without perspective correction):
Image
Post Reply