Hallo Zusammen Ich habe einige aktive 3D Brillen herum liegen, und würde gerne meinen Bildschirm (LC-M44-DFHD-120) modden, um dem 3D Unterstützung hinzuzufügen. Die 3D Technologie ist ja nicht kompliziert, und geht auch noch wenn nicht alles perfekt synchronisiert ist. Vor Jahren hatte ich mal einfach eine 3D Brille mit 30Hz umschalten lassen, und ein bei jeder Frame wechselndes Video auf meinem IPad laufen lassen, und das hat sogar funktioniert (nur das Bild hat sich manchmal rein / raus gekehrt, weil halt nicht ganz synchron, und sich manchmal änderte welches Auge welches Bild bekommen hatte). Die Softwareseite ist kein Problem, die bekomme ich in den Griff. Das Hauptproblem ist das Synchronisieren des Umschalten. Bei VGA wäre es ja trivial, herauszufinden, wann ein neues Bild kommt, und wann es zu Ende ist. Da gibt es ja ein VSync / VBlank Signal. Aber bei der Auflösung 3840x1080 kann ich VGA ja gleich vergessen. Der Monitor kann DisplayPort und HDMI, aber die haben ja digitale, vermutlich sogar verschlüsselte Signale, da geht das nicht so einfach. Gibt es da irgend eine Möglichkeit, da an so ein Signal heranzukommen? Alternativ, könnte ich so ein Signal irgend wie im Bildschirm selbst / vom Panel abgreifen? Und weiss zufällig jemand, wie man den auf macht, ohne ihn kaputt zu machen? Ich sehe von aussen natürlich mal wieder keine Schrauben...
:
Verschoben durch Moderator
https://www.vsynctester.com/howtocomputevsync.html https://www.vsynctester.com/ https://www.displayhz.com/ Also gehen tut das. Nach trivial schaut es eher nicht aus.
@nixiefan Danke für die Links. Das ist leider aber nicht, was ich brauche. Wie schon gesagt, die Software Seite ist kein Problem. Da Bild selbst werde ich dann entweder in Mesa oder im Kerneiltreiber umschalten lassen. Da kann ich dann auch richtiges Quadbuffering für Anwendungen implementieren (im Kernel wird in der Regel im Treiber ein Buffer ausgewählt, und dann per DMA ausgegeben), und ich kann schauen dass bei frame skips immer beide Frames geskippt werden, dass alles synchron bleibt. Das ist alles kein Problem. Was du verlinkt hast ist etwas um SW VSync Timings im Browser herauszufinden mit JS, aber das ist aus mehreren gründen für mich nicht relevant: 1) Ich brauche das dort gar nicht. Ich mache dann eh quad buffering, das immer rechtes linkes Bild abwechselt ist damit garantiert, und die Anwendung weiss dann jeweils auch, welches Bild es ist. 2) In JS reichen bei jedem requestAnimationFrame ein oder 2 Frames zu zeichnen, synchronisieren muss man dort noch gar nichts. Der Browser, der Compositor, und Mesa selbst, könnten mit double buffering auch eh schon sicherstellen, dass es zu keinem tearing usw. kommt. Zusätzlich gibt es für den Browser sowieso WebVR, wenn man Stereo 3D im Web machen will, nimmt man einfach das. Das tatsächliche HW VSync ist dort noch gar nicht wirklich relevant. 3) Alle Zeitfunktionen, Inklusive performance.now(), in JS, werden künstlich ungenauer gemacht, um Fingerprinting zu verhindern. Das ist also definitiv kein guter Ort, um solche Sachen zu versuchen herauszufinden. Programme machen solche Sachen wie oben manchmal, um abzuschätzen, wann die nächste Frame tatsächlich angezeigt wird, um lag minimal und konsistent zu halten, und damit auch jitter zu reduzieren. (Die Zeit ist relevant für wie weit ein Objekt in einer Frame bewegt werden muss, usw.) 4) Ich habe gar nicht vor, JS zu verwenden. Ich habe vor, einfach bestehende Anwendungen, und eigene mit normalen OpenGL Quad buffering zu nehmen. Aber eben, der Teil der Bildumstellung könnt ihr als gelöst betrachten. Was ich brauche, ist wie schon gesagt, ein Signal zum timen des Umschalten der Brille. Ok, das könnte ich auch versuchen, beim Commit des nächsten Frames im Kernel zu machen, und vermutlich würde das auch gehen. Aber dort gibt es doch einige Variablen, die mir Probleme machen könnten. Der ganze Weg, durch die Grafikkarte, die Adapter und Kabel bis zum Bildschirm, und dann zur Anzeige selbst, es würde mich doch überraschen, wenn das delay dort immer exakt das selbe wäre. Vermutlich müsste ich das also bei jedem Anschliessen des Bildschirms immer wieder neu justieren. Daher wollte ich das eigentlich möglichst nahe beim eigentlichen Signal und möglichst nahe am Bildschirm machen. Und @mods, deshalb hatte ich den Thread auch nicht unter dem "PC Hard- und Software" Forum eingestellt, weil das dann wirklich nicht mehr viel damit zu tun hat. Wobei, ich könnte trotzdem mal versuchen, das umstellen der Brille auf der PC Seite zu machen, beim Commit des neun Frames. Vielleicht geht es ja besser, als ich erwarten würde.
Am einfachsten wäre wohl an einem Ecken des Bildschirms abwechslungsweise Weiss und Schwarz anzuzeigen - und dann dort eine Photodiode montieren. So werden jegliche allfällige Latenzen irrelevant.
Sean G. schrieb: > Am einfachsten wäre wohl an einem Ecken des Bildschirms > abwechslungsweise Weiss und Schwarz anzuzeigen - und dann dort eine > Photodiode montieren. So werden jegliche allfällige Latenzen irrelevant. Das ist tatsächlich eine interessante Idee. Ich muss mal schauen, ob sich die Brillen schnell genug umschalten lassen. Wobei, einige Brillen haben separate einschalt und ausschalt Befehle, Dann könnte ich eine fixe zeit das Bild an lassen, ausschalten bevor das nächste kommt, und anschalten sobald es da ist. Je länger ich darüber nachdenke, desto besser gefällt mir die Idee. Das ganze wäre sogar auch quasi portabel. Das Weisse / Schwarze Feld könnte ich auch in Videos hinein kodieren, dann könnte ich das sogar auf meinem Tablet usw. zum Filme schauen verwenden, ganz ohne dort die Grafiktreiber zu modifizieren. Ich denke, das werde ich dann mal ausprobieren. Danke!
> Gibt es da irgend eine Möglichkeit, da an so ein Signal heranzukommen?
Das letzte mal wo ich so einen 3D-Adapter gesehen habe, benutzte
der einfach DVI. Und in dem winzigen Kaeschtle steckte ein ebenso
winziger Spartan 3(A?). Der allerkleinste wenn ich mich richtig
entsinne.
Daniel A. schrieb: > Ich muss mal schauen, ob sich die Brillen schnell genug umschalten lassen. Wenn nicht bräuchtest du halt noch einen Mikrocontroller (oder irgendwas mit nem NE555 - da hab ich aber keine Ahnung wie genau :D ) um das Signal zu verzögern, und allenfalls den Duty Cycle anzupassen.
Sean G. schrieb: > Daniel A. schrieb: >> Ich muss mal schauen, ob sich die Brillen schnell genug umschalten lassen. > > Wenn nicht bräuchtest du halt noch einen Mikrocontroller (oder irgendwas > mit nem NE555 - da hab ich aber keine Ahnung wie genau :D ) um das > Signal zu verzögern, und allenfalls den Duty Cycle anzupassen. Im Prinzip den "gemessenen/ optisch detektieren" Wechsel hernehmen um die genauen Zeiten zu vermessen und denn Synchronisierungszeitpunkt festzulegen und damit dann "Vorhersagen" wann der nächste Wechsel kurz bevorsteht um die Brille zeitig ab-/um- zuschalten. Über die PC-Grafikkarte glaube ich nicht das das heutzutage noch was wird. Die Monitore haben ja auch nochmal eine etwas aufwendiger Bildbearbeitung laufen und geben nicht mehr wie früher einfach ein Pixel nach dem anderen aus. Da wird erstmal ein Frame komplett empfangen, um z.B. das Bild passend zu skaliert, die Helligkeit angepasst, die Farbtemperatur, eine Gammakorrektur durchgeführt, das Bild nachgeschärft und und und. Da hängen schonmal einige Frames in der Pipline bevor diese überhaupt in den (Mehrseitigen)Ausgabebuffer des LCD landen. Bis der dann physikalisch überhaupt aktiv geschaltet wird wird dauert es nochmal etwas. Der Zeitpunkt eines Umschaltens in der PC-Software muss daher nicht wirklich der Zeitpunkt sein wann dieses Umschalten auch sichtbar wird. Was aber eigentlich passen müsste, ist der gleichmäßige Abstand zwischen den Umschaltzeitpunkten. Normalerweise müsste halt der Monitor ein Signal ausgeben, wenn er gedenkt in Kürze das nächste Frame anzuzeigen...
Mit einem FPGA ist das kein Problem, das zu Synchen und einen Vorlauf zu programmieren. In HW könnte man zumindest etwas zwischenschalten, die SAV aufwerten und ein einstellbares Synch machen. Zuvor müsste man aber das 3D-Format klären: Es gibt ja line-by-line (also wechselnde Zeilen für die Bilder mit insgesamt halber Y-auflösung) und side by side, also halbe X mit jeweils wechselnden Monitoren innerhalb der Zeile.
Es ist nun schon ein paar Jahre her, das ich etwas mit HW gemacht habe. Ich habe mittlerweile ein paar alte atmega1284p und einen 16MHz quarz ausgegraben. IR Dioden habe ich auch noch welche herumliegen. Eine Photodiode habe ich zwar gerade keine zur Hand, aber ich glaube irgendwo müsste ich noch einen Photowiderstand haben, ich muss den nur wieder finden. Die Timings für das IR Signal kann ich mir von https://github.com/lukis101/3DVisionAVR/blob/master/3DVisionAVR/IRProtocols.h#L26 ziehen. Damit sollte ich das in den nächsten paar Tagen mal ausprobieren können. Neben der einen 3D Vision IR Brille habe ich aber auch noch 4 Bluetooth 3D Brillen von einem sehr alten Samsung TV. Der atmega1284p hat ja kein BT, und ist ansonsten etwas überdimensioniert. Könnt ihr mir einen von der physischen Grösse her möglichst kleinen uC empfehlen, der BT hat, mindestens 2 freie IO Pins (für die IR Led und die Photodiode), und mit mindestens 16MHz läuft?
Ok, danke. Wobei, kann man mit dem auch BT machen, nicht nur Zigbee? Aber egal, es gibt da ja einige Chips, ich bestell einfach mal ein paar und schaue dann weiter.
Harald K. schrieb: > Wozu brauchst Du 16 MHz Takt? Damit ich genug Zeit habe, um auch das IR Signal auszugeben. Ok, vermutlich würden auch 8MHz, oder gar 1MHZ, reichen, wenn ich den Code richtig lese, sind die Zeiten dort in us angegeben. Ich habe mir die Signalausgabe auch von dem weiter oben verlinkten Repo abgeschaut, aber es gibt ja auch effizientere Methoden, so ein Signal auszugeben, als in dem Repo dort verwendet wird. Aber etwas mehr zeit zur Verfügung zu haben kann nie schaden.
Daniel A. schrieb: > Wobei, kann man mit dem auch BT machen, nicht nur Zigbee? Dann nimm den hier: https://www.ti.com/product/CC2540
Interssante Diskussion. Ich hab mich auch schon ein paarmal gefragt ob man die 3D-Brillen von meinem TV nicht auch am Rechner nutzen koennte. Soweit ich weiss nutzen diese Brillen (Panasonic) Bluetooth. Jedenfalls entspricht die Lebensdauer der CR2025 in der Brille eher Bluetooth als Wlan und die Schnittstelle ist auch bidirektional. :) Da stellt sich natuerlich die Frage wie man das in Software macht, zumal ich es mir schwierig vorstelle sowas ueber Bluetooth syncron zu halten. Vanye
Mittlerweile konnte ich die IR Brille schon mal erfolgreich ansteuern (siehe Anhang). Es geht aber nur, wenn ich die Brille auf die IR LED zeigen lasse oder umgekehrt, und sie nahe genug beieinander sind. Und ich glaube meine LED Raumbeleuchtung funkt manchmal auch noch rein. Aber zumindest mal ein Anfang. (Keine Ahnung, ob diese IR LED für soetwas überhaupt geeignet ist.) Was ich noch herausgefunden habe: Zwischen den IR Sequenzen muss mindestens etwa 2500 us Pause sein. Solange sie länger ist, kann man sie aber ziemlich beliebig wählen. Es scheint nicht möglich zu sein, einzelne Kommandos abzusetzen. Die Brille tut nur etwas, wenn ich die ganze Sequenz (links an, links aus, rechts an, rechts aus) durchgehe. Lasse ich auch nur eine aus, macht sie nicht mehr mit. Edit: Es scheint, der Videoupload ging schief. Also hier ein Link der geht: https://temp-s.s.abrecht.li/20230403_231815_1.mp4
:
Bearbeitet durch User
Mittlerweile habe ich den Photowiederstand befestigt. Und zum testen mal ein langsames Signal (100ms) angelegt. Das geht einigermassen, aber die Brille macht nicht wirklich mit, die tut und lässt, was sie will: https://temp-s.s.abrecht.li/20230404_232242_1.mp4 Jetzt muss ich erst mal suchen, warum, das könnte etwas dauern. Es gibt einige Kandidaten. Vielleicht ist das Timing nicht genau genug. (Ich muss mir mal die caps für den quarz besorgen). Vielleicht will es die Brille doch schneller. Vielleicht liegt es am kaputten Akku der Brille. Vieleicht ist die IR led die falsche Wellenlände oder zu schwach. Oder vielleicht ist es sonst was. Naja, irgendwann werde ich es schon raus finden. Was ich mir auch noch überlegen muss, momentan schaue ich einfach nur auf die Helligkeit. Aber vielleicht wäre es besser, wenn ich stattdessen auf Helligkeitsänderungen gehe. Der Bildschirm und die Umgebung sind ja nicht immer gleich hell, und ganz dunkel ist er auch bei schwarz nicht.
Daniel A. schrieb: > Photowiederstand Von der Schreibweise abgesehen die schlechteste Möglichkeit, Licht auszuwerten. Nimm 'ne Photodiode oder einen Phototransistor, die sind nicht so arschträge.
Ich habe nun noch ein PDF mit diversen timings gefunden: https://cmst.curtin.edu.au/wp-content/uploads/sites/4/2016/05/2011-17-woods-helliwell-3D-Sync-IR.pdf Es scheint die NV Brille hat nicht so schön gerade timings, wie ich anfangs dachte. Vermutlich muss ich da einfach näher dran ran kommen.
So ganz habe ich es noch nicht hinbekommen, aber es ist definitiv machbar. Ich komme nicht so ganz dahinter, welche Anforderungen die NV Brille an das Signal stellt. Schalte ich konsistent mit 60Hz oder 120Hz um, und lasse beide Gläser gleich lang an / aus, läuft sie stabil. Versuche ich z.B. 30Hz, geht es nicht mehr. Aber die 10Hz von oben gingen manchmal kurzzeitig? Es scheint auch doch nicht immer so zu sein, dass ich alle 4 Kommandos immer senden muss. Lasse ich die "aus" oder "an" Kommandos nur jedes 2te mal aus, bleibt die Brille am laufen. Aber ein ganzes umschalten auslassen, das mag sie nicht. Und ich glaube, wenn das Signal ihr einmal etwas zu sehr von der Durchschnittsfrequenz abweicht, mag sie es auch nicht. Sobald ich versuche, das Umschalten an das Synchronisierungssignal zu koppeln, will sie nicht mehr, und ich bin mir nicht sicher, warum. Manchmal macht sie kurzzeitig doch mit, dann sieht man auch wirklich nur eines der Bilder: https://temp-s.s.abrecht.li/b3.mp4 Aber irgend etwas passt ihr noch nicht.
Ich denke, ich habe mein Problem nun gefunden. Am Anfang hatte ich quasi das hier versucht:
1 | while(1){ |
2 | ir_cmd_left_on(); |
3 | _delay_ms(1000/120); |
4 | ir_cmd_left_off(); |
5 | _delay_ms(1000/120); |
6 | ir_cmd_right_on(); |
7 | _delay_ms(1000/120); |
8 | ir_cmd_right_off(); |
9 | _delay_ms(1000/120); |
10 | } |
Und dachte, die Brille macht 60Hz mit. Aber 1000/120 wird natürlich abgerundet. Wenn ich Stadtessen _delay_ms(1000./120); nehme, geht es nicht mehr. Genauso, wenn ich mit einem Timer exakt das Umschalten auf 60Hz Time. Erst Irgendwo um die 62Hz fängt die Brille an, mit zu machen. Mein Monitor läuft natürlich mit rund 60Hz, wie eigentlich alle. Darum wollte die Brille nicht mit machen. Es ist fast so, als wäre das Ding von Nvidia absichtlich so designt worden, dass es mit normalen Monitoren nicht sauber laufen kann. Die Samsung BT Brillen kann ich auch vergessen, die gehen nur mit richtig polarisierten Bildschirmen. Ich kann meinen Bildschirm auf 120Hz einstellen, aber mein Laptop macht das nur bei halber Auflösung mit, und ich kriege mit meinem momentanen Aufbau bei der Frequenz die Brille entweder nicht schnell genug, oder nicht genau genug geschaltet, dann hab ich ghosting. Auf jeden Fall muss ich erst mal ein paar Sachen umbauen, und eventuell ein paar andere Brillen und anderen Kram besorgen.
Das hier ist bei 120Hz: https://temp-s.s.abrecht.li/b4.mp4 Würde vermutlich schon reichen. Aber IRL ist das ghosting noch etwas sichtbarer, dass muss noch besser gehen.
Daniel A. schrieb: > Schalte ich konsistent mit 60Hz oder 120Hz um, und lasse beide Gläser > gleich lang an / aus, läuft sie stabil. Versuche ich z.B. 30Hz, geht es > nicht mehr. Aber die 10Hz von oben gingen manchmal kurzzeitig? > Es scheint auch doch nicht immer so zu sein, dass ich alle 4 Kommandos > immer senden muss. Lasse ich die "aus" oder "an" Kommandos nur jedes 2te > mal aus, bleibt die Brille am laufen. Aber ein ganzes umschalten > auslassen, das mag sie nicht. Und ich glaube, wenn das Signal ihr einmal > etwas zu sehr von der Durchschnittsfrequenz abweicht, mag sie es auch > nicht. Kling für mich danach, dass da in der Brille drin eine PLL läuft, also wohl in digital implementiert aber das selbe Prinzip. Mach ja auch Sinn, dass da dazwischen mal ein Komando fehlen darf, vielleicht weil die Hand gereade zwischen Brille und Monitor ist um Pop Corn in den Mund zu tun :-) Schade dass der Fangbereich erst ab 62 Hz beginnt. 30 Hz pro Auge willst du (ich definitiv) zwar nicht aber kann halt jeder Monitor.
Es scheint, dass die IR 3D Brillen mit 4 Kommandos aus dem weiter oben verlinkten PDF, nicht mehr hergestellt werden. Man findet noch diverse BT / RF Brillen. Solche die das sogenannte "Full HD 3D" verwenden. An die Specs (und Lizenzen) davon wird man wohl nicht mehr so einfach kommen, die Seite dafür ist seit Jahren schon von spam übernommen worden. Aber ich habe noch eine Bluetooth spec gefunden: https://www.bluetooth.com/specifications/specs/3d-synchronization-profile-1-0-3/ Ob dass wohl das selbe ist? Im Internet liest man, bei BT / BTLE gibt es die Unterteilung Profil, Services, Characteristics. Aber die Spec erwähnt nirgends "characteristic" in dem Zusammenhang, obschon Profil und Services erwähnt sind. Zwischen Profilen wie diesem, gibt es wohl gröbere Unterschiede zu normalem BT / BTLE? Da werde ich wohl nicht jeden BT(LE) Chip nehmen können. Aber allzu genau habe ich mir das ganze auch noch nicht angeschaut. PS: Mir ist noch eine Sache aufgefallen. Wie es scheint, ist es für einen LCD Monitor recht ermüdend, 120 mal in der Sekunde zwischen Weiss und Schwarz umzuschalten. Beim anzeigen dunkler Farbtöne scheint es, zumindest vorübergehend, zu einer Art Einbrenneffekt kommen zu können, wenn man das macht. Aber bisher scheint es nicht dauerhaft zu sein.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.