16
Programming with Blackvoxel / Voxel pixel selector box, render offset
« on: October 21, 2014, 05:29:08 am »
There's a constant '256' and '128' in the code, that in most cases is the size of a pixel.
I was making a static const global struct to contain values like this...
but somehow this isn't the value that's used in all places.
Edit: Nevermind I don't have questions... my issue was 256/128 is also used in player dimensions so I ended up shrinking the player... and everything from a mouse's perspective looked the same.... so have to do some more combing; the player doesn't collide right for isntance.
the voxel selection box renders in the new size... but is offset from the floor by 256(ish) so I was wondering what it's called? where it's drawn?
and the cubes are still spaced out by 256... what 'creates' the world? I would think that saves would be in voxel indexes... so if I change 256 to (GlobalSettings.VoxelBlockSize=64) and 128 to (GlobalSettings.VoxelBlockSize/2)
-------
I implementd a ZMatrix class which is basically ZTransformParams and ZPolar3d rolled into 1... so only the initial setting the yaw/pitch/roll updates that matrix, instead of later computing TransformParams possibly more than one time...
I lost the actual yaw/pitch/roll values, but have functions that can get the relative yaw/pitch/roll of the matrix, which ends up always between -180 and 180 instead of 0-360, and I'm not sure which direction 0 yaw 0 pitch 0 roll is.... THe RTFM block reads normal, but appears behind me... my 'forward' ends up being a 'backward'... Oh also keeping it as a matrix I can just return the address of the row for each axis, which is the normal right, normal up, and normal forward vectors already computed (part of transform params kinda) .
I got the plane mostly working... managed to take off and land and yaw/pitch/roll mostly works... there are some iteritive effects that aren't quite right....
The matrix rotate is always relative to the current rotation.... it's for tracking 6DOF in space really where yaw/pitch/roll is always relative to your current yaw/pitch/roll. I also have rotate matrix around an arbitrary axis... so I can pass the Y axis and an angle for flat-yaw rotation that the plane does as it is rolled...
The ground mode also has an auto correction to the roll, so every iteration just applied -roll to current roll to make the character stand up... ended up making the look up and down kinda auto rotate you if you pass the top... kinda like watching something go over head, when looking up, you'd keep looking up until you rotate your body and start looking (pitch) down to continue...
The other place I noticed polar vectors used is in the tree generators; so I ended up not replacing that usage.
Oh - so the other thing is I think that the 'view cone' isn't aligned forward anymore... was wondering what builds the forward culling... because it mostly works, but at times I'm getting strange short draws of sectors...(?)
Oh, and modified the save file... added blkplr3 that just stores location (zmatrix.origin) and viewdirection (zmatrix.quaternion) (this is a Vec4 that represents the current 3x3 rotation matrix) ; and not the camera location and direction, since this is always relatively updated by calling Actor->SetPosition()... so onload just set location viewdiection and call setposition.
I reread some of the things on your board, and I realize you're not looking for code input you're looking for funding input... so I'm gonna stuff a copy in my own repository so I can at least track all these changes...
I was making a static const global struct to contain values like this...
but somehow this isn't the value that's used in all places.
Edit: Nevermind I don't have questions... my issue was 256/128 is also used in player dimensions so I ended up shrinking the player... and everything from a mouse's perspective looked the same.... so have to do some more combing; the player doesn't collide right for isntance.
the voxel selection box renders in the new size... but is offset from the floor by 256(ish) so I was wondering what it's called? where it's drawn?
and the cubes are still spaced out by 256... what 'creates' the world? I would think that saves would be in voxel indexes... so if I change 256 to (GlobalSettings.VoxelBlockSize=64) and 128 to (GlobalSettings.VoxelBlockSize/2)
-------
I implementd a ZMatrix class which is basically ZTransformParams and ZPolar3d rolled into 1... so only the initial setting the yaw/pitch/roll updates that matrix, instead of later computing TransformParams possibly more than one time...
I lost the actual yaw/pitch/roll values, but have functions that can get the relative yaw/pitch/roll of the matrix, which ends up always between -180 and 180 instead of 0-360, and I'm not sure which direction 0 yaw 0 pitch 0 roll is.... THe RTFM block reads normal, but appears behind me... my 'forward' ends up being a 'backward'... Oh also keeping it as a matrix I can just return the address of the row for each axis, which is the normal right, normal up, and normal forward vectors already computed (part of transform params kinda) .
I got the plane mostly working... managed to take off and land and yaw/pitch/roll mostly works... there are some iteritive effects that aren't quite right....
The matrix rotate is always relative to the current rotation.... it's for tracking 6DOF in space really where yaw/pitch/roll is always relative to your current yaw/pitch/roll. I also have rotate matrix around an arbitrary axis... so I can pass the Y axis and an angle for flat-yaw rotation that the plane does as it is rolled...
The ground mode also has an auto correction to the roll, so every iteration just applied -roll to current roll to make the character stand up... ended up making the look up and down kinda auto rotate you if you pass the top... kinda like watching something go over head, when looking up, you'd keep looking up until you rotate your body and start looking (pitch) down to continue...
The other place I noticed polar vectors used is in the tree generators; so I ended up not replacing that usage.
Oh - so the other thing is I think that the 'view cone' isn't aligned forward anymore... was wondering what builds the forward culling... because it mostly works, but at times I'm getting strange short draws of sectors...(?)
Oh, and modified the save file... added blkplr3 that just stores location (zmatrix.origin) and viewdirection (zmatrix.quaternion) (this is a Vec4 that represents the current 3x3 rotation matrix) ; and not the camera location and direction, since this is always relatively updated by calling Actor->SetPosition()... so onload just set location viewdiection and call setposition.
I reread some of the things on your board, and I realize you're not looking for code input you're looking for funding input... so I'm gonna stuff a copy in my own repository so I can at least track all these changes...