Hallo leute, ich bin auf der suche nach literatur zum thema bearbeiten von vektorgrafiken auf einem fpga, rendern von 2d und 3d grafiken. aber leider geht eigentlich alles was man so findet weit über das thema hinaus, bzw setzt nicht so tief unten an. als problemstellung könnte man z.b. dies sehen: gegeben ist eine 2D oder 3D Grafik, diese enthällt allerdings nur die konturen bzw. einschließenden Flächen der Figur. diese Figur soll nun mit bestimmten Figuren ausgefüllt werden und wieder in vektoren abgespeichert werden. ich würde mich sehr über vorschläge für grundlegende literatur oder andere ansätze freuen.
Fabian -leuchte1 schrieb: > Hallo leute, > ich bin auf der suche nach literatur zum thema bearbeiten von > vektorgrafiken auf einem fpga, rendern von 2d und 3d grafiken. Hm, hilft dir Literatur über Voxel rendering FPGA weiter ? http://ntnu.diva-portal.org/smash/get/diva2:567036/FULLTEXT01 MfG,
das sieht schon mal sehr gut aus vielen dank :-) aber weitere vorschläge sind immer gern gesehen,
ich hab das dokument jetzt mal durchgelesen grundlegend ist es sehr interessant und beantwortet auch einzelne fragen, allerdings ist es noch nicht ganz das was ich suche. ich glaube der titel war aber auch etwas schlecht formuliert. ich habe mir nochmal genau gedanken darüber gemacht und würde jetzt als zentrale frage sagen: wie teile ich komplexe 2d figuren in dreiecke auf? beispiel: beliebiges polygon in dem wiederrum beliebige polygone liegen können die vom äußeren polygon eingeschlossene flächen wieder ausschliesen. praktisch: ein blatt papier in das willkührlich löcher gefressen sind in dreiecke aufteilen.
Fabian -leuchte1 schrieb: > praktisch: ein blatt papier in das willkührlich löcher gefressen sind in > dreiecke aufteilen. Das ist ja jetzt keine FPGA-Frage. Kläre erstmal den Algorihtmus. Dann schreibe den in einer Hochsprace Deiner Wahl auf und teste erstmal, ob die Software das macht, was sie machen soll. Und erst dann kommt der Schritt, um das ganze auf einem FPGA umzusetzen... Duke
ja da hast du recht. dachte nur da die zielplattform ein fpga ist frage ich mal ob soetwas vielleicht schon jemand gemacht hat. ich werde mal suchen
Das macht keiner freiwillig auf einem FPGA :-) Der Aufwand einen Algorithmus auf einem FPGA zu implementieren ist wesentlich höher, als das Ganze auf einer CPU umzusetzen. Daher wir es nur dort gemacht, wo es unbedingt nötig ist. Duke
Was aus der 2D/3D-Materie für FPGAs geeignet ist, sind mehr einfache Algorithmen: - Punkte/Linien/etc. zeichnen (+evtl. ZBuffer,Aliasing..) - Pixelbuffer/ZBuffer löschen - Punkte transformieren (Matrizenalgebra..) - Linien clippen Schau dir mal Algos wie die von Bresenham an, sind sehr einfach in FPGAs zu giessen. Komplexere Aufgaben wie z.B. implizieren idR auch komplexere Datenstrukturen, eher für CPUs als für FPGAs geeignet. Hier macht die CPU die Vorberechnung, FPGA ist fürs zeichnen zuständig. Folgendes Beispiel (d.h. die Graphik) läuft komplett ohne CPU: http://www.youtube.com/watch?v=jDzPfAbHLFI Beispiele wie Folgendes sind mehr in der CPU implementiert: http://www.youtube.com/watch?v=Dtuiy-btxXk
Duke Scarring schrieb: > Der Aufwand einen Algorithmus auf einem FPGA zu implementieren ist > > wesentlich höher, als das Ganze auf einer CPU umzusetzen. Nicht, wenn du es mit MATLAB machst. Mache Sachen, gehen auf FPGA sehr gut. Auch im Render-Bereich. Selbst Siemens hat Karten im Einsatz, die rein mit FPGAs arbeiten und rendern.
Duke Scarring schrieb: > Das macht keiner freiwillig auf einem FPGA :-) > Der Aufwand einen Algorithmus auf einem FPGA zu implementieren ist > wesentlich höher, als das Ganze auf einer CPU umzusetzen. > Daher wir es nur dort gemacht, wo es unbedingt nötig ist. Nicht unbedingt, mit einer externen CPU gibt Synchronisationsprobleme etc., besonders wenn es um Echtzeit geht. Also implementiert man eine Soft-CPU (oder eher Soft-DSP) auf einen eh vorhandenen FPGA. Oder nimmt einen FPGA mit Hard-CPU-core. MfG
danke für die vielen antworten. ich werde mich mal in die algorithmen einlesen. eigentlich muss ich ja in diesem fall nur linien und punkte ziehen. das grundlegende ist aber wohl die fehlerfreie aufteilung in dreiecke auch von komplexen polygonen.
ich würde mich allerdings noch über einen tip für algorithmen freuen die speziell auf mein kernproblem zielen. aufteilen beliebiger polygone mit und ohne löcher (wiederrum durch polygone definiert)
Fabian -leuchte1 schrieb: > ich würde mich allerdings noch über einen tip für algorithmen freuen die > speziell auf mein kernproblem zielen. aufteilen beliebiger polygone mit > und ohne löcher (wiederrum durch polygone definiert) Falsches Forum.
Angehängte Dateien:
-
polygon.png
160 KB
Also du hast ein äußeres Polygon in dem innere drinnen sind - und du willst die Fläche dazwischen in 3-Ecke aufteilen? Also ich würde erstmal etwas bauen mit dem ich den Abstand von zwei Punkten berechnen kann. Und dann musst du dir überlegen ob du nur vorhandene Punkte verbinden möchtest, oder ob du ach neue Punkte (z.B. in der Mitte einer Strecke) neu einfügen möchtest. Das Beispielbildchen zeigt: Ein äußeres Polygon mit zwei inneren. Dann wurden die Punkte nach Entfernung verbunden, also je Näher die zusammen liegen desto früher. Verbindungen dürfen sich nicht überschneiden und keine Verbindung darf durch eines der inneren Polygone gehen oder, falls gegeben wie bei einem Stern aus äußeres Polygon, das äußere Polygon verlassen. Also das sind schon ein paar Funktionen die man da bauen muss ... und so würde ich vorgehen. Edit: Und natürlich brauchst du eine Funktion die sicher stellt, dass am Ende nur Dreiecke vorkommen, also die Funktion muss irgendwie alle Dreiecke testen ob es auch Dreiecke sind. Ich würde das aber wirklich in einer CPU machen und nur das Zeichnen selbst dann im FPGA, also die Koordinaten dann an den FPGA übergeben.
Ermel Hoch schrieb: > Soft-CPU (oder eher Soft-DSP) auf einen eh vorhandenen FPGA. Oder nimmt > > einen FPGA mit Hard-CPU-core. Nee! Nach allem, was ich in dieser Richtung gesehen habe, ist das vollkommen ineffektiv. Die Softcores eigenen sich nur zu dem einen Zweck, eine sehr komplizierte, aber langsame <100 MBit Kommunikation sequenziell abzuarbeiten, wenn man Steuerungen und Verwaltung realisiert. Ansonsten laufen die Softcores langsam in den Kosten davon und sind oberhalb von 500MBit auch nur noch mit schnellen FPGAs zu machen, werden also nochmal teuerer. Wenn Algorithmik auf dem FPGA, dann immer so, dass man möglichs breitbandid rein- und rauskommt (PCI) und auch breit bleibt, d.h. auf partiell hohen Wortbreiten und zudem viel Redundanz für paralleles Arbeiten. Wenn man mit dem Tempo und der Befüllung der Recheneinheiten Zeit hat, diese einfach sind und zudem alles sehr gut parallelisierbar ist, kommt man sehr schnell auch in Richtung der Grafikarten mit denen zumindest intern hohe Rechendichten machbar sind und die oberhalb eines gewissen Kostenrahmens auch billiger werden. Zumindest die billigen Grafikartenlösungen unter 200,- sind sehr preiseffektiv, weil die noch mit einer entsprechenden Stückzahl verkauft werden und fast dasselbe leisten, wie einer 400,-er Karte. Vektorgrafiken auf FPGAs sind schon anspruchsvoll, zu reinen Darstellen scheint mir das aber etwas oversized. Soll denn damit auch was gerechnet werden? Ich denke da an FEM-simulationen und Wetter ...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.