Jump to content

  • Log In with Google      Sign In   
  • Create Account


simonjacoby

Member Since 19 Jan 2006
Offline Last Active May 02 2013 04:31 PM

Topics I've Started

Sorting faces according to depth but keeping an index buffer

31 March 2013 - 12:25 AM

Hi guys,

 

I have a problem where I want to sort faces according to depth to be able to render them without a depth buffer (or even a depth component in the position of the vertex, I just want to have x and y in the position).

 

However I still want to have a have a nice index buffer so that I don't have to treat them as separate faces, for memory (and performance, but mostly memory) reasons.

 

Basically, I just want to make a draw call that draws the entire mesh, knowing that it will be drawn back-to-front (overdraw is a smaller problem than the vertex processing in my specific case), and indexed so that I process as few verts as possible.

 

Does anyone have any ideas on how to accomplish that?

 

Thanks,

 

Simon

 

 

 


[D3D9] Anybody had this PIX problem before?

18 September 2011 - 04:38 AM

Hi all,

I'm having a PIX issue that's confusing me. The thing is, this only happens if I select "Single frame capture whenever F12 is pressed", and it only happens while the application is running. If I capture a frame and look at it, all the API calls are there, and the data and rendering is correct for each API call.

The problem I'm having then running it is that the rendering becomes complete garbage (primitives become distorted, UV's stretched, drawcalls seem to be interrupted in the middle of the call (such as text rendering stopping after rendering a couple of characters)).

When running it from Visual Studio, I'm using the debug libs, I've #define D3D_DEBUG_INFO before the includes, I've cranked up the D3D Control panel to maximum debug output level, maximum validation, break on memory leaks, break on d3d9 error, and enable shader debugging, and I've also run it through the REF rasterizer.

Not a single warning (yes, I've eliminated all redundant state setting), and running through REF looks perfect. I've run it on both AMD and Nvidia cards, and the behaviour is the same: No warnings, looks and works fine as standalone and running through Visual Studio (in both debug and release builds), garbage when running through PIX if PIX is set to "Single frame capture...", but when inspecting the API calls in the captured frame works fine.

Thankful for any insight you might have on this :)

[D3D9] Finding out which register a shader parameter is mapped to

21 June 2011 - 10:54 AM

Hi,

is it possible to find out which register a shader parameter is mapped to, without using ID3DXConstantTable, and not explicitly assigning a register via a shader parameter?

I'd like to load shaders as effects, but not use the effect framework to update my shader constants.

From an effect I can get a handle to a technique, from that technique I can get a handle to a pass, and in that pass I can get the vertex-/pixelshader function being used. From that I can get a constant table. Using a constant table I can get a handle to a constant by it's name, and using that handle I can get a D3DXCONSTANT_DESC which has a member RegisterIndex which contains the index of the register it's mapped to.

This just seems like a really long way to go just to get the register mappings of the parameters. Is there a simpler or more direct way?

Thankful for any tips!

/Simon

Logarithm with any base in PS3.0

05 April 2011 - 09:01 AM

Hi,

the topic says it all. Does anyone know a trick so that I can (efficiently) perform a logarithm with any base using only the instructions available in pixel shader 3.0? Basically I want an inverse of pow(x,y).

Afaik in PS3.0 there is only log, log10 and log2 which performs logarithm of bases e, 10 and 2 respectively, but no general version that can perform for any base.

Any ideas are very much appreciated!

/Simon

[SOLVED] Depth-based DOF and reflections

19 February 2011 - 06:54 PM

Hi,

I've added a standard depth-based DOF post-processing pass to my terrain renderer, and noticed a horrible artifact. The CoC for the reflection in the water is completely wrong. This is because the CoC is based on the pixel depth for the water surface, instead of the reflected surface. The problem is most apparent when the water surface is undistorted and the focal plane is direcly over it.

I googled around, and apparently it's a limitation with all depth based DOF filters. Here's a page I found that explains the problem more clearly, with images: http://www.altyna.co...reflections.htm

The page also describes a solution, but unfortunately it's completely unusable for real-time renderers. (Basically jittering the camera position and rendering many frames).

So, is there anyone who has a proper solution to this problem? I've been thinking about storing a CoC value in the alpha channel of each texel of the reflection, but that seems overly complex, and would probably cause problems with alpha blending other stuff.

Thankful for any insight you might have!

Cheers,

Simon

PARTNERS