Seriously? At any point are you even going to ATTEMPT to read any material at all on what you are trying to argue about?

 

Ambient occlusion is NOT an effect that is 'usually used in ios games', in fact, it hasnt been used in ANY ios games, because until recently mobile phones havent had the power or battery to do it.

 

Modern combat 5 is the first actual game to do it, bragging out the wazoo for using the effect, and it hasnt even released yet. http://toucharcade.c...raphics-tricks/

 

 

Killzone shadow fall uses ambient occlusion, windwaker hd uses ambient occlusion, bayonetta 2 uses it, ryse son of rome uses it, infamous second son crows about using it in several interviews, the only people who dont brag about using ao as part of their global illumination solution, are using sparse voxel octree gi, but oh wait, no ps4 game out yet uses it because it can barely handle it, so the ps4 uses ambient occlusion instead.

 

It doesnt bother me that you have no idea what you are talking about. It does, however, bother me that youve argued this clueslessly about it, this long, without even ATTEMPTING to look up what you are arguing about, instead making up blatant lies like, 'hurrr thats an effect they use on cell phones!!!'

 

Thats crap. Do not lie to me because you dont feel like looking something up.

 

You dont understand how physical lighting works, and only notice a difference between how standard primitive local lighting works and thus think vastly superior global lighting is wrong. Its not.

 

Global illumination>>>>>>>>>>>>>>>>> local lighting.

 

That darkness where light doesnt bounce where the sand meets the concrete is physically correct, and fantastic use of ambient occlusion, which is NOT a 'cell phone only technique'.

 

Hell, anyone can look at any corner between walls in their house and see the effect ao simulates.

 

You have a LOT of reading to do.

 

 

 

 

 

1. Shin en THEMSELVES told you they arent using tesselation for the environment. https://mobile.twitt...99301386240?p=v

 

Thats it dude. Its not tesselated.

 

2. What does any of that have to do with ibl? 

3. Do you know what ibl is?

4. If you bothered to look up and copy vomit all that unrelated material, why didnt you just look up ibl?

 

Shin en said no to tesselation, here is why:

The wii u has geometry shaders, while its above and beyond ps3/xbone... Its not up to snuff to gcn architecture like xbone and ps4 are using, so, as shin en said, its not some crazy 'get tons of vertice detail for free card' like people seem to think. Geometry shaders CAN do some good tesselation, but its not their primary purpose, which is too evaluate primitives or interpolate values. Again, they can do it, but they are limited, there is an in process upper bounds on the number of output elements, and the execution must stay within the shader. Instancing can speed up the second issue, but any way you slice it, its not something you want to try and use on a large environment with geometry shaders, especially if you are going for a 60fps target, thats what tesselation shaders are for. Which shinen actually more or less said in an interview asking about tesselation.

 

It would, however, work pretty well with a small number of objects like say the in game vehicles. Its probably used for detail work on the close lod's of the vehicles.

 

and where exactly shinsn claims that they did not use tesselation or dispalcements(i have gone to the link and they dont mention anything you say)?

already shinen had said that they were preparing a game for wii u and they would use tesselation, and you can tell just by looking at the image that this game is using it; the level of detail of the rocks its pretty good and also there is internal occlusion and the silhoutte shadow corresponds pretty well with the bump areas, with normal mapping and bump mapping is not possible to achieve that, even less with objects that are parallel to our view; the geometry looks real, its not difficult to see that its not a trick of light that normal mapping and bump mapping use to fake it. We can also see that the terrain and the rocks have pretty good amount of vertices elswhere that give a good LOD, and to form finer pieces you need tesselation, and tessleation oftenly works along with displacment according to nvidia

parallex occlusion could have been a possibility if the terrain wasnt oblique. Oblique angels cause artifacts with parallex occlusion

Dang. Almost forgot about this game.

Hope it looks good.

WW know on a technical level, it will be impressive under the hood.

But it is possible to do everything right and "miss" the boat based in public perception of what art style looks nice.

You look at Project Cars for example and it looks unbelievable.

But the art style is realistic. So it's a certain target.

Fast racing is going for a sci if futuristic look with high res sharp textures.

There is going to be a priority on speed, so it goes without saying there wil need to be some trade offs.

However, this is a team that is known for maximizing what is available.

So once again highly interested. Though the shifting timetables always seem to affect enthusiasm.

oh it does, here

it loos pretty good to me, the terrain and the rocks have pretty good lod and judging by the geometry and the shadows seems they used tessellation with dispalcements here

So you have no idea what ibl is then.

 

Guy, you specifically said 'That must be tesselation' (from sand dunes 30 meters away, and a rock formation 500+ meters awat lol)

 

And they said ' We used a lot of 3D scanning. Great results but hard to work with >1GB files for a single mesh...' '. From these we process them to game compatible assets.'

 

 

