Normal Mapping Wii demo

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.

I believe DRS is just automatically generating the normal maps from the diffuse textures at the moment. Those issues would be fixed with custom made normal maps, which have already been made for Quake textures and hence why we are pestering him to get in loading of external textures, lights etc. :D
 
Any chance of you releasing a work in progress build of it. I'm sure their are many people (me included) who would be more then willing to beta test it and look for inconsistencies or errors in the graphics for you. :D
 
@Iron: I'm using Quake's original light positions. Actually it's funny: ID created a pretty realistic lighting model but didn't use it that way. They kind of used lights to "decorate" area's, hence 200-300 lights per map. They could get away with that because they prerendered that data to lightmaps. So, in the end, an area in Quake may contain way beyond 24 lights. I just limit the number visible shadow casting lights to 24 per rendered frame (which is mostly ok). Besides that, each surface is limited to cast light from the 4 most nearby lights. So custom maps shouldn't break the engine, but may contain errors in terms of lighting. In contrast, a map that is designed with a limited, more realistic, number of lights will look better and is less likely to contain errors.

@Fafalada: Thanks! Since the stencils are exported to a texture I should be able to use hw filtering (i.e. implementing an actual 4x4 filter in tev would take 16 texture samples and require a complete 16 stage pass). Though the problem with hw filtering would be that the colour values must differentiate enough; there is no integer value between 0 (no shadow) and 1 (shadow) which means a shadow value must be stored as a value bigger than 1, so the hw can actually interpolate between those. From there it's just multiply the filtered value with the light intensity. Yes, I'm currently using RGB8 but I export to RGB565 to reduce texture size (which means I have either 5 or 6 bits available). There are some other formats available that may suit better but I still have to test with those.

@Deadly: pretty much what Tron says. Dedicated bump maps will enable the same results as I showed with the cube demo. But I'd like to add that if a surface is lit uniformly from each side, you don't see the bumps (just like in a real world surface). Speculatity makes bumps more evident too, which you see in the first image you referred to.

@Link: That's what I'm planning to do. But, with the shadowing going on it runs only 12 fps. With some optimizations it runs 16 fps, but with a lot of errors in shadowing. I estimate that this can run about 25 fps at least, but it requires optimizing the shadow volumes first (a shadow BSP would be a good point to start). When I have managed to do that I'll release that version. The followups will contain shadowing and normal mapping on entities and support for texture and light overriding. Hopefully I can provide a download end next month or so (I possibly can't work fulltime on it the next 7 weeks since I ran into an assignment I just had to take on).

Sadly enough, no new screens yet. It's hard to make good progress with this stuff!
 
@Iron: I'm using Quake's original light positions. Actually it's funny: ID created a pretty realistic lighting model but didn't use it that way. They kind of used lights to "decorate" area's, hence 200-300 lights per map. They could get away with that because they prerendered that data to lightmaps. So, in the end, an area in Quake may contain way beyond 24 lights. I just limit the number visible shadow casting lights to 24 per rendered frame (which is mostly ok). Besides that, each surface is limited to cast light from the 4 most nearby lights. So custom maps shouldn't break the engine, but may contain errors in terms of lighting. In contrast, a map that is designed with a limited, more realistic, number of lights will look better and is less likely to contain errors.

@Fafalada: Thanks! Since the stencils are exported to a texture I should be able to use hw filtering (i.e. implementing an actual 4x4 filter in tev would take 16 texture samples and require a complete 16 stage pass). Though the problem with hw filtering would be that the colour values must differentiate enough; there is no integer value between 0 (no shadow) and 1 (shadow) which means a shadow value must be stored as a value bigger than 1, so the hw can actually interpolate between those. From there it's just multiply the filtered value with the light intensity. Yes, I'm currently using RGB8 but I export to RGB565 to reduce texture size (which means I have either 5 or 6 bits available). There are some other formats available that may suit better but I still have to test with those.

@Deadly: pretty much what Tron says. Dedicated bump maps will enable the same results as I showed with the cube demo. But I'd like to add that if a surface is lit uniformly from each side, you don't see the bumps (just like in a real world surface). Speculatity makes bumps more evident too, which you see in the first image you referred to.

@Link: That's what I'm planning to do. But, with the shadowing going on it runs only 12 fps. With some optimizations it runs 16 fps, but with a lot of errors in shadowing. I estimate that this can run about 25 fps at least, but it requires optimizing the shadow volumes first (a shadow BSP would be a good point to start). When I have managed to do that I'll release that version. The followups will contain shadowing and normal mapping on entities and support for texture and light overriding. Hopefully I can provide a download end next month or so (I possibly can't work fulltime on it the next 7 weeks since I ran into an assignment I just had to take on).

Sadly enough, no new screens yet. It's hard to make good progress with this stuff!


