What I wanted to do is to start PhysX.cpl to display PhysX Properties. After some searches, I found the solution. Just enter control followed by the cpl file in the run box of Windows:

control PhysX.cpl

and you should get this:

I played with Depth Of Field (DoF) these last days in the upcoming Demoniak3D but I’m not very satisfied because I still have some problem to control the focus (the non blurred part of the field of view). Depth of field is done in a post processing step and uses the scene color and depth maps as only inputs (no multiple render targets). Here is a first preview:

I’ve coded today a small gamma correction filter in Smode. I’ll talk about gamma correction a little bit more very soon with a Demoniak3D demo. Here is the result on a simple scene: a teapot lit with a Phong shader.

The following image shows the rendering of the scene done in the usual manner, I mean without gamma correction:

and now the same scene gamma-corrected (factor 2.2):

Under Visual Studio 2005 (VC8), you can enable the multithreaded build of projects. This great feature makes it possible to use several CPUs to build your projects. This is a per-project setting and it’s done in command line: /MPx where x is the number of cores you want to use. Example: /MP2 to use 2 CPUs if you have (like me) a core2duo.

I’ve done some tests with Demoniak3D:
- Demoniak3D (default): Build Time 0:33
- Demoniak3D (/MP2): Build Time 0:15

Great boost in productivity of large projects!

[-source-]

Some users have reported that FurMark 1.4.0 has the Trojan-Downloader.Win32.Agent.vpx. I did this morning the scan with the latest version of Kaspersky and the very latest version of their database. Kaspersky hasn’t found any threat or trojan in FurMark setup installer nor in FurMark root directory. FurMark is clean. MajorGeeks and Softpedia are very good proofs of FurMark’s cleanness.

I did some searches over the Net and I found that others users have some false alarms. I guess the problem comes from the InnoSetup (the utility used to create FurMark_Setup.exe) and depends of the version of Kaspersky’s database. So if you have Kaspersky antivirus, be sure to update it with the latest database.

I sent FurMark_Setup.exe to Kaspersky Lab and I just receive the reply from the Virus Analyst:
“I suppose it WAS a false alarm, and it has been already fixed.”
This time everything is ok!

During the conversion of shaders written in Cg/HLSL, we often find the saturate() function. This function is not valid in GLSL even though on NVIDIA, the GLSL compiler accepts it (do not forget that NVIDIA’s GLSL compiler is based on Cg compiler). But ATI’s GLSL compiler will reject saturate() with a nice error. This function allows to limit the value of a variable to the range [0.0 - 1.0]. In GLSL, there is a simple manner to do the same thing: clamp().

Cg code:

float3 result = saturate(texCol0.rgb - Density*(texCol1.rgb));

GLSL equivalent:

vec3 result = clamp(texCol0.rgb - Density*(texCol1.rgb), 0.0, 1.0);

BTW, don’t forget all float4, float3 and float2 which correct syntax in GLSL is vec4, vec3 and vec2.

Are you ready for a small velvet GLSL shader? Here’s one, at least a preview of the one I’ve just coded for a demo with Smode. Smode… a software dedicated to create… demos! And the cool thing, is that Smode demos will be also available for Demoniak3D. Don’t look for Smode, it’s not available for you, public… Only few people on this planet are enough lucky to play with. But if you really want to touch it, just drop me an email…

As soon as the next release of Demoniak3D, the 1.24.0 (or better the 1.30.0 because of the huge amount of changes), will be ok, I’ll put online the velvet demo with its nice GLSL shader. And if I’m late, don’t hesitate to post a small message to wake me up!

Here is an example of a Intel’s graphics driver that support openGL 1.5 without supporting GLSL:
- Mobile IntelR 965 Express Chipset Family

For more examples, look at users’s submissions here: www.ozone3d.net/gpu/db/

Okay this is my analysis, but what is the Intel point of view? Here is the answer:
- x3100 & OpenGL Shader (GLSL) thread
- Intel’s answer

I think GLSL support with Windows is not a priority for Intel…

vec4 packFloatToVec4i(const float value)
{
  const vec4 bitSh = vec4(256.0*256.0*256.0, 256.0*256.0, 256.0, 1.0);
  const vec4 bitMsk = vec4(0.0, 1.0/256.0, 1.0/256.0, 1.0/256.0);
  vec4 res = fract(value * bitSh);
  res -= res.xxyz * bitMsk;
  return res;
}

Unpacking a [0-1] float value from a 4D vector where each component was a 8-bits integer:

float unpackFloatFromVec4i(const vec4 value)
{
  const vec4 bitSh = vec4(1.0/(256.0*256.0*256.0), 1.0/(256.0*256.0), 1.0/256.0, 1.0);
  return(dot(value, bitSh));
}

Source of these codes: Gamedev forums

static unsigned int mirand = 1;
float sfrand( void )
{
    unsigned int a;
    mirand *= 16807;
    a = (mirand&0x007fffff) | 0x40000000;
    return( *((float*)&a) - 3.0f );
}

It produces values in the range [-1.0; 1.0].

You can find the making of this random gen HERE.