What is Super Mario Galaxy using to create this effect?

[DeadlyNinja]

There are a lot of effects in Mario Galaxy, but since the system is weaker, are they using substitutes for certain effects? For example, that picture looks like it's using EMBM for the extra detail, but could it be just gloss mapping? I mean, I can look at something like Far Cry and say without hesitation that this is EMBM, but I can't do that with the Wii. Mario Galaxy seems to spam whatever it is quite a bit throughout the game. Looks good of course, but I just want to be sure that it is EMBM and not something else.

 

[fearsomepirate]

it's EMBM. Flipper had some silicon basically dedicated to the effect, which is somewhat less complex than normal mapping. ERP had explained something about it a while back; try searching for it.

 

[Squeak]

Where did you get the idea that it's less complex? If anything it requires special hardware. Normal mapping can be done with palettes and alphablending if needed.
It's a much more general approach to the problem (manipulating 2d surfaces with post processing for 3d effects) than normal mapping.

 

[Bohdy]

I think he means that its more complex to perform on the Wii compared to EMBM.

I do remember Faf stating the capability for EMBM is practically hardwired into the Flipper, so this makes sense.

 

[DeadlyNinja]

Oh yeah, he's right, the Wii does have hardware support for EMBM. I completely forgot about that. Normal mapping on the other hand is not supported by the Wii.

So there's technically no excuse for 3rd parties not to use it, correct? Or is it limited by the amount of RAM and/or fill rate?

 

[Squachy]

Oh yeah, he's right, the Wii does have hardware support for EMBM. I completely forgot about that. Normal mapping on the other hand is not supported by the Wii.

So there's technically no excuse for 3rd parties not to use it, correct? Or is it limited by the amount of RAM and/or fill rate?

according to High Voltage Software, they are using normal maps for their game engine for The Conduit, so i guess the wii does support normal mapping? Or just not in hardware...i dunno.

 

[Bohdy]

IIRC normal mapping can be done efficiently for static lights.

For dynamic lights it is more difficult.

 

[Squeak]

according to High Voltage Software, they are using normal maps for their game engine for The Conduit, so i guess the wii does support normal mapping? Or just not in hardware...i dunno.

Or maybe they are just using a word they think more people are familiar with..?
EMBM can do anything normal mapping can do and more. For example you can use coloured reflectionmaps and you aren't limited to only reflections, you can also do simple parallax mapping (probably not with z-occlusion).

The limiting factore before was the GCs low clockrate. It was originally meant to go somewhat faster. That in turn resulted in lower fillrate and less time for the TEV to perform its magic per frame.
With the new clock, you can practically shower your games in TEV effects and still keep 60fps (look at Galaxy).

 

[fearsomepirate]

Where did you get the idea that it's less complex?

From ERP.

The TEV is an 8 stage combiner with some additional logic designed for EMBM.

Both lack real flexibility, because IMO they look to have been designed for a very specific job. A good example is the EMBM logic, it's basically 2, 3 part dot products per stage but the allowed inputs are heavilly limited because they are what you would use for EMBM. Another is that you can only use a left handed coordinate system (or right can never remember which one works) because the projection matrix isn't a complete matrix, and the hardware always clips -W.

I guess you need the complete matrix and arbitrary inputs to do normal mapping like you see in Doom 3. I think I should have said "requires more flexibility" rather than "more complex." I wonder if the Conduit is somehow working around this, or if they're brute-forcing the normal maps through another means. Anyway, here are the threads the new peopel should read:

http://forum.beyond3d.com/showthread.php?t=1086
http://forum.beyond3d.com/showthread.php?p=844403

 

[Squeak]

Question is: Why use normal mapping, when you have a perfectly good hardwired EMBM, that does the same and more?

 

[TapamN]

Question is: Why use normal mapping, when you have a perfectly good hardwired EMBM, that does the same and more?

Plain normal mapping needs two texture reads: once for the normal map, and once for the base texture.

EMBM normal mapping needs three texture reads: once for the normal map, once for the light map, and once for the base texture.

 

[Squeak]

Plain normal mapping needs two texture reads: once for the normal map, and once for the base texture.

EMBM normal mapping needs three texture reads: once for the normal map, once for the light map, and once for the base texture.

If you are content with vertex lighting, that is.
On hardware that doesn't have a lookup table/logic for generating a "phong" spotlight, you need a light map.
And I'm almost certain that you aren't forced to have light map on Flipper/Hollywood. You could probably just perturb the vertex light instead.

 

