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]

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?

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]

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

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(>> 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

[olive]

...
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...

Thanks for sharing your code.

Yes, as a free software project, we need to find some funding, but we are also searching for contributors on the game itself. That's one of our main priority.

To help to contribute we have published the Blackvoxel source code on GitHub here: https://github.com/Blackvoxel/Blackvoxel. See the announcement here http://forum.blackvoxel.com/index.php?topic=67.0 and here http://www.blackvoxel.com/view.php?node=1550. So you would be welcome among contributors  .

The GPL licence is the only fixed rule: as a free software basis, programmers should remain free to do what they want or contribute to what they want to.

Contributors can choose helping us to improve or develop some point we'll discuss or items on the roadmap as they want to.

Or (at their choice) they can develop their own ideas on a "fork" basis without constraints. We can decide at some point (on our appreciation) to bring some ideas and/or code we found interesting to the main project.

Organising contributions is not an easy job as we may have to make decisions about project direction. But with time, we'll certainly find how to make best for it.

One last thing : when we'll integrate some code or ideas, we'll add the contributor names in the game credits screen (and appropriate credits citation files). So don't forget to put your real name somewhere if you want it to be listed.

The Blackvoxel Team

[d3x0r]

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(>> 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

Right; I actually ended up replacing '256.0' so it missed all the integer versions... there are a few other places that 256 is used...

I ended up making a separate global varible "VoxelSizeInBits" which then expands and creates the actual voxel size... then I had the number to fixup the shifts too.

'12' and '16' are also rarely used numbers, these were shifts from world space to sector (world_bits + ZVOXELBLOCSHIFT_[x/y/z]) and a few places where it was just '8' from world space to voxel coordinate.

most compiles generate shifts if the constant is a power of 2 in a multiply or divide when generating optimizations; at least MSVC and GCC do.

-64 = 0x(ffffff)C0
dividing or shifting a signed variable results in the same value
if the value was an unsigned integer the shift would give the wrong result because it would not be sign extended, and would be 0 filled at the top instead...

-----
Made a fork on github...
I would try to make a pull request to sync some of the stuff; (cmakelists for instance) but I mangled(touched/modified) a lot of sources in the update to use SDL2.
I don't know if you get to see forks on github
My original changes were from the source download, which was behind the sources on github... hmm maybe I can fix that... otherwise I think I end up losing some changes...

Well at least there isn't a lot in code conflicts... (fixed reversions)

if normal selection fails, I was using the same raycaster and shortening the max iterations; then realized I just had to scale forward by world voxel size * (6), get the voxel that point is in and draw voxel selector in air... and set that it collided so click can set the block... want to add like shift-scrollwheel to change the distance of that block... but still need to fix scrollwheel events in SDL2 port.

[olive]

Right; I actually ended up replacing '256.0' so it missed all the integer versions... there are a few other places that 256 is used...

I ended up making a separate global varible "VoxelSizeInBits" which then expands and creates the actual voxel size... then I had the number to fixup the shifts too.

'12' and '16' are also rarely used numbers, these were shifts from world space to sector (world_bits + ZVOXELBLOCSHIFT_[x/y/z]) and a few places where it was just '8' from world space to voxel coordinate.

most compiles generate shifts if the constant is a power of 2 in a multiply or divide when generating optimizations; at least MSVC and GCC do.

-64 = 0x(ffffff)C0
dividing or shifting a signed variable results in the same value
if the value was an unsigned integer the shift would give the wrong result because it would not be sign extended, and would be 0 filled at the top instead...

Yes, compilers are replacing some divide by shift. But there is a trap... 

Look at this program:

Code: [Select]

    int a = -64, b, c;
    b = a / 256;
    c = a >> 8;
    printf("Divide : %d\nShift : %d \n",b,c);

This will give you the following result:

Code: [Select]

Divide : 0
Shift : -1

(Note it uses only signed integers.)

So, the program give us different results with divide and shift. And we use the "right" signed arithmetic.

Lets analyse how shifts are working:

This is how -64 is coded in binary:

1111111111111111111111111111111111111111111111111111111111000000 = -64

Naturally, we must use the appropriate x86 signed right shift instruction (sar) to preserve sign in the shift.

So, shifting by 8 with preserved sign will give you:

1111111111111111111111111111111111111111111111111111111111111111 = -1

Right shifting this negative value will never give 0 even if shifted forever.

So, shifting, even with signed instructions don't give the same result for negative numbers than division.

You said compilers are optimising some divisions with shift: yes it's entirely true. But there is some subtlety in what they do.

Looking at the assembly code comparing how shift and divide are translated to assembly(with GCC), we found:

c = a >> 8;

Code: [Select]

mov -0xc(%rbp),%eax
sar $0x8,%eax
mov %eax,-0x4(%rbp)

No surprise, pure shift is translating to "sar" x86 instruction.

And for the divide form:

b = a / 256

Code: [Select]

mov -0xc(%rbp),%eax
lea 0xff(%rax),%edx
test %eax,%eax
cmovs %edx,%eax
sar $0x8,%eax
mov %eax,-0x8(%rbp)

That's where things become interesting.

The divide instruction is translated to shift instruction... but other instructions where added by the compiler.

In few words, these instructions are testing if the value is negative and in this case, the input value is adjusted before being shifted.

This clever trick give the right result for negative value shift.

But without this fix, "shift as divide" would have given an incorrect result for negative numbers.

The Blackvoxel Team

[d3x0r]

Yes, compilers are replacing some divide by shift. But there is a trap... 

Look at this program:

Code: [Select]

    int a = -64, b, c;
    b = a / 256;
    c = a >> 8;
    printf("Divide : %d\nShift : %d \n",b,c);


Oh I see... well I didn't change any operators....
that's interesting...
that does solve some boundary issues (or cause if not recognized)