Signed-off-by: Tobias Frisch <tfrisch@uni-koblenz.de>

Signed-off-by: Tobias Frisch <tfrisch@uni-koblenz.de>

Signed-off-by: Tobias Frisch <tfrisch@uni-koblenz.de>

Signed-off-by: Tobias Frisch <tfrisch@uni-koblenz.de>

Resolve "Kamera - Trackballkamera"

Closes #42

See merge request !35

Signed-off-by: Tobias Frisch <tfrisch@uni-koblenz.de>

Signed-off-by: Tobias Frisch <tfrisch@uni-koblenz.de>

Merge branch '42-kamera-trackballkamera' of gitlab.uni-koblenz.de:vulkan2021/vkcv-framework into 42-kamera-trackballkamera

[#42] Simplified update methods, replaced clones to references, added namespace, corrected applications

Signed-off-by: Tobias Frisch <tfrisch@uni-koblenz.de>

Before:
If more than one trackball camera controller is added to your application, changing the m_radius variable via scroll event would lead to adjusting the radius for all cameras attached to the trackball camera controller.

After:
Before updating the radius, the m_radius variable is changed in respect to the current distance from the camera to its center point. This enables handling all cameras with attached trackball camera controller separately.

Per default: index = 0 is the active camera. The user should determine himself via setActiveCamera which camera should be active

deletion of controllers and cameras no longer needed
move window manipulation from controller to manager
move calculation of lastx and lasty from controller to manager
remove methods concering handling of cameraController vector
add methods concerning management of camera vector

cameras + controllertypeenums in vector
remove cameraController vector
remove activeControllerIndex
remove methods regarding cameraController objects
add methods regarding camera objects

Resolve "Refactor(?) VertexLayout"

Closes #75

See merge request !61

Merge branch '75-refactor-vertexlayout' of gitlab.uni-koblenz.de:vulkan2021/vkcv-framework into 75-refactor-vertexlayout

Signed-off-by: Tobias Frisch <tfrisch@uni-koblenz.de>

Remove offset calculation in shader reflection. Proper offsets are now calculated on vertex binding creation.

Signed-off-by: Tobias Frisch <tfrisch@uni-koblenz.de>

Signed-off-by: Tobias Frisch <tfrisch@uni-koblenz.de>

Merge branch 'develop' into 42-kamera-trackballkamera and update all main.cpp so that they can work with the current camera objects

# Conflicts:
#	modules/camera/include/vkcv/camera/Camera.hpp
#	modules/camera/include/vkcv/camera/CameraManager.hpp
#	modules/camera/src/vkcv/camera/Camera.cpp
#	modules/camera/src/vkcv/camera/CameraManager.cpp
#	projects/first_mesh/src/main.cpp
#	projects/first_triangle/src/main.cpp

1) Now there is only one camera class (no inheritance anymore). Furthermore, the camera object is separated from camera controls and only manages camera specific information, such as the view matrix, projection matrix, the position, etc. Camera controls are now handled via camera controller objects.

2) The CameraManager now manages an arbitrary number of camera controllers, such as PilotCameraController or TrackballCameraController (TraceCameraController will be implemented soon!). Before you can use a camera object in your render loop, you need to add at least one camera. You do not have to use a camera controller to render something, but you need to implement camera movements yourself... If you want to CONTROL a camera object, you can make use of the existing camera controller objects. To create a controller, you need to add a camera controller object to the camera manager and specify which camera should be used for this controller. You can change the bound camera whenever you like to. To switch between all existing camera controllers, you can use the active controller in the render loop and change the cycle between all camera controllers via Tab.
See the example projects for an examplary application.

3) Currently, events are only handled for the active camera controller.

4) DISCUSSION: We use the 'new' keyword within the camera manager class. Unfortunately, we did not find any other way to create an object (such as the camera controller) inside the scope of one function and make use of the inheritance (only pointers seem to support this) or to refer to an object that updates everywhere where it is refered. To not lose the object at specified memory location, we need to create it via 'new' and ensure that all allocated objects are deleted within the destructor of the camera manager. Find this lines at the 'TODO' marked locations. If you have a better idea to solve this problem, please let us know. :)