I need a definitive answer, Can the GC do normal mapping?ERP

[Ooh-videogames]

I 'm hoping that ERP, will respond before the thread ends up on the next page of threads. I can never get a answer thats say's that it can't be done, impossible or can.

 

[StefanS]

Re: I need a definitive answer, Can the GC do normal mapping

I 'm hoping that ERP, will respond before the thread ends up on the next page of threads. I can never get a answer thats say's that it can't be done, impossible or can.

First of all , if you want an answer from ERP then I'd be a good idea to include his name in the title since it increases the chances of him dropping in.

Secondly, I believe Flipper can't do it without the help of Gekko, so you'll have to use the CPU.

 

[Ooh-videogames]

Re: I need a definitive answer, Can the GC do normal mapping

I 'm hoping that ERP, will respond before the thread ends up on the next page of threads. I can never get a answer thats say's that it can't be done, impossible or can.

First of all , if you want an answer from ERP then I'd be a good idea to include his name in the title since it increases the chances of him dropping in.

Secondly, I believe Flipper can't do it without the help of Gekko, so you'll have to use the CPU.

Why, Flipper does EMBM and it uses a normal mapp?

 

[ERP]

FWIW I haven't actually tried to do it, but it ought to be possible although not very practical (read slow) with multiple combiner stages. You would also have to so the per vertex setup on Gekko.

The reason EMBM doesn't require CPU intervention is that it is hardcoded into the T&L.

 

[Kristof]

The reason EMBM doesn't require CPU intervention is that it is hardcoded into the T&L.

Last time I checked EMBM was a per pixel effect which has nothing to do at all with T&L. Did you mean to say fixed function pixel pipe ?

EMBM remains one of the worst named functionalities ever, its a full dependent read operation which can be used for a lot more than just bumpmapping.

K-

 

[ERP]

I thought it required per polygon setup of the 2x2 offset matrix, but it's been a while since I looked.

 

[Farid]

EMBM remains one of the worst named functionalities ever, its a full dependent read operation which can be used for a lot more than just bumpmapping.

K-

That's why Nintendo likes to call it "indirect texturing".

 

[Ooh-videogames]

FWIW I haven't actually tried to do it, but it ought to be possible although not very practical (read slow) with multiple combiner stages. You would also have to so the per vertex setup on Gekko.

The reason EMBM doesn't require CPU intervention is that it is hardcoded into the T&L.

Normal mapping is per pixel right, is the GC capable of the per-pixel shading using the TEV. Or is it only capable of doing per-vertex?

 

[ERP]

No it's capable of per pixel, however the combiner doesn't have a dp3 operation, so you would have to do the multiplies and adds seperately.

Normally with "Normal mapping or Dtot 3" you light in tangent space, so there is some per vertex work which you would have to do on the CPU.

 

[akira888]

My memory might be fuzzy but IIRC early "EMBM" implementations were used primarily for planar or quasi-planar surfaces and thus all vertices had the same 2x2 du/dv direction transform matrix. Later implementations (GF3/R8500 era) generated this matrix on a per vertex basis inside the VS which made it more appropriate for use on non-flat surfaces.

But its been years since I looked at the DX7/DX8 SDKs so take this with the usual pinch of NaCl.

 

[bbot]

ERP,

According to the leaked specs:

http://www.beyond3d.com/forum/viewtopic.php?p=412531#412531

The Xbox2 cpu has a special dot product instruction. How many floating point operations does a dp3 instruction involve?

 

[Fafalada]

No it's capable of per pixel, however the combiner doesn't have a dp3 operation, so you would have to do the multiplies and adds seperately.

Err - I haven't looked at the docs in a long time, but from what I recall Flipper's dependant read performs a 3x2 matrix transform. So isn't all you'd need to do, set the appropriate vector in first row and clear the other on per vertex basis, and use a 1d luminance map as the target for resultant lookup.

I imagine the per-vertex stuff wouldn't be cheap, but it's still using just one combiner stage - no?

 

[Li Mu Bai]

I have heard that it can be done through cascading TEV stages, but the resultant vertex data must all be offloaded onto the Gekko. (processor intensive) So technically feasible, but problematic to implement. (& ultimately, fillrate limited) I hear much talk about "overloading" the Gekko with vertex instructions, (in discussions) yet have never really seen any examples of, or developers saying that this was a porting impediment so to speak.

This was supposed to cause or limit the GC's ability for displaying complex geometry & smooth animations. (RE4, MP, MP:Echoes are obvious examples of this being untrue) It ultimately depends on how capable the Gekko is at balancing the various processing tasks. The devs. proficiency with the architecture also comes into play.

 

[Ooh-videogames]

I have heard that it can be done through cascading TEV stages, but the resultant vertex data must all be offloaded onto the Gekko. (processor intensive) So technically feasible, but problematic to implement. (& ultimately, fillrate limited) I hear much talk about "overloading" the Gekko with vertex instructions, (in discussions) yet have never really seen any examples of, or developers saying that this was a porting impediment so to speak.

This was supposed to cause or limit the GC's ability for displaying complex geometry & smooth animations. (RE4, MP, MP:Echoes are obvious examples of this being untrue) It ultimately depends on how capable the Gekko is at balancing the various processing tasks. The devs. proficiency with the architecture also comes into play.

Yeah, MP:E the indirest texturing used for portals and also the water in RE4, I was also wondering about some of the Bosses in RE4, paticularly the last boss and it, the part human, part scorpion boss.

I read that the ps2 and the GC can do displacement mapping in a ATI pdf presented during GDC2003, I'm not sure, but I think there's some of that in RE4 later in the game.

 

[ERP]

No it's capable of per pixel, however the combiner doesn't have a dp3 operation, so you would have to do the multiplies and adds seperately.

Err - I haven't looked at the docs in a long time, but from what I recall Flipper's dependant read performs a 3x2 matrix transform. So isn't all you'd need to do, set the appropriate vector in first row and clear the other on per vertex basis, and use a 1d luminance map as the target for resultant lookup.

I imagine the per-vertex stuff wouldn't be cheap, but it's still using just one combiner stage - no?

Unless I'm remembering wrong it's only a dot 2 operation.

:Edit: Scratch that I remember what the issue is, only one of the inputs can be set up in the shader, the other one comes out of constants.

 

[Li Mu Bai]

According to Gamasutra, it is indeed possible:

Potential Algorithms
Technically many shading methods work on current generation hardware as on the Nintendo Gamecube. These methods include (but are not limited to):

dynamically lit polygons with global and local lights specular highlights
illumination maps
reflection mapping
emboss mapping (shift and subtract of a height field)
bump mapping (per pixel calculations for diffuse, specular and reflective components)
projected shadows
self-shadowing
shadow volumes
projected reflections
layered fog
polynomial texture mapping
displacement maps
multiple texture mapping
custom dithering

http://www.gamasutra.com/features/20021002/sauer_pfv.htm

I doubt any developer has even tried implementing it on the GC, as this tends to be primarily a western exploited tech. aspect. The majority, or perhaps even all of the eastern devs. I have yet to see try, other than possibly Team Ninja.

 

[Fafalada]

Displacement maps are possible on anything with fast enough connection from CPU to the GPU, but given the throughput of current gen hw, they aren't all that much use.

:Edit: Scratch that I remember what the issue is, only one of the inputs can be set up in the shader, the other one comes out of constants.

Yeah I just saw it too - wondering though, if you kept changing that constant matrix memory with every primitive, what kind of speed impact would that have?

 

[ERP]

Some constants on GC are very expensive to set I'd guess they would have a good chance of flushing the backend of the pipeline, but I can't say I've ever tried it.