iamscottmoyers / cambhaxx-gles

GLES experiment
5 stars 0 forks source link

Rotating cubes an misaligned cubes #7

Open iamscottmoyers opened 11 years ago

iamscottmoyers commented 11 years ago

Do we want to go down the path of allowing cubes that aren't aligned to a grid? We have started that way, but looking at voxatron I'm not sure they allow this. Aligned to grid cubes will make collision detection easier.

There's also the question of whether cubes can be rotated at angles other than 90 degrees?

davestevens commented 11 years ago

i was reading abut voxels in the week. wikipedia states: "A voxel (volumetric pixel or Volumetric Picture Element) is a volume element, representing a value on a regular grid in three dimensional space." the use of regular grid to me suggests that it is a finite grid? although, we should decide on how the game play will be, i was thinking about camera view and if its top down (or even slightly off angle of top down) then snapping to a grid for rotation would be fine i guess, but if we want a section in first person mode then rotation would be horrible. so i guess it depends on how we see the game working.

iamscottmoyers commented 11 years ago

I think the camera should be allowed to go wherever we want to put it. No grid / angle restriction. If we are sticking to the wiki voxel then yeah the cubes must be aligned to the grid and can't rotate at angles other than 90 degrees. Which is not what we currently have.

We should think of some structures for storing objects in the 3D grid, there's a couple of ways I can think of at the moment not sure which is best.

  1. 3D array containing pixel data (populated / unpopulated / colour) - If there are a lot of empty pixels this is a waste of space...but easy to search for whether a given pixel is populated or not. Could be that each pixel simple contains a pointer to data rather than a structure.
  2. Linked list of coloured pixels and 3D coordinates - Possibly smaller memory footprint, but will take a while to search. OOOOO could speed that up with octrees.
davestevens commented 11 years ago

i kind of means that if you're in first person perspective and seeing out of a characters eyes which can only rotate 90 degrees (i guess in a snap to grid motion) then you're going to be looking north and then immediately east.

the use of a 3d array means we will be limited to a size though? which would also be different for different devices? if we used a linked list of current objects (these are arrays of pos_t) including a global position and direction, then animations would simply move objects a set size in the 3d space.

iamscottmoyers commented 11 years ago

Yeah I get you now. I thought 1st person was 3rd person. 1st person would not look good you're right, we could perhaps just smooth the camera out if we wanted 1st person.

Well we would set our 3D array to the level size which isn't device specific...unless it was a level that was huge and there wasn't enough memory.

3D array is good for collision detection, if the pixel is already set then we've had a collision. But we can use a lot of memory. If a 100x100x100 level is big enough then we should be fine. 1000x1000x100 is like 400MB on a 32 bit device, before we've allocated colours etc.

A linked list would probably be better anyway, we will likely need such a thing so we can reference a particular object in a level anyway. If collision detection is slow we can do fancy things like use octrees.