DeadlyNinja
Veteran
Ah, I see, that explains everything.
Normal Mapping Wii demo
- Thread starter DRS
- Start date
And besides it being open source, it has emotional value (I played it a lot and I really respected it for its tech), some cool people already ported it to Wii, so easy to pick up, and I'm too lazy to write an engine+game from scratch.
As for the models, I'm not sure, but I think it still looks flat because Tenebrae uses heightmaps thus a fixed height range. Normal maps basically correspond to a dynamic height range, i.e. you can have all texels in a normalmap orient 90 degrees to the left if you like, but such a thing is basically impossible with a height map. I guess the low polycount will always be evident when you come up close because you get large edges, can't mask that out.
@Iron: Do you have the 100MB or the 5MB version of Tenebrae? I think the 100MB version has better textures and the 5MB version just generates the bumpmaps.
Have been able to port the screenshot part (though it seems I get some unstability after taking them, it just hanged when I tried to load e1m2). Also implemented 16:9 (although, still using 640x528)
Still need to check if the normal mapping is correct using the new shader. I have the feeling that some projections may be mirrored. Perhaps I have to reduce the light level a bit as well because it leads to more evident specularity)
edit: mmm it suddenly appears to me that the screenshots miss some lines in the bottom...
As for the models, I'm not sure, but I think it still looks flat because Tenebrae uses heightmaps thus a fixed height range. Normal maps basically correspond to a dynamic height range, i.e. you can have all texels in a normalmap orient 90 degrees to the left if you like, but such a thing is basically impossible with a height map. I guess the low polycount will always be evident when you come up close because you get large edges, can't mask that out.
@Iron: Do you have the 100MB or the 5MB version of Tenebrae? I think the 100MB version has better textures and the 5MB version just generates the bumpmaps.
Have been able to port the screenshot part (though it seems I get some unstability after taking them, it just hanged when I tried to load e1m2). Also implemented 16:9 (although, still using 640x528)
Still need to check if the normal mapping is correct using the new shader. I have the feeling that some projections may be mirrored. Perhaps I have to reduce the light level a bit as well because it leads to more evident specularity)
edit: mmm it suddenly appears to me that the screenshots miss some lines in the bottom...
Last edited by a moderator:
DeadlyNinja
Veteran
Looks pretty neat. A little overdone with the normal maps, but this is a demo for showing off normal maps.
Do you have any screens of what the areas originally looked like? I've never played Quake before. I didn't have a PC to play it back then.
Do you have any screens of what the areas originally looked like? I've never played Quake before. I didn't have a PC to play it back then.
Last edited by a moderator:
@Deadly, I agree on the normal maps. Using glossmaps and dedicated normalmaps will help too. You can find some screens on the net for now. I'm not planning to implement a feature to turn off normal mapping, though it wouldn't be such a big problem to do so ofcourse. Let's call it a future 'nice to have'.
My goal is to also show off per light volume shadows if possible=) I'll use either the color or alpha buffer to act as stencil buffer. What I'm planning:
* In pass 1 I'll just render the scenery to zbuffer, probably in 320x240 res, I'll also determine what lights are visible there.
* In pass 2 and 3 I'll draw the volumes for each visible light in 320x240 res, though due to limited bit depth of alpha buffer, I need to switch between drawing front faces and back faces more often resulting in more rendering passes than when using a real stencil buffer. I don't assume that will be a huge performance hit though. For each light, the resulting drawn volumes will be exported to textures.
* In the final pass I'll draw the scenery in high res. For each light, the shader will look up the corresponding volume texture to determine if a pixel is lit by that light.
I think the Wii can handle it, but the huge amount of lights in Quake might spoil it. We'll see!
@Tron: reading those lights shouldn't be a problem. I currently read the lights from the entity dictionary clientside anyway. So using a rtlight file instead of the dictionary is possible. Again, a 'nice to have' to me. My priority is to get things up and running using the original level designs. Mainly because you can use any missionpack with it then. So if it turns out that Quake has too many lights, using stuff from Darkplaces might be an easy alternative, but I'd rather look into creating an algorithm that combines lights that are close to eachother to reduce the count..
My goal is to also show off per light volume shadows if possible=) I'll use either the color or alpha buffer to act as stencil buffer. What I'm planning:
* In pass 1 I'll just render the scenery to zbuffer, probably in 320x240 res, I'll also determine what lights are visible there.
* In pass 2 and 3 I'll draw the volumes for each visible light in 320x240 res, though due to limited bit depth of alpha buffer, I need to switch between drawing front faces and back faces more often resulting in more rendering passes than when using a real stencil buffer. I don't assume that will be a huge performance hit though. For each light, the resulting drawn volumes will be exported to textures.
* In the final pass I'll draw the scenery in high res. For each light, the shader will look up the corresponding volume texture to determine if a pixel is lit by that light.
I think the Wii can handle it, but the huge amount of lights in Quake might spoil it. We'll see!
@Tron: reading those lights shouldn't be a problem. I currently read the lights from the entity dictionary clientside anyway. So using a rtlight file instead of the dictionary is possible. Again, a 'nice to have' to me. My priority is to get things up and running using the original level designs. Mainly because you can use any missionpack with it then. So if it turns out that Quake has too many lights, using stuff from Darkplaces might be an easy alternative, but I'd rather look into creating an algorithm that combines lights that are close to eachother to reduce the count..
I'm certainly interested to see how it turns out, but if you are going to try and implement the realtime shadows as well I think any automatic solution will always be inferior to lights that have been positioned by an artist taking into account overlap, shadow directions in relation to light fixture textures etc.
There are actually .rtlight files around for the mission packs as well. I'm not trying to belittle the work you are doing because what you have already is impressive, and I am looking forward to playing through Quake on my Wii with fancy modern effects. I just think you will definitely get much more impressive effects using lighting setups designed for real time lighting and shadows, and falling back to the original light positions if updated data isn't available.
The original PC Call of Duty is Quake III based, and I'd really like to play that game with some bumpmapping and shadow casting. Get it working on the Wii with the proper controls and I'd be happy cause CoD3 has no MP and WaW and all the others on varying systems are still not as fast and furious as the very original! 
I must say how surprised I am at how no one created higher resolution texture and model mods for the games. Any visual mods were just skins. I hope Call of Duty classic is remade with some of these features, and it better be available on PC or at least a patch is made available >:/
I must say how surprised I am at how no one created higher resolution texture and model mods for the games. Any visual mods were just skins. I hope Call of Duty classic is remade with some of these features, and it better be available on PC or at least a patch is made available >:/You are so awesome.
I like WaW MP, though haven't played it lately. Think they missed a change to implement some normal mapping=)
As for the rt light files, you are right, it'll improve the quality.
Ok, this works in concept. This runs 24 320x240 stencil textures, thus a maximum of 24 lights per frame. Framerate is lost though, have to look into optimizing it a lot. And these are just static volumes, Í haven't coded dynamic ones for entities yet.
Futhermore, the stencil textures haven't been filtered, so it looks a bit aliased. Last but not least, it seems that everything compiled is stored in that 24MB SRAM. The game's texture heap is allocated in that 64MB Dram (it seems that we can't allocate more than 52MB though, which leaves a magic 12MB not accesible. So perhaps that 12MB OS story is true after all). I was forced to change the screen grabber a little as well because I'm using most of the SRAM for stenciling now. So now I just grab the external frame buffer, but it seems the conversion between YCbCr gives some artifacts. Never the less, some screens:
Reg,
Danny
As for the rt light files, you are right, it'll improve the quality.
Ok, this works in concept. This runs 24 320x240 stencil textures, thus a maximum of 24 lights per frame. Framerate is lost though, have to look into optimizing it a lot. And these are just static volumes, Í haven't coded dynamic ones for entities yet.
Futhermore, the stencil textures haven't been filtered, so it looks a bit aliased. Last but not least, it seems that everything compiled is stored in that 24MB SRAM. The game's texture heap is allocated in that 64MB Dram (it seems that we can't allocate more than 52MB though, which leaves a magic 12MB not accesible. So perhaps that 12MB OS story is true after all). I was forced to change the screen grabber a little as well because I'm using most of the SRAM for stenciling now. So now I just grab the external frame buffer, but it seems the conversion between YCbCr gives some artifacts. Never the less, some screens:
Reg,
Danny
Iron Tiger
Regular
Are your normal maps going in the SRAM, too? If so, would having premade normal maps that can be stored in the GDDR free up space for higher res stencils or filtering?
I've been trying to find my copy of Tenebrae, but I'm only home on the weekends, and it hasn't been in the few places I thought it would be. I'll try searching the net for a source, too.
I've been trying to find my copy of Tenebrae, but I'm only home on the weekends, and it hasn't been in the few places I thought it would be. I'll try searching the net for a source, too.
DeadlyNinja
Veteran
DRS, is this suppose to be just a personal demo, or do you plan to release this to the public?
@Iron: No those are allocated in the Dram too. Since those textures arent that big I suppose the texture cache will be sufficient to keep the speed. The stencil textures on the other hand are quite big so I really wanted those in SRAM so GPU can access them fast. Don't worry about Tenebrae too much for now, it's not like I'd finish this tomorrow otherwise=)
@Deadly: This will be released. Though I figure, a new game using this engine would be great too.
@Tron: up to some extend I guess; I'm not sure if this version of Quake streams textures from disk (SD card in this case=) while playing. If so, it wouldn't be an issue at all. If not, someone should implement streaming textures=)
And thanks for the compliments so far!
@Deadly: This will be released. Though I figure, a new game using this engine would be great too.
@Tron: up to some extend I guess; I'm not sure if this version of Quake streams textures from disk (SD card in this case=) while playing. If so, it wouldn't be an issue at all. If not, someone should implement streaming textures=)
And thanks for the compliments so far!
Iron, I realized I only answered your question like... half... or so...=) Higher resolution stenciling would be possible ofcourse. But, it would require higher fillrate to draw the volumes, more time to copy the internal framebuffer to SRAM and more texelrate to use it to full extend. I think that is a little too much for the Wii with this number of lights going on.
So, to go such a route, the game should be tailored to those limits. For example, I read an article about modelling lighting in Doom and they recommended to not overlap shadowing lights to much. That is because each light renders the area once, which is quite expensive. So I guess Doom proves, taking those limitations into consideration when designing an area still results in amazing visuals.
As for filtering, I just meant anisotropy and/or bilinear filtering when actually drawing the surface polygons. This would reduce the shadow jaggies a little and the stencils are kept 320x240.
So, to go such a route, the game should be tailored to those limits. For example, I read an article about modelling lighting in Doom and they recommended to not overlap shadowing lights to much. That is because each light renders the area once, which is quite expensive. So I guess Doom proves, taking those limitations into consideration when designing an area still results in amazing visuals.
As for filtering, I just meant anisotropy and/or bilinear filtering when actually drawing the surface polygons. This would reduce the shadow jaggies a little and the stencils are kept 320x240.
Iron Tiger
Regular
Are you positioning your own lights, or does Quake actually have 24 lights in some scenes? Does the standard engine have a set limit on number of lights, or could fanmade levels for the standard code "break" your engine?
Just some notes you could try:DRS said:
Ideally you'd want to run around 4x4 box filter on your stencil-maps(just in screen space, nothing fancy). You can get nice soft-shadow look this way even though math is a horrible hack - the tradeoff is that you'll get a bit of shadow-bleed around some polygon edges but the issue is minor and many games have shipped with it (for the better, IMO).
Technically you only need to render ZBuffer once - you can downsample it with Pointsampling for shadows (but not sure if this is helpful on Wii given that you have to copy it out to main memory first though).
Since you're rendering stencil into separate textures anyway you could just use RGB to get 8bit counter(or maybe you already are?).
DeadlyNinja
Veteran
If you're going to release them, may I make a few suggestions? They're mainly artistically related since I'm not tech expert.
http://sd-engineering.nl/nmcube/quake05.jpg
This image's normal maps are really cluttered. I think you should focus on big bold details instead of the smaller stuff. The game is running at a mere 480p, so I'm not sure the details will show up that nicely.
http://sd-engineering.nl/nmcube/1/quake02.jpg
Like this one, instead of doing little bumpy details, perhaps you can make the individual bricks pop out more. You can have detail, but too much detail can be a bad thing.
Space out the bumps across the board, because it's too messy right now.
http://sd-engineering.nl/nmcube/quake05.jpg
This image's normal maps are really cluttered. I think you should focus on big bold details instead of the smaller stuff. The game is running at a mere 480p, so I'm not sure the details will show up that nicely.
http://sd-engineering.nl/nmcube/1/quake02.jpg
Like this one, instead of doing little bumpy details, perhaps you can make the individual bricks pop out more. You can have detail, but too much detail can be a bad thing.
Space out the bumps across the board, because it's too messy right now.