Tiny gap after item is placed

We've posted a status update with some first screenshots of the new terrain generation. There is also a new update available for the Java version!

    Post by philtwice ().

    This post was deleted by the author themselves ().
  • Gillwin wrote:

    are these blocks in the game or planks and beams? if they are pnb do you have the grid on or off?
    Planks & beams, grid off. The gap is actually the same size as the "setp 1" size, which means you have to compensate for it. Here's another example (nothing else is touching the placed plank):
    Files
  • Not sure if you were using the snap feature to generate this but if you were than that would explain it. When beams snap on to each other they over lap by 0.01 so you would have to compensate for this in the over all length of the beam. This becomes more noticeable when snapping several pieces in a row and then comparing them to blocks. The gap will become more noticeable.
  • Happens even without snapping. This bug is a misalignment rather than an overlap, though. I've never seen any overlap/length issues. It's only the positioning that goes wrong.
    Here's another example, modular snapping off. The plank is aligned to the orange one below and the beige corners around it, yet somehow sinks into the orange one.
    Files

    Post by Deirdre ().

    This post was deleted by the author themselves ().
  • Deirdre wrote:


    • This is no bug. With the grid you have more accuracy.

    I don't see how this could be intentional. Snapping two equal planks implies that they'll be aligned perfectly, yet there's always this 0.0025 block misalignment. Why would the size command be as low as 0.0100 if the positioning accuracy only goes down to 0.0125? Why would this mysterious inaccuracy not show in the transparent preview plank, but show in the placed plank? And most tellingly: why can you compensate for it with the keyboard by just moving it 0.0025 blocks (i.e. "setp 1")?
    Put simply, the positioning shown in the transparent preview isn't being used. It's always misaligned by 0.0025 in at least one axis.
    As for the grid, it isn't useful here because its minimum size is way too large (0.0625).
  • Well, unfortunately this comes from some precision issues. The x, y and z coordinates of construction elements are stored as 16 bit ints (i.e. 2 bytes per component), primarily to keep the memory consumption per construction element as low as possible. We will get rid of this artificial restriction in the new version, so this should greatly improve the precision when working with very small construction elements ;)

    Unfortunately I'm not sure if we can fix this issue in the current version... the only real solution is to store the coordinates as 32 bit values, but that would require a world conversion :(

    philtwice wrote:

    Why would the size command be as low as 0.0100 if the positioning accuracy only goes down to 0.0125?
    Originally the minimum value for the setp, setr and setl command was 1, but many people asked for smaller values back then. Actually the 0.01 value can be useful sometimes, as the precision issue really depends on various factors (e.g. your world position).
    But I understand that this misalignment can be pretty annoying when it occurs...

    philtwice wrote:

    Why would this mysterious inaccuracy not show in the transparent preview plank, but show in the placed plank?
    The preview element uses 32 bit values for its position. When placing the element, it's converted to a 16 bit value (with taking the actual chunk offset into account), that's why there is this difference between the preview and the placed element :/