Why wasn't the OP banned for spamming?

The amount of times he copy pasted the same damn thing over and over and over again. That was nothing other than spam. Made reading the whole thread a chore more than anything else. Good thing Zarx and Pemalite came in to make the thread actually worth something.

Not sure what that article has to do with what I said... Sure using LOD to just render less stuff improves performance because you are rendering less stuff. It is not doing the same work quicker just doing less work.

Did I contribute anything ?  

the LOD and the passes for the material(also mentioned there by gpu gems)are few of the examples i could put, there are many other examples i can put here were you can see that lowering the passes saves up shader power that can be used for other rendering purposes, but will take some space here that i am not sure everybody will bother to read

And yes, of course that defered rendering is not perfect and besides the problems with huge bandwidth requirements you also have issues like alpha blending and msaa, but there are good solutions for that, instead of msaa for example you can use temporal antialaising, which laos is cheaper than msaa and is better suited with defered rendering, FXAA or Fast Approximate Anti-Aliasing is also a good option

As for the transparency, well you can combine defered and forward rendering, forward rendering would be just used for the parts where you need transparency or can use some other solutions like the ones found here

http://www.csc.kth.se/utbildning/kth/kurser/DD143X/dkand12/Group1Marten/final/final_TransparencyWithDeferredShading.pdf

"

How can we render transparent object using deferred shading?

Within the frame of this project, several techniques for rendering transparent objects

were examined on their advantages and disadvantages. Below we suggest a

review of previous studies on deferred shading as well as some of the practical solutions

for application of this technique in transparency. We propose a prototype of own developed technique for rendering of transparent objects. The built of our

deferred shader is described along with actual integration, of the front renderer and

deferred shader techniques, is explained in particular. We discuss the test results of

our prototype in terms of performance and image quality and describe the model

we used for this testing.

Rendering transparent objects with deferred shading impose some problems as the

depth-buffer used for rendering during deferred shading only supports one fragment

at a time. In our work, we have chosen to use alpha-blending in a post pass using

front rendering. Despite the flaws of alpha-blending, it is still very straightforward

and is easy to implement into a deferred shader. In the next section we discuss

basic functions of our algorithm

Deferred shading with Front Rendering

The front render is used to process transparent objects and fits well into the deferred

shading pipeline. It renders all opaque objects first with the deferred shader

and then renders the transparent objects on top using the front renderer. This is

important as the depth buffer has to be filled with opaque objects first, to prevent

rendering of non-visible transparent objects. When the front renderer is performed,

the final picture can be rendered to the frame buffer for display.

The implementation has the following rendering stages:

1. Render all opaque geometry to the G-Buffer

2. Bind the G-Buffer as texture. For each light in the scene draw a full screen rectangle

and calculate lighting at each pixel using the data from the G-Buffer. Save

result in the P-Buffer.

3. Sort all transparent entities in back to front order.

4. Render all transparent geometry using the front renderer. Blend the result to the

P-Buffer using the depth buffer to filter out any non-visible transparent geometry.

5.-Copy P-Buffer to frame buffer.

"

Now next time I get some actual news (not tweets from months ago) out of Shin'en and make a thread about it, it will get associated with this mess.

megafenix please, I say this in the nicest possible way, just stop.

Anyone have details on a release date, frame rate and resolution for this?

It's 720p/60fps.

No release date yet.

ok, will talk abot other things, my only point is that the less passes you use to do a job the better as long as the result is the same or almost equal to the other solution that was going to use more passes through the pipeline, thats all

imagine you have to deliver 6 water jars, one person decided to deliver them one by one from point A to point B using his natural gifts, other peson decides that instead of doing it the traditional way he will use a wheelbarrow(consider it as the bandwidth and can hold 3 jars)  to move those jars from point A to point B and with it can move 3 jars at a time

obviously the person that uses the wheelbarrow will travel less times through the road and also will save up a lot strenght doing it that way, the only additional cost will come from his wallet  though

thats the thing with defered vs forward, defered requires less passes and less shader power in order to acheive the same job that for forward rendering would have taken a lot more stress on the gpu; surely are issues like msaa and atransparency but the solutions for them still dont cost as much vertex power as like forward rendering, the strongest disadventage would be bandwidth

As for other topic, any news if there are in reality fixed shaders on the wii u gpu or at least an indication that developers have used fixed functions on the wii u?

Again that example is just using lod to reduce shader detail on distant objects. Yes it is reducing the number of passes but it's just not doing that shading on distant objects. So it's not "doing the work in less passes makes it faster" it's "not doing certain effects on distant objects, makes it faster because you are doing passes on fewer objects" you are still doing the same number of passes on near objects. So not really relevent to the topic we were discussing.Which was often times splitting the work up into seperate passes is often faster. Once again you have posted a responce that is completly irrelevent to the topic on hand because it uses some of the same words. And to reiterate I am not saying their aren't cases where batching and combining operations into one pass doesn't make things faster in some cases. Just that it is not a hard and fast rule, and that there are in fact many cases where the opposite is true and splitting up tasks into more simpler passes is often the better aproach.

And yes that is exactly what I said about deferred shading, I am not sure why you are repeating the point I just made.

Anyway I am out, peace.

Wasnt that his pint all the time?

the less passes the better(of course as long as the end result is almost the same)?

even if its true that there are still rendering passes for the nearby objects would you still prefer to waist rendering passes for both the neraby objects and the ones that are distant to you and can barely be seen?

the whoe point is just reduce the rendering passes as much as possible as long as the result is equal or almost equal to the other approach with more passes, why put more gpu stress on the gpu when is not necessary?

seriously that guy at least provides examples and reliable sources, what have you done besides randomly throwing words without something to support it?

i am not even sure whats your purpose or what is the conlusion you want to reach, at least provide resources to prove your point, not just say whatever you want