Thats NOT tesselation guy, tesselation is the subdivision of primitives, into more vertices, in real time on the games runtime.

 

NOT scanning a real or high end 3d render image to get a result and then approximating it to usable game assets, thats image based.

 

Oh, and obviously ambient occlusion dingleberry, its not dependant on geometric complexity, and its not part of any texture map, and works from any visible angle.

 

Mind you, what if they used 3d scanning?

here

http://www.academia....acement_Mapping

"

Domain surface and a scalar displacement map

One application of displacement mapping that will be looked at more closely is displaced subdivision surfaces (Lee et al, 2000). It is used for describing surface of highly detailed models that are generated by 3D scanning devices. This method greatlyreduces memory requirements for the model, as it requires only a relatively simpledomain surface and a scalar displacement map.

"

Another example

http://research.micr...e/hoppe/dss.pdf

"

Displaced Subdivision Surfaces

ABSTRACT

In this paper we introduce a new surface representation, the

displaced subdivision surface. It represents a detailed surface

model as a scalar-valued displacement over a smooth domain

surface. Our representation defines both the domain surface and

the displacement function using a unified subdivision framework,

allowing for simple and efficient evaluation of analytic surface

properties. We present a simple, automatic scheme for converting

detailed geometric models into such a representation. The

challenge in this conversion process is to find a simple

subdivision surface that still faithfully expresses the detailed

model as its offset. We demonstrate that displaced subdivision

surfaces offer a number of benefits, including geometry

compression, editing, animation, scalability, and adaptive

rendering. In particular, the encoding of fine detail as a scalar

function makes the representation extremely compact.

1. INTRODUCTION 

An alternative is to express the detailed surface as a displacement

from some simpler, smooth domain surface (see Figure 1).

Compared to the above, this offers a number of advantages:

(1) the patch structure of the domain surface is defined by a

control mesh whose connectivity is much simpler than that of

the original detailed mesh;

(2) fine detail in the displacement field can be captured as a

scalar-valued function which is more compact than traditional

vector-valued geometry;

A simple example of a displaced surface is terrain data expressed

as a height field over a plane. The case of functions over the

sphere has been considered by Schröder and Sweldens [33].

Another example is the 3D scan of a human head expressed as a

radial function over a cylinder. However, even for this simple

case of a head, artifacts are usually detectable at the ear lobes,

where the surface is not a single-valued function over the

cylindrical domain.

The challenge in generalizing this concept to arbitrary surfaces is

that of finding a smooth underlying domain surface that can

express the original surface as a scalar-valued offset function.

"

Here you have a prctical use of 3d scanning with displacement

http://pixelsix.net/...tivePlay.3Dscan

"

3D Scanning

For my personal scanning results go to link

Friedrich's Milkscanner

The Milkscanner is a free tool that allows the scanning of objects and creates a Displacement map for use with Moviesandbox or any other 3D App that would allow for displacement mapping.

"

here is another if you dont like that one

http://www.surfacemimic.com/gallery/

"

Welcome!

"

Considering the above and this reply from Shinen:

"

"

Its obvious that the 3d scanning would later be converted to compatible meshes and they would later process them with tesselation and other stuff

As for the rest you are claiming, there are level of detail you know, its obvious they are using displacements and tesselation cause the geometry feels real not a fake using lighting tricks like bump or normal maps which are easy to tell in parallel objects?

http://www.nvidia.co...-bundle-uk.html

so are you saying taht the rocks and mountains in fast racing neo look like the image in the left side?

here more examples

is the ground in fast racing neo plane or detailed ith true geometry?

you can also tell that is diplacment and not bump or normal mapping cuase these ast 2 just simulate depth with light and if you look closely looks plane specially in parallel objects, and also the shadows of the objects would not reflect the bumps on the edges while diplacement does; looking closely to the shadows we can see that hey in fact respect the bumps of the edges of the objects

Displacement mapping is a technique for adding geometric detail to surfaces at render time. In contrast with bump mapping, which works by just changing the surface normal to create the illusion of surface detail, displacement mapping modifies the surface itself.Here is an example of the same object rendered with bump mapping and with displacement mapping:

                                     Original object                                                                                        Bump mapping

                                                                                   Displacement mapping

In the case of displacement mapping, the surface is actually modified, which leads to correct outline, shadow and GI. In the case of bump mapping, although the surface appears modified, the outline and the shadow stay the same.

Note that displacement is different from other kinds of shading, since it needs to modify the actual object surface. Therefore an object must be displaced before it can be rendered. This is why in V-Ray displacement is represented with a modifier (although the modifier can take the displacement map from the object material).

Sorry dude, you did this to you on your own

well, i have read the differences between displacement mapping and other techniques like bump mapping and normal mapping and in this picture its clear they are using dispalcement map

