Jump to content
  • Advertisement

coordz

Member
  • Content Count

    160
  • Joined

  • Last visited

Community Reputation

130 Neutral

About coordz

  • Rank
    Member
  1. coordz

    DoF (depth of feild)

    This link has a good description of techniques http://http.developer.nvidia.com/GPUGems3/gpugems3_ch28.html
  2. coordz

    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.
  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 http://developer.amd...es/default.aspx 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.
  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
  5. coordz

    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. coordz

    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. coordz

    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. coordz

    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
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!