Hallo
Ich wollte mal fragen, ob es in SVG möglich ist einzelne Elemente “3 Dimensional” anzuzeigen.
Ich denke vorallem an Bilder. So dass ich dann die oberen beiden Eckpunkte etwas herunter und etwas näher zusammen setzen kann, so dass das dann wie ne Fläche aussieht, die nach hinten läuft.
Ich hoffe ihr wisst, was ich meine 
Freundliche Grüsse
Also du meinst sinngemäß sowas (hier mit Animation):
hoffmann.bplaced.net/svgueb/sterntetraeder2.php
Muß man bei den aktuellen SVG-Standards jedenfalls selbst
ausrechnen und projezieren, ist aber nicht so schwierig:
hoffmann.bplaced.net/hilfe.php?m … projektion
Die W3C-Arbeitsgruppen für CSS und SVG haben Arbeitsentwürfe
für einfache 3d-Transformationen und Projektionen am Start.
Zumindest angewendet auf (X)HTML kann man wohl z.B.
bei aktuellen webKit-Versionen solche Transformationen mal
ausprobieren, meine ich (habe aber selber nur mal kurz 2d
getestet). Ist für die Praxis aber noch nicht akut, weil das erst
jeweils die ersten Arbeitsentwürfe sind, die noch komplett
geändert werden können (oder auch müssen, da der Gedanke ist,
daß der CSS- und der SVG-Entwurf zusammenpassen sollen).
Achso - wenn mit ‘Bilder’ Pixelgraphik gemeint ist, das ist sinnvoll
möglich mit diesen Arbeitsentwürfen, zu Fuß eher schwierig.
Technisch könnte das in SVG 1.1 gehen mit Filtern, da gibt es
eine feDisplacementMap:
w3.org/TR/SVG11/filters.html … acementMap
Der Haken ist dabei allerdings, daß man diese
Verschiebungskarte erstmal selber ausrechnen muß (Farbverlauf
mit Grauwerten sollte da eine plausible Lösung liefern).
Jetzt mal angenommen ich mache mit SVG eine 3D Karte mit Fluchtpunkt mache - also zuerst mal eine Grafik, die den Boden darstellt, dann sicher noch einige Häuser (also 4 Grafiken; front, seitenwände und dach) und ein paar büsche (1 oder 2 grafiken pro Busch) - ist es dann sinnvoll, nach jedem Schritt (Der Benutzer soll durch diese Karte laufen können) die Perspektiven neu zu berechnen?
Oder ist es da aus Performancegründen sinnvoller, wenn ich eine “statische” 3D Karte (halt ohne Fluchtpunkt) mache, die sich einfach den Schritten entsprechend verschiebt?
Freundliche Grüsse und danke schon mal 
Da SVG eigentlich für 2D-Graphiken gedacht ist, verwendest du
für sowas besser ein anderes Format oder wenn es sehr
interaktiv sein soll, verwendest du ein java-Programm oder
-applet, um sowas zu realisieren. Java hat ja wiederum auch
Schnittstellen für SVG, damit könnte man dann zumindest jede
Ansicht als SVG ausgeben.
Wie man bei meinen PHP-Skripten sieht, wird das mit Animation
für das Darstellungsprogramm schon recht mühsam, wenn da
kompliziertere Szenen gerechnet werden sollen - dann ja
zwangsläufig in Echtzeit für eine solche Animation.
Mit Interaktion und einem komplizierterem Szenario braucht man
da viel mehr Rechenleistung und ein Format, welches dazu
geeignet ist.
In den mailing-Listen zu HTML5 ist immer mal wieder X3D im
Gespräch - die täten da auch gern einen ähnlichen Status wie
MathML und SVG innerhalb von HTML bekommen. Jedenfalls
könntest du dir mal angucken, ob das etwas bietet, was dich
einer Lösung für kompliziertere Szenarien näherbringt, ohne das
Rad neu erfinden zu müssen ;o)
de.wikipedia.org/wiki/X3D
Ich selbst habe das nie ausprobiert, frag mich also nicht, was man
da wie macht ;o)
Wenn du den ganzen Projektionskram für kompliziertere Objekte
machen willst als ich das getan habe, so ergeben sich da
zwangsläufig üble, aber bekannte Probleme, wo man dann froh ist,
wenn das Darstellungsprogramm die löst und man das nicht
zu Fuß selber machen muß, was erforderlich ist, wenn man ein
eigenes Skript hat, was dann letztlich animiertes SVG raushaut,
was (nahezu) nichts von einer dritten Raumdimension weiß.
Die Berechnungen wollte ich eigentlich mittels Javascript durchführen, da dann schonmal die übertragung der neuen SVG-Daten wegfällt. (Soweit ich mich erinnere ist JS fähig über DOM auf SVG-Dokumente zuzugreiffen…) 
Der Nachteil von X3D ist natürlich, dass der Besucher ein Browserplugin installieren muss. Und diese 3Dimensionale Karte ist eine ganze zentrale Komponente …
Von Java selber habe ich sozusagen keine Ahnung. Ich hab mir zwar mal was angeschaut, aber ich könnte mich nicht mal ans Ausgeben von Text zurückerinnern (da ich es dann nie gebraucht habe, verschwand halt mein Interesse …)
Bei java-script solltest du dann natürlich auch eine Variante
bereitstellen, wo die Information auch ohne Skriptinterpretation
verfügbar ist - ist bei SVG recht komfortabel möglich.
Ansonsten mußt du bei solch einem Ansatz sicher alle Probleme
alleine in deinem Skript lösen, also sicherstellen, daß sich
Objekte nicht durchdringen, gucken, was vorne und hinten ist
und dann eben alles in der richtigen Reihenfolge nach der
Projektion ausgeben - und das für jeden Schritt der
Skript-Animation.
Bei meiner Animation berechne ich ja auch mit PHP, was vorne
und hinten ist und ändere dann per Animation eben die
Reihenfolge, in der die einzelnen Objekte referenziert werden.
Dabei ist das ja eine diskrete Animation, die Transformationen und
Projektionen aber kontinuierliche. Das ist bei einer Skriptanimation
etwas einfacher, weil es da keine kontinuierliche Änderung von
Attributen oder Eigenschaften gibt, also kann man immer exakt
bestimmen, welche Reihenfolge die richtige für den aktuell
darzustellenden Rahmen (frame) ist.
Sollte die reihenfolge nicht gleich bleiben?
Zudem ist mir gerade noch die Frage aufgetaucht, ob das nicht viel zu ressourcen belastend ist, wenn das ganze zuerst berechnet wird und dann müssen noch x Elemente zeitgleich verschieden animiert werden…
Vlt. sollte ich lieber das Rad neu erfinden? 
Nun, wenn sich Objekte bewegen oder aber auch der Beobachter
selbst sich bewegt, muß die Zeichenreihenfolge nicht
gleichbleiben, sofern die Objekte sich in der Sichtlinie des
Beobachter teilweise verdecken.
Kommt also ganz drauf an, was passiert und wie komplex die
Szenerie ist, ob sich die Zeichenreihenfolge ändert oder nicht.
Da SVG nunmal nur zweidimensionale Pfade kennt, ist es immer
so, daß man ausgedehnte Objekte in ebene Flächen, bestehend
aus Einzelpfaden zerlegen muß, dann transformieren, die
Zeichenreihenfolge bestimmen und dann darstellen.
Generell müssen dies auch 3D-Formate tun, nur ist das dort dann
eher Aufgabe des Darstellungsprogrammes als des Autors.
Bei einem richtigen 3D-Format kann man die vom Autor
notwendig angebbare Information also deutlich knapper halten
als bei einem 2D-Format, weil beim ersteren die Transformationen
und Projektionen und die Bestimmung der Zeichenreihenfolge dem
Darstellungsprogramm überlassen werden kann, während bei
einem 2D-Format der Autor dies alles selber berechnen muß und
das Ergebnis davon explizit in die Datei reinpacken muß.
Der Aufwand und die notwendige Rechenleistung sind bei beiden
Varianten relativ hoch. Bei der 2D-Variante muß das
Darstellungsprogramm allerdings eine Dimension weniger
verwalten, daher kann das deutlich einfacher ausfallen, muß
dafür aber auch deutlich größere Dateien vom Autor verwalten,
um das gleiche Ergebnis zu erzielen.
Hmm, ja…
Danke dir 