the difference is simple, bump mapping doesnt create geometry, it jst creates the illusion of a bump using lighting tricks

http://www.3dtutoria.../tutorial?id=10

"

What Is The Difference Between Displacement And Bump Maps?

A displacement map is real geometry (polygons), while a bump map is tricks of light to make it look like it has real geometry. Normal maps are like bump maps, as in the way they both trick the light, but normal maps actually change the surfaces normals and bend the light. Bump map renders faster but you do lose quality. Normal maps are used more in low poly games. Displacement maps, because of their longer render time, are mostly used on objects that need high level detail.
(NOTE; To see a bump map or a normals map in the view port, on the view port menu, go to shading>hardware texturing. Still on the view port rendering, now go to renderer>high quality rendering. Now you can see it in the view port.)

Bump Map

Bump map is best used for when adding "texture" to a model. Example; cloth, pores, surfaces that don't want to look 100% smooth, etc.

A displacement map generates real geometry, unlike some other features in Maya that just trick the bending of light. A displacement map can not be seen in high quality render mode in the view port, but you can convert a displacement map into real geometry you can physically see in the Maya view port.

"

Here is anoher good example with images

http://help.chaosgro...isplacement.htm

"

What is displacement mapping?

Displacement mapping is a technique for adding geometric detail to surfaces at render time. In contrast with bump mapping, which works by just changing the surface normal to create the illusion of surface detail, displacement mapping modifies the surface itself. Here is an example of the same object rendered with bump mapping and with displacement mapping:

                                     Original object                                                                                        Bump mapping

                                                                                   Displacement mapping

In the case of displacement mapping, the surface is actually modified, which leads to correct outline, shadow and GI. In the case of bump mapping, although the surface appears modified, the outline and the shadow stay the same.

Note that displacement is different from other kinds of shading, since it needs to modify the actual object surface. Therefore an object must be displaced before it can be rendered. This is why in V-Ray displacement is represented with a modifier (although the modifier can take the displacement map from the object material).

"

limitaion of bump mapping vs dispalcement

https://diglib.eg.or...df.abstract.pdf

"

Bump mapping does not really alter the underlying geometry,
but only perturbs the normals on the surface. For small irregularities
on a surface, bump mapping is ideal, since it does not increase
the amount of geometry, but gives the impression of real textured
surfaces.

The limitation of bump mapping becomes obvious when
the surface is parallel to the viewer and the Bump does not create a
silhouette. Also as a surface moves in perspective space the shape
created in the viewers mind by the bump map will not occlude other
objects.

To add real geometric detail to a flat surface, displacement mapping,
first introduced by Cook [2], can be used

"

here we have examples with the limitation of normal maps and that they only fake geometry and silhoute does not change

on the other hand here we have the results with displacement mapping

http://stoneschool.c...2004/index.html

"

At left is the basic result: a plane with real displacement mapping. Note that this is not bump or normal mapping; it's true displacement mapping. The silhouette edge is correct, and there are internal occlusions from the displaced surfaces, neither of which you get from bump/normal mapping.

The trick to this is pretty much what the title says: it's doing a discretized ray cast within the volume of the maximum displacement in the GPU. The movie that comes along with the sketch has a pretty clear diagram about what they're doing.

"

We can clearly see in this picture that the rocks do have a true level of detail and that the meshes have correct outline, global ilumination and shadows(you can clearly see that the shadows of the rocks respect the the bumpy areas where bump mapping and normal mapping would not show the shadows of the simulated outline). Plus, eventhough some rocks are parallel to the view, the paralell surface of the rocks do have a corresponding  silhoutte for the bumps, normal mapping and bump mapping have a limitation that would not let them modify the silhoutte of the mesh and in parallel view is very obvious, not to mention that there are internal occlusions in the dispalced surfaces, something that is not possible neither with bump mapping nor with normal mapping

http://hypershadehan...splacement-map/

as for the possibility of being the work of parallax occlusion, well I at first considered it but hs a limitation with oblique angels that produce artifacts that we do not see here

look:

http://udn.epicgames...dedMapping.html

"

Parallax Occlusion mapping

Parallax occlusion mapping adds depth by ray tracing to find the correct texture coordinate based on the camera's view direction. This creates a true perspective correct depth to the material. The occlusion part also means that parts of the height map can occlude other parts which helps to increase the depth. Lastly with self shadowing, more artificial depth is added to the material. Parallax occlusion mapping however is very expensive and generally shouldn't be used everywhere.

The main problem with parallax occlusion mapping is that at oblique angles the ray tracing is often not precise enough to retrieve the correct height map. As you can in the image below, at oblique angles it is easy to have ray tracing miss the correct depth, or find the incorrect depth. This can be resolved by increasing the number of depth passes or by decreasing the height scale. Large height scale also cause the same problem.

