First of all, hello forum! I just discovered this place today and I dont know how I missed it before. Lots of cool stuff here.
Has anyone implemented a linear octree? I mean, as apposed to a linked list- its just a massive bitfield. I really like the idea of exploiting the fact that 3D space splits into 8 just as a byte has 8 bits, and it seem a nice data-oriented approach. My plan is to have each leaf voxel represented by a single bit, and I can just evaluate the list as bytes (zero or non-zero) to assess if the next lower level of detail contains geometry, and read the bitfield as 64 bit doubles for the level beyond that. After that, I think I'll have to store an additional "acceleration bitfield", where each bit represents the third level down from the leaf level, bytes represent the fourth, and so on... unless I can think of a better way to evaluate the zero/nonzero status of very large structs (I dont want to do massive loops, checking 64 / 512 / 4096 doubles - the whole point is direct-index speed). I don't know, what do you think?
But the burning question on my mind is if this kind of typecasting is going to seriously hurt performance, keeping in mind that the entire bitfield will be a multiple of 64 bits, and ought to fit nicely into doubles, but I dont really know. And since I'm having to rewrite my entire engine to go with this linear method before I can even check performance, I really just need a sanity check that I'm not overlooking something incredibly dumb.
Thanks for reading
Has anyone implemented a linear octree? I mean, as apposed to a linked list- its just a massive bitfield. I really like the idea of exploiting the fact that 3D space splits into 8 just as a byte has 8 bits, and it seem a nice data-oriented approach. My plan is to have each leaf voxel represented by a single bit, and I can just evaluate the list as bytes (zero or non-zero) to assess if the next lower level of detail contains geometry, and read the bitfield as 64 bit doubles for the level beyond that. After that, I think I'll have to store an additional "acceleration bitfield", where each bit represents the third level down from the leaf level, bytes represent the fourth, and so on... unless I can think of a better way to evaluate the zero/nonzero status of very large structs (I dont want to do massive loops, checking 64 / 512 / 4096 doubles - the whole point is direct-index speed). I don't know, what do you think?
But the burning question on my mind is if this kind of typecasting is going to seriously hurt performance, keeping in mind that the entire bitfield will be a multiple of 64 bits, and ought to fit nicely into doubles, but I dont really know. And since I'm having to rewrite my entire engine to go with this linear method before I can even check performance, I really just need a sanity check that I'm not overlooking something incredibly dumb.
Thanks for reading
