Überlegungen zum Mapbuilding

Wenn ich bei euch mitlesen will, muss ich ständig was nachgooglen.
Mesh:
http://erbsen.er.funpic.de/.theprodu...emo/meshes.htm
Habt ihr noch mehr so Wörter die ich nicht kenne?

Das mit der Bilddatei, oder einem Videoframe ist mir auch durch den Kopf gegangen.
Das ist aus meiner Sicht dasselbe.
Wenn ich das damals beim Amiga richtig verstanden habe, haben die einen großen Leistungssprung im Datentransfer gemacht als sie einfach die Videodatenschaufel benutzt haben. Die war notgedrungen schnell und eben schneller als der Rest der Speicherverwaltung.
Beim Amiga gab es keine strikte Trennung zwischen Hauptspeicher und Videospeicher. Das war alles einer.

Aus diesem Grund lohnt sich aus meiner Sicht schon, mal zu gucken wie Frames behandelt werden und vielleicht auch Routinen aus der Frame -Fummelei zu adoptieren.

Der Amiga hatte auch das erste ernst zu nehmende Bilddateiformat:
IFF Intechange File Format. Mit Haeder und Boddy und so.

Des Weiteren hatte er eine witzige Art Speicher zu sparen.
Die hieß HAM.
Hold and Modify. Da wurde für den Nachbarpixel nur der Differenzwert gespeichert.
Also: Alten Wert halten und neuen Modifizieren. Damit haben sie farbtiefen generiert die eigentlich unmöglich für das System waren.

Zum Thema speziell:
Insgesamt kann man ja ein komplettes Array real, oder virtuell errichten. Aber die Koordinaten die fürs Leben wichtig sind machen nur einen Bruchteil davon aus.

Man könnte übrigens, wenn wir hier grob was klar haben auch in einen Evolutionären Prozess eintreten und mal was Prototypenhaftes auf die Beine stellen.
Und mal sehen wie sich das macht.
Das ganze könnte man im ersten Durchlauf auf dem PC machen um die Logik und Funktionalität zu entwickeln. Erst dann verkleinern und auf den µC.
Dabei können zwei Modelle verfolgt werden:
Array und Vector.
Der Zustrom von Sensordaten müsste idealer weise erstmal künstlich sein. Denn nicht jeder hat einen lauffähigen Robi im Schrank oder unter dem Sofa(wo ihn Mutti nicht findet).

So für ein Post genug

Netter Gruß

@PicNick:
Wäre es mit erträglichem Aufwand möglich Deinen Server dazu zu bringen TCPClient zu TCPClient zu routen?.

Damit könnten wir eine lebende Entwicklungsumgebung herstellen.
Die Clientfunktionalität haben wir ja auch schon.

Netter Gruß

Hallo,

wenn ich mich mal reindrängen darf. An die Pixelfreunde, vielleicht interessiert euch ja die Datenstruktur des Oct-Trees.

Hier werden 3 dimensional orientierte Daten (binär besetzt/frei oder auch skalare) in einer Baumstruktur repräsentiert, die genau wie ein Array Nachbarschaften fest definiert und zugleich eine Art dreidimensionale Lauflängenkodierung beinhaltet.
Das ganze kann problemlos um eine Dimension reduziert werden.
http://de.wikipedia.org/wiki/Octree

Zitat:

---

Zitat von marvin42x

@PicNick:
Wäre es mit erträglichem Aufwand möglich Deinen Server dazu zu bringen TCPClient zu TCPClient zu routen?.

---

Kein Aufwand. Aber die Clients müßten ihre IDs bekanntgeben.