"

Dispalcement maps dont have the oblique limitation and steep angles dont represent a probelm either, this and the explanation about the internal occlusion and the shadows that respect the bumpy areas of the surfaces, is why dispalcement map makes more sense for the rendering of the terrain, the mountains and rocks, and also nvidia concurs

http://www.nvidia.co...ssellation.html

"

DirectX 11 Tessellation—what it is and why it matters

A displacement map is a texture that stores height information. When applied to a surface, it allows vertices on the surface to be shifted up or down based on the height information. For example, the graphics artist can take a slab of marble and shift the vertices to form a carving. Another popular technique is to apply displacement maps over terrain to carve out craters, canyons, and peaks.

"

As for tesselation?

Well, we can see that the terrain and the rocks have pretty good amount of small fine vertices pieces in the ground and the rocksproviding a good level of detail, and thats pretty much the work of tesselation; plus, there would be no benefit of using displacement without tesselation cause both need one and the other

http://www.nvidia.co...ssellation.html

"

DirectX 11 Tessellation—what it is and why it matters

Like tessellation, displacement mapping has been around for a long time, but until recently, it has never really caught on. The reason is that for displacement mapping to be effective, the surface must be made up of a large number of vertices. To take the example of the marble carving—if the marble block were made up of eight vertices, no amount of relative displacement between them can produce the relief of a dragon. A detailed relief can be formed only if there are sufficient vertices in the base mesh to depict the new shape. In essence—displacement mapping needs tessellation, and vice versa.

With DirectX 11, tessellation and displacement mapping finally come together in a happy union, and already, developers on jumping on board. Popular games like Alien vs. Predator and Metro 2033 use tessellation to produce smooth-looking models, and developers at Valve and id Software have done promising work on applying these techniques to their existing game characters.

"

Obviously not, the wii u may be fficient and the fixed stream cores may give a boost in performance but still is a step awa in power vs the xbox one and ps4, but despite that the wii u can show pretty good next generation graphics looking games if companies give it a try

I am little busy to chat about hardware capabilities but guess an image tells more than numbers, so here i leave something from shinen

It really looks good to me, specially the terrain and the rocks that have a pretty good level of detail, it would seem shinen is using some tesselation as they promised they would

I am not fan of fatal frame series but i would like this one to come to usa

Good story, wonderful graphics and a bit enjoyable gameplay

I also want to play xenoblade x

it amazes me that some stafff of the eurogamer reporters still call wii u directx10 tech when pretty much directx11 equivalent features like multithreaded rendering(project cars), compute shaders(report from eurogamer secret developers, or the wii u sdk documentation) and other stuff

http://www.eurogamer...ategy-behind-it

"

Digital Foundry on the tech that best matches the Big N's revamped approach to console R&D.

By Richard Leadbetter Published 10/01/2015

The hardware make-up of Nintendo's last console is based on two key components -ancient PowerPC cores from IBM (the presence of which appears to have been dictated mostly by Wii back-compatability), along with DirectX 10-era graphics technology from AMD. While the Wii U was a power-efficient design, its PowerPC CPU architecture would be immensely difficult to scale down to mobile, while AMD left the kind of graphics tech utilised by the Wii U behind many, many years ago.

"

Not to mention that there are wii u games there taht clearly use diretx11 equivalent features and even if the gpu started as a customized rv770 we must remeber that the the hd5000 and hd6000 gpus from amd are basically using the same architecture as the hd4000(rv770) gpus with tiny little changes to improve performance and give directx11 support, since the wii u gpu is custmized is no wonder that nintendo made the necessary changes for next generation graphics support, and this wouldnt be the first time since nintendo also has made modifications on cpu and gpu devices back on the gamecube era, and the gamecube cpu was different than the standard powerpc 750 series of those times

Long time no see... but on topic I can't wait to see this actually in motion. should be sweet. Cool they are delivering and not delaying like project cars and 90's arcade racer but yes I hope this releases before the end of the year?

I am also pretty existed about this game, also the comments from the developer pretty much confirmed that wii u has pretty good capabilities and good amount of edram bandwidth that it can handle triple buffering for the deffered rendering with ease and this technique is known to take a lot bandwidth and crytek knows that since the esram on xbox one is barely enough for the framebuffer of 900p and the gbuffer for the deffered rendering, but with wii u shinen only uses 1/3 of the edram for the triple buffering with g buffers and about 7.1MB of edram for the framebuffer with double buffering, that still leaves almost half main edram for other things

the art style seems to resemble wipeout hd for the ps3

oh god here we go again. Grab the popcorn everyone.

Yeah we seen the pic we have a topic on it.

i see, please give the link cuase I looked for the topic but didnt find it

