Jump to content

  • Log In with Google      Sign In   
  • Create Account

lazy shading


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 20 June 2014 - 06:22 AM

When working on my home rasterizer i noticed that i shade

all the triangles then later clip it (so i do a lot of unnecessary shading)

 

This is becouse shading is done in world space (when i move models

relative to the lights - all this is done in world space) 

 

.. but as i said it seem to by unnecessary to shade all the triangles tahat

goes dead (filteres out) later - so maybe i could revrite it to do lazy shading

(count only alive set of triangles then back and shade them)

 

I m curious if modern engines (like ogl etc) use this concept or they

shade everything in brute force before the clipping tests?

 

 

 

 



Sponsor:

#2 Madhed   Crossbones+   -  Reputation: 3133

Like
0Likes
Like

Posted 20 June 2014 - 06:36 AM

Why do you open a new thread for this? Check your other thread where I wrote about tiled rendering, which is a solution for this problem.



#3 Bacterius   Crossbones+   -  Reputation: 9281

Like
3Likes
Like

Posted 20 June 2014 - 06:37 AM

Shading is done after clipping. There is literally no point in shading pixels [that the player is supposed to see] which will not be drawn on screen, so they aren't. This is done automatically by the GPU hardware. It should not be too hard to modify your rasterizer to take this into account when shading, I think, it's a fairly basic (and natural) optimization.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#4 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 20 June 2014 - 07:18 AM

Shading is done after clipping. There is literally no point in shading pixels [that the player is supposed to see] which will not be drawn on screen, so they aren't. This is done automatically by the GPU hardware. It should not be too hard to modify your rasterizer to take this into account when shading, I think, it's a fairly basic (and natural) optimization.

alright,

possibly, but it was not the feerst seen of this as this is not 100% strightforward (after clipping you have a transformed coordinates and you return to old ones 4 steps back in the pipeline to shade it there



#5 Samith   Members   -  Reputation: 2274

Like
0Likes
Like

Posted 20 June 2014 - 08:44 AM

 

Shading is done after clipping. There is literally no point in shading pixels [that the player is supposed to see] which will not be drawn on screen, so they aren't. This is done automatically by the GPU hardware. It should not be too hard to modify your rasterizer to take this into account when shading, I think, it's a fairly basic (and natural) optimization.

alright,

possibly, but it was not the feerst seen of this as this is not 100% strightforward (after clipping you have a transformed coordinates and you return to old ones 4 steps back in the pipeline to shade it there

 

 

 

After clipping you do your pixel rasterization, which is the step in which you interpolate all the vertex attributes that you transformed/passed through the vertex transform stage. People often do lighting in view space, and for that all you need is a view space normal to be interpolated for each pixel in order to do lighting. You don't need to go back in the pipeline to get any data.



#6 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 20 June 2014 - 08:56 AM

 

 

Shading is done after clipping. There is literally no point in shading pixels [that the player is supposed to see] which will not be drawn on screen, so they aren't. This is done automatically by the GPU hardware. It should not be too hard to modify your rasterizer to take this into account when shading, I think, it's a fairly basic (and natural) optimization.

alright,

possibly, but it was not the feerst seen of this as this is not 100% strightforward (after clipping you have a transformed coordinates and you return to old ones 4 steps back in the pipeline to shade it there

 

 

 

After clipping you do your pixel rasterization, which is the step in which you interpolate all the vertex attributes that you transformed/passed through the vertex transform stage. People often do lighting in view space, and for that all you need is a view space normal to be interpolated for each pixel in order to do lighting. You don't need to go back in the pipeline to get any data.

 

 

you need 'get back' to count a normal there on demand - for clipping I dont need a normal so i must get back for it only to use it for shading at a very later stage (even after 'vertex depth' test (i do such depth clipping on vertexes before rasterisation for speed )) - but dont matter, now im more confuzed by the making light less plastic, see the other thread maybe you could help?

 

(this could be closed as everything's clear)






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS