Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

134 Neutral

About ganchmaster

  • Rank
  1. Quote:Original post by Drakex Well, I'd assume it's faster than looping through 15 effects and setting the "View" matrix 15 times. Unless, of course, that's just what the ID3DXEffectPool is doing. I figured it'd do something more elegant. If not, then I won't worry about it too much. Yeah, I would assume it is doing something better than that; it probably has a single value that the other effects can reference...But the thing I am thinking is that it still will be calling SetXXConstant for each effect, every time you Begin() it, whether or not the parameters are shared, and that is what you really want to avoid. Anyway maybe you should avoid using the effect system for this stuff and just upload constants into registers. The nice thing about that is that the upload only happens once and you can use the value in any shader, so it is more efficient. The downside is you have to do a bit more work managing a register layout, but in practice I think it's simpler than using the effect system. You can use the "register" keyword in HLSL to force values to specific registers; just be sure they aren't being clobbered by other HLSL programs.
  2. Perhaps you could make a dummy effect which uses all the same shared parameters, and use that to set them. Just curious, why do you think there's a speed boost from using an effect pool?
  3. ganchmaster

    3d textures

    3D textures, as precomputed "arrays", do have uses in games. They are used for lookup tables for complicated functions. I have used them, for instance, to do lookups into precomputed offset tables for jittered shadow map sampling. There's also a neat thing you can do with animated textures; if you use a 3d texture for a animated texture (instead of page flipping 2d textures) you can get blending between the "pages" - good for some effects like fire. Just because someone doesn't use 3d textures, they shouldn't say "3d textures have no uses in games. period." That's silly. It's just another tool you can use for various things, that has strengths and limitations like any other feature; there's no reason to fear it. I don't know why people are slamming this guy just because he asked for some 3d textures. If he wants to make a renderer that uses 3d textures, why not? Maybe he'll make something cool. He didn't say "I'm thinking of using 3d textures, BUT MY ENGINE MUST BE AS TEXTURE CACHE-FRIENDLY AS POSSIBLE". For all we know, he's doing an offline renderer. And, at least he's not doing the same thing as everyone else. I think using 3d textures may be good for some types of rocks; it will be easy to get the mapping consistent. Orangytang gave some of the real reasons that 3d textures may be slow, but those may be acceptable to the original poster. It's true that most 3d textures will be procedurally generated. But it may be faster to pregenerate them rather then compute them in the actual shader at time of use. And then you have a 3d texture. For the original poster, I'd suggest that he look into generating these noise textures offline - look up perlin noise and you will find lots of examples. I'm sure you can get all kinds of marble textures and stuff like that going easily. One thing I would suggest is to make sure all of your 3d textures are power of 2, as it seems like the cost of memory alignment will be larger in 3 dimensions.
  4. ganchmaster

    Projection Matrix

    Quote:Original post by Deckards Yes, the Z values aren't mapped linearly into [0,1] space, but as [0,1] is the view volume between the near and far plane, all the vertices that have a Z value in the [near,far] range should have their transformed value in the [0,1] range, right? Yeah, that is correct. So I guess what I stated earlier is not the problem. It looks like the sign of your mat._23 term is incorrect. Usually people have +1 as the _32 parameter, and the signs of the _22 and _23 terms are + and -, respectively. Since you have -1 as _32, probably the signs of _22 and _23 should be - and +.
  5. ganchmaster

    Projection Matrix

    Quote:Original post by Deckards With a far plane at 10000 and a near plane at 1, a z values of about 5000 should be transformed into ~= 0.5, right? This may be the source of your confusion: the world Z values are not mapped linearly into [0,1] space. Generally most of the [0,1] range will be taken up by the area very near to the camera. I haven't done the math for this case but I wouldn't be surprised if the Z buffer value at 5000 ends up > .99. What actual value did you get? Your functions look correct from a cursory glance.
  6. ganchmaster

    Idea: Partially deferred shading

    Quote:Original post by Cypher19 First, render the normal/diffuse/whathaveyou textures normally, but when rendering the scene, instead of just doing a quad that renders the scene with a pixel shader grabbing texture values like crazy as it goes, it uses the actual scene geometry. In the vertex shader, the geometry has one texture coordinate that is calculated by taking the post-perspective location, and transforming it into texture space. Then, in the PS, the appropriate texel is looked up using it. I thought of this but I don't think it works right. The problem is, what texture values (from your "G-buffers") are used at the edges? When doing normal multisampling AA, the blended pixels at the edges of triangles are actually made from two or more shading operations, including, for example, two separate diffuse texture colors. But your G-buffer, which is the size of the screen, only stores one diffuse color there. So some of your multisampled pixels will end up using the wrong texture lookup values. Rendering the G-buffers with AA doesn't help either, this causes both edges to share the same blended color (and normal, etc.), instead of blending the output color. You could try rendering the G-buffers at double resolution - if the subsamples are sampled at the right subpixel offsets, allowing you to sample into the G-buffer at it's pixel resolution, this might be better, but still not correct (given the rotated grid), and it would be a crushing blow to texture access bandwidth. By the way, has anyone actually tried the edge-blurring method as described in GPU Gems 2 for STALKER? I looked at it and decided it wouldn't give good enough image quality, but didn't actually try it...anyone care to share their experiences?
  7. ganchmaster

    Modern Fast Rendering?

    Quote:Original post by superpig Quote:Original post by Max_Payne I will check out spherical harmonics. But are they fast on modern hardware? Fast enough that I know of commercial games using the technique. Interesting, can you say which one(s)? It always seemed to me like a technique that was great for demos but difficult to apply in a general way in a game environment - at least an interior style game.
  8. Quote:Original post by SimmerD Ok, I'm a bit confused. I don't see any problem with partially transparent objects receiving shadows from opaque objects. Is this what you're having trouble with? In general with depth-based shadow maps, objects in the scene can receive shadows even if they are not rendered into the shadow map. Are you talking about the difficulty of rendering the transparent objects into the shadow map itself? I believe his problems stem from the fact that he is using multipass rendering; you can't conveniently alpha blend multiple passes. BTW, if you have lots of alpha blended objects (not just alpha test) you might consider trying to go to a single-pass technique.
  9. If you must use multipass, this can be a hard problem. Carmack has mentioned using a dithering pattern, and then blurring over it. Apparently that works pretty well for him. In more detail: Say you have a translucent surface with %50 translucency. Instead of using alpha blending, render every other pixel in the surface, maybe using alpha test, or perhaps some kind of frame buffer operation is available that will do this. So you have a pattern of opaque pixels like so: X X X X X X X X X X X X X X X X X [edit]Ok, the formatting makes my X's not come out the way I wanted here. Suffice it to say that they're in a checkerboard pattern. Each opaque pixel can easily be correctly shadowed and lit, because it's not translucent. Then, when you have render all lights onto all translucent surfaces, somehow blur/downsample them. This will average them with the frame buffer and you'll get correct lighting with translucency. NVidia's new supersampling transparent AA might be able to help with this, by doing the blurring for you. There are disadvantages to the technique, of course, and you should check out Carmack's 2004 Quakecon speech for more details. Another option: render all of your shadow buffers beforehand. Then, render all opaque objects, using whatever shadow buffers they need. Then, render translucent objects. If you want to use multipass on translucent objects, you could try something like: initial pass: multiply frame buffer (dest) colors by translucent alpha for each light: add src color * translucent alpha to frame buffer This is equivalent to doing a alpha blend with the correct "multipassed" color.
  10. ganchmaster

    Modern Fast Rendering?

    Quote:Original post by Max_Payne Actually, its the best way of doing things for us. Animating models in hardware is not possible on all hardware, and if we want per-polygon hit tracing and collision detection, it requires that it must be done on the CPU anyways. And its not like sending batches of vertices in a vertex array is really a problem with modern hardware. Animating models in hardware is possible on all of your target platforms, though. It's a good point that you must effectively animate the polygons on the CPU if you want to do collision detection per-polygon. However, very few games really need per-polygon collision detection on skinned objects. And even if yours is one of them, you will have to animate the normals also, and if you're doing normal-mapping, the binormals and tangents. So that can start to add up. Many games are CPU bound, and if you are doing a large city with indoors and ourdoors, 5000-15000 render batches, and per-polygon collision detection, and moving all of the vertex data for characters dynamically onto the card every frame, I bet yours will be one of them ;). So you might not want to write off vertex shader animation just yet. In particular, don't avoid it just because you haven't it done it before, if that's the case.
  11. ganchmaster

    Modern Fast Rendering?

    What range of hardware (CPU/GPU) will you be targeting? Your base level rendering seems reasonable for a start to get something running. To render a large city environment with reasonable detail, you will have to spend a lot of time on LOD and HSR techniques. Do you have plans for that stuff?
  12. ganchmaster

    Minimum bounding ellipsoid implementation

    Here's a crazy idea: compute an optimal OBB for the points. Scale the points along the OBB axes by an amount equal to the the OBB axis lengths, so that they fit in a unit length OBB. Now compute a bounding sphere for the points (there should be ways to do this near-optimally). Stretch the bounding sphere back by the inverse of the scale transformation to form an ellipse. I don't know how optimal it will be, but it may be not too bad. In many cases it will probably be very near optimal.
  13. He doesn't mean vertex buffers; he means vertex streams. As in SetStreamSource. Anyway, the best answer is to set up a profiling situation and see. Load the same data using one stream and two streams and see what the difference is. I'm guessing it won't be much, but I haven't tried it myself.
  14. ganchmaster

    ATI / NVIDIA Performance Issues

    Quote:Original post by weasalmongler If I put them into a static buffer then I am unable to move them around. I would have to do one call to DrawIndexedPrimitive as I would have to change the modelview matrix. By performing the transformations myself on the CPU, I eliminate this problem. I see. Like AndyTX said, it sounds like you need to look into instancing techniques, if you really want to draw a large number of independently moving objects with a single DrawPrim call. With the right instancing scheme, you should theoretically be able to make a good optimization by saving a lot of the overhead of the dynamic buffer. But also, even if you are using a dynamic buffer, why are you calling CreateVertexBuffer every frame? You can create it once and fill it over and over. Maybe that is the source of your problems?
  15. ganchmaster

    ATI / NVIDIA Performance Issues

    Quote:Original post by weasalmongler The reason I am not using static buffers is that it would require 1 call to DrawIndexedPrimative per game object. - James Why not just put all of the vertex data into a single static buffer? That would still be better than copying every frame.
  • 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!