Block.getDirection()

[Josharias]

@Marcin Sciesinski and @Immortius, you guys had a discussion about Block.getDirection() on IRC. Since both of you are offline, this is the next best communication mechanism.

It sounded like you two were pointing out that Block.getDirection() does not fully describe the different rotations that a block can be placed. I agree. However, I would not say it is bad in its present form. The block family gives the direction property a value which can be used later on. Granted, it is not the complete set of rotation, but it is a good start as it covers the horizontal story well (it is just limited to being always upright).

Marcin, I think I am using it correctly in Machines where the SurfacePlacementFamily gives a direction for each block. Do you figure this is using it wrongly?

 

[Cervator]

Is this related at all? https://github.com/MovingBlocks/Terasology/pull/1735

 

[Immortius]

@Cervator no, not really.

Looking at the direction attribute, it isn't well defined what it means. I thought it would be the side that was the front, after rotation is applied, but for many blocks it is actually the top (?). Having rotation (as in the transformation done to the block by the family factory) as an attribute may make more sense, but it will be very family dependent. We need to come up with a defined meaning for whatever attribute we want in this space, to at least tide us over until a potential larger scoped rework of blocks down the track.

On BlockFamilyFactories, these are getting a bit of a shake up in the gestalt-asset integration. BlockFamilyDefinitions are now proper assets, and block family definition "sections" (e.g. all, topbottom, sides, left, right, etc) are better handled. BlockFamilyFactory no longer gets access to the json, not manipulates block family data during load - but plays a stronger role in creating the actual blocks.

 

[prestidigitator]

Just an idea, (disclaimer: I'm coming at this as a complete newbie in terms of the engine and code base), but axis-aligned node orientations might be represented well as an enum of basis vectors, with methods that can convert to and from other formats (quaternions, Euler angle triples, non-aligned vector bases, etc.), conveniently transform between each other, etc. For example:

• OBJX_WORLDPOSX_OBJY_WORLDPOSY - Object's x-axis along world's x-axis and object's y-axis along world's y-axis. This is equivalent to no rotation at all (identity transformation).
• OBJX_WORLDNEGX_OBJY_WORLDNEGY - Object's x-axis opposite world's x-axis and object's y-axis opposite world's y-axis. This is equivalent to a 180-degree rotation around the z-axis.
• OBJX_WORLDNEGX_OBJY_WORLDPOSY - Object's x-axis opposite world's x-axis and object's y-axis along world's y-axis. This is equivalent to a 180-degree rotation around the y-axis.
• OBJX_WORLDPOSY_OBJY_WORLDPOSZ - Object's x-axis along world's y-axis, and object's y-axis along world's z-axis. This rotates around an axis equidistant from each primary axis, shifting x to y, y to z, and z back to x.
• ...

Possible enum methods:

• static AlignedOrientation fromRollPitchYaw(Roll roll, Pitch pitch, Yaw yaw)
• static AlignedOrientation fromUnalignedVectorBasis(Vector3f objectXDir, Vector3f objectYDir)
• static AlignedOrientation fromUnalignedRotation(Quat4f rot)
• Quat4f toQuat4f()
• AlignedOrientation rotatedAroundWorldY(int increments)
• ...

 

[Immortius]

We have a class called Rotation that deals with axis-aligned rotations - you "create" an instance (doesn't actually create a new instance each time, reuses them) by providing a combination of Yaw, Pitch and Roll rotations where each is an enum with the four possible axis rotations.

 

[prestidigitator]

Yeah. I saw that much at least before making the suggestion. It's why I gave the static AlignedOrientation fromRollPitchYaw(Roll roll, Pitch pitch, Yaw yaw) method signature as an example. This would just be a way to clearly and canonically delimit all 24 possible unique orientations.