Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


pondwater

Member Since 26 Sep 2010
Offline Last Active Aug 27 2013 10:45 AM

Posts I've Made

In Topic: Calculating area left uncovered by overlapping projected circles on a plane

25 August 2013 - 07:35 PM

@nonoptimalrobot

 

Sorry the colouring algorithm (which your right, probably isn't even the correct term) is used to compute a value in the objective function of the annealing algorithm. The annealing is used to optimize the placement of these ellipses over a mesh. I'm using a GPU approach similar to the on used in:

 

Han, Y., Roy, S., & Chakraborty, K. (2011, March). Optimizing simulated annealing on GPU: A case study with IC floorplanning. In Quality Electronic Design (ISQED), 2011 12th International Symposium on (pp. 1-7). IEEE.

 

It works very nicely so far, except that i've hit a bottle neck on this particular area calculation. When i mentioned: "Currently I run 256 to 1024 compute shader invocations depending on the resolution of my current approach, each calculating the overlapped area asyncronously." I meant that each compute shader invocation is computing the area for their respective energy value from the objective function.

 

@unbird

 

Here is an image example:

 

Top (Side view):

 

    Red = original mesh surface

    Blue = projected mesh surface

    Black = disks and their projections

 

Bottom (Top-Down view):

 

    Blue = projected surfaces

    Green = uncovered area I want to calculate

 

cKjqH9v.png


In Topic: Calculating area left uncovered by overlapping projected circles on a plane

23 August 2013 - 03:48 PM

Currently I run 256 to 1024 compute shader invocations depending on the resolution of my current approach, each calculating the overlapped area asyncronously.

 

I was considering using a rendering type approach as you suggested, but drawing and counting pixels instead of simply querying. Do you think there would be a performance gain in what would effectively be 256-1024 sequential occlusion queuries per annealing iteration?

 

I do not have any experience with the ARB_occlusion_query OpenGL extension so I do not know anything about its performance.


In Topic: Finding a unit vector orthogonal to another vector, on a plane

13 June 2013 - 08:40 PM

Well this is embarrassing, lol. I guess I was really over thinking it.

 

That works perfectly, thank you very much!


In Topic: skeletal animations and suitable formats

17 November 2012 - 03:19 PM

Find yourself an XML parser, I used rapidxml from http://rapidxml.sourceforge.net/ , it seemed lightweight, then again I haven't much experience parsing XML files so definately look around yourself, here would be a good starting point: http://stackoverflow.com/questions/170686/best-open-xml-parser-for-c

Definately look at wazim's article for a nice introduction to the .dae file format and how to approach it.

In Topic: skeletal animations and suitable formats

17 November 2012 - 02:31 PM

Here is the link you were talking about:

http://www.wazim.com..._Tutorial_1.htm

In any case, you want to have some sort of asset conditioning pipeline where you take in an interchange format like .dae and bring it into your own runtime format for your game/engine. How your engine manages its content at runtime is another story.

I attempted to go the approach you did and write my own collada parser. I got it working, but it wasn't robust at all. I find the incredible amount of a variance in the .dae format extremely frustrating and ended up switching to using Assimp for my .dae models. It is great. Nice clean interface, very robust, and much faster than my own parser for optimizing vertex indices. I'd recommend attempting to roll your own like I did, once you get it working for just 1 instance of the .dae format you will understand the format so much more and will feel more comfortable transitioning to Assimp.

Here is a fantastic tutorial if you decide to switch to Assimp:

http://ogldev.atspac...tutorial38.html

It also teaches you how to skin on the GPU, instead of the CPU like wazim's.

PARTNERS