By using this site, you agree to our Privacy Policy and our Terms of Use. Close
maxima64 said:
fatslob-:O said:
megafenix said:


jjaja, dont worry, i also have had same feelings as you and even today i still learn, but as i mentioned i am still speculating here so lets not dig u to much on the topic, but i will try to ask shinen thneselves just to see if i am lucky and get an answer, as long as i dont have it maybe i should avoid the topic for a while

If I were Curl, I'd be very offended by now ... 


i feel the same about you, the way you treat people is denigrating and even worse when they show you the proof under the nose and you still dont admit your mistakes

its ok, veryfing my answer again i think it can be misunderstood that way and for that I give my apologises to curl-6, not to mention that she and faslob were right about the triple framebuffers(i msunderstood shinen for triple gbuffers)so yea i can learn from my mistakes like many others can(well except some there that wont admit something like the defered rendering having better performance than forward though i demostrate it with good sources or that amd indeed had tiled based gpus)

 

to pemalite

yea, as i told you i already knew about the single pass multitexturing since the gamecube era, the gamecube was capable of 8 textures in a single pass, get it?

single pass and 8 multitextures(if we combine single pass and multi-texturing obviously we get single pass multitexturing, much like the 6 textures per pass example from ati smartshader); sorry for not bothering in putting the name of the technique, thought that was implicit and the ati smartshader was just an example of why single pass is bettter than multipass, whats important there is the concept of achieving a work by using the pipeline as less as possible, thats all what matters not the technology from years ago. Also as i mentioned eventhough defered rendering doesnt do things in a single pass is still far less than what forward rendering would require, forward requires a pass per light and defered need only two passes

here

https://hacks.mozilla.org/2014/01/webgl-deferred-shading/

"

Today, most WebGL engines use forward shading, where lighting is computed in the same pass that geometry is transformed. This makes it difficult to support a large number of dynamic lights and different light types.

Forward shading can use a pass per light. Rendering a scene looks like:

This requires a different shader for each material/light-type combination, which adds up. From a performance perspective, each mesh needs to be rendered (vertex transform, rasterization, material part of the fragment shader, etc.) once per light instead of just once. In addition, fragments that ultimately fail the depth test are still shaded, but with early-z and z-cull hardware optimizations and a front-to-back sorting or a z-prepass, this not as bad as the cost for adding lights.

To optimize performance, light sources that have a limited effect are often used. Unlike real-world lights, we allow the light from a point source to travel only a limited distance. However, even if a light’s volume of effect intersects a mesh, it may only affect a small part of the mesh, but the entire mesh is still rendered.

In practice, forward shaders usually try to do as much work as they can in a single pass leading to the need for a complex system of chaining lights together in a single shader.

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.

Until recently, WebGL had a roadblock for implementing deferred shading. In WebGL, a fragment shader could only write to a single texture/renderbuffer. With deferred shading, the g-buffer is usually composed of several textures, which meant that the scene needed to be rendered multiple times during the g-buffer pass

"

 

here is another easier example for forward rednering passes

http://docs.unity3d.com/Manual/RenderTech-ForwardRendering.html

"

Forward Rendering Path Details

This page describes details of Forward rendering path.

Forward Rendering path renders each object in one or more passes, depending on lights that affect the object. Lights themselves are also treated differently by Forward Rendering, depending on their settings and intensity.

Rendering of each object happens as follows:

  • Base Pass applies one per-pixel directional light and all per-vertex/SH lights.
  • Other per-pixel lights are rendered in additional passes, one pass for each light.
  • Base Pass

    Base pass renders object with one per-pixel directional light and all SH lights. This pass also adds any lightmaps, ambient and emissive lighting from the shader. Directional light rendered in this pass can have Shadows. Note that Lightmapped objects do not get illumination from SH lights.

    Additional Passes

    Additional passes are rendered for each additional per-pixel light that affect this object. Lights in these passes can’t have shadows (so in result, Forward Rendering supports one directional light with shadows).

"

 

thats all what i was trying to mean, with defered rendering you use less shader power and put less stress on the pipeline since its not being overused, the obvious disadventage is more bandwidth and other issues like with alpha blending