Blackvoxel > Programming with Blackvoxel
Voxel pixel selector box, render offset
d3x0r:
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...
Qon:
Ehm what?
I have no idea what you are trying to to say. Are you discussing the BV source code or some other code?
What is a voxel pixel?
d3x0r:
--- Quote from: Qon on October 21, 2014, 07:10:14 am ---Ehm what?
I have no idea what you are trying to to say. Are you discussing the BV source code or some other code?
What is a voxel pixel?
--- End quote ---
Sorry I don't know your dictionary. Voxel pixel is probably a redundant statement and should just be voxel... voxel block?
------------
Of course I'm talking about BV code.
I ironed out a few more issues with changing 256 to a variable... there was a few place where shift operators were used. Fixed the ZSectorSphere (which was actually IsPointVisible, which I broke by not using TransformParams class) usage so correct 'distant' things are rendererd.... there's also a near render ... I know because I had one working and not the other.
Now most everthing is good until I get to the first random land sectors, and I have sectors appearing in air, and sectors rendering and then not rendering and I'm just sitting still... what class/function renders the first random landscapes?
Edit:
World_Genesis; and various functions there. got it.... still don't know why.... I assume it's some base offset based on height map as a unit of real space? something I dunno
d3x0r:
Fixed that; I ended up missing searching headers for '256' and '128' (and shifts....) but most important there was a translation of player position to player sector position that was not updating correctly... so every sector block was outside of distance and qualified for ejection.
much more stable now... (well as stable as before I started mangling it with a global setting for block size)
really want to make it more like an object setting ala Space Engineers
olive:
--- Quote from: d3x0r on October 21, 2014, 03:28:56 pm ---Fixed that; I ended up missing searching headers for '256' and '128' (and shifts....) but most important there was a translation of player position to player sector position that was not updating correctly... so every sector block was outside of distance and qualified for ejection.
much more stable now... (well as stable as before I started mangling it with a global setting for block size)
really want to make it more like an object setting ala Space Engineers
--- End quote ---
Hi d3x0r,
If you changed code for conversion, there is a little trap in the player to voxel coordinate conversion. If you replace shift by division it won't work because result is different on some values. Try with negative value -64.0, division(/256.0) and shift(>>8) won't give the same results. That could be enough to mess a lot of things.
The shift conversion was used to avoid having two "0" voxels ( 64.0 and -64.0 position would have given the same result : 0).
Another problem if you replaced the "256" constant in code is that this number is also the number of voxels in a zone. The zone is the unit for the generator to choose the kind of landscape that will be generated. That's used in some code in the generator ("ZWorldGenesis.h" and .cpp).
The Blackvoxel Team
Navigation
[0] Message Index
[#] Next page
Go to full version