• Content count

  • Joined

  • Last visited

Community Reputation

430 Neutral

About wyrzy

  • Rank
    Advanced Member
  1. Mesh Batching Options

    Quote:Original post by Zipster Instead of rendering each sub-mesh individually, batch all the sub-meshes that have the same texture/shader. That removes the number of buildings from the equation. I was thinking of doing that exclusively, but I have to work with user created content (ie, content I have no control over), and there is little guarantee several sub-meshes will be visible that have the same texture (all objects will generally have the same shader). Also, perhaps my buildings description was a bit vague - the user can create their scene of whatever they choose, we just import it. Some of our test scenes at the moment were composed of buildings with various textures though since that was not performance friendly at the moment. I could just impose the constraint that your performance is going to drop significantly is you decide to have different textures on meshes that are the same. I don't know how well the customers would like that though. At the moment, I'm leaning towards implementing the texture atlases for meshes that wouldn't batch well otherwise, and use Zipster's idea in the scenarios where I have a decent number of smaller meshes that all of the same texture. I was holding off on implementing the texture atlas approach since its likely going to be a pain to get working with proper wrapping, mip-mapping, and such. I have a good idea how to go about it, its just going to likely take some time to get working correctly.
  2. Mesh Batching Options

    Quote:Original post by VladRBind several textures to stages 0-15, use relevant texcoords and inside a shader decide which vertex should be textured with either of the textures. I'm not sure if I follow. Are you suggesting I decide in the vertex shader which texture to sample in the pixel shader. I didn't think that was possible (unless using SM4 texture arrays which I can't use). How would I go about doing that? If I decided in the pixel shader, it would force 16 lookups on SM2 cards which would likely kill the performance.
  3. Hi, I am attempting to improve the batch performance of some simulation I am working on. Currently, I'm working with scenes that has relatively simple meshes, but often have several varying textures. Imagine a building scene, with lots of simple buildings but often widely different textures. Some of the buildings may have multiple textures as well. At the moment, the meshes are broken up into sub-meshes, with one texture per sub-mesh. I render each sub-mesh individually. With lots of buildings, or even a good number of complex buildings (20+ textures on each building), the performance gets quite horrible even on recent hardware. I'm trying to improve performance by drawing several buildings at a time. However, its often difficult to find several that all have the same texture. The only real option I could think of is to use texture atlases. I'm limited to SM2+ hardware, so I can't use those wonderful texture arrays or anything like that. On SM2/3 hardware, I can't think of any other technique that would achieve what I am trying to do other than texture atlases. I thought texture atlases were a bit of a dated technique, but I'm not really up to date with batching techniques. Are there any other options for rendering batches of geometry with varying textures? Or am I limited to texture atlases? If I do decide to go with atlases, I know about the drawbacks with texture wrapping and such. Thanks for any other suggestions or confirmations that texture atlases would be the best option. [Edited by - wyrzy on June 23, 2008 7:40:54 PM]
  4. I'm fairly certain that: ID3D10RenderTargetView * renderTargetView[] = {0}; ID3D10Device::OMSetRenderTargets(1, renderTargetView, depthStencilView) should work as well. This is unlike DX9 where you always needed to have a color buffer set. I haven't gotten around to trying that myself yet though, since I haven't had a need to do so.
  5. Quote:Original post by AndyTX The second you should really address by using parallel-split shadow maps (aka. cascaded shadow maps) or similar. I thought he said he was already using parallel-split shadow maps? Quote: _ When i use a shadow map of 4096 instead of 1024 (with or without PCF), artifacts are very minimized. As AndyTX mentioned, this is more of a problem with lack of shadow map resolution, as opposed to lack of precision in the shadow map. How many splits do you use? Also, what near / far plane values are you using? What are the near/far planes of the subdivided view frustum during your shadow pass? Have you tried rendering the view frustums? It may be the case that one split is covering a large portion of your scene, negating any improvements you'd get from using parallel split shadow maps. You can often modify the practical split formula a bit so that the splits cover your scene more nicely. I've found it to be more of an art than an exact science, but keep in mind what the point to the multiple splits is and that will probably help when tweaking the constants. Also, as others mentioned, there is no 'perfect' constants for any of these values as they are largely scene dependent.
  6. Quote:Original post by texel3d Can i simulate polygon offset with D3D9 ? How ? D3DRS_DepthBias / D3DRS_SlopeScaleDepthBias or (DepthBias / SlopeScaleDepthBias if setting in the FX file) would be the equivalent of OpenGL's polygon offset as far as I can tell. Assuming you are using hardware shadow maps, you'd want to set the render states when you render the shadow maps. I use DepthBias = 0.00002f and SlopeScaleDepthBias = 6.00000 and that looks pretty nice for me. It fixed my self shadowing problems for my scenes. Also, good values for DepthBias and SlopeScaleDepthBias are dependent on your near / far planes. See ftp://download.nvidia.com/developer/presentations/2004/GPU_Jackpot/Shadow_Mapping.pdf for a better description. Also, do you do things like move up the far plane when clipping to the view frustum for PSSM? I have a far plane at 1000 but move it up to 400 when subdividing the view frustum. If you have a first person game/demo, the shadows in the far distance are hardly noticeable. I also use a split bias of 0.75 instead of the default 0.5. Again, its dependent on how much you care about shadows further away from you but for my purposes it seemed to produce nicer results. Another thing I added that reduced incorrect self-shadowing artifacts was to clip to the minimum of the eye frustum's z values. This of course has the potential to miss shadow casters, so in my vertex shader of the light pass I do something like: vsOut.Position.z *= vsOut.Position.z >= 0; which sets all potential shadow casters between the eye frustum and the light to have a z value of 0. When doing a shadow compare, it will result in that object being in front (w.r.t. the light) of anything the eye can see. This is exactly what you want. This can cause problems if you have very large triangles casting shadows (since the interpolation of depth values won't be correct if one vertex of a triangle has z < 0 and another has z > 0), but in practice I've found the this tradeoff to be worth it and for reasonably tesselated scenes I have not noticed any artifacts. Alternatively you could write to the DEPTH register, but for performance reasons you probably don't want to do this. However, you can get much better depth precision with this approach since your z-values get confined to a much smaller range (min-z / max-z of eye's frustum in light's NDC space). Which will in turn help with incorrect self-shadowing artifacts you are getting.
  7. PerspectiveFovLH mystery

    Quote:Original post by skytiger My understanding of a perspective transform's treatment of Z values is that it scales them from the range near->far to the range 0->1 so Z' = (Z - near) / (far - near) This assumption is not correct. The mapping of Z-values from view space to post-projective space is not linear. Also, Quote: if you look at the directx documentation it says: w 0 0 0 0 h 0 0 0 0 zfarPlane/(zfarPlane-znearPlane) 1 0 0 -znearPlane*zfarPlane/(zfarPlane-znearPlane) 0 which means Z' = ((5 * 10) / (10 - 1)) + ((-1 * 10)/(10 - 1)) = 0.444444 Correct, that's Z before you project back into w=1. Dividing by w (5 in your case), gives you Z = 0.888888955 (in NDC space), which is what the function TransformCoordinate() is giving you. So, do you see why the D3DX functions are correct now? [Edited by - wyrzy on March 23, 2008 6:31:13 PM]
  8. I would recommend starting with parallel split / cascaded shadow maps, and see if that works well for your scene. There's a decent demo at http://hax.fi/asko/PSSM.html.
  9. Another Sorting Thread

    It really depends on your application whether to sort or z-prepass. I tried both for something I had been working on. Sorting by effect and then by distance, with no z-prepass, worked best for me. Of course you'd still want to sort by effect even with a z-prepass. Quite a few effects may require the depth buffer in texture format, so you might need to do a z-prepass already. However, supporting multisampling is tricky. If you use an R32F texture to store depths, Geforce 7 and below doesn't support MSAA on that, so the depth buffer for your prepass and forward pass can't be the same. There are hardware specific FOURCC formats (for DirectX), though I'm not sure what range of video cards the NVIDIA ones are supported on. Of course if you are CPU limited then then the extra time required to sort front to back can be unnecessary. So it really depends on your application. For today's standards, I think it is generally accepted sorting on render state would often cost you more than you gain, though I have not done any analysis of this myself.
  10. HDR Help

    Quote:Original post by MJP I'm not really aware of very many D3D10 tutorials period, since the API is still relatively new at this point. Humus has a few, but nothing related to HDR. Perhaps someone else knows of some more? I don't know if you can count these as tutorials, but there's a D3D10 HDR sample in NVIDIA's SDK 10. I think there also might be a D3D10 one in the DirectX SDK samples.
  11. I settled on creating quite a few different input layouts (like 6 or so) and making a dummy shader with all the various vertex shader input structs. You can also put these vertex shader input structs in a global fx header file that is included in other fx files so your shaders only use those formats. That seemed to work pretty well for me. I think you could also use shader reflection via the ID3D10ShaderReflection interface, but unless you need to work with any type of input layout, I think it might be too much work. I then store a pointer to an input layout on a per mesh basis, since you need the input layout when rendering. You could choose this at load time based on the vertex layout of your mesh's vertex buffer. I don't claim this is the 'best' way to do things, but it seems Hellgate London uses a similar approach (see: pg 61 of http://developer.download.nvidia.com/presentations/2007/gdc/UsingD3D10Now.pdf). There are probably much more elegant ways, but this method is pretty simple and easy to implement.
  12. Quote:Original post by David Sanders The problem is with the quality of the text when zoomed in and out. Have you looked at Valve's Improved Alpha-Tested Magnification for Vector Textures and Special Effects paper? That could solve the text problem. The implementation doesn't look too difficult, and they provide HLSL code (which could be translated into GLSL quite easily).
  13. I think wolf is talking about "Percentage Closer Software Shadows" (PCSS) which is a NVIDIA sample. I could be wrong, but I think adaptive shadow maps (ASM) is a movie-targeted technique used in offline renderers (like Renderman). IIRC, they use a lazy-evaluation technique which doesn't seem like it would be too fast. As far as GPU implementations are concerned, I don't know of any source implementations but there's a paper here that I found with a quick google search for "Adaptive shadow maps gpu". It claims 5-10 fps on a 6800GT for somewhat simple scenes in the worst case.
  14. debugging direct3D 10

    The control panel should allow you to specify directories that d3d10 debugging is enabled for. Also, when creating the device, pass D3D10_CREATE_DEVICE_DEBUG for the flags. I also recall having to add D3D10SDKLayers.dll to my system path, but that was a while ago so the latest installer might automatically do that now.
  15. CreateRenderTarget + HDR

    Are you saying you're trying to create a rendertarget with a format of D3DFMT_A16B16G16R16F and with multisampling? CreateRenderTarget() can create 64-bit FP rendertargets just fine, but unless you have a 8-series NVidia or a ATI card (I think the x1XXX series and up supported FP16 msaa), then CreateRenderTarget() will most likely fail. What video card do you have? If its a Geforce 6/7, then creating a multisampled fp16 render target will most likely not work. Also, as far as work-arounds go, Valve uses an HDR technique that renders to 8-bit per channel textures (see: http://ati.amd.com/developer/techreports/2006/SIGGRAPH2006/Course_26_SIGGRAPH_2006.pdf, pg 138), however, I implemented it and don't like the look of blooming after tonemapping. For DX9 hardware, I would suggest an 'EdgeAA' method (just blur parts of the image at depth discontinuities). It won't give the same result as hardware msaa, but will probably look better than no anti-alising at all.