Block rotations?
XeonG opened this issue · comments
Will support be added for that?
The Voxelmetric system is made for you to build on to. It's a very simple addition but you need to edit each block type that'll support it, like logs.
(This repo is a lot different than Alex's, and I haven't fully explored it yet. Not sure where the block configurations are... xD)
It's a simple addition, guess I'll take a look at it.. getting to the stage where I don't have any plans to recreate a whole bunch of blocks just to have them facing different directions, would be better supported in code and the uv's updates accordingly. Just not sure how best to implement it.
I completely understand your point and I gave up digging in the code for the answer I expected. @richardbiely should answer this one for us.
You could store a rotation info in BlockData. It is currently 16-bit long which makes it possible to represent 65536 different block types. You could reserve a few of its bits for rotation. E.g., in a block world, these would most likely be 0, 90, 180 or 270 degrees which are 4 different states which translates into 2 bits. Thus, 4 different rotations and 16384 different blocks. Depending on rotation bits, you would then interpret return values of world.textureProvider.GetTextureCollection differently.
I've not done anything like that, you got some more info on learning about this bit voodoo
struct BlockData
{
...
ushort m_data;
public ushort Type { get { return m_data& 0x3FFF; } }
public ushort Rotation { get { return m_data>>14; } }
...
}
That helps... but I was meaning like what is this called so I can look it up and understand it better...
also what if I wanted to store in something else like I dunno block health? could that be squeezed into the same m_data ushort? or could the data_types class be adjusted to support an easier way of expanding it too include other bits of data?
E.g., in a block world, these would most likely be 0, 90, 180 or 270 degrees which are 4 different states which translates into 2 bits
yeh would kinda be 6 different states ideally to include facing up/downwards aswel as a minimum, then again rotation for that aswel.. heck you ever just played 7 days to die? that is a far better comparison on how I'd like to do block placement, so yeh like that.. for block/3dmodel placement rotations.
also what if I wanted to store in something else like I dunno block health? could that be squeezed into the same m_data ushort?
And why would it not be possible? :) However, the more "status" data you store the less bits remain there for different block types. For larger or more complicated worlds I guess you'd end up with BlockData which is at least 4B in size (not being a power of 2, 3B might not be an option because of possible performance issues due to memory aligment).
or could the data_types class be adjusted to support an easier way of expanding it too include other bits of data?
I'm not sure if I understand the question. Like I state above, you can simply reserve more bits for your purposes. There is no "data_types" class in the framework. Did you mean the BlockData struct? Be more specific, please :)
"And why would it not be possible? :) However, the more "status" data you store the less bits remain there for different block types. For larger or more complicated worlds I guess you'd end up with BlockData which is at least 4B in size (not being a power of 2, 3B might not be an option because of possible performance issues due to memory aligment)."
What I'm after is some sort of tutorial on this, what is it called that you are doing here with reserving bits in the ushort and then doing stuff like this...
public ushort Type { get { return m_data& 0x3FFF; } }
public ushort Rotation { get { return m_data>>14; } }
...its not something I've ever come across myself, (well maybe a bit :) but not like this. Good thing calc has a scientific mode with bits to play with... so I see how it could work more visually :)
"Did you mean the BlockData struct? "
yes I must have meant that... asking because I see its all setup for ToByteArray and that only takes in mdata, so changing how the struct would get serialized if I added another ushort to the mix would mess up how it already works.
Would switching mdata to uint give me more leg room to play with, would it effect performance much?
...its not something I've ever come across myself, (well maybe a bit :) but not like this. Good thing calc has a scientific mode with bits to play with... so I see how it could work more visually :)
Yes, I totally agree with this. When I first began programming and started using bits and shifts I always wanted to see it all in bits. The 1s and 0s are just much more visual. And now that the latest version of C# has binary literals you can just use the 0b prefix! Before the latest version I always used int binary = Convert.ToInt32("10101011", 2); to see the binary.
Yeah I get how it works now..still curious on this though...
yes I must have meant that... asking because I see its all setup for ToByteArray and that only takes in mdata, so changing how the struct would get serialized if I added another ushort to the mix would mess up how it already works.
Would switching mdata to uint give me more leg room to play with, would it effect performance much?
Would switching mdata to uint give me more leg room to play with, would it effect performance much?
Performance wise I doubt there'd be any significant change. However, memory consumption would be doubled.
Are block rotations supported natively in the project now?
No, they are not