• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

130 Neutral

About coordz

  • Rank
  1. OpenGL DoF (depth of feild)

    This link has a good description of techniques http://http.developer.nvidia.com/GPUGems3/gpugems3_ch28.html [quote name='ic0de' timestamp='1297298532' post='4772158'] Hi i'm programming a 3d game in C++ with OpenGl on windows. I'm trying to add some sort of DoF (depth of field) system. Right now everything works and it renders properly but it has absolutely no DoF and I have no idea how to add it. If anyone has any experience using DoF or knows a tutorial on how to implement it, could they point me in the right direction? [/quote]
  2. DX11 HLSL compile in Visual C++

    You can find FXC in Utilities\bin\x86 under you DX SDK directory. I use a custom build rule for various extensions including .hlsl and .fx. [quote name='forsandifs' timestamp='1296673481' post='4768658'] Thank you very much for your reply MJP. I watched a video by AMD detailing some basics of Compute Shaders, and they recommend the following command line for compilation of .hlsl files with output into a header file: [code]...>fxc /Tcs_5_0 /EMyShader /FhOutput.h HLSLCode.hlsl[/code] where "..." represents my project's source directory, but I get an error like "fxc is not a recognised command..." etc. Also I did a search on my system for fxc.exe and it doesn't seem to exist on my system. Stumped as to where to go from there to be honest. [/quote]
  3. The DX shader compiler will generate the same DX asm regardless of the hardware. It is this DX asm that is then consumed by the driver (AMD/NVIDIA) to compile for the particular hardware in your machine. I'm using an Radeon 5870 and envious of your newer card There's a very useful tool by AMD [url="http://developer.amd.com/gpu/shader/pages/default.aspx"]http://developer.amd...es/default.aspx[/url] which will allow you to compile DX shader *independently* of the GPU in your machine. It's actually meant for profiling but in your case I'd be interested to know what happens when you try compiling your shader in this tool and if you get the same errors. [quote name='n3Xus' timestamp='1296319866' post='4766688'] Does the assembly code generated by the directX shader compiler in any way differ if you use a radeon/gefore gpu? Which gpu do you have coordz? I have a Radeon 6950. [/quote]
  4. What DX runtime and SDK are you using? I tried this shader as you described with June 2010 but get no error or warning. OT why do you want to prefer flow control? especially as you seem to want to optimize [quote name='n3Xus' timestamp='1296309337' post='4766615'] Hey, Even if I don't write to the groupshared variable, just declare it, it gives me the error on optimization levels 2 and 3. I compile the shader with these flags: UINT shaderCompileFlags= D3D10_SHADER_OPTIMIZATION_LEVEL1| D3D10_SHADER_PACK_MATRIX_ROW_MAJOR| D3D10_SHADER_PREFER_FLOW_CONTROL| D3D10_SHADER_ENABLE_STRICTNESS; Change D3D10_SHADER_OPTIMIZATION_LEVEL1 to 2/3 to get the error. Here is the code: [code] // Packs float4 in [0,1] range into [0-255] uint uint PackFloat4(float4 val) { return (uint(val.x*255.0f)<<24)|(uint(val.y*255.0f)<<16)|(uint(val.z*255.0f)<<8)|(uint(val.w*255.0f)<<0); } // Unpacks values and returns float4 in [0,1] range float4 UnpackFloat4(uint value) { // Note: 1/255=0.003921568 return float4( ((value>>24)&0xFF)*0.003921568, ((value>>16)&0xFF)*0.003921568, ((value>>8)&0xFF)*0.003921568, ((value>>0)&0xFF)*0.003921568); } Texture2D texColor: register(t0); RWTexture2D<uint> uav: register(u0); // THE ERROR POINTS TO THIS LINE: groupshared uint gsPixels[32*2*2]; [numthreads(32,2,1)] void CSMAIN( uint3 threadID:SV_GroupThreadID, uint3 groupID:SV_GroupID) { int tx=groupID.x*32+threadID.x; int ty=groupID.y*2+threadID.y; int tid=threadID.x+threadID.y*32; // Line (in pixels) int currentLineInPixels=threadID.y*64; // Blur side int blurSideTimes16=blurSideTimes16=((uint)tid*(1.0f/16.0f)-2*threadID.y); blurSideTimes16=(blurSideTimes16*2-1)*16; int2 texcoords=int2(tx,ty); int2 texcoordsWithOffset=texcoords+int2(blurSideTimes16,0); // Pixel at current texcoords int index=16+threadID.x+threadID.y*64; gsPixels[index]=PackFloat4(saturate(texColor[texcoords.xy])); // Its offset pixel gsPixels[index+blurSideTimes16]=PackFloat4(saturate(texColor[texcoordsWithOffset.xy])); // Wait until all pixels are stored in shared memory GroupMemoryBarrierWithGroupSync(); // Read pixels on the left/right from the current pixel float4 sum=float4(0,0,0,0); int temp=threadID.x+currentLineInPixels; [unroll]for(float f=0;f<32;f+=1.0f) { // Perform intensity based on gradient here, reduces instruction count sum+=UnpackFloat4(gsPixels[temp+f]) * (1-abs( (16 - f)*(1.0f/16.0f)) ); // 16==halfSamples, 0.0625=1/halfSamples } sum/=32; uav[texcoords]=PackFloat4(sum); } [/code] [/quote]
  5. OpenGL Intercept OpenGL function calls

    You can also check out http://research.microsoft.com/en-us/projects/detours/
  6. If you've not used cube maps before I would strongly suggest working through a simple cube map example. Start with loading a static cube map into your cube texture and then render something using that as an environment map. Then try generating a dynamic environment cube map. Take a look at http://developer.nvidia.com/object/cube_map_ogl_tutorial.html. The extension they talk about has been core for a while btw. The difference is you can use FBO's rather than the texture copy stuff in the tutorial. You can directly bind the faces of your cube map to the FBO. Moving to depth maps is then pretty simple as you've already got shadow mapping working. Change to using cube depth textures and in your depth shadow shader start using cube map accesses. In your FBO you can forget about having colour buffers as well as the depth buffers as you can disable writes to colour buffers if you're only interested in depth.
  7. OpenGL OpenGL 3.3 sample code

    Trying out GL 3.3 is pretty keen :) I think ATI only made drivers available today for 3.3 and 4.0. I think for most things, 3.2 samples will get you going although I sympathize with the seeming lack of bang up to date GL sample code.
  8. OpenGL Debug shaders

    On the GLSL devil homepage there is a section on why the debug button may be disabled: you're graphics card must support certain extensions.
  9. Quote:Original post by Yann L Texture border are deprecated, and have been removed from OpenGL 3.x. It is to be expected that the feature is not hardware accelerated anymore on current and future GPUs, even on a GL 2.x compatibility profile. You should drop texture borders in favour of manual texture coordinate adjustments. Deprecated, yes. But previously existing drivers rewritten to remove already hardware accelerated codepaths? I doubt this so I'm surprised at the result. Are you quite literally just commenting out the code setting the border size and changing the texture wrapping? Nothing else is changing in the app?
  10. You can't bind a texture to read into a shader and have the same texture bound as part of an FBO that you're using for output. You can write to a depth buffer just by writing to gl_Depth in your fragment shader. It sounds like what you need to do is set up two depth buffers and use them in a ping-pong fashion using one as input and the other as output and then swapping.
  11. I would hope/guess/assume that as long as the things you are looping on or doing conditionals on in your shader code have been defined const then the GLSL compiler will be able to unroll, i.e. in your example const int texsize = 4; const int TexTypes[texsize] = int[texsize](TEX_COLOR3, ..... ); Your app then needs to tag on the correct header to your generic app to set up these consts. For ATI cards, you could also put your shader into their GPUShaderAnalyzer app which shows you the compiled version of your code. From this you'd be able to see if the loops were being correctly unrolled.
  12. Quote:Original post by karwosts It is unlikely anyone can help you unless you post the relevant code sections that are causing errors. Agreed. I also suggest you upgrade to the latest drivers. I think GL 3.2 was only introduced in ATI's drivers in December 2009 so there could still be wrinkles being ironed out.
  13. OpenGL Some help with optimization

    If you are vertex bound you probably want to get some culling on the go before you pass the vertices to the GL. It sounds like you're dropping pre-baked objects in a repeating way? If (as swiftcoder suggests) you use VBOs and create these for each object you could then use instancing and some sort of geometry shader culling of the instances. At the very least simple bounding spheres on the CPU side should be used to cut down on the amount of geometry to be processed.
  14. For sure you can just bind the depth as a sampler. Just make sure you set your depth comparison to NONE.
  15. I've implemented a marching cubes algorithm which spits out a number of triangles per voxel. These triangles form a triangle list which is then rendered. I now want to do some post processing on this mesh and save the resulting mesh. Most mesh formats use a list of vertices then have a triangle list referencing these vertices. I would like to convert my random bag of triangles into a properly connected mesh. My initial thoughts are to scan my triangle list and extract a list of identical vertices (within a small tolerance) then convert the triangles to reference these vertices. This allows me to save the mesh okay. I'm then left with extracting the connectivity from this mesh representation. I'm wanting to to do mesh smoothing therefore for each vertex I need to answer the question "what are all the other vertices I'm connected to?". So 3 questions really: 1) Is there a way to implement marching cubes to directly give me connectivity information? 2) How can I extract vertex connectivity froma given mesh? 3) Do I really need this info if all I want to do is smooth the mesh? Many TIA
  • Advertisement