actually they neither denied it nor directly confirmed it, although 3d scanning gives pretty large assets that would be impossible to fit in ram even with BC1 texture compression(assets of >1GB per mesh are way to big for the wii u ram even with 6x texture compression), and since they say they transform those files into compatible assets its very possible that they used tesselation with dispalcement maps to reduce the memory storage of the original assets, after all they wouldnt be the fiorst ones in taking this approach, and reading thier response again the answer could be taken as a complement to what i mentioned

it really looks great, the lod of the terrain and rocks is pretty good, the geometry looks real and not a fake simulation and also the shadows respect the siluet of the objects with the bumpy areas and the bumpy areas also display a very good amount of fine and small triangle pieces despite being lateral to our view. Seems that they have used tesselation with displacement as they mentioned some time ago that they would use it in one of their games for wii u

3Dude, on 14 Mar 2015 - 1:20 PM, said:

You are making the mistake of thinking bandwidth is the only solution, when your quote itself states '/memory trafficking'.

Nintendo uses low latency for its deferred rendering. Nintendo doesnt need high bandwidth, to send over massive piles of data that build up during latency waits, because there is no waiting on latency. The wii u is also not as powerful as those systems, and doesnt need to trafic a fraction of what GCN does.

Also, that bandwidth is operational bandwidth, it is used specifically FOR calculating each pixel. Yes, you are still confusing operational bandwidth, with what the edram does, which is store and transport. The very fact you keep making quotes ABOUT OPERATIONAL BANDWIDTH, and then referencing it to a storage pool is proof of that.

 