just a quick question about the wii ram: me and a friend of mine are debating on the "purpose" of the 1t-sram and gddr3 on the wii. he says that the 1t-sram can be considered as "video ram" and the gddr3 as "system memory", while i think both can be considered as "main memory".
 
just a quick question about the wii ram: me and a friend of mine are debating on the "purpose" of the 1t-sram and gddr3 on the wii. he says that the 1t-sram can be considered as "video ram" and the gddr3 as "system memory", while i think both can be considered as "main memory".

If anything the opposite would be true. 1T-Sram's much lower latency makes it perfect as system memory. Where as the much higher latency of GDDR3 makes it far more suited to being used as video memory (game code is much more reliant on random access then graphics tasks). Though I'd tend to think you're probably right in that either pool can be used for either task.
 
Last edited by a moderator:
As far as I know, there are a few things that have to be done in one of the two pools. At least the XFB has to be in MEM1 (1T-SRAM) I believe. Other than that, I think developers can really use the pools pretty much any way they want.
 
If anything the opposite would be true. 1T-Sram's much lower latency makes it perfect as system memory. Where as the much higher latency of GDDR3 makes it far more suited to being used as video memory (game code is much more reliant on random access then graphics tasks). Though I'd tend to think you're probably right in that either pool can be used for either task.

