Jump to content

  • Log In with Google      Sign In   
  • Create Account

Calling all IT Pros from Canada and Australia.. we need your help! Support our site by taking a quick sponsored surveyand win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 30 Nov 2010
Offline Last Active Jan 02 2014 11:04 AM

Posts I've Made

In Topic: Making a "Busy Loop" not consume that much CPU (without Sleep)

19 May 2013 - 04:48 AM

Why create a busy loop that will always consume CPU ? Here a single line to do this, and it is self documented std::this_thread::wait_for( std::chrono::milliseconds( 1u ) ); This internally use WaitForSingleObject with the visual studio 2012 implementation.


Also, waiting for less than one millisecond is likely to not do much because it do not exist such precision in the system. You can read the cpu clock with some intrinsic or use QueryPerformanceCounter, but the first one is unlikely to be useful because it may be inconsistent between cores and modern CPU can vary their frequency, and the second one is in fact quite cycle heavy, so not really a good choice for a spin loop.


Why do you need to wait for a so short period of time ?

In Topic: Shadow map surface aspect ratio ?

05 May 2013 - 04:07 AM

We allocate power of two texture because it reduce somme padding that may occurs in the memory ( not so true now, specially with big surfaces, but an old habit ). After that, if i allocate some 2048x2048 shadow map surfaces for my pool, it does not mean i have to use all the texels, if i have a distant shadow that should projet on may be 10% of the screen, i may reserve a sub rectangle and scale and bias uvs.


It exist also a lot of technique to improve the texel ratio of the shadow map (warp the projection, refine the shadow frustum around the casters, ...), because as said by hogman, there is no a 1/1 match between a shadow map texel and the frame buffer pixels.

In Topic: Can shaders apply to specific polygons?

05 May 2013 - 02:14 AM

Also, if there is no dependency between two consecutive rendering states ( like write to a render target then read it, depth test on then depth test off, ... ), modern GPU will not wait for the previous one to end before stating the new one, I do not know how many parralel context there is on earlier GPU, but the latest AMD one have 8 :)


Also, changing context is not yet free, so grouping by states the primitives is a good and mandatory practice.

In Topic: [Renderer] Public buffer class

05 May 2013 - 02:05 AM

First, buffers are not only for geometry ! You can put anything you want in them, there is a lot of way to represent geometry ofcourse, constants like projection matrix, bone array for skinning, linked list pool of node for various algorithm, from tiled light culling to per pixel translucency sort, octrees, histogram, and everything relevant to your renderer, or even not rendering stuff like array of particles to simulate them on gpu, ...


Second, virtual is an outcast banned keyword in a renderer. We have to deal with too much data, too much instances to keep a basic OOP style. grouping and sorting by types the primitive to call a compile time know method for rendering is far better. And this is of course only one thing, behind the scene, things can me split up for optimisation, sort by rendering states, mass instanciate, ... 

In Topic: Real-Time Tessellation Techniques of Note?

04 April 2013 - 01:07 AM

To me the next standard for characters, weapons and important landmark will be catmull-clark with this solution :


http://research.microsoft.com/en-us/um/people/cloop/tog2012.pdf with this update for crease edges http://research.microsoft.com/en-us/um/people/cloop/EG2012.pdf


This is the research and fundation of the opensubdiv initiative from pixar ( open subdiv do not yet have everything done, but the paper is enough to write your own implementation ).