Design Refactor Camera to be Component based

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Moved to the Suggestions forum as a Design thread :)

Hopefully we can eventually move this again into the Core/Engine type forum as a design, doc, and discussion thread for anything Camera related!
 

zeokav

New Member
Contributor
Alright @Cervator . I was wondering - we get approximately 400ish hours for SoC. I might be undermining this task (need input from @manu3d on this), but making the camera a component and refactoring wherever required might not take as much time, right? So if I were to pick this topic up, what exactly do I focus on to fill the summer?
For instance, I have a leap controller lying around and I'm sure implementing that will take quite some time. If I were to write a proposal for this particular topic, what else am I supposed to include (of course, given that I'm not actually undermining this task).

Thanks!
 

manu3d

Active Member
Contributor
Architecture
Converting cameras to component is tricky because of a) the math involved b) the many places cameras are currently hardcoded in. Untangling everything is going to be a time-consuming task and you'd have to dig pretty deep in the ES way of doing things, not to mention you'd have to navigate the PR traffic - other PRs will affect the same area of the codebase you are modifying and you'll need to coordinate with other developers or adapt to their actions. So, I wouldn't underestimate the time it would take to deal with this task.

That been said, I understand your concern. Remember that these tasks are provided as guidance/suggestions. So, if you feel like this task is too short, you might want to pair it with something else or simply expand it. For example on top of converting cameras to components with the aim of having a single, component-based, active camera, you could go the whole way and work with me on the DAG pipelines to allow for multiple cameras rendering at the same time. I'd be surprised if this doesn't fill the whole summer.
 
Last edited:

zeokav

New Member
Contributor
@manu3d The thing is - I might feel that it's short, but it might not be. Since I'd only be approximating right now, what happens if I mention some things on my proposal, but I can't get through with all of it?
Also, would you suggest me to make more PRs to the repo - not related to this topic - (I've had 3 merged, I think) or to dig deeper and find out more about how I'd be implementing Cameras?
 

manu3d

Active Member
Contributor
Architecture
(...) what happens if I mention some things on my proposal, but I can't get through with all of it?
GSOC organizations tend to reward efforts more than results. So, if you put in a strong effort for three months but the results are somewhat short of the original goals, that won't be a problem. One strategy is to organize the proposal with a main section containing a number of must-have goals and then add some secondary sections with "bonus goals" and "nice-to-have" things that can be implemented if the time left allows it.

Ultimately estimating how much time something will require is part of the learning experience and is on the path to professionalism: you make an estimate at the beginning of the project (I can do a,b,c in the 3 months of the GSOC) and then you verify how close your estimate was when the project is finished. For a number of times you'll probably get the estimates wildly wrong. But over time it is a skill that will improve.

Also, would you suggest me to make more PRs to the repo - not related to this topic - (I've had 3 merged, I think) or to dig deeper and find out more about how I'd be implementing Cameras?
It's a bit of a balancing act really. PRs make you visible within the community and this certainly helps. On the other hand, you need to have -some- knowledge of the code you'd be working on during the GSOC, to be -reasonably- confident you can achieve at least most goals in your proposal. So, ideally you'd do PRs that allow you to at least explore the parts of the codebase that will be relevant for your project proposal.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Manu speaks the truth, go for a "safe" base proposal and include some extras you can approach if able :)

I wouldn't consider the Leap as a potential part of this or really any other ideal GSOC proposal. It is a really peripheral topic (heee) and depends on a lot of other stuff like IndianaJohn's VR and motion controller magic, so that area of code will likely be "hot" with activity and dependencies. Plus it has its own hardware sharply limiting who can participate, and its own SDK to make bridges/middleware for. It is a doable item but I would call a base implementation alone a "safe" proposal but one that would be tricky to really impress us with vs far more applicable ideas for this summer.

As for non-GSOC PRs and other work yes please! And ideally in related areas. @Rostyslav Zatserkovnyi for instance did a pile of work on NUI topics before GSOC student apps were even due, which was a huge reason why his NUI editor proposal got picked. Also as part of early digging like that we found out that keeping it an in-game editor instead of an external tool was far more doable and applicable, despite the idea calling for an entirely external tool.
 

zeokav

New Member
Contributor
Got it! Thanks for the inputs! :)
I went through the related issues and forum links specified in issue #2797 (The original issue), and it does look like it has been a feature that's been long due. :eek:

Anyway, I'm going to try understanding #1126 since it touches both Cameras and the Input System - might be a good entry point to the Camera side of the code.
Also, #1272 seems like a follow up to the whole problem. Once we have an independent camera to work with, I'm pretty sure it'd be comparatively easier to figure out. The same goes for the cinematic game mode that skaldarnar proposed.
 

manu3d

Active Member
Contributor
Architecture
#1126 is indeed something that might be useful to get your hands dirty.

But I don't feel it's worth pursuing #1272 before cameras are turned into components. I mean, what's a third person view camera? It's a camera that orbits around the player. We already have the functionality for entities orbiting other entities, i.e. the player. What we don't have are entities including camera components, so that we can simply pass an entity with a CameraComponent to the WorldRenderer and it becomes the active camera.
 

Skaldarnar

Development Lead
Contributor
Art
World
SpecOps
#1272 and other ideas, like camera path for automatic camera movements, sound like good stretch goals to me. If making cameras components turns out to be easily completable you still have some sensible task to further work on.
 

zeokav

New Member
Contributor
@Skaldarnar Yep, I am adding a few extra goals to the proposal in case it turns out to be easily solvable! I have quite a few ideas in mind. Even if I can't pull some of them off (in case refactoring takes more time than anticipated), they can be implemented later because they are good extensions. Here are a few things I have in mind -
  • The first application is going to be the implementation of a switchable camera that can switch between first person and third person views readily. This is going to be my first real application after refactoring simply because it indicates success. The rest require more work and are possibly going to just be derived from something like this.
  • Something on the lines of what NVidia is doing with Ansel - take 360 degree shots of the environment. While this is ambitious and can be a project in itself, it's an idea that can be implemented later if not now with the help of a detachable camera. A smaller version of this concept can be implemented - something like a screenshot instead a complete 360 degree shot, which can be taken with the help of the said detachable camera.
  • An extension of that could be a cinematic camera say when the player is idle or something of that sort. A detached camera that follows a set path and is not controlled by the player himself.
  • CCTVs - This was the actual reason I started looking at this whole topic. Having CCTVs (or just multiple cameras, in general) would be cool. However, this comes in later since it also requires a method to stream the rendered result and produce it on a block. @Cervator suggested looking at a module that implements a programmable terminal on the screen - yet to go through it. Might involve a few other areas of code.
  • Drones - Another version of the free flying camera. The player may use control drones to fly around places.
Quite a few other things can be implemented if we have a component based camera to be honest. Any object to which a camera can be attached is basically another feature that could be implemented and further worked on.

Like @manu3d had suggested - there are some other things that can be done like moving matrix computations to shaders. I am keeping this thing at a slightly lower priority level since I am not well versed with GLSL (at all, sadly). It will take some time to understand and get the concepts through. By then, I could focus on other things like the ones I have listed above.

This is the plan as of now. I am cooking my proposal up. Should finish the first draft by tomorrow, at worst. Let me know if anyone has any other ideas in mind that could be implemented. :D
 

manu3d

Active Member
Contributor
Architecture
Generally speaking I like the direction you are going toward. I'd say the 360 degree shot is very low priority at this stage. I'd much prefer you helped moving matrix computations in the shaders as a stretch goal. But for everything else I certainly like the vision and how you have generated a number of potential creative usages out of the purely architectural/integration work of turning cameras into components: well done.
 
Top