Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Oct 2000
Offline Last Active Feb 05 2016 11:32 AM

Topics I've Started

Lining up a projection within a projection

28 March 2007 - 05:18 AM

Hi, So, I have a scene being rendered with a perspective projection matrix. I also have a rectangular region on the screen that I'd like to render onto another render target and then place back over the scene so that you don't notice any seams. To this end, I've attempted to create an offset/sheared perspective projection matrix that encompases the bit of scene I want to render. This almost works, but I end up with issues where the object is scaled differently using the sheared matrix. I've created the sheared projection matrix in a couple of ways, 1) using trig and 2) by back projecting the extents of the rectanglular region onto the near plane and constructing the new projection in camera space. Both methods seem to give the same kind of error. Has anyone done this kind of thing before? I imagine it's the kind of thing people might find useful in portal engines or when rendering render-to-texture mirrors etc. Can anybody help with this? Many many many thanks, T

Select() with a small timeout VS non-blocking sockets

05 July 2006 - 11:09 PM

This is a question out of curiosity more than anything else. Because windows doesn't implement the fcntl() function (and I didn't know about the ioctlsocket() function to do the same) I simply did a select() with a timeout of 1 microsecond which seemed to work fine. Are there any benifits to using blocking sockets with a really small timeout on select() calls like this? Or is it better to make them non-blocking and just poll recv() etc rather than select()? I'm quite a newbie in this area, but I decided to learn a bit after 3d coding at home started to become a bit dull :). T

Fast summation of a texture

22 May 2006 - 05:15 AM

Hi, Here's what I want to do: Take a texture, add each of it's texels and then divide by the number of texels in the texture. I'd like to do this pretty fast. Here are my initial thoughts on the different ways do this: 1) Go the CPU route and lock/read the texture and do it manually. 2) Write a simple shader to downsample the texture repeatedly adding the elements as it goes, until texture size is 1x1 and grab the value. This would need to use a 16bit RGBA float format and I'd need to be careful I'm sampling correctly. 3) (And this might be slightly silly, i'm not sure it's even possible - just thought of it now :)) For each texel in the original texture, make a point (or point sprite..) that references that one texel for its color. Take a 1x1 R32F render target and render all the points into it, with additive blending. This isn't for a real-time process, but i'd like to make it a bit speedy. Any better ideas or recommendations would be greatly appreciated :). Cheers, T

Projecting cubemaps

22 August 2005 - 05:02 AM

Hi all, I've projected 2D textures in the past (for spot lights and such), mostly with the FFP, but it seemed reasonably easy to move that thinking into a vertex/pixel shader. What i'd like to do is project a cube map using the programmable pipeline, alhough I'm not quite sure what it is I'm supposed to pass to the texCUBEproj instruction (in HLSL). In 2D, i'd multiply the world space pos back into the projector space (with texture offsets and biases included), and pass that along to the tex2Dproj instruction. I think what's confusing me is the fact im dealing with 3d coordinates, with a fourth for the divide. Can anyone give me a little pointer, or post a link to some info regarding this? I've googled but turned up very little info. Any help would be massively appreciated. :) Many thanks, T

Massive number of pixel shader inputs?

18 August 2005 - 04:20 AM

Hi, If we move all lighting calculations into the pixel shader (including transforming our per-pixel normal into world space), so that we avoid changing the number of shader inputs/outputs as the number of lights change, the number of shader inputs becomes quite large. For example:
struct PS_INPUT
    float4 Position   : POSITION;
    float3 Normal     : TEXCOORD0;
    float3 Tangent    : TEXCOORD1;
    float3 Bitangent  : TEXCOORD2;
    float3 WorldPos   : TEXCOORD3;
    float2 TexCoords  : TEXCOORD4;

This allows us access to a per-pixel basis to transform normals into world space, and the world position of the texel we are going to shade. However, we still need to add more texture coords once we factor in things like shadow mapping and projective textures. This seems like quite a lot of inputs to me. So, basically, I'm curious now. On average, how many inputs do you guys have into your shaders? Does the above seem excessive? I guess once you start sending in interpolated lighting normals (rather than doing the math in the PS), the numbers grow quite large anyway..? T