We need a single world model for all of the different views.

[meissnereric]

So here are some questions and thoughts on voxels and physics.

Is voxel engine a view or a model? Dumb “view model”? Is it ok to have chunks loaded that are not in view? What variables does it care about? Do we need to persist during gameplay things that aren’t the chunk manager? What kind of data structure do we store non block objects in? player, workers, baseball bats Where do we store physics data

Persistence Which chunks are on RAM and which ones are on disk? Just around the players? What about workers? Physics?

Physics What kinds of variables need to be tracked? Pos/Vel/Acc Where should those variables be? Block some external data system (physics engine?) Physics engine only has reference to objects undergoing physics and handles variables Things that recently got touched by the player / workers / other things undergoing physics Should they persist on disk write? What happens when an object attempts to leave the loaded area? Pause before entering unloaded chunk maybe more variables to track Do we just set velocity = 0 there? Or do we remember? Delete it as entering unloaded chunk perhaps an invisible force field destroys it ;) Load the chunk its going into could bog down the world

[tefu]

I'll try answering some of these.

Is voxel engine a view or a model?

Both, I guess. The voxel engine I'm working on getting pulled in is based on the two voxel engine tutorials, Let's Make a Voxel Engine and Glescraft. Both tutorials suggested that voxels know how to update and render themselves—in this case, a chunk of 16x16x16 voxels. The important thing to note is that update() and render() are not how you alter the grid of voxels. They just update and render the view. The model here is changed through ChunkManager member functions like set(int x, int y, int z, BlockType type) (which sets the voxel at grid position X, Y, Z; see here if you're curious).

What variables does it care about?

It mostly just cares about static voxels on a 3D grid. "Static" meaning these voxels don't move. They just have an integer position, and know what type of voxel they are. I'm not opposed to someone making that more flexible, though (e.g., giving each voxel a durability).

Is it ok to have chunks loaded that are not in view?

This is getting into optimizations, but chunks that are currently not in camera view are both loaded in memory and rendered to the GPU. I'd like to fix the GPU part, but it's fine if they're still in memory.

[meissnereric]

Hey all,

I've reserved a room in Library 418F at 4:00 PM today (Monday, March 16th) to talk about how we're bridging the gap between the World class and the Voxel engine. We'd like to talk about how the Voxel engine is getting data from the World object, what the Voxel engine needs, etc.

If you're involved in any part of either building/generating the World or working on one of the Voxel engine forks right now, please come so we can all get on the same page and work collectively.

[waredavid]

Will be there

[tefu]

Meeting up isn't exactly transparent for the distance students, or anyone who can't go.

My thoughts on the voxel engine right now: it isn't much of a parallel problem to begin with. I think we originally went for it because "Parallel problems need data, and a giant 3D matrix of voxels would be a great source of data!" This is somewhat true for analyzing the matrix (e.g. building a map or creating workers to interact with the world), but from my experience playing with it, the voxels themselves don't change much. Generating the world is a one time cost at startup, and it's not like we want a metric ton of tsunamis and black holes tearing the world apart (new feature, anyone?).

The real performance concern with a voxel engine is graphics. Everything I read on the subject would talk of lowering the memory sent to the GPU--rather than increasing CPU performance--cause rendering polygons is hefty computer work. However, graphics is beyond the scope of the course. I think there was a tacit assumption at the beginning of the semester that some people know graphics--and while that's probably true--no one could try working on it until now because it wasn't parallel, at least in the CPU sense.

We'd like to talk about how the Voxel engine is getting data from the World object

The World object wasn't very usable, so I tried putting the 3D matrix of voxels inside the ChunkManager class--which is both the engine and a model. I realize this isn't very MVC, but I'm not sure of how to refactor it. One choice for now would be to wrap the ChunkManager in the World class. Then we'd just call update and render on the ChunkManager when the World updates and renders.