Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 29 Aug 2002
Offline Last Active Jan 30 2015 06:09 AM

Posts I've Made

In Topic: frac(x) results in strange artifacts when x is close to zero

24 September 2014 - 06:57 PM

Fwiw, you should never avoid using mips without good reason. Mips are there largely to avoid thrashing the cache, and therefore improve performance. You can avoid the problem Erik described by supplying your own derivatives into the tex2d call that are calculated prior to the frac() call. This lets the hardware use the mips that it would have had the frac() call not been there. Something along the lines of this:

float2 uv = worldPos.xz / 4; // <- swizzle elements however you need, instead of doing your math seperately on x and z!
float alpha = tex2Dgrad(_Grid, frac(uv), ddx(uv), ddy(uv)).a;

Also, its perfectly acceptible to use texture coordinates that are outside of 0 to 1. You can assign sampler addressing modes to let the hardware automatically repeat the texture, or clamp it, in either dimension. That avoids the need for the tex2Dgrad & frac completely.

EDIT: sorry, i missed the part where Erik already pointed out the usages of the wrap mode. I'll leave my comment about tex2Dgrad though, as its handy for similar situations that cant be fixed via repeat (such as when tiling within 0 to 1)

In Topic: deferred shading and clearing the swap chain render target

07 September 2014 - 05:15 PM

You could write to a fullscreen polygon that at depth 1.0f with a depth-test of less-than

In Topic: Having trouble with energy conservation with IBL.

01 September 2014 - 05:22 PM

Isn't that fairly realistic to expect though, a light 1000 times brighter in a single direction should have a pretty noticeable impact. 1000 times the impact in fact. When processing the cubemaps though, are you taking the solid angle of each pixel into consideration? A single pixel's light is scaled by the area on the sphere it is seen from (without this, doubling the resolution of the cube map could effectively make it 4 times brighter, etc)

In Topic: Isn't "delete" so pesky to type? Wish there was a better way?

26 August 2014 - 06:43 PM

Oh you people.  rolleyes.gif


For anyone who is legitimately confused, have fun researching C++'s comma operator.  And yes, the comma operator can be overloaded; that might blow your mind.  In fact, I bet with a templated overload of the comma operator, plus an appropriately designed class with an overloaded delete operator to represent a collection of deletable pointers, one could make ApochPiQ's code actual behave exactly as presented.  Frightening.  Too bad it would lose the 3x performance gain, heh!  smile.png

This is true. And for a few seconds after reading your post i seriously considered it. Then realized that i can implement it easier and safer through variadic templates!


template <typename T> void d(T *t) { delete t; }
template <typename T, typename... U> void d(T*t, U&... u) { delete t; d(u...); }

d(foo, bar, baz);


Not sure if i feel dirty or not...

In Topic: Specular questions (with pics)

11 May 2014 - 06:33 PM

The specular material property is a mask describing how much red, green and blue light the surface reflects - its a ratio of the light intensity, so you should be using both.