Support NeoGAF

[Popstar]

What happens if you exceed the 2048 polygon cap then? Nothing?

I don't realize what we're discussing anymore. Or is it the quad thing?

If so I stand corrected.

There is no polygon cap. It's a vertex cap of 6144 vertices.

How many polygons that works out to depends on how you're submitting them.

• Discreet triangles without any vertex re-use? You can have 2048 (6144/3).
• A single big triangle strip? You get 6142 polygons (6144-2).
• Discreet quads without vertex re-use? Down to 1536 (6144/4).
• etc.. etc..

 

[phosphor112]

To my eye they are using dynamic lights added on top of baked lighting. Pretty standard stuff.

Agreed.

That's not how technical discussions work. Give me a source, then we can talk.


I've just watched a playthrough of the nursery, and I'm not convinced that that's true. There are dynamic lights, but I'm not seeing any obvious light bounces. Even if they were experiencing radiosity, lighting is linear, so it's possible to bake bounce patterns for pre-computed lights separate from your main light map. For instance, Halo 3 flashes its GI-computed lights at the end of the level Crow's Nest. It does it with pretty much the entire light map, so almost everything on-screen visibly dims, but you could easily engineer a system that stores multiple light maps and flashes them independantly when desired based on the behaviour of their associated "lights". Actually, the portal-based engines used in some mid-90's games also allow for basic hand-made animated "global illumination" using built-in flicker patterns and the ability to modify light levels on particular surfaces and simple volumes (not that this is useful for modern engine development, but it's a cool historical footnote in computer graphics).

What's really interesting and a hallmark of what would be considered real-time GI is when lights whose location can change in a non-preplanned way experience radiosity... and honestly, some lights placed by the player in ZombiU are blatantly obviously not experiencing any GI at all. For instance, look at when the pad is pulled out at around 22:20. That's an extremely vibrant blue dynamic light, and it seems very clear that the only illumination from it is direct. It's casting shadows, but a light that bright *should* absolutely be casting bounced light all over the room, especially since it's a player-controlled light and therefore worth devoting real-time GI resources toward.

Yep, this gives it away.

 

[lostinblue]

It's not a polygon cap. It's a vertex cap of 6144 vertices.

How many polygons that works out to depends on how you're submitting them.

• Discreet triangles without any vertex re-use? You can have 2048 (6144/3).
• A single big triangle strip? You get 6142 polygons (6144-2).
• Discreet quads without vertex re-use? Down to 1536 (6144/4).
• etc.. etc..

Ah, that. So we count vertices instead of polygons?

Ok; How many does that amount to in realworld scenarios though? I'm still staying by my argument that... say, DK64 should be a hard fit onto the DS when it comes to polygons per frame.

 

[sangreal]

To those discussing the lighting in ZombieU, if this is of any help, the lighting system used in the game isn't something made by UBI, instead it uses a middleware app called Beast, from autodesk.

Since this is part of Gameware, Beast is free to developers as part of the agreement between Autodesk and Nintendo.

That said, Beast is an very amazing piece of software.

You sure about that? From autodesk's PR:

Under terms of the agreement, Autodesk, Inc. has granted Nintendo the right to provide licensed Wii U game developers with three Gameware products: Autodesk Scaleform middleware for user interface development, Autodesk Kynapse middleware for artificial intelligence and Autodesk HumanIK middleware for interactive character animation.

 

[frankie_baby]

So you tech experts look at this. On this site their resident tech gurus seem to have solve the Ram bandwidth issue. Go check out the last 5 pages or so and see what you think... Are they crazy?

http://thewiiu.com/topic/6973-wii-us-ram-is-slower-than-ps3xbox-360/page-9#entry189991

OH WOAH!!! Well some of them certainly sound like they know what they're talking about, could the 12.8 be debunked