[Mintmaster]

I mean, I can look at something like Far Cry and say without hesitation that this is EMBM, but I can't do that with the Wii.

Actually, I don't think that is EMBM in the FarCry pic. It's just per-pixel specular with a high exponent (which needs high precision math to look good).

 

[DeadlyNinja]

Actually, I don't think that is EMBM in the FarCry pic. It's just per-pixel specular with a high exponent (which needs high precision math to look good).

That's why I wanted to ask to make sure. I was actually thinking it was the other way around. The specular lights can give off the illusion of bumps due to the way it's reflected.

 

[Squeak]

That's why I wanted to ask to make sure. I was actually thinking it was the other way around. The specular lights can give off the illusion of bumps due to the way it's reflected.

It's probably just specular normal mapping, but it could just as easily be EMBM. AFAIR FC uses EMBM on the water, which is one of the things the tech is really good for.

 

[fearsomepirate]

Question is: Why use normal mapping, when you have a perfectly good hardwired EMBM, that does the same and more?

If you need a light map for EMBM (Cube-style, anyway) to replicate the effect of normal mapping, it seems to me that it wouldn't work with a lighting engine like Doom 3's, where the light sources are constantly moving. Wouldn't you have to recompute the light map every frame?

 

[TapamN]

If you need a light map for EMBM (Cube-style, anyway) to replicate the effect of normal mapping, it seems to me that it wouldn't work with a lighting engine like Doom 3's, where the light sources are constantly moving. Wouldn't you have to recompute the light map every frame?

Er, when I said light map, I was thinking of something like the "phong map" on this page, which would be distorted by EMBM and used as the light intensity. I didn't mean the static light maps applied to the level used in, e.g., Unreal/Quake. Light map was just the first thing that I could think of to call it.

 

[Squeak]

If you need a light map for EMBM (Cube-style, anyway) to replicate the effect of normal mapping, it seems to me that it wouldn't work with a lighting engine like Doom 3's, where the light sources are constantly moving. Wouldn't you have to recompute the light map every frame?

There is nothing to recalculate, if it's just a generic spotlight. You just render the scene over again.
With EMBM you have the option of using environment maps though for specular reflections. That, you will have to render first.
EMBM is the superior tech from a quality PoV. It is more slightly more costly to implement in hardware, but shaders can be programmed to do it if necessary.

 

[Mintmaster]

EMBM is the superior tech from a quality PoV. It is more slightly more costly to implement in hardware, but shaders can be programmed to do it if necessary.

It's a lot more than "slightly" more expensive. There's a big reason that GF4 MX avoided it even though we saw it in the Matrox G400, Kyro I/II, Radeon, and Geforce 3.

You need a huge pixel pipeline (or register space) to do dependent texturing. With regular texturing, though, you can start fetching texels as soon as you know the texcoords after the vertex processing. Unfortunately, the feature's omission in NVidia's products before NV20 is what made the feature mostly unused in DX7 hardware.

I agree, though, that EMBM is a far superior tech. I think every game in the DX8 era would have equal (and sometimes superior) IQ if it used DX7 EMBM. Not that I think it should be used when math gives a similar effect, but it certainly is a powerful feature.

 

[Squeak]

It's a lot more than "slightly" more expensive. There's a big reason that GF4 MX avoided it even though we saw it in the Matrox G400, Kyro I/II, Radeon, and Geforce 3.

You need a huge pixel pipeline (or register space) to do dependent texturing. With regular texturing, though, you can start fetching texels as soon as you know the texcoords after the vertex processing. Unfortunately, the feature's omission in NVidia's products before NV20 is what made the feature mostly unused in DX7 hardware.

I agree, though, that EMBM is a far superior tech. I think every game in the DX8 era would have equal (and sometimes superior) IQ if it used DX7 EMBM. Not that I think it should be used when math gives a similar effect, but it certainly is a powerful feature.

GF4 avoided it because it was a budget card. I don't know whether it really couldn't do it, or it was just a feature "adjustment" to make the big brother seem worth the money, but most GPUs after that time had programmable shaders that could be made to do it.

It really isn't that much of an overhead. You just need the extra cache, buffer and register space for the hightmap. You need to be able to hold piece of the hightmap, logic and registers for reading 2x2 texels of the HM and perturb the UV coordinates accordingly.
Not that much more complicated than (real) trilinear or dual texturing. And indeed sharing much of the same hardware.