#148293 - Peter - Fri Jan 04, 2008 1:28 pm
I wonder how the developers of dementium: the ward have achieved the flashlight effect shown in th followig screenshots:First I thought it would be just some kind of overlay and gets blended with the 3d scene, but on several screenshots the light looks rather perspective, for example when it's projected at a corner of a wall or into another room.
Then I thought maybe it's done with a shadow-volume. But instead of darkening the affacted area, it brightened. But no idea if you can change the shadow-color/blending mode.
Another theory is again a shadow-volume, but with an "invered cone" as volume. So everything except in the cone gets shadowed.
What do you think how the effect is achieved?
_________________
Kind Regards,
Peter
#148308 - M3d10n - Fri Jan 04, 2008 3:28 pm
Yes, that's a shadow volume, but it's not inverted.
With the correct settings, you can make it so the fog will not affect the pixels inside the shadow volume. So the areas outside the flashlight cone are darkened by a cleverly adjusted black fog, while the cone volume does nothing but show the unfogged scene.
#148313 - Bloodypriest - Fri Jan 04, 2008 4:00 pm
If I remember correctly what I heard at GDC, this effect is actually based on a bug in the DS fog engine. I think it has to do with an unfogged 3d model while the scene is fogged which will make the scene show through or something like that ; I don't remember correctly. And they could not explain every detail because of Nintendo's NDA.
#148318 - silent_code - Fri Jan 04, 2008 4:12 pm
right, right!
if you used an inverted cone, all you'd get is a real bad depression. it's much pain to get it working with the z-pass shadow volume algorithm used by the nds, if you *can* do it at all (i tried...).
you can, however, define any color for the shadow. :^)
EDIT: afaik, you can't change the nds' blending mode besides modulate and decal. that also applies to shadow blending.
i havent tried texturing the shadow, but using it for "fog cutouts" like in that game (looks interesting!) is not hard - and you can tell from the images that it's doing that (what also limits the visuals you can get with that technique, eg. distant objects, no matter how lit they are, will allways dissolve in darkness that way). is, like posted before, a matter of setting things up right.
#148361 - M3d10n - Fri Jan 04, 2008 11:34 pm
Actually, it's on GBATek:
http://nocash.emubase.de/gbatek.htm#ds3dshadowpolygons
From the link:
| Quote: |
| The old Fog Enable flag in the Attribute Buffer is ANDed with the Fog Enable flag of the Shadow Polygons, this allows to exclude Fog in shaded regions. |
So, if you enable fog for the scene, render geometry with fog enabled (bit 15 in the poly attribute), and render the shadow volume with fog disabled afterwards, the pixels inside the volume will be unfogged.
#148364 - Peter - Sat Jan 05, 2008 12:06 am
Awesome, thanks for the info! Not that I want to program this effect, I was just curious how they might have done it.
And again learned something today, yay! :)
_________________
Kind Regards,
Peter
#148366 - simonjhall - Sat Jan 05, 2008 12:38 am
Just reading that info on gbatek about this shadowing lark and it does sound pretty easy! I'm gonna have to have a go :-)
However you just KNOW that as soon as you add that DS 'funk factor' a ten minute job is actually going to take you hours until you realise you need to set some obscure bit in a register somewhere... Grr...
Now the only thing holding me back from using shadow properly is that it eats into your valuable polygon count...
/more off-topic:
Reckon you could use the display capture to do shadow mapping?
_________________
Big thanks to everyone who donated for Quake2
#148371 - elhobbs - Sat Jan 05, 2008 1:54 am
I had a go at writing a shadow map quake level viewer using the display capture. I rendered the scene once with the level textures and captured the frame then copied to main memory. Then I rendered the frame again using the lightmaps with display capture then copied the frame to main memory. I then blended the two frames in software using a lookup into the quake colormap. As you may imagine it runs at about 10 frames a second and uses the lowest resolution mipmaps since one of the vram banks is lost to capture. since the lightmaps are so tiny I packed them into larger texture blocks like glquake - this makes it almost impossible to do any type of texture loading and unloading for the lightmaps so they needed to stay resident in vram. this did not even render any of the monsters and they typically take longer to render then the bsp file. I would say that it is a no go for quake, but cetainly possible for something that is designed from the start with this in mind.
#148437 - Bloodypriest - Sat Jan 05, 2008 6:44 pm
| M3d10n wrote: |
Actually, it's on GBATek:
http://nocash.emubase.de/gbatek.htm#ds3dshadowpolygons
From the link:
| Quote: | | The old Fog Enable flag in the Attribute Buffer is ANDed with the Fog Enable flag of the Shadow Polygons, this allows to exclude Fog in shaded regions. |
So, if you enable fog for the scene, render geometry with fog enabled (bit 15 in the poly attribute), and render the shadow volume with fog disabled afterwards, the pixels inside the volume will be unfogged. |
Yes! That was it! That's the "feature" the speaker at GDC was saying was a bug due to weird way fog was rendered on the DS.