Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 31 Aug 2011
Offline Last Active Nov 28 2013 03:40 AM

Posts I've Made

In Topic: Debugging Memory Leaks in Visual Studio 2010 (c++)

04 April 2013 - 08:47 PM

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


In Topic: Are static member functions ever used?

04 April 2013 - 08:43 PM

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;".

In Topic: How do I handle lots of textures

04 April 2013 - 08:21 PM

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

In Topic: Occlusion Query for Logic - not Graphics?

04 November 2012 - 09:38 AM

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

In Topic: Sorting by depth for occlusion queries + sorting by materials and meshes

09 June 2012 - 04:38 AM

Just as you said, first depth only.