16 minutes ago, ryt said:

but what made the initial system from start right-handed

It determined by what direction of Z axis we has select to build a system. Let begin from begining. Operation of cross-production build a vector that perpendicular for both of source vectors. But it possible 2 opposite directed vectors that lie on same straight line and have same length.  Wich same of its vectors we selected as positive determine a handness of the system we use.  But for different purposes we may select different directions. Hardware uses RH system. So to make result of calculation in LH system compatible with harware, libraries have a LH set of matrix building functions for base operations, that constracted as mirrorded RH matrices, to perform a conversion to RH system used by hardware by the way. Also any mirror transformation invert handness of coordinate system.

This is mostly just a decision initially taken when a Library is created. Which could also be because the lib is initially used with dx or OpenGL (which have different handedness). In the end there’s no right or wrong; most important is to stick with one throughout everything you do.

1 hour ago, ryt said:

Ok, this is if I started initially with a right-hand coordinates, but what made the initial system from start right-handed?

The initial system as you call it is the normalized device coordinates (NDC). It is left handed with z going into the screen.

Every tutorial you have ever seen with right hand coordinates use a projection matrix that inverts the z using a scaling of -1. When you use a library like GLM to 'magically' create your projection matrix you don't even know this is happening.

All the tutorials on the web that have you draw a triangle using x,y,z coordinates less than 1 and no matrices are in fact drawing directly into NDC space and thus every beginner tutorial for OpenGL is using left handed coordinates.

1 hour ago, ryt said:

You mentioned fixed part of pipeline, what about non-fixed,

Programmed pipeline part have to convert handness of system that used for calculations, to handness of system used by hardware fixed part for rasterizing. It conversion usually done just by mirrored projection matrix.

1 hour ago, ryt said:

but what made the initial system from start right-handed?

Better say it initially have same handness that graphic API you use. Really you can not see about any differences on calculations until draw a results. Only difference is a rotations direction. By other words if you mean that you perfom a calculations in left-hand system without conversion results to right-hand system you will see on screen mirrored image and opposite rotations for API that use RH system and viseversa for mentioned RH system and API that use LH.  Also inverting handness of system inverts sign of volume integrations. It why CADs usually using LH system instead of much comfortable for visualisation RH system that usually used in CG.  

3 hours ago, cozzie said:

This is mostly just a decision initially taken when a Library is created.

How do you decide this when creating a new library?

4 hours ago, fleabay said:

The initial system as you call it is the normalized device coordinates (NDC). It is left handed with z going into the screen.

Every tutorial you have ever seen with right hand coordinates use a projection matrix that inverts the z using a scaling of -1. When you use a library like GLM to 'magically' create your projection matrix you don't even know this is happening.

All the tutorials on the web that have you draw a triangle using x,y,z coordinates less than 1 and no matrices are in fact drawing directly into NDC space and thus every beginner tutorial for OpenGL is using left handed coordinates.

I read now about NDC and I think it's not what I'm asking. As I understood NDC is when you start to use rasterizer to present the world to the screen.

In my case I don't need to present anything to the screen or calculate projection matrices or something similar, I just need a world (space) that behaves according to the left-hand rule. So that for e.g. if you want a ship to move in positive z-axis and if your x-axis is pointing away from you, y-axis pointing up then the ship should move to the left. If a ship would move right than it would be a right-hand system.
That was also my initial intention, to have it move to the left side and create such system.

What I think it is, though I might have it wrong, is that libraries have a predefined basis vectors pointing in desired direction, left-hand or right-hand. If that would be true than all it's functions should use these basis vectors inside functions like cross() and others, which seems not likely possible to me.

1 hour ago, ryt said:

is that libraries have a predefined basis vectors pointing in desired direction,

Really it use a - cross only to cunstract matrices where it is significant. It a LookAt and projection matrices only.Just it require to understend from where needs of different handness come. Imagine a front view of any vhechicle for example. How to place axes for it view? Intuitive direction is x "to right" and y "upward", becouse it habitually since  secondary or ever primary school. But how to be with z axe to add a 3D?  It is cross production of x and y but what it direction more comfortable? To find it direction we have to look on side or top view. It intuitively comfortable when it have positive direction to front of vhechicle. On front view it direction "to us". So for model space it is comfortable a left-hand system. But what comfortable for camera space?  x "to right" and y "upward" again most comfortable directions. But how to be with direction of z? On camera z is intuitively distanse to object, so comfortable direction is "away", so it right-hand system . But if we will draw model built in left-hand model space to rigth-hand camera space we will see a back insteand of front view due to opposite direction of z axes on model and camera spaces. So we have to convert view to camera space inverting a z axe, that same as mirror it respectively to screen plane. So it is only significant to perform conversion only on world space to camera space conversion stage. Also we have a world space where we navigate a models and camera. For left-hand models it require a left world space. so right-hand camera navigated in left space will have opposite rotation direction (i mean world rotation that LookAt actually perform to match a world z axis with camera z axis, not a navigation of camera that performed as usual object navigation in same system that other world objects). So LookAtLH  just a same as LookAtRH but for opposite direction.  Becouse it conversion accumulated in matrice it cost zero.

Really on practicle used two methods of solwing it issue with different direction of axe.

One of it is a using left-hand system for all positions and other game mechanics calculations and convert only on related to camera tasks to perform conversion on view stage, and it primary solution for CADs and other modelling tools. Other method is to convert models to right-hand system by inverting x axe on exporting from modelling tool stage, use RH world and do not care about what system use for each operation becouse anything in RH, that often used in games.  It why libraries have 2 set of matrices constraction functions related to camera. RH set perfom no system conversion and LH set mirror/inverse camera rotations  to make RH from LH.

1 hour ago, ryt said:

In my case I don't need to present anything to the screen or calculate projection matrices or something similar, I just need a world (space) that behaves according to the left-hand rule.

These 2 replies are all you need then, what more is there to understand?

On 9/28/2018 at 10:58 AM, alvaro said:

What makes the system left-handed is your interpretation of what the x, y, and z coordinates mean when you visualize the vectors. The arithmetic is independent of handedness, so there is nothing in the library that depends on it.

23 hours ago, fleabay said:

Lets say we have 3 Axis. The first axis can point any direction. Let's say it points right. Now for our second axis, it needs to be perpendicular (90%) to the first for our Cartesian system. For convenience let's say it points up but there is a whole range around the x axis it could point. Now the third axis can point in only one of 2 directions to maintain the 3D Cartesian grid. Toward us or away from us. These 2 possibilities had to be called something. Someone noticed you could use your left and right hand to differentiate between the 2 and thus they were named as such.