könnte mir das sogar vorstellen...

[Karlos2]

je länger ich darüber nachdenke....
ich bin zwar kein Grafik-Engine-Entwickler, aber:
man muss ja "nur" eine passende Datenstruktur finden, die praktisch den LOD der Modelle dynamisch und 100% skalierbar errechnet.. d.h.: Der Input: Punkt-Modell und abstand zum Betrachter -> _sein "suchalgorithmus" -> output: reduziertes punktmodell, und das alles in liniearer Rechenzeit zur Auflösung des Outputs. fertig.

was spricht denn dagegen, dass wenn man bei z.B. 2-fachem Abstand auch nur jeden 2. punkt des elephanten nimmt? natürlich muss man die vorher einmal so anordnen, dass sie leicht zu extrahieren sind?

gruß

[AnnonymerAnalphabet]

Ich glaube, was Du meinst sind optimierten Raycasting-Algorithmen, etwa VRC http://en.wikipedia.org/wiki/Volume_ray_casting.

Oder habe ich Dich hier falsch verstanden.

Die sind nicht neu, allerdings
- sehr Speicherintensiv (!)
- verglichen mit Polygonen sehr rechenintensiv
- keine Animationen möglich

und genau diese Nachteile hat sein Verfahren (angeblich) nicht ...

[niabot]

Ja. Genau das dachte ich mir auch. Nur sieht man in keiner der Demos einen dieser angeblichen Vorteile. Was ich hier sehe ist eine Kombination aus Instancing und LOD. Damit kann man wirklich solche Welten zusammenbauen und in Echtzeit rendern. Einziges Problem: Es ist nicht "Unlimeted Detail" sondern "Unlimited Repeated Detail" ;-)

[Karlos2]

Volume Ray Casting meine ich eigentlich nicht..

was ich meine ist, anschaulich dargestellt:
wenn man z.b. sprite als gegner hat (duke nukem 3d ;)) dann könnte man ja die sprites entweder zuerst skalieren (mit interpolation) auf die größe die proportional ist zum abstand bis zum betrachter (camera) oder aber man könnte einfach einen reduzierten speicherzugriff nehmen. z.b. nur jeden 2. pixel des Gegners, oder jeden vierten, je nachdem, wie weit es von einem selbst entfernt ist.... wenn ein sprite gaaanz weit entfernt ist, dann ist das vllt. nur ein pixel, z.b. der mittlere.. => viel schneller, da man nicht über das bild iterieren muss.

bei sprites geht es ja relativ einfach, weil die einfach salopp-gesagt in eine array gespeichert werden können.
und nun "einfach" so ein "array" jedoch für 3d objekte finden. fertig?!? was denkst ihr?

[grmpf]

Nochens... Detail != Anzahl von Modellen

[grmpf]

Genau in den Bahnen hab ich auch gedacht.

Kleines 1x1 der Effizienz... lass weg, was Du nicht brauchst.
Und da es nun mal auf Datenwolken basiert, die erst mal an sich sogar ohne Farbinfo auskommen, sparst Du dir jede Menge Arbeit.

1. Atome wählen
2. Farbe dazu
3. Fertig.

[niabot]

Es wäre aber für den praktischen Einsatz essentiell das es nicht nur 20 oder 50 verschiedene Modelle sein können. Geht das nicht, hat man etwas tolles, aber praktisch nutzloses geschaffen. Ist in etwa so als wenn man sich eine Verteidigungsanlage gegen Mirarus baut, die auch super funktioniert. Dumm nur, dass noch nie jemand einem Miraru begegnet ist. ^^

[grmpf]

Ehrlich gesagt seh ich da kein großes Problem, wenn die engine nur 20-50 Modelle zur gleichen Zeit benutzt, können die andren doch nachgeladen werden.


Ich find es schade, dass bei dir nicht sein kann, was nicht sein darf.
Das wirkt doch sehr wie ein Fünfjähriger, der mit dem Fuß aufstampft.
Oder gar wie die Diskussionen über die ersten Eisenbahnen -> Geschwindigkeiten über 20MPH sind tödlich etc.

Statt ständig zu mutmaßen, was nicht geht, wart doch einfach ab.

[niabot]

Ich reagiere nur auf das was ich gesehen habe und die Aussagen die im Raum stehen, aber nicht untermauert sind. Das was ist sehe ist sehr mau und meiner persönlichen Meinung nach nicht praxistauglich, da zu sehr eingeschränkt. Da wir diesen Stand der Technik bereits vor fünf Jahren schon hatten, es danach aber unlösbare Probleme gab (z.B. Animation von unendlichen Details) und solche Dinge in den Präsentationen jedes mal fehlten, gehe ich schlichtweg erst einmal davon aus das hier nichts passiert ist, was diese Technik auf Spiele übertragbar machen würde.

[stuepfnick]

Karlos2 schrieb:
--------------------------------------------------------------------------------
> Volume Ray Casting meine ich eigentlich nicht..
>
> was ich meine ist, anschaulich dargestellt:
> wenn man z.b. sprite als gegner hat (duke nukem 3d ;)) dann könnte man ja
> die sprites entweder zuerst skalieren (mit interpolation) auf die größe die
> proportional ist zum abstand bis zum betrachter (camera) oder aber man
> könnte einfach einen reduzierten speicherzugriff nehmen. z.b. nur jeden 2.
> pixel des Gegners, oder jeden vierten, je nachdem, wie weit es von einem
> selbst entfernt ist.... wenn ein sprite gaaanz weit entfernt ist, dann ist
> das vllt. nur ein pixel, z.b. der mittlere.. => viel schneller, da man
> nicht über das bild iterieren muss.
>
> bei sprites geht es ja relativ einfach, weil die einfach salopp-gesagt in
> eine array gespeichert werden können.
> und nun "einfach" so ein "array" jedoch für 3d objekte finden. fertig?!?
> was denkst ihr?

Ganz genau das denke ich auch. Ich schätze mal, das ist eines der Geheimnisse. Somit rennt das ganze VIEL schneller, da man keinen Durschnitt von mehreren Atomen berechnen muss, bzw. man muss eben auch nicht in verschiedenen Detailstufen speichern (Octree), eben nur im hohen Detailgrad und da nur die Oberflächen und diese sind komprimiert.

http://grenouillebouillie.wordpress.com/2011/11/21/in-defense-of-euclideons-unlimited-details-claims/