Zwischenmöglichkeit:
Alles wird ge-broadcastet. (ausser dorthin, wo's herkommt)

Gruß ins Tal (wo die vielen Brücken sind) :mrgreen:

Bei den Speicherungsmöglichkeiten auf µC wird man (oder halt nur ich) den Kopf mal schief halten, damit das Hirn in einer Ecke zusammenläuft und man besser nachdenken kann.
Aus dem Bauch zumindest weiß ich, daß es keine einzelnen seligmachenden Weg geben kann, es wird drauf ankommen, was man für Auswertungen braucht.

@gast1234: angeguckt, danke. Die meisten Verfahren beruhen darauf, daß man hemmungslos "new" sagen kann, und wenn's nicht reicht, kauft man einen größeren PC. Denen (für Games) kommt's primär auf die Geschwindigkeit an.
Dem µC fehlt halt sowohl als auch. :-(

Ahh, jetzt ja ;-)

Also, so langsam kommen wir zu einem gemeinsamen Verständnis.
Was ich als "Bitmap" und "Pixel" bezeichnet habe, meint genau das, was auch mit "Frame" gemeint ist - eine "Bilddatei". Ohne Header. Ohne Kompression. Einfach 1:1 als Array im Speicher abgelegt. Mit 4 Bit "Farbtiefe" pro Pixel.

Hat schon mal jemand Erfahrungen mit komprimierten Daten auf einem Microcontroller gemacht? Der Zugriff auf die Daten ist sicherlich langsamer und umständlicher, als wenn man direkt auf die Daten in einem Array zugreifen kann. Nach meiner Einschätzung muss man die Daten zum Zugriff ja zumindest teilweise wieder "expandieren", lohnt der Aufwand dafür?

Bleibt die spannende Frage, ob die speichereffiziente Variante einer Speicherung in Vektoren hinreichend gut zu verarbeiten ist. Spannender ist es allemal, die Frage ist ob es auch effizient zu implementieren ist.

Lineare Algebra war nicht so meine Stärke - gibt es einen coolen Trick, den Schnittpunkt zweier Vektoren zu berechnen, oder läuft das auf das lösen eines Gleichungssystems raus?

Gruß
Reinald

Zitat:

---

Die meisten Verfahren beruhen darauf, daß man hemmungslos "new" sagen kann, und wenn's nicht reicht, kauft man einen größeren PC

---

Nachtrag:

Wenn man sich mal das Verhältniss der meisten Flächen zu ihren Umfängen ansieht, erkennt man, dass mit steigendem Umfang die Fläche annähernd quadratisch zunimmt. Im Umkehrschluss bedeutet dies hier, dass eine Verfeinerung des Rasters, den Einspareffekt überlinear erhöht.

Geht man jetzt noch in den Raum oder Hyperraum, gehen die Einsparungen in Richtung dritte, vierte ... Potenz zur Verfeinerung des Rasters.

Das Verfahren ist nicht für performancesüchtige Grafikfreaks ausgelegt, sondern war mal Idee einer speichereffizienten und nicht verlustbehafteten Speicherung von Voxeldaten, wie sie bei einer Magnetresonanz/Kernspin- oder Computertomograhpie vorkommen.

@gast1234:
Mein lieber Mann.......
Schwere Kost.
Sieht aber sehr interessant aus.
Danke für die ausführliche Mühe.
Das hat ja richtig Arbeit gekostet.
Für meinen Teil brauch ich etwas Zeit um das genauer zu beleuchten.
Im ersten Hinschauen wäre das durchaus ein Kandidat den man mal realisieren sollte.

@all:
Wenn ich schon am Anfang hier mit Prototypen rum fuchtele bevor überhaupt der theoretische Überbau steht.
Geschieht das aus meiner Erfahrung mit dem RN-Comm Projekt in dem ich gerade mit mache.
Dort haben wir uns sehr viel Mühe im Vorfeld mit der Theorie gegeben. Was sicher auch wichtig war.
Als dann die ersten Programme das laufen lernten konnten wir aber aus den praktischen Erfahrungen heraus einiges über Board werfen und neu definieren.
Im Rückblick gesehen hätten wir meiner Meinung nach schon viel früher etwas Hemdsärmeliger rangehen können um die Praxis und Theorie gleich zeitig wachsen zu lassen.
Das ist aber jetzt, wie gesagt, meine ganz persönliche Meinung dazu.

@PicNick:
Prima, das Angebot ist angenommen :-)
Ich bestelle hiermit einen RN-Comm Server mit Client ->Sever->Broadcast Funktionalität.
Ausbaustufe: Völlig egal
Liefertemin: Ab jetzt
Preis: Eine Huldigung.
Ich würde dann mal einen Sendeclient und einen Empfangsclient herstellen wollen(in VB2005).
Der Sendeclient sollte mal eine Reihe von Koordinaten ausgeben die im Sendeclient empfangen werden.
Daran kann man dann Programmteile Knüpfen die mit den Daten was machen.
Das wäre Programmtechnisch mal ein Vorschlag.
Um Meinungsäußerung wird gebeten.
Genug für den Post.

Netter Gruß

Eine Rundfrage:
Welche Programmiersprachen stehen denn so zur Debatte?

Netter Gruß