Edit - or maybe not (just seen forth storm's reply)

 

[lord pie]

If the lighting was truly backed, you would have a... well, you wouldn't have a light with a varying intensity, or it would look like the projections on the rave, with the lighting behind being constant an then the projections being there, moving, on or off, but not the effect that you actually have.

Unless you placed a dynamic light in the same place as a baked light. So the combined effect at runtime was a light that appears to change intensity, but is only changing intensity in its direct lighting component.

Once again, pretty standard stuff.

...

Not surprised it is uses Beast. While watching a video of the game earlier I was thinking it looked very much like Beast - by the artefacts

 

[Popstar]

Ah, that. So we count vertices instead of polygons?

Ok; How many does that amount to in realworld scenarios though? I'm still staying by my argument that... say, DK64 should be a hard fit onto the DS when it comes to polygons per frame.

I'm not really going to get into that discussion, I just felt the need to correct your 2048 triangle cap/NDS<N64 argument since you kept repeating it.

I will note that if you look at the Maya screenshot of the Mario 64 mesh you posted earlier, it does give a vertex count.

 

[lostinblue]

I'm not really going to get into that discussion, I just felt the need to correct your 2048 triangle cap/NDS<N64 argument since you kept repeating it.

Ok, thanks for your contribution anywho.

I will note that if you look at the Maya screenshot of the Mario 64 mesh you posted earlier, it does give a vertex count.

Yes, I know. It's the "Verts" entry.

I model, but I never optimized for games/game limitations.

 

[freezamite]

Agreed.


Yep, this gives it away.

This gives NOTHING away. The fact that the scanner isn't casting a radiosity effect, which in part is explained by the fact that it's a special light that no one besides the player can see, doesn't prove that there isn't any dynamic radiosity light on the game, like you are trying to imply.
What matters is that this game has dynamic radiosity lights, not only pre-backed ones.

There are dynamic lights, but I'm not seeing any obvious light bounces. Even if they were experiencing radiosity, lighting is linear, so it's possible to bake bounce patterns for pre-computed lights separate from your main light map. For instance, Halo 3 flashes its GI-computed lights at the end of the level Crow's Nest. It does it with pretty much the entire light map, so almost everything on-screen visibly dims, but you could easily engineer a system that stores multiple light maps and flashes them independantly when desired based on the behaviour of their associated "lights". Actually, the portal-based engines used in some mid-90's games also allow for basic hand-made animated "global illumination" using built-in flicker patterns and the ability to modify light levels on particular surfaces and simple volumes (not that this is useful for modern engine development, but it's a cool historical footnote in computer graphics).

This could explain the light effect, not the lantern effect. And let's be realist here, how many light maps would be needed to do that? At least, 1 for light source, and it would be something expensive to do (it was in Mirror's Edge without any dynamic lights, imagine now in ZombiU).

Look at the video I posted before, at 4:06 more or less is when the effect is more notorious.
Once the door is opened, and the light stops to rebound on the door, the lighting of the frame changes completely. This is not pre-backed at all. You can't pre-backe lighting for every player or dynamic object animation.

Unless you placed a dynamic light in the same place as a baked light. So the combined effect at runtime was a light that appears to change intensity, but is only changing intensity in its direct lighting component.

Once again, pretty standard stuff.

Can you explain me how you achieve the lantern effect using pre-backed lighting? Or how it can react to the fact of the door being opened or closed? Well, you could erase the lightmap from the memory once the event of opening the door is triggered, but then again, there is the lantern effect to support the fact that it's real time illumination we are dealing with.

 

[phosphor112]

This gives NOTHING away. The fact that the scanner isn't casting a radiosity effect, which in part is explained by the fact that it's a special light that no one besides the player can see, doesn't prove that there isn't any dynamic radiosity light on the game, like you are trying to imply.
What matters is that this game has dynamic radiosity lights, not only pre-backed ones.


This could explain the light effect, not the lantern effect. And let's be realist here, how many light maps would be needed to do that? At least, 1 for light source, and it would be something expensive to do (it was in Mirror's Edge without any dynamic lights, imagine now in ZombiU).

Look at the video I posted before, at 4:06 more or less is when the effect is more notorious.
Once the door is opened, and the light stops to rebound on the door, the lighting of the frame changes completely. This is not pre-backed at all. You can't pre-backe lighting for every player or dynamic object animation.

You don't know what you're talking about. That's post processed color grading from entering the new room/area.

 

[freezamite]

You don't know what you're talking about. That's post processed color grading from entering the new room/area.

