network profile
| bio | website | emitcode.com |
|---|---|---|
| location | Issaquah, WA | |
| age | 23 | |
| visits | member for | 1 year, 10 months |
| seen | Apr 19 '12 at 8:54 | |
| stats | profile views | 5 |
I write the code.
|
Apr 13 |
awarded | Supporter |
|
Apr 13 |
awarded | Scholar |
|
Apr 13 |
accepted | How can I incorporate physics into a procedurally generated world from a geometry shader? |
|
Nov 20 |
awarded | Autobiographer |
|
Jul 17 |
comment |
How can I incorporate physics into a procedurally generated world from a geometry shader? Indeed. We found that using XNA and keeping everything on the CPU gave us about 1 million vertices in roughly three minutes on a Core i7 with 8 cores and 8 threads parallelizing multiple sections of terrain per thread. When trying to do that in real-time and hopefully rendering the terrain before the player could see it, we achieved about 20 frames per second. So, a test case is definitely in order with each of the methods. |
|
Jul 17 |
comment |
How can I incorporate physics into a procedurally generated world from a geometry shader? The main problem we had was the GPU-CPU barrier. In the sense of, once we generate and render the terrain on the GPU, how do we figure out what the terrain looks like on the CPU side of things in order to do collisions and other things. I suppose your thought about keeping it on the CPU is valid. I mean, we can probably optimize our algorithm quite a bit and generate less terrain. I'll mark your response as the solution in a day or two to see if anyone else has a response. Thanks for provoking some alternative thoughts. |
|
Jul 17 |
awarded | Student |
|
Jul 17 |
asked | How can I incorporate physics into a procedurally generated world from a geometry shader? |
