Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

295 Neutral

About VladimirBondarev

  • Rank
  1. VladimirBondarev

    Comparing Shadow Mapping Techniques with Shadow Explorer

    I've done a small specialization at my university about aliasing on shadow mapping, Its not top quality, but perhaps could be useful to someone else: http://www.bondarev.nl/files/specialization_shadow_mapping_algorithms.pdf
  2. VladimirBondarev

    Debugging Memory Leaks in Visual Studio 2010 (c++)

    I use this type of implementation for this: http://www.flipcode.com/archives/How_To_Find_Memory_Leaks.shtml Doesn't work on malloc etc.   It will make your code really slow, but the awesome thing is.. you can add some extra functionality: -Record when the memory block was allocated. -Reset you memory-track-table -Output the table when you like to a file -etc.
  3. VladimirBondarev

    Are static member functions ever used?

    If you declare global static object in c/cpp file "static type gObjectName;" you cannot link the object from the header file by calling "extern type gObjectName;".
  4. VladimirBondarev

    How do I handle lots of textures

    You could combine textures into one large texture, recalculate UVs based on your new texture... should do the trick.
  5. VladimirBondarev

    Occlusion Query for Logic - not Graphics?

    First of all i like the idea, but it has some potential problems. -Possible problem is to drawing 360 fov view in single pass. If im not mistaking, projection matrix does not allow fov of 360. -Occlusion query stalls your GPU. Perhaps not important for you, but its good to keep it in mind. -The resolution will determain the precision of your approximation. -If to split 360 pass into 2x 180 fov, you will still face precision problems: low approximation precision on the edges. -also possible to split into 6x 90 fov passe, same way cubemaps are generated. i would defenatly go for this one. Modern engines use a very simple software rasterizer to solve occlusion problems (has still same problems for your solution) to stay away from gpu. Basic unoptimized approach would be something like: -draw all objects that are potential occluders in on cubemap (6x 90 fov). Except the one that will be tested. -do occlusion query test on object of interest on each of 6 rendertargets. -sum the result. In my opinion it will be a heavy process and not consistent. Have you considered to do any other tests then occlusion query? I would recommend to try something in direction of simplified object-models and raytracing heuristics. Like: Sphere1 - occluder Sphere2 - object of visibility interest. -is sphere1 aligned with sphere2 and how much? Can be tested with simple dot-product. -how does does my current fov effect the corelation of delta distance and sphere sizes. Good luck!
  6. VladimirBondarev

    My Projects

  • 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!