Speicherverbrauch bei ungewöhnlicher Heightmap



  • Guten Abend.
    Es nimmt mich nur Wunder, aber habt ihr schon mal gemessen, wie viel Speicher eine kleine Heightmap (256*256) verbraucht? Kann mir jemand mal Zahlen seiner Implementation (ich hasse dieses Wort langsam 😉 ) posten? Das wäre echt nett... ich hab eben das Gefühl, dass es bei mir ein wenig zu viel verbraucht... 🤡



  • 256*256 Byte?...
    Naja, kommt halt auf die Auflösung an..



  • 64kb hälst du für viel?



  • Sorry, hier kann mal jemand schliessen. Ich hatte eigentlich den Speicherverbrauch zur Laufzeit gemeint, aber hatte sowieso am falschen Ort gemessen. Hatte einen Verbrauch von 34MB, aber das war nicht die Map 🤡 .


  • Mod

    wenn du mit dem vertexshader aus einer heightmap ausließt, könntest du auf ca 1byte/vertex kommen, je nach overhead und mapformat auch auf 1/2byte pro vertex bis ..byte pro vertex.

    rapso->greets();



  • aber nur mit ner bruteforce lösung..


  • Mod

    life schrieb:

    aber nur mit ner bruteforce lösung..

    hier geht's um worst case bei vertex/pixel. sonst wären die algorithmen überhaupt nicht vergleichbar und darüber muss man nicht anfangen zu debatieren, dafür gibt es doch hier genug c++ vs java,pascal,... threads 😃

    rapso->greets();



  • irgendwie reden wir grad aneinander vorbei?!

    hier geht's um worst case bei vertex/pixel

    worst case? hu? Was ist an 1 Byte pro vertex / heightmapeintrag worstcase?

    sonst wären die algorithmen überhaupt nicht vergleichbar und darüber muss man nicht anfangen zu debatieren, dafür gibt es doch hier genug c++ vs java,pascal,... threads

    was für algorthimen? was hat das mit c++ vs java oder sonstwas zutun? oO

    Eigentlich meinte ich nur, dass das mit dem 1 Byte pro vertex nur stimmt, wenn man das ganze brutforcemäßig macht (also pro heightmapeintrag 1 vertex). Normal macht man es ja zumindest so, dass man bei weit entfernten punkten, weniger vertices pro eintrag benutzt und damit verbräuchte man automatisch mehr speicher pro vertex..


  • Mod

    life schrieb:

    irgendwie reden wir grad aneinander vorbei?!

    hier geht's um worst case bei vertex/pixel

    worst case? hu? Was ist an 1 Byte pro vertex / heightmapeintrag worstcase?

    bei verfahren die das byte der heightmap pro vertex mappen. (z.b. displacementmapping mit VS3.0)

    life schrieb:

    sonst wären die algorithmen überhaupt nicht vergleichbar und darüber muss man nicht anfangen zu debatieren, dafür gibt es doch hier genug c++ vs java,pascal,... threads

    was für algorthimen?

    heightmap algorithmen

    life schrieb:

    was hat das mit c++ vs java oder sonstwas zutun? oO

    ist genauso abwegig wie jetzt einzubringen "hey, moment, es gibt doch millionen algorithmen die von 0.02bit/vertex bis 1kbyte/vertex es bringen können."

    life schrieb:

    Eigentlich meinte ich nur, dass das mit dem 1 Byte pro vertex nur stimmt, wenn man das ganze brutforcemäßig macht (also pro heightmapeintrag 1 vertex). Normal macht man es ja zumindest so, dass man bei weit entfernten punkten, weniger vertices pro eintrag benutzt und damit verbräuchte man automatisch mehr speicher pro vertex..

    das muss nicht automatisch so sein, hängt vom algo ab.

    aber es ist klar, dass man LODs benutzen kann, aber darum ging es nicht wirklich, denn wenn du das einwirfst, kann ich sagen, dass man bezierpatches nutzt, diese haben in der ferne 1byte/vertex und in der nächeren umgebung 0.00..byte/vertex (je nachdem wie hoch man dazwischen tesseliert) usw. und wenn wir jetzt die speichergrößen der verschiedenen algorithmen und dazu noch ihre verschiedenen implementierungen vermischen, dann ist die antwort 1byte bis maximum was der pc hergibt an speicherverbrauch 😃

    rapso->greets();



  • rapso schrieb:

    bei verfahren die das byte der heightmap pro vertex mappen. (z.b. displacementmapping mit VS3.0)

    wenn ein byte der heightmap ein vertex darstellt, ist es logisch, dass es nachher 1 byte pro vertex ist :ugly:

    ist genauso abwegig wie jetzt einzubringen "hey, moment, es gibt doch millionen algorithmen die von 0.02bit/vertex bis 1kbyte/vertex es bringen können."

    ich find das nicht so abwegig. Zumal 1kbyte/vertex auch schon deutlich worse(r) als dein worstcase 1 byte/vertex ist 😛
    Unsinnig finde ich es eher, den speicherverbrauch relativ zu der Anzahl der vertices zu messsen. 1 Byte pro heightmapentry ist sehr viel logischer und richtiger als zu behaupten 1 byte pro vertex (da das vom algo abhängt)..

    das muss nicht automatisch so sein, hängt vom algo ab.

    aber es ist klar, dass man LODs benutzen kann, aber darum ging es nicht wirklich, denn wenn du das einwirfst, kann ich sagen, dass man bezierpatches nutzt, diese haben in der ferne 1byte/vertex und in der nächeren umgebung 0.00..byte/vertex (je nachdem wie hoch man dazwischen tesseliert) usw. und wenn wir jetzt die speichergrößen der verschiedenen algorithmen und dazu noch ihre verschiedenen implementierungen vermischen, dann ist die antwort 1byte bis maximum was der pc hergibt an speicherverbrauch 😃

    rapso->greets();

    eigentlich gings hier nur um die heightmap bis du mit deinen vertices angefangen hast >_<


  • Mod

    [quote="life"]

    rapso schrieb:

    bei verfahren die das byte der heightmap pro vertex mappen. (z.b. displacementmapping mit VS3.0)

    wenn ein byte der heightmap ein vertex darstellt, ist es logisch, dass es nachher 1 byte pro vertex ist :unknownicon: [quote]
    genau so logisch wie 4bit/2byte/4byte/16byte/24byte/32byte/... pro vertex, je nach implementation

    ist genauso abwegig wie jetzt einzubringen "hey, moment, es gibt doch millionen algorithmen die von 0.02bit/vertex bis 1kbyte/vertex es bringen können."

    ich find das nicht so abwegig. Zumal 1kbyte/vertex auch schon deutlich worse(r) als dein worstcase 1 byte/vertex ist 😛
    Unsinnig finde ich es eher, den speicherverbrauch relativ zu der Anzahl der vertices zu messsen. 1 Byte pro heightmapentry ist sehr viel logischer und richtiger als zu behaupten 1 byte pro vertex (da das vom algo abhängt)..

    es ist nur unsinnig, falls man noch LODs einbezieht, ansonsten hat man 1pixel/vertex und in dem falle ist es äquivalent von verticen und pixeln zu sprechen. aber es wäre unsinnig noch LODs einzubeziehen, da dann auch noch fragen der qualität usw verglichen werden müßten und dann würde man noch schnell auf das abwegen der performance/qualität/speicherverbrauch kommen.

    eigentlich gings hier nur um die heightmap bis du mit deinen vertices angefangen hast >_<

    es ging um vertices als er fragte "Kann mir jemand mal Zahlen seiner Implementation...", da ich nicht meinen alten voxelrenderer rauskramen wollte um nachzusehen, daher nahm ich übliche implementationen die auf vertices setzen.

    rapso->greets();



  • es ging um vertices als er fragte "Kann mir jemand mal Zahlen seiner Implementation...", da ich nicht meinen alten voxelrenderer rauskramen wollte um nachzusehen, daher nahm ich übliche implementationen die auf vertices setzen.

    Implementation, nicht darstellung.. Er hat nichteinmal geschrieben, dass er die heightmap darstellen will. Es ging nur um die Speicherung der Daten der Heightmap ("habt ihr schon mal gemessen, wie viel Speicher eine kleine Heightmap (256*256) verbraucht?")..


  • Mod

    life schrieb:

    es ging um vertices als er fragte "Kann mir jemand mal Zahlen seiner Implementation...", da ich nicht meinen alten voxelrenderer rauskramen wollte um nachzusehen, daher nahm ich übliche implementationen die auf vertices setzen.

    Implementation, nicht darstellung.. Er hat nichteinmal geschrieben, dass er die heightmap darstellen will. Es ging nur um die Speicherung der Daten der Heightmap ("habt ihr schon mal gemessen, wie viel Speicher eine kleine Heightmap (256*256) verbraucht?")..

    wo steht dass meine implementation die ich für die darstellung nutze nicht erwünscht ist?

    rapso->greets();



  • rapso schrieb:

    wo steht dass meine implementation [der heightmap] die ich für die darstellung nutze nicht erwünscht ist?

    hab ich nicht geschrieben. Aber es ging um den Speicherverbrauch der Implementation der Heightmap und nicht um die Darstellung der Heightmap --> Es ist unsinning den Speicherverbrauch relativ zu der vertex anzahl zu beschreiben, da die darstellung für die eigentliche frage (wieviel speicher verbraucht die heightmap?) völlig irrelavent ist.


  • Mod

    life schrieb:

    rapso schrieb:

    wo steht dass meine implementation [der heightmap] die ich für die darstellung nutze nicht erwünscht ist?

    hab ich nicht geschrieben. Aber es ging um den Speicherverbrauch der Implementation der Heightmap und nicht um die Darstellung der Heightmap --> Es ist unsinning den Speicherverbrauch relativ zu der vertex anzahl zu beschreiben, da die darstellung für die eigentliche frage (wieviel speicher verbraucht die heightmap?) völlig irrelavent ist.

    LODs sind irrelevant, weil man dann noch qualitätsvergleiche anstellen müßte, also _muss_ man einen Fall annehmen, der immer gehen sollte (mit jeder implementierung), und zwar dass das ganze terrain mit 1vertex/1pixel dargestellt wird und für diesen fall sollte man den speicherverbrauch angeben der wegen verschiedener implementierungen trotzdem variieren kann.
    ansonsten kann ich mit LODs sicherlich jedes terrain auf 1byte speicherverbrauch bekommen und die frage der qualität wäre nun das, was man meiner meinung nach raushalten sollte aus einem gespräch über den speicherverbrauch, weil es dann sehr in subjektivität abgleitet.

    rapso->greets();



  • Ohh, mal was Neues hier... 😎

    Bye, TGGC (Denken, und gut ist.)



  • ER IST WIEDER DA 👍



  • rapso schrieb:

    life schrieb:

    rapso schrieb:

    wo steht dass meine implementation [der heightmap] die ich für die darstellung nutze nicht erwünscht ist?

    hab ich nicht geschrieben. Aber es ging um den Speicherverbrauch der Implementation der Heightmap und nicht um die Darstellung der Heightmap --> Es ist unsinning den Speicherverbrauch relativ zu der vertex anzahl zu beschreiben, da die darstellung für die eigentliche frage (wieviel speicher verbraucht die heightmap?) völlig irrelavent ist.

    LODs sind irrelevant, weil man dann noch qualitätsvergleiche anstellen müßte, also _muss_ man einen Fall annehmen, der immer gehen sollte (mit jeder implementierung), und zwar dass das ganze terrain mit 1vertex/1pixel dargestellt wird und für diesen fall sollte man den speicherverbrauch angeben der wegen verschiedener implementierungen trotzdem variieren kann.
    ansonsten kann ich mit LODs sicherlich jedes terrain auf 1byte speicherverbrauch bekommen und die frage der qualität wäre nun das, was man meiner meinung nach raushalten sollte aus einem gespräch über den speicherverbrauch, weil es dann sehr in subjektivität abgleitet.

    rapso->greets();

    bitte lesen was ich geschrieben habe (und du gequoted), nochmal nachdenken und dann darfste nochmal posten thx 🙂


  • Mod

    naja, irgendwann siehst du ein dass ein vergleich nur bei volldarstellung der heightmap innerhalb einer implementation sinn macht.

    rapso->greets();



  • vielleicht lernst du irgendwann mal einen fehler einzugestehen, anstatt nur zu versuchen von ihm abzulenken...


Anmelden zum Antworten