nope, as i said before i consider both latency and bandwidth important factors, neverthless i am giving more focus on memory bandwidth since its the thing that its being more understimated on the wii u edram(take for example shy guy's quote), thats why i brought topics like deffered rendering, g-buffer quotes from shinen like the triple 720p buffering+g-buffer(for deffered rendering)+intermediate buffers, and of course cryteks quote about the memory bandwidth requirements for the deffered rendering to even be a burden for the xbox one esram of 200GB/s

Then get used to walls of those posts a lot in these topics.

Shin'en is,Nintendo of course will,PG did. Published games will and many indies. Big AAA games likely not as they abandoned Wii U but most of them not all but most are not worth it anway. Now smaller publishers that make some great but hidden gems kinda sucks no on Wii U. XCX and Zelda U make Wii U groan like a all night orgy baby.

Besides shinen i would say that those behind fatal frame for the wii u also did good, we also have to wait if devil´s third graphics have vastly improved as itagaki claims and i am also hope that the wii u version of shadow of the eternals is still on the works but right now we only know that Shadow of the eternals development has started again at Quantum Entanglement Entertainment, that was confirmed past year on october 31

http://www.polygon.c...t-entertainment

good news, in the last nintendo direct the new fatal frame V was confirmed for western release

minute 24:40

I cant wait to play it

i was marely talking about memory bandwidth and latency in separate topics, i never did a direct comaprasion between the two, the mentioning of the deffered rendering was due that the technique requires a g-buffer and g-buffers are very well known to be very hungry on memory bandwidth

here

https://hacks.mozill...ferred-shading/

"

Deferred Shading

Deferred shading takes a different approach than forward shading by dividing rendering into two passes: the g-buffer pass, which transforms geometry and writes positions, normals, and material properties to textures called the g-buffer, and the light accumulation pass, which performs lighting as a series of screen-space post-processing effects.

This decouples lighting from scene complexity (number of triangles) and only requires one shader per material and per light type. Since lighting takes place in screen-space, fragments failing the z-test are not shaded, essentially bringing the depth complexity down to one. There are also downsides such as its high memory bandwidth usage and making translucency and anti-aliasing difficult.

"

Crytek also has a mentioning about the memory bandwidth problems with deffered rendering(the tchnique requires g-buffer)

http://wccftech.com/...andwidth-gains/

"

Crytek Shares a Secret Method for Utilizing Xbox One eSRAM’s Full Potential – Resulted In High Bandwidth Gains
Recently, GamingBolt published a snippet of their interview with Crytek’s US Engine Business Development Manager Sean Tracy. Talking about utilization of CryEngine with tiled textures, Tracy talked about the role of Xbox One eSRAM in saving ‘big’ bandwidths, and shared a secret method that the Ryse development used to unlock Xbox One eSRAM’s full potential. He said:

This technique helped the developer a lot in optimizing Ryse: Son of Rome on Xbox One as it resulted into high bandwidth gains and allowed the development team to use just a single compute shader for lighting and culling.

“CryEngine has a unique and novel solution for this and was shipped with Ryse. One of the problems when using Deferred Shading is that it’s very heavy on bandwidth usage/memory traffic. This gets exponentially worse as overlapping lights cause considerable amounts of redundant read and write operations. In Ryse our graphics engineers created a system called tiled shading to take advantage of the Xbox One.”

“This splits the screen into tiles and generates a list of all the lights effective each title using a compute shader. It then cull’s light by min/max extents of the tile. We then loop over the light list for each tile and apply shading.”

“In practice this made for the biggest bandwidth save we could have hoped for, as just reading the Gbuffer once and writing shading results once at the end for each pixel. Only a single compute shader was used in Ryse for light culling and executing entire lighting and shading pipelines (with some small exceptions for complex surfaces like skin and hair).”

"

So, if even the xbox one esram high memory bandwidth of 200GB/s can run into troubles with the bandwidth requirements of the deffered rendering for even to crytek to come up with additional soltions, then how in the world wii u edram could handle the bandwidth requirements of the triple 720p buffering+gbuffer(for the deffered rendering)+intermediate buffes all at 60fps with less then xbox one esram memory bandwidth?

And yea, i already know that gpu have their own tiny memories like lovcal data shares, texture caches and such, thats precisely why i told shy guy that 500GB/s of memory bandwidth is not an overkill for the gpu at all

here

http://developer.amd...nsform-part-ii/

"

Why to use Local Memory?

Local memory or Local Data Share (LDS) is a high-bandwidth memory used for data-sharing among work-items within a work-group. ATI Radeon™ HD 5000 series GPUs have 32 KB of local memory on each compute unit. Figure 1 shows the OpenCL™ memory hierarchy for GPUs [1].

Figure 1: Memory hierarchy of AMD GPUs

Local memory offers a bandwidth of more than 2 TB/s which is approximately 14x higher than the global memory [2]. Another advantage of LDS is that local memory does not require coalescing; once the data is loaded into local memory, it can be accessed in any pattern without performance degradation. However, LDS only allows sharing data within a work-group and not across the borders (among different work-groups). Furthermore, in order to fully utilize the immense potential of LDS we have to have a flexible control over the data access pattern to avoid bank conflicts. In our case, we used LDS to reduce accesses to global memory by storing the output of 8-point FFT in local memory and then performing next three stages without returning to global memory. Hence, we now return to global memory after 6 stages instead of 3 in the previous case. In the next section we elaborate on the use of local memory and the required data access pattern.

"

So, if each local data share on an amd  hd 5000 gpu(wii u is either based on hd4000 to hd6000 sicne there is also a rumor about the e6760, not to mention that from hd4000 to hd6000 are all based on the rv770 architecture) can have as much as 2TB/s of memory bandwidth, why an edram with 500GB/s of memory bandiwdth would be an overkill?

thats precisely why i told shy guy that 500GB/s of edram memory bandwidth wouldnt be a problem for the gpu to handle.

Thanks for  old news we have topics on. No really we needed to be reminded because we can't remember anything from 4 days ago.

haha, sorry, to be honest i just watched the thing yesterday at night since i didnt have time to do it before, on purpose, could you give me the link of the topic?

thanks

I remember that twitter conversation.

Those things are all true, but they are made possible because of the higher capacity of the wii u edram, not because MS pr made a fake claim to a 256 Gb/s bandwidth that they couldnt use for anything they were trying to insinuate, and that we should use that as a basis for the wii u's bandwidth, which is what you constantly come back to say.

Your reasoning is that the new console must have better bandwidth than a half truth claims ms pr made about the 360, ignoring the fact its the Capacity and latency that are far, far, far more important in this case.

latency is important, i know that since the gamecube era, but bandwidth is important factor too, you can read documentation about the importance of bandwidth for deffered rendering using the g-buffer which is very demanding, do not ignore that fact either

"

I dont know where the problem is Megafenix. The eDRAM in WiiU is rumored to be between 35 and 70 GB/s as much i heard. Thats enough. You dont need 500 GB/s... that would be an overkill. And if you remember correctly, Shin'en said in the interview with HD WARRIORS, that bandwidth is not the bottleneck of todays GPU's. Latency is the real problem, and that the WiiU is great at latency.

"

that wouldnt do since g-buffer for defered rendering requires lots of bandwidth, and while shinen commented of bandwidth not being a problem on modern hardware, they were refering to the RAM not the Edram.

https://dromble.word...he-wii-u-power/

"

When testing our first code on Wii U we were amazed how much we could throw at it without any slowdowns, at that time we even had zero optimizations. The performance problem of hardware nowadays is not clock speed but ram latency. Fortunately Nintendo took great efforts to ensure developers can really work around that typical bottleneck on Wii U. They put a lot of thought on how CPU, GPU, caches and memory controllers work together to amplify your code speed. For instance, with only some tiny changes we were able to optimize certain heavy load parts of the rendering pipeline to 6x of the original speed, and that was even without using any of the extra cores.

"

The comment is not refering to the gpu memory and as you know every gpu has their own memory called vram and the wii u edram is basically that, system ram is for other stuff. The bandwidth requirements depend on which techniques you use, if you use forward rendering then you dont need that much memory bandwidth but it costs you lots of processing power, with deffered rendering(confirmed by shinen on fast racing neo) you save up lots of processing power but requires much more memory bandwidth, its a trade-off

here

http://jcgt.org/publ...02/04/paper.pdf

"

The size of the surface attribute buffer—the g-buffer—is typically 16 to 32 bytes per visibility sample in optimized high-quality real-time systems. The DRAM bandwidth consumed in writing this buffer, then reading it for each light pass is signifi- cant, even with only a single light pass. For example, a screen with a four-megapixel display, using four 24-byte samples per pixel at 60 Hz, would consume 46 GB/s of bandwidth, assuming only one lighting pass, just for the uncompressed g-buffer write and subsequent read. Thus, in practice, either anti-aliasing or pixel resolution (or both!) is often sacrificed to maintain high frame rates on economical hardware. This is perhaps the most serious issue with the technique, as low visibility sampling rates confound simple solutions to efficiently rendering partially transparent surfaces, edge anti-aliasing, and higher-dimensional rasterization.

"

thats just an example with one light pass, even xbox one with 200GB/s of sram bandwidth has troubles handling the framebuffer and using a g-buffer(ryse of rome for example which is 900p), 70GB/s of edram bandwidth are very short for wii u edram to handle triple buffering 720p+g-buffer+intermediate buffers in games like fast racing neo and other games as well

As for 500GB being an overkill, no it wouldnt, actually gpus from amd hd4000 to current ones can handle terabytes of bandwidth and i have the proof just under my pocket.

and this is what pisses me off no one is really showing what it is capable of. I hope Retro next game is not a donkey kong game and something more realistic because the hater always use artstyle as to why Wii U games look good. I want something gritty to shut them up.

well, you could show them games like fatal frame, deus ex revolution and such, a good example to show them that wii u is no old tech is with this example between final fantasy with directx11 improvements against fatal frame

Ask them, if this is directx11

then this is directx10?

enjoy some gameplay here

this is also a good example, but surely people would say that cartoony games dont count

Actually what

I remember Shin en says they use about 16Mb for three 720p frame buffers so there is no screen tearing, and have tons of room to use the rest to preload a bunch of stuff, archive a bunch of stuff, use it as a cpu scratchpad...

The Wii u's edram design is a lot different than the 360's, the 360's was on a seperate daughter die with the rops, it only got its full bandwidth with the rops on that die, any other interaction, access or sending data, had to cross the 32Gb/s bridge, and a lot of latency, to get the rest of the system.

THe wii u's is embedded on the same substrate with the rest of system, so it gets its full bandwidth without having to cross a bridge, and doesnt have any of the added latency that comes with that.

The publisher incumbents who decide what games get made, and where, simply dont want the wii u to be a player in their game.

actually what shinen mentioned is that 16MB of edram on wii u is enough for 1080p with double buffering

http://hdwarriors.co...ined-by-shinen/

"

Manfred Linzner of Shin’en:

‘Wii U eDRAM usage is comparable to the eDRAM in the XBOX360, but on Wii U you have enough eDRAM to use it for 1080p rendering.

In comparison, on XBOX360 you usually had to render in sub 720p resolutions or in mutliple passes.

Even if you don’t use MSAA (MultiSample Anti-Aliasing) you already need around 16Mb just for a 1080p framebuffer (with double buffering). You simply don’t have that with XBOX360 eDRAM. As far as I know Microsoft corrected that issue and put also 32MB of Fast Ram into their new console.

We use the eDRAM in the Wii U for the actual framebuffers, intermediate framebuffer captures, as a fast scratch memory for some CPU intense work and for other GPU memory writes.

Using eDRAM properly is a simple way to get extra performance without any other optimizations.

"

the xbox 360 edram+ROPS and other components had an internal bandwidth of 256GB/s, the bridge between the gpu and the edram was limited at 32GB/s

So obviously the wii u edram has more than 256GB/s otherwise the porting wouldnt be so easy, right now speculation goes for 563.2GB/s or more, not to mention that if xbox 360 10MB was barely enough for the 720p with double buffering and wii u 7.1MB of edram is enough to hold 720p with double buffering then clearly the wii u edram must pack much more bandwidth

well, in the interview with hd warriors you can clearly read that shinen mentioend they need 16MB for 1080p with double buffering, and recently they did mention they are using 3 720p framebuffers on fast racing neo but they did not say it takes 16MB, in fact a 720p framebuffer on wii u edram, according to shinen, takes about 3.6MB for each of them

here, you can confirm that on their twitter

https://twitter.com/...639073798500353

"

@eubank_josh Even having all three buffers in EDRAM would be no problem as they are only 3 x 3.6Mb of 32Mb.

"

Thats about 10.8MB of edram for the triple buffering with 720p buffers, so, what they use the rest of the 21.2MB of edram(not to menion that there is another tiny edram of avout 2MB and 1MB of sram according to the photo)?

well, just keep reading and you will see that they also use edram for the g-buffer(you need this bufer to store the lighting information of the deffered rendering), intermediate buffers and other stuff

i also think there hasnt been much generation leap, this kind of feels like the transition from nes to snes, not the huge leap from 32/64bits systems to the 128 bits systems like gamecube,xbox and ps2 or the great leap from these consoles to the ps3 and 360. Although i admit that the the new graphic features make the games look prettier and is nice to have games in native hd or full hd instead of sub-HD and less screeen tear

I am not sure that NX(if its a home console of course) will keep backward compatibility via hardware since it could be said that IBM is out of the semiconductor market after selling its fabs to GlobalFoundaries;although IBM has a contract with GlobalFoundaries so that they will keep making chips for IBM(contract seems to be for 10 years since 2014), it seems that will only cover the new power pc designs like watson or chips for super computers and not desktops; IBM seems to be interested only in high end supercomputers and in cloud, mobile, analytics and other technologies, so it could be said that desktop chips are no longer in their plans

http://www.pcworld.c...end-design.html

It seems nintendo has two reasons for moving into the x86 design, developers need and no one to make powerpc chips for them or at least in the line for desktop pruposes

As for the GPU, i feel it will be just a little above ps4 in terms of raw power, but there is one thing i am almost certain, NX will use HBM/HBM2 technology(i feel it will be HBM2 since HBM has a limit of 4 gigabytes), with this the power consumption will be lower and edram will not be any longer necessary for GPU bandwidth needs, with this the development process will be easier, specially for third parties

Its to bad that they are considering NX when clearly this console wont be out this or next year, if they dont want to put so much effort in squeezing the Wii U specific features(fixed shaders most likely) there are other approaches they can take

Use SMAA isntead of MSAA or EQAA

1.-If THEY by chance are using MSAA or maybe EQAA like the ps4 and xbox one, they can replace it with SMAA which gives similar results to MSAA with less strain improving performance and doesnt blur as much as FXAA and can be used as a post-processing antialaising solution http://www.tweakguid.../Crysis3_6.html

Occlusion Culling may also be of big help:

Try Occlussion Culling

2.-Occlusion Culling is a feature that disables rendering of objects when they are not currently seen by the camera because they are obscured by other objects. This does not happen automatically in 3D computer graphics since most of the time objects farthest away from the camera are drawn first and closer objects are drawn over the top of them (this is called “overdraw”). Occlusion Culling is different from Frustum Culling. Frustum Culling only disables the renderers for objects that are outside the camera’s viewing area but does not disable anything hidden from view by overdraw. Note that when you use Occlusion Culling you will still benefit from Frustum Culling.

http://docs.unity3d....ionCulling.html
http://http.develope...ugems_ch29.html

3.-Some adjustments on the LOD(level of detail) for renders that are far away is also an option.

Try out a variable framebuffer so that resolution will change instead of the framerate (Wipe Out HD did this)

4.-Another approach is to use a variable resolution/framebuffer so that resolution will change isntead of the framerate during the gameplay, this way whenever there would be fps peaks the resolution will change isntead. This trick was used in Wipe Out HD for the ps3 tokeep the 60fps at variable 1080p(resolution could go as low as 1440×1080 certain times) and tricked many as is not very noticeable in race games http://www.eurogamer...sleight-of-hand

A, i almost forgot this other solution(reduces the number of draw calls)

http://docs.unity3d....llBatching.html

"

To draw an object on the screen, the engine has to issue a draw call to the graphics API (e.g. OpenGL or Direct3D). The graphics API does significant work for every draw call, causing performance overhead on the CPU side.

Unity can combine a number of objects at runtime and draws them together with a single draw call. This operation is called “batching”. The more objects Unity can batch together, the better rendering performance (on the CPU side) you can get.

Built-in batching support in Unity has significant benefit over simply combining geometry in the modeling tool (or using theCombineChildren script from the Standard Assets package). Batching in Unity happens after the visibility determination step. The engine does culling on each object individually, and the amount of rendered geometry is going to be the same as without batching. Combining geometry in the modeling tool, on the other hand, prevents efficient culling and results in a much greater amount of geometry being rendered.

Static batching, on the other hand, allows the engine to reduce draw calls for geometry of any size (provided it does not move and shares the same material). Static batching is significantly more efficient than dynamic batching. You should choose static batching as it will require less CPU power.

"