Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1351314 views, last view: 12/09/2021 06:26

This thread is for discussion of Sauerbraten coding issues / implementation ideas etc.

   Board Index   

#1568: Re: ..

by rancor on 03/14/2008 08:30, refers to #1567

Yeah, I know you do, but the post I replied to didn't seem to.

The main point I was making was that anything using an octree structure is more similar to Sauerbraten then something using BSP.

This actually does seem more similar to the Sauerbraten structure, in that the voxels are the world, though not sure as to the exact format, as the article didn't go into enough detail.

reply to this message

#1569: Re: sparse voxel octree

by 9382938475 on 03/14/2008 14:33, refers to #1565

the cube structure isn't really defined by verts or triangles. its just that's what today's video cards understand so that's what it gets transformed into...

the octree implicitly stores the size and positions of everything, and the cubes just used to tweak things a little bit. that's why map sizes on disk are small - most of the info is being derived at runtime.

probably if sauerbraten just used really really tiny cubes, it'd be quite similar. but that's not practical today, so it allows for larger cubes that can be tweaked.

"The most little angle value is Pi/24, textures are fixed, etc..."

technically voxels are even worse. The 'smallest angle' is 90 degrees and 'textures' are only a single colour. You're kind of comparing trees with forests. Theres a difference between the properties of the primitives themselves, and the emergent properties of having a group of primitives placed together.

the thing to remember is that while the 'sparse voxel octree' doesn't even attempt to run decently on today's hardware, the genius of sauerbraten is that in compromises just enough to allow it do so.

reply to this message

#1570: Re: sparse voxel octree

by 9382938475 on 03/14/2008 15:27, refers to #1569

actually, what I think would be really interesting, is if the editing took more of a voxel editing approach. So you'd use small cubes of uniform grid size to carve up the world in various ways. This would just be at the cube level; not modifying the edges at all at this point. And then you could select an area and remip up to higher gridsizes in a way that smoothly uses the edges and whatnot.

and one could even work the other way around as well, subdividing cubes using something similar to a catmull-clark thing that works within the constaints of cubes. this'd work nicely for organic geometry at least. the nice thing about this is that you can work with cubes at a uniform gridsize and have the engine do the work of scaling detail up and down.

the heightmap stuff kind of attempts this, but this is a tough problem with multiple issues. In a sense it tries to do too much at the same time, yet still being useful for only very specific situations.

Really you need to split editing into two:
1) raw solid cube editing (no edge modifications, uniform gridsize), then
2) powerful filters that can be applied to groups of cubes to do stuff like smoothing, scaling gridsize up or down, and that sort of thing. Ideally one would let the engine manage edges and gridsizes itself, as much as possible.

There's a lot of research still there on how the filtering should be done though. The height map stuff does some cool things with paired-cube groupings, which makes transitions much smoother. But this needs to be moved from '2D heightmaps', to full 3D maps. There's a lot more cases to deal with when doing that though.

reply to this message

#1571: ..

by IllvilJa on 03/14/2008 18:53

Hm... regarding the above post on tools for creating objects in the saurebraten octree world: it could be useful not only to have powerful filters in the editor, but also to be able to write LUA/Python/Perl/Javascript/whatever scripts that process the world. Another stab at the latter is to create LUA/Python/Perl/whatever libraries that allows external programs to autogenerate or modify .ogz files. This can both be used to carry out some of the work with the .ogz maps, or to create a complete .ogz map from scratch. With a cleverly use of pseudo random number generators and seed values, one can have a script which creates the same fully playable pseudorandom map each time given the same random seed. This in turn can be used to implement random terrain in sauerbraten or mods (just like games like Freeciv and others have random maps), a seed value is generated randomly and distributed to all clients. Then all clients start generating the related pseudorandom map and once that is done, the clients enter said map.

Could bring the joy of exploration into the game. Ok, perhaps more suitable for a more BF2-like mod, but still.

reply to this message

   Board Index