Jump to content

  • Log In with Google      Sign In   
  • Create Account


(ok)

Member Since 19 Sep 2011
Offline Last Active May 29 2012 04:34 AM

Posts I've Made

In Topic: Destructible planetary size terrain : SVO, MC or DC extraction, both ?

28 May 2012 - 07:16 AM

Hi Digitalfragment,

Thanks a lot for the input.

Use this to generate your not-yet-destroyed object once at load time, not for real time.

Ok, I was even ready to cook before and deploy the whole terrain volume(at game installation) as a single reference SVO(even if very heavy on disk), stream / play with / destroy an instance of it in-game.

Depends on how you want to destroy it.

Upon impact with shots and let the gravity break-up the detached group(s) in smaller shards upon collision(+enough speed) with the underlying rest of the terrain.
If I use child pointers, I am not sure to understand how to update the octree after such events.

To shatter an SVO is just taking a chunk of the voxel nodes out and creating a new SVO out of them.

Thanks for that, this is one of the keys I needed to hear !

Heavy use of spatial partitioning

I tried to get familiar with several inner/leaf node structures to store my noise values but I am still hesitating in choosing one that will serve as well an easy ray-casting and physics animation.
I saw one person on youtube publish a sample with fair frame rates, ray-casting only on the CPU.
I asked him about the node structure used and he said he used barely half of Laine & Karas's one (without contours nor colors for test purposes) and their exact same ray-casting algo but without CUDA. Laine's ray-caster looks indeed easy to pull from CUDA to CPU. I probably need to have a shot at something like this but I am still not 100% sure :



Much thanks again Digitalfragment.

In Topic: Rendering many trees

27 May 2012 - 03:03 PM

but usually the data seems useless

Sometimes it is hard to figure out the cause of your stalls from the profiler only but if a module function comes on top at your app's run-time, at least you know your app is intensively using it. You must also use timing functions directly in your code to locate bottlenecks.

For your second question, it often depend on your transparency approach. If you use raw blending, you need a clever primitive ordering to get the most of it but sometimes screen door is more appropriate (no back to front order needed).

Check those :
http://www.gamedev.net/topic/599103-issues-with-blending-transparency/

http://www.opengl.org/archives/resources/faq/technical/transparency.htm

In Topic: Rendering many trees

27 May 2012 - 02:03 PM

Clb is right, you must measure as much as you can, and NO, you don't really need training for that.
You will be glad to simply check out methods with the highest profiles(the ones on top of the list) and possibly concentrate on/optimize them.

You can also more directly evaluate the time spent between statements with very simple functions.

Just google for c++ profiler/profiling tools.

Bench-marking your code is crucial to evaluate yet if you have enough budget for a specific job before writing it.
It also helps a lot to get extra clues about what's possibly wrong.

In Topic: Rendering many trees

27 May 2012 - 11:10 AM

Ok so it is not the drawing...

I don't know how you have implemented your quadtree but maybe you could test if some trees located outside the desired area get processed ?

For example, you could try to setup a breakpoint if a candidate tree is outside the desired area just to check. You could also double check if your whole loop or part of it does not get processed several time instead of only once. Check if one of your visible trees does not get considered more than once.

It happens to me all the time, fast(your

trunk/branches

) does unfortunately not always mean neat.

Good luck.

In Topic: Rendering many trees

27 May 2012 - 10:25 AM

Ooops sorry, you are doing quadtree culling yet so there might be unnecessary traversal.
My best guess is to debug your quadtree scheme and make sure no unnecessary trees are processed before or after.

PARTNERS