Creating Octrees on GPU

by gernot.ziegler on 06/02/2008 19:11, 12 messages, last message: 06/24/2008 15:22, 1697 views, last view: 04/08/2024 06:52

Hej folks!

After having created quadtrees in OpenGL on the GPU (building times in the millisecond area), I have now an algorithm available that produces the same in
http://www.mpi-inf.mpg.de/~gziegler/ocpyramid/test-0000.avi

Let me know if you are curious on its inner workings :-)

-Gernot (more info on www.mpii.de/~gziegler )

   Board Index   

#1: Interested!

by MeatROme on 06/02/2008 21:17

Yes, I'd like to see some code - if you're willing to share :)

reply to this message

#2: ..

by scasd on 06/03/2008 20:42

I wonder how fast that algorithm is with projected shadows. Lightmaps are unusable if you process geometry on the GPU I think. Would be nice by the way. But it will break Sauerbratens low-spec philosophy as long as you dont keep the CPU-based octree as fall-back. Destructible terrain might be a problem in that case.

The additional calculations may also cause slowdowns to the other math done on the GPU.

reply to this message

#3: nice

by fhdskjconrhfjdks on 06/15/2008 20:01

It looks impressive:

http://www.mpi-inf.mpg.de/~gziegler/ocpyramid/0926_pot_octree_l4.png


Was poking around in the folder :D

reply to this message

#4: Re: ..

by L. Tempris on 06/23/2008 23:29, refers to #2

Destructable terrain- there are games that have it. Why cant you see what they have done to get that result then work with that?

reply to this message

#5: Re: ..

by tentus_ on 06/23/2008 23:38, refers to #4

Because Sauerbraten uses a unique deformable cube octree system, which means that trying to steal someone else's code and apply it is straight-up impossible. Even in very similar engines it's usually easier (and better in the end) to write your own code, and Sauerbraten is about as dissimilar to any other game engine as you can get (excluding Cube 1, of course).

This has been discussed before, try searching it up. Some very novel and interesting solutions and conundrums in the destructible terrain question. Lots of good idea-sparking.

reply to this message

#6: SP Idea

by tman_elite on 06/23/2008 23:55

An interesting thing to try would be to have a whole bunch of small brick models, and use them as "boxes" with a really high weight in sp mode. You could make a wall that could be blown apart by rockets or grenades, although shooting it wouldn't exactly get the desired effect... perhaps making the wall two layers thick would solve this.

reply to this message

#7: ..

by Captain_Ahab on 06/24/2008 01:39

I just had an idea ( but I'm too lazy/noob to do it myself )

can a script be called that can copy/paste a bunch of cubes that have already been pre-lightmapped to switch places with a beginning bunch of cubes without ruining the lighting? without screwing things up too much if one is careful about textures/lights?

for example:
a rocket hits a building and blows up, hitting a trigger to run a script to swap the wall out and swap in a blown up wall in its place.

reply to this message

#8: Re: ..

by tentus_ on 06/24/2008 03:59, refers to #7

Not currently, no. It'd take a pretty massive rewrite to do so as well, and even after a solid amount of work, it'd be hideously space-demanding. Of greater concern to me, would there be an elegant way of editing such a swap? I can't really think of one.

reply to this message

#9: Re: ..

by Captain_Ahab on 06/24/2008 04:08, refers to #8

I was thinking of a hidden area on a map to store a few pieces to copy/paste

but if it wouldn't work, oh well

reply to this message

#10: Re: ..

by tentus_ on 06/24/2008 04:52, refers to #9

It's not a bad idea for how to do it (if I was trying to make it reality that's how I would do it), but think about it in terms of the current editor. Up until now, and probably well into the future, it has been impossible to edit geometry without completely removing the lightmaps from the affected area. Swapping two sections in a map would mean that there'd have to be a rewrite preventing the discard from happening- and imagine how hideously that could affect the rest of the editing code.

Were such a thing possible, there'd be a few things that'd almost have to happen as well. One, you'd obviously need a way to show the selected area, and how they link together. Probably just render a variation of the selection box around each area, with little numbers in the eight corners ("1" for state one, etc).

Two, when the lightmaps are rendered you would want any light that affects the first state to also apply to the second state, but not vice versa, nor would you want the reverse. Hopefully our hypothetical mapper is smart enough to put the second state geometry somewhere out of the way, but there's no counting on it. And this could look really weird if you've got, say, a tall object being removed. Almost better to just teleport to a second copy of the map in scenarios like that.

Three, what happens to any monster or player inside? If you have a roof collapsing or something, they're going to have to get ejected to an empty space. But it's going to have to be a much smarter ejection that what we currently have for jumping out of editmode, because you don't want player deliberately blowing spots up so that they can get ejected above the clipped area of a map (which they will find exploit, inevitably). The best way I can think of to do a "smart" ejection would be to calculate all the possible exit points of each swappable area, which probably couldn't be done in real time, meaning like PVS you'd have to precalculate it and save it inside the ogz.

Any thoughts on any of this? I'd really like to hear an opinion from someone with more experience in this than me, I'm postulating on admitted limited knowledge.

reply to this message

#11: Re: SP Idea

by SheeEttin on 06/24/2008 05:38, refers to #6

A little while back, I had an idea about a destructible model, basically a non-damaging barrel.
I tried implementing it, but with my very limited C++ skill, I failed miserably.

If anyone wants to try it, here's how I envisioned it: Take the barrel, and remove the exploding, but keep the destroying.
It seems simple, but then there's the problem of figuring out how to add the entity. (As I said, I failed miserably.)

reply to this message

#12: Re: ..

by JadeMatrix on 06/24/2008 15:22, refers to #10

tentus is right. Probably the only feasible way to work destructible geometry is a massive rewrite. I'm thinking Cube 3, so don't hold your breath.
This post wasn't very helpful, sorry. I think I already exhausted all my ideas wherever this was originally discussed.

reply to this message

   Board Index