Kein Thema. Gern geschehen :)

Er hat hier doch jeden Tag aufs Neue den Spaß seines Lebens. Und wie sieht dein Leben aus?

Danke für die Erklärung! Mein Vote hast du! Immer wieder schön, dass man hier auch richtig was lernen kann!

Wieso "Scheiß"? Ist doch alles recht leicht verständlich.

7. Nochmal in eine Textur rendern: Diesmal allerdings nicht aus der virtuellen Perspektive des Spielecharakters, sondern aus der Perspektive des Beamers (natürlich auch nur virtuell -- wir bleiben im Weltkoordiantensystem des Videospiels, können die Beamerposition aber durch die vorherige Kalibrierung im virtuellen Raum abbilden). Der Trick hierbei ist, dass wir die Textur aus dem vorigen Renderpass jetzt per Projection Texture Mapping auf das Modell des Raumes/der Wand projizieren (ist die Tiefenvarianz der Wand zu hoch, wäre Projective Texture Mapping vielleicht angebrachter). Die bisherige Kameraposition ist dabei der Projektionsursprung des Mappings. Außerdem muss der virtuelle TV im Modell dabei koplanar mit der Projektionsebene des ersten Renderpasses sein. Das sind aber nur ein paar Koordinatentransformationen -- wir wissen ja alle Abstände etc. durch die Kalibrierung.
8. Da wir aus der (virtuellen) Perspektive des Beamers gerendert haben, wissen wir genau was der (reale) Beamer projizieren muss, damit das projizierte Bild so aussieht, als wäre es die Fortsetzung des TV-Bildes aus der Perspektive der_des Spielerin_s. Der Perspektivwechsel ist wichtig, sonst sieht um den TV alles verzerrt aus. Die Textur aus Schritt 7 dann halt noch vom zweiten Monitorausgang (Beamer) darstellen lassen und fertig!

Falls es jemand noch vor Microsoft schaffen will (das Problem ist aber ohnehin eher die nötige Hardware und nicht der Problemlösungsalgorithmus):
1. Raum bzw. die Raumseite des TVs rekonstruieren (Stichworte: 3D reconstruction, structure from motion): zB mit Tiefenkameras (zB Kinect Fusion), mit einem Multi-Kamera-Setup, mit einem monokularem Natural Feature Tracking and Mapping System (zB PTAM oder MonoSLAM), oder halt einfach per Hand mit Lineal, Modelling-Software und viel Zeit.
2. Falls du es nicht per Hand gemacht hast: Punktewolke der Rekonstruktion triangulieren, um ein Modell aus Polygonen zu erhalten.
3. Beamer auf TV-Mittelpunkt kalibrieren (dh den Vektor zwischen Projektorlinse und TV, samt dessen Länge bestimmen). Dadurch erfährt unsere Software auch gleich wo im Raum genau der TV ist.
4. Das fertige Modell des Zimmerteils im Videospiel laden. 5. In der Renderloop des Videospiels die aktuelle Szene einmal normal für den TV rendern.
6. Szene ein zweites Mal rendern, aber diesmal mit einem wesentlich größerem View Frustum (um über den TV-Bereich "hinausschauen" zu können) und größerem Viewport (sonst wirds pixelig). Der Teil, den der TV einimmt, sollte man dabei ausmaskieren. Gerendert wird nicht in den Framebuffer, sondern eine Textur, die wir im nächsten Renderpass wiederverwenden.

