1 minute ago, Mike2343 said:

camera system

What is the camera system? Just a culler (+ setting some shader buffers)?

1 minute ago, matt77hias said:

What is the camera system? Just a culler (+ setting some shader buffers)?

Much like I showed in my example code but it only returns a hash of it's name as reference; each camera also has to have a name which just makes it easier to search for hash("main camera").  The culling system is also a friend of the camera class, so it can do plane vs sphere then plane vs OBB/AABB culling tests.  I'm using OpenGL currently and yes the camera class just sets a uniform buffer which the renderer passes on to the shader.  The camera class is more or less a dumb class, just holding data and builds basic transforms glm::mat4 Projection() const; type stuff.

5 minutes ago, Mike2343 said:

The culling system is also a friend of the camera class, so it can do plane vs sphere then plane vs OBB/AABB culling tests.  I'm using OpenGL currently and yes the camera class just sets a uniform buffer which the renderer passes on to the shader.  The camera class is more or less a dumb class, just holding data and builds basic transforms glm::mat4 Projection() const; type stuff.

You always mention the camera class has certain functionality. But the camera system class instructs to perform this functionality, right?

1 minute ago, matt77hias said:

You always mention the camera class has certain functionality. But the camera system class instructs to perform this functionality, right?

class CameraSystem
{
	struct LenseData
	{
		uint64_t m_LenseID;
		// for PBR cameras
	};
	struct CameraData
	{
		uint64_t m_CameraID;  // hashed name provided to CreateCamera()
		LenseData *m_Lense = nullptr;
		// ... all the data for any type of camera kept here, near/far plane, viewport info (height/width), aspect ratio, etc.
	};
public:
	// ... 

	uint64_t CreateCamera( const std::string camera_name, const glm::vec3& position, ... );
	
	uint64_t CreateLense( const std::string lense_name, ... );
	void	AttachLense( const uint64_t& camera, const uint64_t& lense );
	
	void	Position( const uint64_t& camera, const glm::vec3& new_position );
	glm::vec3 Position( const uint64_t& camera ) const;

	// A lot more getters and setters...

private:
	friend Renderer;
	friend CullingSystem;

	glm::mat4 ProjectionMatrix( const uint64_t& camera ) const;
	glm::mat4 OrthoMatrix( const uint64_t& camera ) const;

	std::vector<CameraData*> m_Cameras;
    std::vector<LenseData*> m_Lenses;
};

As you can see, it's a bit of a mess right now, I just kept adding functionality to it.  Forgot to add in the BuildBuffer() function that is in the private section for the renderer too.  It builds the UniformBufferObject (OpenGL backend) that gets uploaded to any shader requiring camera data.  Right now the renderer actually buffers the "main camera" data as most things need it, instead of calling into this function each time.  Only if the shader or rendering requires a different camera for say shadow maps does it then come back to this class and gets that specific cameras buffers and transforms, etc.

12 hours ago, Mike2343 said:

Only if the shader or rendering requires a different camera for say shadow maps does it then come back to this class and gets that specific cameras buffers and transforms, etc.

For shadow maps, I used to return a Camera from the Light, but now I just return the view-to-projection matrix since this will probably the only thing that you need. The benefit of not reusing a general Camera for your Lights, is that you can increase the numerical precision of your view-to-projection matrices. For an omni light, you do not need any trigonometric functions and you can represent some entries exactly as a float for example.

9 hours ago, matt77hias said:

For shadow maps, I used to return a Camera from the Light, but now I just return the view-to-projection matrix since this will probably the only thing that you need. The benefit of not reusing a general Camera for your Lights, is that you can increase the numerical precision of your view-to-projection matrices. For an omni light, you do not need any trigonometric functions and you can represent some entries exactly as a float for example.

That's pretty darn smart.  I'll give it a try, thanks