Suche simple Grafik- u. Sound-API.

otze

knivil schrieb:

Man macht es nicht so.

Quatsch. Voxel-Engine ist ok. Gibt einige populaere Vertreter, sowohl pure als auch hybrid.

Aber auch die packen das voxel array in die Graka und hauen dann einen Raycaster drüber.

sC++k

Dann erklärt mir doch mal wie man gezielt solche Algoritmen programmieren soll, wenn man für jeden einzelnen Pixel ein Voxel berechnen muss, ohne auf jeden einzelnen Pixel und deren Koordinaten sowie RGB-Werte Zugriff zu haben?

Das ist halt das Prinzip dahinter. Es müssen dadurch keine Texturkoordinaten sowie Vektoren berechnet werden(außer bei Physik u. Animation).
Das spart im großen u. ganzen immens Rechnleistung u. macht das Dargestellte im stillstand oder bei Cam-Bewegung unabhängig von der Menge die dargestellt werden kann. Somit hängt die Komplexität des Dargestellten nur von der Arbeitspeicher u.Festplatten-Kapazität ab,
welche für komplexe Darstellung in dieser Form rechnerrisch aber im erträglichen Bereich sein sollte.

Eine Frage hierzu: Was Glaubt ihr welche Rechenleistung min. notwendig sein sollte damit man "2073600" Pixel(FullHD) in die Ablage kopieren kann
und damit 60 Bilder pro Sekunde auf den Bildschirm flippen kann?

PS:
unkriptisch = (z.B)logisch, allgemeinverständlich, selbsterklärend, schemenhaft
Ich kann hier aber auch ein Wörterbuch empfehlen :
http://www.woerterbuch.info.

dot

Das große mit Voxeldaten ist, dass dir selbst bei trivialen Modellen sofort der Speicher ausgeht, wenn du nicht irgendwelche schlauen Methoden zur Komprimierung hast...

Fytch

sC++k schrieb:

PS:
unkriptisch = (z.B)logisch, allgemeinverständlich, selbsterklärend, schemenhaft
Ich kann hier aber auch ein Wörterbuch empfehlen :
http://www.woerterbuch.info.

das seh ich ein bisschen anders:
http://www.duden.de/suchen/dudenonline/unkriptisch
und bei einer expliziten suche nach dem wort findet man mit google als einziges diesen thread.