Teasy, interesting point there. Never looked at it from that perspective actually! Do you think there are any cases where there are benefits in using SRAM for GPU related stuff (i.e. huge textures that can't fit in cache or so)?

As far as I know, there are a few things that have to be done in one of the two pools
A thing to add: the GPU cannot export to DRAM as it seems, only to SRAM. And the c compiler compiles to SRAM, though I'm not sure if that's just a linker setting.
 
Rendered to texture cube environment maps? The GPU writes directly to the SRAM and reads it right away for use in the scene.
 
Rendered to texture cube environment maps? The GPU writes directly to the SRAM and reads it right away for use in the scene.

No, I decided not to because it's a pain to project the correct cube faces to a polygon again. In worst case it requires 5 face lookups, thus resulting in problems that are hard to solve in TEV. With shadow volumes those problems can be avoided quite nicely, though the catch is that each light needs to be prerendered every frame. That wouldn't be a requirement when using projective shadows.
 
Teasy, interesting point there. Never looked at it from that perspective actually! Do you think there are any cases where there are benefits in using SRAM for GPU related stuff (i.e. huge textures that can't fit in cache or so)?

I'd think using the 1T-Sram for any task would always be a benefit to that task. Even large textures are effected by latency to some degree obviously. But is there a case when it would be a benefit to use the 1T-Sram for GPU related tasks at the expense of using it for game code?, I can't think of any myself.

I'd think the best idea would be to keep the textures that won't fit in the GPU cache in GDDR3 (the latency is poor but with big textures peak bandwidth is most important and GDDR3 has plenty). Unless there's space left over in 1T-Sram, in which case maybe some of it could be used as a secondary GPU cache. With the textures that the GPU cache will most likely need next being streamed from GDDR3.
 
Last edited by a moderator:
DRS said:
Though the problem with hw filtering would be that the colour values must differentiate enough; there is no integer value between 0 (no shadow) and 1 (shadow) which means a shadow value must be stored as a value bigger than 1, so the hw can actually interpolate between those.
Yea back on PS2 what we did was take a stencil texture and run it through alpha test with a palette that was setup to output 0/128 based on shadow being off/on, and then filter that. I guess on Wii you could do similar with dependant lookup?

Btw - the lights in those levels are primarily static, aren't they? For cases where light and geometry doesn't move, you can precompute "static"shadow-volumes, which can be optimized to minimize fillrate and geometry usage, while still giving you shadow-casting over moving objects etc.
 
I'd think using the 1T-Sram for any task would always be a benefit to that task. Even large textures are effected by latency to some degree obviously. But is there a case when it would be a benefit to use the 1T-Sram for GPU related tasks at the expense of using it for game code?, I can't think of any myself.

I'd think the best idea would be to keep the textures that won't fit in the GPU cache in GDDR3 (the latency is poor but with big textures peak bandwidth is most important and GDDR3 has plenty). Unless there's space left over in 1T-Sram, in which case maybe some of it could be used as a secondary GPU cache. With the textures that the GPU cache will most likely need next being streamed from GDDR3.

Ok thanks Teasy! Actually that's the same setup the initial port by Eluan has. All textures go in the GDDR. And it also explains why programs get compiled to SRAM mem; it's just meant to be.

Yea back on PS2 what we did was take a stencil texture and run it through alpha test with a palette that was setup to output 0/128 based on shadow being off/on, and then filter that. I guess on Wii you could do similar with dependant lookup?

Yes, I could use the result of a stencil lookup to perform an indirect lookup. Perhaps it would also be possible to use gammacorrection when exporting from EFB (don't know what it does yet:/) to increase intensities and then scale and clamp, negate and add one to get values between 0 and 1. Besides that, needless to say that I completely dig your hardcore oldschool coding style=)

you can precompute "static"shadow-volumes, which can be optimized to minimize fillrate and geometry usage, while still giving you shadow-casting over moving objects etc.

Exactly what I'm starting on now. Though I already precalculate the volume coordinates if that's what you mean. I also first had some blocking issues fix due some stupid errors and assumptions I made. I found out that it is possible to export 8bit red channel and use it in TEV as an 8 bit intensity texture. So bit depth problems aren't much of an issue now and I need less SRAM. I also overlooked one thing with switching from back to front face more often when drawing the volumes; it may result in the requirement for signed numbers in framebuffer. Actually I ran in that problem when I applied my first tweak to find neighbouring surfaces and take out the coincidencing faces.

Anyway, I initially was to look into cutting the volumes using the BSP algorithm (which ofcourse makes it easy to remove coincidencing sections). I think it would also drop the requirement for negative framebuffer issue since you can sort the volumes from back to front more easily. But, since I'm lame I will use a portal setup instead (not that it makes things easier but at least I have experience with calculating portal intersections). Also, I already found that the volume depth radius invluence performance greatly (obvious ofcourse). Anyway, I gonna need some time to implement that.

P.S. Did you guys implemented volume shadowing on the PS2 too? If so, what improvements resulted in the biggest peformance gains? I'm also looking for a good solution for specularity and shadowing. Currently, the volumes must completely fill out a room, even when the light's radius is smaller than that. So if anyone has ideas let me know.
 
Time for a refresh!

This stuff consumes quite some time as it turns out. As I mentioned I wanted to look into optimizing the shadow volumes since I assumed that Fillrate would be the first bottleneck to face. So I programmed some polygon cutting etc but it turned out that it took way too much time to precalc, and besides that, it degraded the performance! The optimizations basically resulted into more vertices and it seems that the vertice count is the first bottleneck. This was confirmed when I yesterday bumped up the stencil res to 640x240 instead of 320. It practically runs the same framerate.

At this point I have 1-d^2 light attenuation, specular and diffuse normal mapping world shadow volumes, brushmodel (doors ammoboxes etc) volumes and alias (all other object) volumes and 640x240 stencil operation.

The dynamic volumes are still very unoptimized so performace drops quite a bit when enemies occur. I will implement an initial optimization on that to help playabilty a little and then I'll release this version, probably in two weeks. I promized to release an earlier version, but I didn't felt it was of any use. Also I still have to enable underwater shadowing and create a nice watershader, hence two weeks. And some other stuff such as smoothshading.

Some screens of the current version:

quake01.jpg


quake02.jpg


quake03.jpg


quake04.jpg


quake05.jpg


quake06.jpg


reg,
 
Last edited by a moderator:
Wow, cool, an update.

It seems like there's no middle ground for the textures. They either look blurry close up, or blurry from afar. Is there anything you can do about that, or would it require you can completely redo the textures at a higher res (yeah, I know you don't have the time for that). The textures in the 4th image look the best. Doesn't look too blurry no matter how close or far they are.
 
I see what you mean. Part of that is resulting from the lighting; too many lights and the bump effect is gone. To me the far textures are quite detailed. Tenebrae for example throws in some distance blurring which really makes far textures blurry. So this should be sharper than that. On the other hand, the texture quality sucks ofcourse, which results in the near blurring. Same goes for the models; it's a blurr with normalmapping and selfshadowing:)

What I will do, somewhere in future, since I'd like to investigate the impact, is switching to Tenebrae's texturepack which has 512x512 textures. The Wii is really lacking memory so to actually implement such a thing I would need texture compression and most probably some means to dynamically load textures. Now there is some info on texture compression on Hollywood, but I wouldn't be surprised if my first 10 efforts to implement it result in garbage.
 
What a nice project!
What I will do, somewhere in future, since I'd like to investigate the impact, is switching to Tenebrae's texturepack which has 512x512 textures. The Wii is really lacking memory so to actually implement such a thing I would need texture compression and most probably some means to dynamically load textures. Now there is some info on texture compression on Hollywood, but I wouldn't be surprised if my first 10 efforts to implement it result in garbage.
Since the Wii supports DXT compressed textures, you could take a look at http://nothings.org/stb/stb_dxt.h -- it's public domain and pretty straight forward to use, especially if you're already working with 4x4 RGBA blocks. A while ago I implemented my own GX texture library which uses this routine for on-the-fly texture compression, and it works pretty well. I imagine you want to take a stab at this yourself, but if you need any pointers I'll be happy to lend a hand or a snippet of code. :)
 
Back
Top