Well, I think it's pretty obvious that you're trolling here. How can this be "color grading from entering the new room" if I'm talking of the lighting of the lantern rebounding on the door while the player is using the lockpick?
It's pretty obvious to me who is the one that has no clue about what he is talking about.

PD: Now that I look at the video... where do you see the color grading effect when he enters the new room? There isn't any sort of HDR lighting there...

 

[HTupolev]

The Scanner is a strong-direct light, it of course doesn't have a radiosity effect.

What is that even supposed to mean? Why should a strong direct light not bounce off of surfaces?

Well, I think it's pretty obvious that you're trolling here. How can this be "color grading from entering the new room" if I'm talking of the lighting of the lantern rebounding on the door while the player is using the lockpick?
It's pretty obvious to me who is the one that has no clue about what he is talking about.

PD: Now that I look at the video... where do you see the color grading effect when he enters the new room? There isn't any sort of HDR lighting there...

Colour grading just means adjusting colour balance. Light-level acclimation is not the only sort of grading (and actually, it's entirely possible for light-level acclimation to exist in non-HDR games).

I'm not convinced that there's actually any light rebounding from the player's source in that lockpick scene you referenced. The player's light has a pretty wide casting field; In the ZombiU videos I've seen, it's quite common for there to be a spot of light reflecting off of the wall next to the player.

 

[freezamite]

What is that even supposed to mean? Why should a strong direct light not bounce off of surfaces?

Because it's a special light that even Zombies can't see. Or maybe because with a big and strong light like that, implementing radiosity would be too expensive and the framerate would fall.

Colour grading just means adjusting colour balance. Light-level acclimation is not the only sort of grading (and actually, it's entirely possible for light-level acclimation to exist in non-HDR games).

Exactly, and an effect like this would affect ALL the colors of the scene, and not only the frame of the door.

I'm not convinced that there's actually any light rebounding from the player's source in that lockpick scene you referenced. The player's light has a pretty wide casting field; In the ZombiU videos I've seen, it's quite common for there to be a spot of light reflecting off of the wall next to the player.

The light halo is to close to the door to be affecting the frame directly. Furthermore, it turns greener...

Let's explain it with images from this 1080p video:
http://www.youtube.com/watch?v=OvBJzRJFhNY

At first, with the light rebounding:

The same, from a different perspective:

Pay attention at the fact that I grabbed this picture when the environmental light was at the minimum intensity, so it doesn't interfere with the lantern effect.

From an instant later. The light of the lantern has moved, still no additional lights from behind, and it's pretty obvious to me that the frame of the door is lighted in a different way, according to the rebound of the light on the door.

Now the back light is on and at maximum strength, of course, this is what happens:

The end of the animation, the bakclight is at minimum again, or at leas with much less strength, and it's pretty clear that the frame's illumination has moved accordingly with the halo of the lantern, even when it's not directly hit by it.

Now the door starts to open:

And now, its opened enough for the light not to rebound on it. The player position hasn't changed at all, you still don't have control over the player at that point.

Pretty obvious to me.

 

[ArchangelWest]

OH WOAH!!! Well some of them certainly sound like they know what they're talking about, could the 12.8 be debunked


Edit - or maybe not (just seen forth storm's reply)

They seem to be rather knowledgeable to me. If they are wrong, I'm open to hearing why in a real and nondismissive way...

 

[phosphor112]

Because it's a special light that even Zombies can't see. Or maybe because with a big and strong light like that, implementing radiosity would be too expensive and the framerate would fall.



Exactly, and an effect like this would affect ALL the colors of the scene, and not only the frame of the door.


The light halo is to close to the door to be affecting the frame directly. Furthermore, it turns greener...

Let's explain it with images from this 1080p video:
http://www.youtube.com/watch?v=OvBJzRJFhNY

At first, with the light rebounding:

The same, from a different perspective:

Pay attention at the fact that I grabbed this picture when the environmental light was at the minimum intensity, so it doesn't interfere with the lantern effect.

From an instant later. The light of the lantern has moved, still no additional lights from behind, and it's pretty obvious to me that the frame of the door is lighted in a different way, according to the rebound of the light on the door.

Now the back light is on and at maximum strength, of course, this is what happens:

The end of the animation, the bakclight is at minimum again, or at leas with much less strength, and it's pretty clear that the frame's illumination has moved accordingly with the halo of the lantern, even when it's not directly hit by it.

Now the door starts to open:

And now, its opened enough for the light not to rebound on it. The player position hasn't changed at all, you still don't have control over the player at that point.

Pretty obvious to me.

You see the blue cabinet? Even THAT has more green than blue in it.

 

[HTupolev]

Or maybe because with a big and strong light like that, implementing radiosity would be too expensive and the framerate would fall.

Lighting model is expensive, not luminosity. The light itself isn't a gigantic thing that casts light over an unusually gigantic area; if the flashlight can be bounced, so should it.

Exactly, and an effect like this would affect ALL the colors of the scene, and not only the frame of the door.

Everything in the scene is pretty green...

Let's explain it with images from this 1080p video:

You make a good argument, but I'm not sure you've accounted for all the variables at play. It's absolutely true that the lighting on the door frame would shift with respect to the flashlight if it was the result of radiosity, but it's also true that it would shift if it was the direct result of the flashlight.

However, the main reason I'm skeptical is that there's a lot happening with the light in that scene. Go back and look at your third-person images, and look at how wide and bright the light source is and look at how it has several components. Now look at these shots from about 7:13 in the video:

The door has barely moved, but the light cast on it is clearly missing that lower bright component that it had in the other shots. And isn't the door's angle too small for the GI to be totally missing? And if the light is the same, why is the direct lighting on the wall around the door frame pretty much gone (not to mention the left wall, which was earlier quite illuminated even in your minimum environmental illumination shot)?
From what I can tell, during the transition from third-person to first-person, the light source rotated significantly and lost a major component, or changed in some other major way that would have an effect like that. Your argument that the light was rebounding but stopped due to door movement doesn't seem to be very strongly supported by the video when viewed in full, I think.

 

[sangreal]

You see the blue cabinet?

Looks green to me. I probably need to calibrate my monitor

 

[Zoramon089]

You see the blue cabinet? Even THAT has more green than blue in it.

37 > 44?

 

[Popstar]

They seem to be rather knowledgeable to me. If they are wrong, I'm open to hearing why in a real and nondismissive way...

Which post has their final math?

 

[sangreal]

37 > 44?

49 > 44.

 

[Zoramon089]

49 > 44.

Oh wow, I'm not sure what I was reading. Maybe I was tired, maybe I was *smoke bomb*

 

[JAYSIMPLE]

i have no idea what is going on in here lol. i feel like a seal clapping. can i just say, i really like my wii u lol

 

[freezamite]

You see the blue cabinet? Even THAT has more green than blue in it.

Yes, the game uses this "greening" filter, but my two points still remain true:
1. There is no color grading between the two rooms. This exact "greening" filter is applied at the next room, but obviously, since there is a lot more light it's not as prominent as in the previous one.
2. Don't you have anything to say about the screens I posted here? Color grading you say...

The door has barely moved, but the light cast on it is clearly missing that lower bright component that it had in the other shots. And isn't the door's angle too small for the GI to be totally missing? And if the light is the same, why is the direct lighting on the wall around the door frame pretty much gone (not to mention the left wall, which was earlier quite illuminated even in your minimum environmental illumination shot)?

Well, firstly this is an approximation, not high precision real time ray tracing that would be what really could represent how the light really rebounds through the whole scene, so it's obvious that if we look at it closely we will see "strange" lighting behaviours.
With that being said, there are also other factors. The more area the light rebounds, the more calculations you have to do, so it's possible that they cut on that a bit.
There is also the fact that you are illuminating a fraction of the door really, and that the rebounded light won't have that much strength. If you add to that the frame width (it's a really thin object, of only about 10 cm width) it's possible that between one thing and the others the frame not being illuminated is not that strange at all.

Finally, the direct lighting you're seeing in that wall comes from the light of the room. It's supposed to be a flickering fluorescent lamp, which varying values that go from "maximum light" to "completely off". I tried to pick the screens with less light coming from that source, but I was also limited by the fact that I had to grab the screens in certain moments so it could be possible to show how the lighting of the lantern was affecting indirectly the frame of the door.

And the fact that this environmental light is turned off on your pics, the fact that the character and his lantern (the only light source that points to the door at that moment) doesn't move at all, and that the frame lighting varies even when it's an static object (we can argue if the effect is more or less accurate, but that would be another topic) in fact proves the existence of real time radiosity on zombiU.
The only explanation at how the frame goes from "slightly illuminated" when all the environmental lights are at the bare minimum to "not illuminated at all" only because the door is being opened is the rebounded light, I can't think of any other explanation, and obviously color grading is not one of them.

 

[Goodlife]

You see the blue cabinet? Even THAT has more green than blue in it.

 

[HTupolev]

Well, firstly this is an approximation, not high precision real time ray tracing that would be what really could represent how the light really rebounds through the whole scene, so it's obvious that if we look at it closely we will see "strange" lighting behaviours.

I don't see it. The notion that the GI would sample adequetely to fill all appropriate areas of the door frame with light when the door is closed, and then completely miss the entire frame when the door is open by like 2 inches, strikes me as quite bizarre. In fact, if it was that bad, I'd be shocked to not see tons and tons of shimmering artifacts as dynamic lights moved through the environment.

With that being said, there are also other factors. The more area the light rebounds, the more calculations you have to do, so it's possible that they cut on that a bit.

That's true, but limiting your casting range to a couple inches is astronomically more than what most people would call "cutting on that a bit."

There is also the fact that you are illuminating a fraction of the door really, and that the rebounded light won't have that much strength.

And how is that different from what was happening during the lock-picking?

If you add to that the frame width (it's a really thin object, of only about 10 cm width)

Width of an object affects how much light it catches in total, but it shouldn't (on a given pass) affect how much light it catches per area, assuming your lighting model actually makes sense.

Finally, the direct lighting you're seeing in that wall comes from the light of the room. It's supposed to be a flickering fluorescent lamp, which varying values that go from "maximum light" to "completely off". I tried to pick the screens with less light coming from that source, but I was also limited by the fact that I had to grab the screens in certain moments so it could be possible to show how the lighting of the lantern was affecting indirectly the frame of the door.

No, this has to be all wrong. The lamp is flickering with a consistant pattern from the moment the player enters the room. The shots you posted of the lockpick scene when the lamp was at its darkest were taken when the lamp was at the lowest value of its pattern.

For the sudden darkness in the left wall to have been due to a change in the lamp's behaviour, the lamp would have to have suddenly shifted to an entirely new flicker pattern at the exact moment when the player finished picking the lock, one capable of being dropped to much darker light levels. Except we know that it didn't, because we can see it still pulsing on the wall as we see the door open from the first-person view.

The only explanation at how the frame goes from "slightly illuminated" when all the environmental lights are at the bare minimum to "not illuminated at all" only because the door is being opened is the rebounded light, I can't think of any other explanation, and obviously color grading is not one of them.

I've given you the explaination. When the player is picking the lock, there is something that can more or less be described as a strong additional light source on the door.
It's undeniable that there are additional lights in play when the lock is being picked, by the way. See this little guy on the door? He's flopping about all over the place during the lock-picking sequence, but he doesn't exist in the pics I took:

I'm baffled as to why you think a differently-positioned/typed light source (which I've just shown exists in that scene to at least some extent) during a third-person sequence is somehow harder to believe than:
1-Realtime GI that is mega elusive on account of a mind-blowingly poor sample rate and a 2-inch casting distance, and
2-An animated environmental light which carries out a repeating pattern for 15 seconds, but which makes a frame-perfect switch to a darker setting at the exact moment a player finishes an action, before heading back into its regular animation.

If you're really stumbling that hard on the fact that the door frame looks greener when the lamp isn't flickering onto it, it's probably the same reason the door itself looks more saturated when there's less light on it. It looks murkier when dark because it's dark. The difference in hue really isn't what you think it is. Go into an image editor and compare some sample points between shots. I just roughly tested a few points with the image at min and max light, and found that on the inner part of the frame near the door's handle, the hue was about 60 in both images. And the hue on the adjacent wall segment? Floating in the neighborhood of 90 in both images. The hues in the image are actually far more stable between shots than I expected them to be (both in an absolute sense and relative to each other), and don't seem to be changing much due to which lights are illuminating things. This isn't a super scientific approach, but I'm not seeing any sort of green-shifting in the darker image where you're claiming that there's proportionally more green light hitting the door frame.

 

[frankie_baby]

They seem to be rather knowledgeable to me. If they are wrong, I'm open to hearing why in a real and nondismissive way...

Which post has their final math?

reading all their stuff is hurting my head, cant find any final maths they're in agreement with (different chips from different manufacturers is confusing things) but they all seem pretty convinced the presumed bus width (and thus the presumed bandwidth) is completely wrong

 

[blu]

reading all their stuff is hurting my head, cant find any final maths they're in agreement with (different chips from different manufacturers is confusing things) but they all seem pretty convinced the presumed bus width (and thus the presumed bandwidth) is completely wrong

They're doing it upside-down, i.e. trying to estimate the DDR3 BW trough bus widths as seen on the die. That's absolutely unnecessary - we know the exact DDR3 chip setup. It doesn't matter what bus that is connected to - the chips cannot produce more than their factory rating (if used to specs, that is).

 

[The_Lump]

Question is, who's eggheads are right? I feel a good old fashioned genius-fight coming on...

 

[frankie_baby]

They're doing it upside-down, i.e. trying to estimate the DDR3 BW trough bus widths as seen on the die. That's absolutely unnecessary - we know the exact DDR3 chip setup. It doesn't matter what bus that is connected to - the chips cannot produce more than their factory rating (if used to specs, that is).

did you read the last 5 or 6 pages worth? they seem convinced anandtech made mistakes regarding chip specs

 

[blu]

did you read the last 5 or 6 pages worth? they seem convinced anandtech made mistakes regarding chip specs

We've had DDR3 part numbers from three sources now. They all agree to a very high extent (the only peculiarity being samsung gDDR3 in 1.5V mode in one case).

 

[tkscz]

So why are we using the lighting from Zombi U when the lighting from NintendoLand is WAY better. Different use of lighting effects of course but still.

 

[phosphor112]

So why are we using the lighting from Zombi U when the lighting from NintendoLand is WAY better. Different use of lighting effects of course but still.

This guy thinks ZombiU has GI effects like radiosity, when all he's doing is trippin balls over nothing. He's basically looking at dynamic light sources that are huge and kinda(!?) looking like radiosity.

 

[tkscz]

This guy thinks ZombiU has GI effects like radiosity, when all he's doing is trippin balls over nothing. He's basically looking at dynamic light sources that are huge and kinda(!?) looking like radiosity.

We had a talk about this on the old WUST, but we used NintendoLand rather than Zombi U. Ultimately no radiosity in NintendoLand, but at points it can really look like it.

 

[phosphor112]

We had a talk about this on the old WUST, but we used NintendoLand rather than Zombi U. Ultimately no radiosity in NintendoLand, but at points it can really look like it.

I think with NintendoLand's art style, radiosity is completely unnecessary.

 

[Donnie]

did you read the last 5 or 6 pages worth? they seem convinced anandtech made mistakes regarding chip specs

I haven't read the entire page, but I spotted an obvious mistake in the argument they're putting across.

One of them found this memory module and believe its a WiiU memory chip. The argument is that because its the same chip used in XBox 360 then it must have more bandwidth then we think.

There's a few problems with that, for one WiiU has 4 RAM chips and 360 has 8. So even if it was the same chip it would have lower combined bandwidth. Secondly that chip is a 512Mbit chip (64MB) while WiiU uses 512Mbyte chips (4096Gbit). If WiiU had 4 of those it would only have 256Mbytes of RAM.. The reason for the confusion is that its actually a Wii memory chip not WiiU. Wii uses a single one of those chips, 64Mbyte GDDR3 while 360 uses 8 of them for 512MByte (64Mbyte x8).

Basically they're getting very confused here.

 

[joesiv]

We had a talk about this on the old WUST, but we used NintendoLand rather than Zombi U. Ultimately no radiosity in NintendoLand, but at points it can really look like it.

And this is really how it's always been in computer graphics, find great aproximations that can look close enough to the much more processing intensive (and unfeasible at the moment) ideal simulation. Hence why shaders exist, shadow maps exist, and pretty much every graphic technique lol.

In the end, who cares, as long as it looks good. For example Unreal 4's new demo, no GI, who cares, it looks frackin awsome.

 

[blu]

And this is really how it's always been in computer graphics, find great aproximations that can look close enough to the much more processing intensive (and unfeasible at the moment) ideal simulation. Hence why shaders exist, shadow maps exist, and pretty much every graphic technique lol.

In the end, who cares, as long as it looks good. For example Unreal 4's new demo, no GI, who cares, it looks frackin awsome.

I care. I've taken the path of radiance these days, wielding a probabilistic zweihander, so mind my swings : )

 

[Donnie]

My best guess at the 32 MB eDRAM bandwidth is 70.4 GB/s. That's at 550 Mhz on a 1024-bit bus. Actually, I'd call it more than a guess, because looking at the arrangement of the interface and counting the connectors seems to confirm.

The 2 MB eDRAM and 1 MB SRAM should be in line w/ their Wii counterparts. Marcan claims these are currently off limits to devs though (and I have no reason to not believe him), so it's kind of a moot point. It sure would be interesting if they could find a way to take advantage of those pools for Wii U mode in the future.

The topic of the caches is quite interesting, especially given the comments on how memory was a major focus in this machine. I find it disconcerting that we cannot positively identify L1 and L2 texture caches yet, as they could go a long way in mitigating the modest speed of the DDR3 when it comes to feeding the TMUs. Block D is a good guess for the L2 cache, but then where is the L1? Did Nintendo streamline the pipeline so that it's not really necessary? Seems unlikely. I have an alternative theory that Block D actually houses the Instruction Cache and Constant Cache. These all need to be accounted for somehow.

The 1MB and 2MB pools might just be used as standard caches when in WiiU mode. Typically a traditional cache wouldn't be accessible by the developer after all, it just does its work automatically.

 

[Donnie]

I don't see why you guys always quote Shin'en. Everything that isn't the Wii U is limited by bandwidth, NOT latency. Latency is still important, yes. That's why Durango has eSRAM and why PS4 has heavy cache and bus customizations to avoid GDDR5 problems, but when it comes to games. Bandwidth is the biggest issue because most of the processing is graphics.

Everything is limited by both latency and bandwidth. I mean its not as if they're separate things, real world bandwidth is always effected to some degree by latency. You can have two memory pools with the same theoretical bandwidth, but if one has higher latency its going to have a lower real world bandwidth than the other (to varying degrees depending on the task).

 

[Nostremitus]

I haven't read the entire page, but I spotted an obvious mistake in the argument they're putting across.

One of them found this memory module and believe its a WiiU memory chip. The argument is that because its the same chip used in XBox 360 then it must have more bandwidth then we think.

There's a few problems with that, for one WiiU has 4 RAM chips and 360 has 8. So even if it was the same chip it would have lower combined bandwidth. Secondly that chip is a 512Mbit chip (64MB) while WiiU uses 512Mbyte chips (4096Gbit). If WiiU had 4 of those it would only have 256Mbytes of RAM.. The reason for the confusion is that its actually a Wii memory chip not WiiU. Wii uses a single one of those chips, 64Mbyte GDDR3 while 360 uses 8 of them for 512MByte (64Mbyte x8).

Basically they're getting very confused here.

Their argument is that each wii u chip has four of those in it.
They're also saying that later 360s also had 4 chips by combining the same way. I don't know enough about it to have an opinion though.

 

[Donnie]

Their argument is that each wii u chip has four of those in it.
They're also saying that later 360s also had 4 chips by combining the same way. I don't know enough about it to have an opinion though.

Ah right thanks, strange idea that, totally wrong as well as memory chips simply don't work like that. Even if they did it would leave WiiU with only 1GB of RAM (64Mbyte chips x 4 per main chip x 4 chips = 1024Mbytes). So its a flawed idea on a few levels.

 

[Popstar]

I took a glance and it seems like they're trying to find the width of the data bus by counting traces. Even though that's not going to tell them anything since not all the traces will carry data. There's power, GND, commands, address, etc. etc.

 

[freezamite]

I'm baffled as to why you think a differently-positioned/typed light source (which I've just shown exists in that scene to at least some extent) during a third-person sequence is somehow harder to believe than:
1-Realtime GI that is mega elusive on account of a mind-blowingly poor sample rate and a 2-inch casting distance, and
2-An animated environmental light which carries out a repeating pattern for 15 seconds, but which makes a frame-perfect switch to a darker setting at the exact moment a player finishes an action, before heading back into its regular animation.

An additional light for the 3rd person sequence would be a reasonable explanation.
I've done some experiments with the lantern in ZombiU, and it doesn't seem to have the radiosity effect that the environmental lights do have.

All in all, this is by no means "year 2000" lighting.

 

[mrgreen]

Where did you even here that? Who ever told you that is so wrong it's ridiculous.

I wrote it down wrong. I said "half as powerful again" as the 360. I didn't mean is the WiiU only half as powerful as the 360, I meant as powerful as the 360 + half as powerful on top (that would be 1.5 times as powerful, then?) I have been told the answer, just clearing something up.

Considering how little power the WiiU uses we really must not be far away from mobiles that have more graphical power than the 360/PS4.

 

[Fourth Storm]

The 1MB and 2MB pools might just be used as standard caches when in WiiU mode. Typically a traditional cache wouldn't be accessible by the developer after all, it just does its work automatically.

This could be. I don't know how useful the 2 MB pool would be. It appears that is only hooked up to a 256 bit bus, so while latency should be pretty low, so should the bandwidth. It does seem perfect to use as a Gamepad framebuffer, though. To include it just for the sake of BC and not have any other function seems like a huge waste of money and die space.

That 1 MB SRAM otoh could in theory be very high bandwidth, so perhaps it is being used as a texture cache in Wii U titles and doing its work automatically. I read that some of the texture cache on Flipper could be locked at least partially, though, so that would seem to indicate that devs would have some type of control over it.

 

[wsippel]

This could be. I don't know how useful the 2 MB pool would be. It appears that is only hooked up to a 256 bit bus, so while latency should be pretty low, so should the bandwidth. It does seem perfect to use as a Gamepad framebuffer, though. To include it just for the sake of BC and not have any other function seems like a huge waste of money and die space.

That 1 MB SRAM otoh could in theory be very high bandwidth, so perhaps it is being used as a texture cache in Wii U titles and doing its work automatically. I read that some of the texture cache on Flipper could be locked at least partially, though, so that would seem to indicate that devs would have some type of control over it.

256bit? What pins did you count? The things I believe should be the interface pins are pretty tiny and hard to count precisely, but the closest ballpark seems to be 512 - per macro. So 2048bit for the 2MB pool.

 

[krizzx]

Interesting. What is the throughput per pin? I was reading that page on the other forum that was posted in here and they stated what looked like a fairly well written argument regarding the pins and bandwidth limit. It was all about the pin count.

I wouldn't go so far as to take that one posted 31.6 GB/s to heart but it was interesting nonetheless.

 

[milsorgen]

I wrote it down wrong. I said "half as powerful again" as the 360. I didn't mean is the WiiU only half as powerful as the 360, I meant as powerful as the 360 + half as powerful on top (that would be 1.5 times as powerful, then?) I have been told the answer, just clearing something up.

Considering how little power the WiiU uses we really must not be far away from mobiles that have more graphical power than the 360/PS4.

I believe nVidia has stated the next mobile hardware cycle will be.

 

[chaosblade]

I believe nVidia has stated the next mobile hardware cycle will be.

They're also talking out their ass. WiiU has low power consumption, but tablets are still somewhere around an order of magnitude less than that. There's no way they're going to pack a WiiU into a tablet form factor. Let alone phones.

 

[lostinblue]

I believe nVidia has stated the next mobile hardware cycle will be.

Oh, I remember the Tegra 3 level of promises.