Working with Lighting and Shadows on the DC

[PH3NOM]

Since KGL is completely absent from any lighting code, I decided to take a swing at it.

I have made an implementation of Dynamic Vertex Lighting based on some resources provided by nVidia, although it applies to GL.
http://http.developer.nvidia.com/CgTuto ... ter05.html
To accelerate things, I have used the SH4s fast math functions when possible.

Here is a basic scene I wrote for testing; some cylindrical and rectangular columns.

In this image, the scene is lit with one diffuse light, and a low level of ambient light:


This image is the same scene with the same diffuse light, except now the specular term is also being calculated:


Same scene, now with a high level of ambient light:


So, I have the basic lighting model up and running, but now it leaves the desire for shadows to interact with the lighting.

My question is, how do we use the PVR to achieve shadows?
I know there is a modifier volume that can be set to "PVR_MODIFIER_CHEAP_SHADOW" but I really dont know how to use modifier volumes.
Any info appreciated!

BTW this guy seems to have achieved some very nice effects with PVR shadows:
http://yam.20to4.net/dreamcast/index_old.html

Small update, added attenuation calculations, and posted a short clip on youtube:

[Christuserloeser]

Impressive! and yeah, I remember that yam.20to4.net website. Nice to see he updated it as recent as 2010

[RyoDC]

>My question is, how do we use the PVR to achieve shadows?