7. Nochmal in eine Textur rendern: Diesmal allerdings nicht aus der virtuellen Perspektive des Spielecharakters, sondern aus der Perspektive des Beamers (natürlich auch nur virtuell -- wir bleiben im Weltkoordiantensystem des Videospiels, können die Beamerposition aber durch die vorherige Kalibrierung im virtuellen Raum abbilden). Der Trick hierbei ist, dass wir die Textur aus dem vorigen Renderpass jetzt per Projection Texture Mapping auf das Modell des Raumes/der Wand projizieren (ist die Tiefenvarianz der Wand zu hoch, wäre Projective Texture Mapping vielleicht angebrachter). Die bisherige Kameraposition ist dabei der Projektionsursprung des Mappings. Außerdem muss der virtuelle TV im Modell dabei koplanar mit der Projektionsebene des ersten Renderpasses sein. Das sind aber nur ein paar Koordinatentransformationen -- wir wissen ja alle Abstände etc. durch die Kalibrierung.
8. Da wir aus der (virtuellen) Perspektive des Beamers gerendert haben, wissen wir genau was der (reale) Beamer projizieren muss, damit das projizierte Bild so aussieht, als wäre es die Fortsetzung des TV-Bildes aus der Perspektive der_des Spielerin_s. Der Perspektivwechsel ist wichtig, sonst sieht um den TV alles verzerrt aus. Die Textur aus Schritt 7 dann halt noch vom zweiten Monitorausgang (Beamer) darstellen lassen und fertig biste.

Hier noch die Lösung des Problems:
1. Raum bzw. die Raumseite des TVs rekonstruieren (Stichworte: 3D reconstruction, structure from motion): zB mit Tiefenkameras (zB Kinect Fusion), mit einem Multi-Kamera-Setup, mit einem monokularem Natural Feature Tracking and Mapping System (zB PTAM oder MonoSLAM), oder halt einfach per Hand mit Lineal, Modelling-Software und viel Zeit.
2. Falls du es nicht per Hand gemacht hast: Punktewolke der Rekonstruktion triangulieren, um ein Modell aus Polygonen zu erhalten.
3. Beamer auf TV-Mittelpunkt kalibrieren (dh den Vektor zwischen Projektorlinse und TV, samt dessen Länge bestimmen). Dadurch erfährt unsere Software auch gleich wo im Raum genau der TV ist.
4. Das fertige Modell des Zimmerteils im Videospiel laden. 5. In der Renderloop des Videospiels die aktuelle Szene einmal normal für den TV rendern.
6. Szene ein zweites Mal rendern, aber diesmal mit einem wesentlich größerem View Frustum (um über den TV-Bereich "hinausschauen" zu können) und größerem Viewport (sonst wirds pixelig). Der Teil, den der TV einimmt, sollte man dabei ausmaskieren. Gerendert wird nicht in den Framebuffer, sondern eine Textur, die wir im nächsten Renderpass wiederverwenden.

Du laberst ziemlichen Müll. Design Patterns und Clean Code Practice dienen lediglich der Maintainability von Software. Die werden dir bei der Lösung des im Video gezeigten Problems keine Hilfe sein. Nur bei der Wartung und Erweiterung deines Endprodukts. Und was du auf ner Spielekonsole mit SQL und SOA willst, ist wahrscheinlich jedem, der etwas Ahnung in dem Bereich hat, völlig schleierhaft. Physik würde sich auch als ziemlich nutzlos erweisen. Übrigens nennt jeder, der mehr als Abiturwissen über lineare Algebra hat, den ganzen Spaß sicher nicht "Vektorrechnung".
P.S.: Ich hasse die Programmierer, die ständig mit dem Programmiersprachen-Name-Dropping-Spiel anfangen müssen, um vorzugaukeln, dass sie Ahnung haben. Welche Sprache zur Problemlösung verwendet wird, ist im Prinzip eh irrelevant. Mit nimmt einfach die zum Problem-Modell am besten passendeste oder schreibt sich eine passendere, domänen-spezifische Sprache.

Vom Abschluss her gesehen bin ich ein einfacher Diplominformatiker. Studiert hab ich aber Computervisualsitik. Reicht auf jeden Fall aus, um das machen zu können. Die Herausforderung liegt hier nicht in der rein technischen Umsetzung, sondern darin, es so umzusetzen, dass es günstig und praktisch genug für Heimanwender ist.