edit:
ein wenig ontopic:
aus deinen letzten threads wie dem hier (http://www.c-plusplus.net/forum/321184) schliesse ich, dass das vorhaben hier doch eine nummer zu gross für dich ist.

edit 2: link klickbar gemacht.

edit 3: ich persönlich tippe auf trolling.

sC++k

dot schrieb:

Das große mit Voxeldaten ist, dass dir selbst bei trivialen Modellen sofort der Speicher ausgeht, wenn du nicht irgendwelche schlauen Methoden zur Komprimierung hast...

"Komprimierung" in Bezug worauf?

dot

sC++k schrieb:

dot schrieb:

Das große mit Voxeldaten ist, dass dir selbst bei trivialen Modellen sofort der Speicher ausgeht, wenn du nicht irgendwelche schlauen Methoden zur Komprimierung hast...

"Komprimierung" in Bezug worauf?

Auf deine Voxeldaten? Ein einziges 512³ RGB Volumen braucht unkomprimiert bereits 384 MB...

sC++k

asfdlol schrieb:

sC++k schrieb:

PS:
unkriptisch = (z.B)logisch, allgemeinverständlich, selbsterklärend, schemenhaft
Ich kann hier aber auch ein Wörterbuch empfehlen :
http://www.woerterbuch.info.

das seh ich ein bisschen anders:
http://www.duden.de/suchen/dudenonline/unkriptisch
und bei einer expliziten suche nach dem wort findet man mit google als einziges diesen thread.

edit:
ein wenig ontopic:
aus deinen letzten threads wie dem hier (http://www.c-plusplus.net/forum/321184) schliesse ich, dass das vorhaben hier doch eine nummer zu gross für dich ist.

edit 2: link klickbar gemacht.

edit 3: ich persönlich tippe auf trolling.

Du irrst in deiner Vermutung, denn dieses Model hab ich schon längst verworfen. Ich benutze nun "Map" o. "Unordered Map".
Dieser Thread ist schon 2 Monate her und ich bin mittlerweile schon viel weiter.
Ich hab mittlerweise eine wirklich effiziente Möglichkeit gefunden dies umzusetzen u. brauch nur noch gewisse Mikrofunktionszugriffe wie Pixelertsellung u. HZ-Frequenztonerstellung!
Trolling?(etwas unhöflich von dir) Nein, ich bin halt erst seit etwa nem' halben Jahr beim Proggen, weshalb ich Threads erstelle wie diese hier Und die nicht um mein
geistigen Horizont zu erweitern, darin ob das was ich vorhab möglich ist,
sondern um Methoden zu finden dieses Möglich zu machen,
aber ich erstellte dieses Thema ja nicht um mich für irgendwas zu rechtferigen,...

also bitte zurück zum eigentlichen Thema

EDIT: Rechtschreibedit und so

Fytch

sC++k schrieb:

Du irrst in deiner Vermutung, denn dieses Model hab ich schon längst verworfen. Ich benutze nun "Map" o. "Unordered Map".
Dieser Thread ist schon 2 Monate her bin mittlerweile schon viel weiter.
Ich hab mittlerweise eine wirklich effiziente Möglichkeit gefunden dies umzusetzen u. brauch nur noch gewisse Mikrofunktionszugriffe wie Pixelertsellung u. HZ-Frequenztonerstellung!
Trolling?(etwas unhöflich von dir) Nein, ich bin halt erst seit etwa nem' halben Jahr beim Proggen, weshalb ich Threads erstelle wie diese hier nicht um mein
geistigen Horizont zu erweitern, darin ob was ich vorhab möglich ist,
sondern um Methoden zu finden dies Möglich zu machen,
aber ich erstellte dieses Thema ja nicht um mich für irgendwas zu rechtferigen,...

also bitte zurück zum eigentlichen Thema

eine bibliothek um einzelne pixel zeichnen zu können? sfml.
von diesen "wirklich effizienten möglichkeiten" würde ich zu gerne mal hören, lol.
sind dir octrees ein begriff und hast du wenigstens diese implementiert? lauft der render-vorgang komplett auf der cpu und werden nur die pixeldaten an die grafikkarte gegeben? ist dein algorithmus parallelisierbar?

sC++k

dot schrieb:

sC++k schrieb:

dot schrieb:

Das große mit Voxeldaten ist, dass dir selbst bei trivialen Modellen sofort der Speicher ausgeht, wenn du nicht irgendwelche schlauen Methoden zur Komprimierung hast...

"Komprimierung" in Bezug worauf?

Auf deine Voxeldaten? Ein einziges 512³ RGB Volumen braucht unkomprimiert bereits 384 MB...

"512³ RGB Volumen"? Meinst du damit was theorisch 512 Texturen mit einer Aufflösung von 512&515 Pixeln in Voxeln umgerechnet sind, wenn ja dann wären
384 MB doch recht akzeptabel.
Und ja, ich glaube ich hab eine recht vernünftige Methode !

dot

sC++k schrieb:

dot schrieb:

sC++k schrieb:

dot schrieb:

Das große mit Voxeldaten ist, dass dir selbst bei trivialen Modellen sofort der Speicher ausgeht, wenn du nicht irgendwelche schlauen Methoden zur Komprimierung hast...

"Komprimierung" in Bezug worauf?

Auf deine Voxeldaten? Ein einziges 512³ RGB Volumen braucht unkomprimiert bereits 384 MB...

"512³ RGB Volumen"? Meinst du damit was theorisch 512 Texturen mit einer Aufflösung von 512&515 Pixeln in Voxeln umgerechnet sind, wenn ja dann wären
384 MB doch recht akzeptabel.
Und ja, ich glaube ich hab eine recht vernünftige Methode !

Ja sowas mein ich und wenn du das für akzeptabel hältst, dann hast du nicht gründlich genug drüber nachgedacht...

Fytch

sC++k schrieb:

dot schrieb:

sC++k schrieb:

dot schrieb:

Das große mit Voxeldaten ist, dass dir selbst bei trivialen Modellen sofort der Speicher ausgeht, wenn du nicht irgendwelche schlauen Methoden zur Komprimierung hast...

"Komprimierung" in Bezug worauf?

Auf deine Voxeldaten? Ein einziges 512³ RGB Volumen braucht unkomprimiert bereits 384 MB...

"512³ RGB Volumen"? Meinst du damit was theorisch 512 Texturen mit einer Aufflösung von 512&515 Pixeln in Voxeln umgerechnet sind, wenn ja dann wären
384 MB doch recht akzeptabel.
Und ja, ich glaube ich hab eine recht vernünftige Methode !

damit ist ein modell gemeint, welches 512x512x512 voxel gross ist und eine farbtiefe von 24 bit hat (in wirklichkeit düften das aber noch mehr sein nämlich 32 bit für den alpha-kanal). also wären wir bei 512mb für so ein kleines modell. hast du irgendwie vor deine modelle zu komprimieren oder willst du die während dem rendern von der festplatte lesen? bedenke: die rechnung eben war nur für so einen winzigen würfel mit 512 kantenlänge. grössere objekte brauchen kubisch mehr speicher.

ot:
erst beim genauen hinschauen ist mir diese passage aufgefallen:

sC++k schrieb:

hustbaer schrieb:

Wir können nicht h(H )ellsehn, weisste...

finde ich lollig wie du die rechtschreibung anderer verbesserst aber selbst kryptisch falsch schreibst und die vier kasus nicht korrekt anwenden kannst. *no offence*

ps.: hast du zufällig etwas mit dem forumsnutzer "lymogry" gemeinsam?

edit:
aber der thread hier ist relativ aktuell:
http://www.c-plusplus.net/forum/322713
all deine if-statements sind redunant da der boolsche wert immer true ist. wird noch lustig hier.

hustbaer

sC++k schrieb:

hustbaer schrieb:

sC++k schrieb:

- ...wenn nicht sogar absolut systemunabhängig,...

Das ist kein Satz, da fehlt was. Das was du suchst gibt's aber nicht (komplett systemunabhängig).

Verstehe, dann halt möglichst multiplattformfähig.
Aber gibt es denn keinen Maschinencode(-Sprache) der auf jeder Maschine läuft!
Zum Satzbau:
Ich weiß, klingt etwas wirr, ist aber glaub' ich tatsächlich einer,
wenn auch ein fragwürdiger!

Nein, ist es sicher nicht.
"Wenn nicht sogar" bezieht sich auf irgendwas vorher. Da ist aber nix vorher.
"Schnell, wenn nicht sogar der Schnellste" macht Sinn. "Portierbar, wenn nicht sogar systemunabhängig" hätte auch Sinn gemacht. Einfach nur "wenn nicht sogar systemunabhängig" ist einfach nur Unsinn.

sC++k schrieb:

Ach, komm'! Bist du schlecht drauf gewesen als du das geschrieben hast o. warste verträumt?
Ist doch offensichtlich dass diese imaginäre Funktion einen Pixel auf dem Screen erzeugen soll
und die dadrüber einen Ton auf Wiedergabegerät.

Und ab jetzt war klar dass du ein arroganter Idiot/Troll bist.

Du hast keinen Plan von dem was du schreibst. Daher denke ich, wäre es günstig wenn du einfach in ganzen Deutschen Sätzen hinschreiben würdest was du haben willst. Statt irgendwelche erfundenen Funktionsnamen, die wohl deiner Meinung nach aussagekräftig sein sollen.

Statt dessen beleibigst du aber Leute die nachfragen oder dir irgendwas erklären wollen, oder machst dich über sie lustig.

Auch gut. Viel Erfolg in deinem restlichen Leben dann noch!

sC++k

[/quote]eine bibliothek um einzelne pixel zeichnen zu können? sfml.[/quote]
Schon probiert ist aber aber meines wissens nach keine um Frequenztöne zu erzeugen.
In der WinApi geht das ( Tutorial: http://www.youtube.com/watch?v=j9fZrYKTJ0Y), aber ich schrieb ja nicht um sonst "möglichst multiplattformfähig"

von diesen "wirklich effizienten möglichkeiten" würde ich zu gerne mal hören, lol. sind dir octrees ein begriff

1. Sei bitte nicht so voreingenommen
2. "octrees" war mir bis ich eben googelte kein Begriff,
aber auf das Konzept kam ich auch schon ist aber im Verglech zu meinem
jetzigen (wenn Konzeppt richtig verstanden )zu uneffizient.

lauft der render-vorgang komplett auf der cpu

Graka meines wissens nach absolut nicht notwendig, aber vielleicht optional , mal schauen!

ist dein algorithmus parallelisierbar?

Wenn du damit meinst dass paralell auch Physik, Animation, Spielelogik u. co. berechnet werden können, dann ja!
Aber Physik, Animation, Spielelogik sind in der Darstellung selbstverständlich nicht unlimitierbars, so dass bei zu viel Nebenzeugs die FPS auch einbrechen können.

dot

sC++k schrieb:

von diesen "wirklich effizienten möglichkeiten" würde ich zu gerne mal hören, lol. sind dir octrees ein begriff

1. Sei bitte nicht so voreingenommen
2. "octrees" war mir bis ich eben googelte kein Begriff,
aber auf das Konzept kam ich auch schon ist aber im Verglech zu meinem
jetzigen (wenn Konzeppt richtig verstanden )zu uneffizient.

Wie genau funktioniert denn deine effiziente Komprimierung? Hast du vor, diese zu veröffentlichen? Ich bin mir sicher, eine Menge Leute (mich eingeschlossen) würden sich dafür interessieren...

sC++k schrieb:

ist dein algorithmus parallelisierbar?

Wenn du damit meinst dass paralell auch Physik, Animation, Spielelogik u. co. berechnet werden können, dann ja!
Aber Physik, Animation, Spielelogik sind in der Darstellung selbstverständlich nicht unlimitierbars, so dass bei zu viel Nebenzeugs die FPS auch einbrechen können.

Er meint wohl, ob dein Rendering Algorithmus an sich parallelisierbar ist, denn das ist der Schlüssel zu Performance...

sC++k

dot schrieb:

sC++k schrieb:

dot schrieb:

sC++k schrieb:

dot schrieb:

Das große mit Voxeldaten ist, dass dir selbst bei trivialen Modellen sofort der Speicher ausgeht, wenn du nicht irgendwelche schlauen Methoden zur Komprimierung hast...

"Komprimierung" in Bezug worauf?

Auf deine Voxeldaten? Ein einziges 512³ RGB Volumen braucht unkomprimiert bereits 384 MB...

"512³ RGB Volumen"? Meinst du damit was theorisch 512 Texturen mit einer Aufflösung von 512&515 Pixeln in Voxeln umgerechnet sind, wenn ja dann wären
384 MB doch recht akzeptabel.
Und ja, ich glaube ich hab eine recht vernünftige Methode !

Ja sowas mein ich und wenn du das für akzeptabel hältst, dann hast du nicht gründlich genug drüber nachgedacht...

Na ja, man könnte mit etwa einer Millionen Voxels schon circa ein kleines grafisch anspruchsvolles Spiel machen. Kommt natürlich drauf an welches ,
aber auch relativ detailierte große Games sollten möglich sein, da ja keine Texturen mehr in den Ram oder in den Code müssen denk' ich sollte sich das im Vergleich zur Vertex-UV-Map-basierten "old-school-GE" im Speicheranspruch ungefehr auf das gleiche Resultat führen.

junge junge du versuchst hier irgendwas hinzubekommen was selbst John Carmack nicht schafft. du wirst nie im leben 60 fps damit hinbekommen

dot

Dir ist schon klar, dass bei einer Auflösung von 1920×1080 allein der Bildschirm mehr als 2 Millionen Pixel hat!? Außerdem kannst du so nicht rechnen, zumindest nicht, wenn wir von Voxeln reden. Vielleicht meinst du ja etwas anders, wenn du von "Voxel" sprichst, normalerweise versteht man darunter jedenfalls ein Sample eines dreidimensionalen Signals. Eine Million Voxel ist gerade mal ein 100×100×100 Würfel...

Aber was auch immer, ich will dich nicht länger mit dummen Fragen davon abhalten, die Computergrafik zu revolutionieren: Schau dir vielleicht mal Pixeltoaster an...

sC++k

..."an sich" parallelisierbar... ...Schlüssel zu Performance...

Was heißt "an sich". Bitte konkretisieren!

Engine veröffentlchen?

Sicher, wenn sie was wird :p. Ich hab aber noch viel zu tun in Bezug auf den eingebauten Music Sequenzer u. gewisse Algoritmen für Physik u. co,
also kann ich jetzt erstmal auch nichts weiter versprechen.

dot

sC++k schrieb:

..."an sich" parallelisierbar... ...Schlüssel zu Performance...

Was heißt "an sich". Bitte konkretisieren!

Das heißt konkret, dass der Renderingvorgang auf sehr viele Prozessoren verteilt werden kann. Wenn dein Algorithmus das nicht erlaubt, dann ist er zumindest nicht sehr zukunftsträchtig...

Vielleicht willst du ja auch mal einen Blick auf das werfen: http://www.atomontage.com/

sC++k

Vielleicht meinst du ja etwas anders, wenn du von "Voxel" sprichst, normalerweise versteht man darunter jedenfalls ein Sample eines dreidimensionalen Signals. Eine Million Voxel ist gerade mal ein 100×100×100 Würfel...

Meinst du damit dass Voxels "in" dem Würfel drin sind wo man sie nicht sieht.
Ansonsten hängt es ja davon man ab wie groß der Würfel ist und damit einhergehen auch die Detailiertheit. Und die Verhältnisse somit ja selbst einstellbar, so dass ein Würfel praktisch schon ab 26 Voxel(EDIT!) gezeichnet werden kann(in der kleinstmöglich Einheit) u. dieser trotzdem nah von der Cam herangezoomt werden kann, durch spezziele Algoritmen eingenommen Auflösungs-simultane Licht u. Schatten-Qualität.

Allgemeiner Nachteil: Umso großer Objekte sind, umso mehr Voxels werden auch benötigt, also kann ein Objekt nicht höher aufgelößt sein als das andere in einer Szene, weil die Verhältnisse sonst nicht mehr stimmen würden, was bedeutet, dass man sich auf eine mehr o. minder einheitliche Voxelauflösung einigen müsste.
Ob ich was anderes meine als Voxels ist/bleibt vielleicht Interpretationssache

Aber was auch immer, ich will dich nicht länger mit dummen Fragen davon abhalten, die Computergrafik zu revolutionieren: Schau dir vielleicht mal Pixeltoaster an...

Sieht ganz interesannt aus, nur gibt's scheinbar noch keine Wiki dazu u. scheint entsprechend der Bugreport noch relativ verbuggt zu sein!