Though I really not that competent on the topic (I don't know exactly is there really exist some hardware on pvr dreamcast chip to deal with shadows), I think there's nothing much can be done.
Because as all we know, pvr only does culling, sorting, and rasterization of polygons, it doesn't do any geometry transformations, so I don't think much can be done on pvr in sense of shadows.
I mean, the problem is, Pvr don't know anything about your 3d world, it receives just a screen coordinates of polygons and then just renders them, using texture information and depth buffer (overlap test).
But what you can do on sh4 is to calculate the projection of an object to the surface, from the point of light source (or multiple light sources, if you want to count them all), and then use that geometry information (triangle strips) and pass it to pvr directly, to blend it with targeted surface color pixels, and to receive a shadow. After that you can also add some program code to blur shadows edge or something like that.

[PH3NOM]

>My question is, how do we use the PVR to achieve shadows?

Though I really not that competent on the topic (I don't know exactly is there really exist some hardware on pvr dreamcast chip to deal with shadows), I think there's nothing much can be done.
Because as all we know, pvr only does culling, sorting, and rasterization of polygons, it doesn't do any geometry transformations, so I don't think much can be done on pvr in sense of shadows.
I mean, the problem is, Pvr don't know anything about your 3d world, it receives just a screen coordinates of polygons and then just renders them, using texture information and depth buffer (overlap test).

Although not quite a "stencil" buffer, the PVR supports modifier volumes that can determine per-pixel weather or not a point is inside a defined volume.

Check that page I linked to in my first post.

Also, this is a post I just found regarding MDK 2 on the Dreamcast:

The Dreamcast shadows aren't stencil shadows. They are a PowerVR2 exclusive feature called "modifier volumes", which are very different:

A stencil shadow volume is drawn after the scene. It interacts with the Z-buffer to "mark" pixels which are inside the volume in the stencil buffer. Then, the render can do blending only against the marked (or unmarked) pixels.

The modifier volume relied on the PowerVR2 unique tiled deferred rendering. It didn't use a z-buffer nor stencil buffer: it could determine, per pixel, if a polygon was inside or outside a modifier volume (via ray-triangle tests) and use a different material if so. This "material" could be darker, brighter or even use a different texture (but this was rarely used).

http://www.neogaf.com/forum/showpost.ph ... stcount=99

What I am asking is basic info on how to use modifier volumes with kos...

[RyoDC]

They are a PowerVR2 exclusive feature called "modifier volumes", which are very different

Huh, that's why I didn't find anything in google on this
Can you advice any sources where I can read on how pvr2 works internally?

[BlueCrab]

What I am asking is basic info on how to use modifier volumes with kos...

There are two examples that are in the KOS tree, assuming you're using a relatively recent enough version (they were added in 2009, IIRC). Here they are:
examples/dreamcast/pvr/modifier_volume
examples/dreamcast/pvr/modifier_volume_tex

They're kinda silly little examples, but they should at least demonstrate basically how you can use modifiers to affect polygons...

[PH3NOM]

What I am asking is basic info on how to use modifier volumes with kos...

There are two examples that are in the KOS tree, assuming you're using a relatively recent enough version (they were added in 2009, IIRC). Here they are:
examples/dreamcast/pvr/modifier_volume
examples/dreamcast/pvr/modifier_volume_tex

They're kinda silly little examples, but they should at least demonstrate basically how you can use modifiers to affect polygons...

Thank you for that!

As I am using the Dev Iso R3 Build of KOS, modifier volume examples were not apart of KOS. I went ahead and updated the pvr code in the kernel to the latest KOS repo.
With that, I updated the way I compile polys for the PVR with my implementation of OpenGL.
I have not yet had time to look at your example code, but are your modifier volumes a quad(2d) or a qube(3d)?

At any rate, here are some screens from my most recent test of my build of OpenGL with Dynamic Vertex Lighting with 3 light sources ( 1 ambient, 2 diffuse with attenuation ).
Dont consider the frame rate bad(20fps), as things are still not final, but not bad considering KGL will crash trying to render this sonic model alone :0

(Very low ambient lighting)


(Medium ambient lighting)


(High ambient lighting)

[BlueCrab]

As I am using the Dev Iso R3 Build of KOS, modifier volume examples were not apart of KOS. I went ahead and updated the pvr code in the kernel to the latest KOS repo.
With that, I updated the way I compile polys for the PVR with my implementation of OpenGL.

I do highly recommend that if you're working on building stuff for others to use that you look into updating the entirety of your toolchain to work with a more current version of KOS. I know that it can be a pain, but it'll be worth it in the end, I'd think.

I have not yet had time to look at your example code, but are your modifier volumes a quad(2d) or a qube(3d)?

Just a single quad.

[PH3NOM]

BlueCrab-
Wow, cant believe this is a 2 year bump.
Thank you again for adding the cheap_shadow example to KOS.
I am considering again the idea of using modifier volumes for simple shadows on DC.

My idea is to tessellate and cache a Cone as 2 Triangle Strips ( base and wall ) once, then when rendering simply set the the matrix scale, translation, and rotation matrices as need to render the mesh as a modifier volume at any given position / rotation / size.


Anything inside that volume will be effectively shadowed.

One thing that bothers me is that the modifier volumes in KOS seem to be more like "modifier sprites", in a 2D context.
The pvr_modifier_vol_t seems very similar to pvr_sprite_col_t, but I dont think that is what I need...
Does the PVR support another type of "modifier volume" vertex type? Or can this effect effect be achieved?

[BlueCrab]

The hardware only supports one polygon type for specifying modifier volumes -- a basic triangle (there is no shortcut way of doing strips with modifiers, you have to do every triangle separately). You can build whatever 3D volumes you want out of those triangles, though.

So, if you're looking at the modifier_volume example, you could add as many more triangles as you want in the volume between lines 154 (pvr_prim(&mod, sizeof(mod));) and 156 (pvr_prim(&mhdr2, sizeof(mhdr2));).

In short, the example only shows 2D, but it should work fine in 3D as well as far as I know.

[PH3NOM]

Ahh, thanks that clears things up a bit.

Just to be clear, I am looking at shadow.c.

At first look I was thinking each polygon was a quad, and that the 4th vertex was derived from polygon triangulation, kind of like how the pvr sprites work.
But now I see each polygon is actually a triangle, which is why you submit 2 of them to create the quad seen.

I also notice you are submitting two headers.
Can you explain a bit about how the headers must be submitted?
Does a header need to be submitted for each modifier polygon, or 2 headers per volume; i.e. 1 to start volume and 1 to end volume?

[BlueCrab]

There's a bit in the header to say what the last triangle is in the volume (versus any other triangle in the volume). That's why you have to submit two different headers. As I said in the last reply, you can submit as many triangles as you want between the first header and the second header.

Note in the shadow.c example (lines 41-43):

Code: Select all

    pvr_mod_compile(&mhdr, list + 1, PVR_MODIFIER_OTHER_POLY, PVR_CULLING_NONE);
    pvr_mod_compile(&mhdr2, list + 1, PVR_MODIFIER_INCLUDE_LAST_POLY,
                    PVR_CULLING_NONE);

The second header there has the PVR_MODIFIER_INCLUDE_LAST_POLY flag set, where as the first one has the PVR_MODIFIER_OTHER_POLY parameter there (which is 0, by the way). If you're building an exclusion volume (for whatever reason), then you'll want to use the PVR_MODIFIER_EXCLUDE_LAST_POLY, of course.

[PH3NOM]

Thanks BlueCrab, thats what I thought.

I think things get tricky with Z Clipping 3D Modifier Volumes. I still need to investigate more...

[PH3NOM]

This is not yet using modifier volumes, but today I have implemented a sort of stencil-based shadows for models, and I am quite happy with the results!

[BlueCrab]

That's pretty impressive, if I must say so myself.

[PH3NOM]

Thank you

Here is a clip of the current build, using the shadow algorithm in the last screen I posted with 2 players.
Shadows still need a bit of tweaking, but not bad for a first pass.

[park]

[quote="PH3NOM"]Thank you

Here is a clip of the current build, using the shadow algorithm in the last screen I posted with 2 players.
Shadows still need a bit of tweaking, but not bad for a first pass.


Wow thats looking pretty cool. Hopefully you consider some sort of demo or maybe even creating \ selling a game in the future.I remember very few dreamcast (two off the top of my head) used the real time shadowmaping shadows(i guess somewhat like modern games) ,derby tsuku 2 and Matt hoffman bmx.Just thought Id mention in case you would be interested in cool effects.

[Bouz]

What about Crazy Taxi and Jet Set Radio?

[SiZiOUS]

PH3NOM, this is really impressive. Keep up the great work!

[bogglez]

The shadows in Matt hoffman BMX and Phantasy Star Online are so pixelated they're probably using shadow maps, aren't they?