Wie lange noch bis zum puren RT ohne Textur?

[nonharderware]

Hallo,

ich weiß nicht wohin es gehört - daher mal ein eigener Thread.

Ich möchte wissen, wie lange wir noch mit Texturen auskommen müssen.
Dieses Konzept ist zwar nett, aber eben mMn. genauso limitiert und eine Zwischenlösung wie es seinerzeit 2D Bitmaps in einer 3D Umgebung waren (3D-FPS der frühen 1990er bis vor Quake: DOOM etc.).

Also wann gibt es Konzepte, Rechenkraft und flüssiges Rendering von einfach hinreichend genau modellierten Polygonen, die dem einfallenden Strahl einfach einen Farbwert mitgeben und der Rest errechnet sich aus Licht und Schatten - ohne, dass hier irgendeine aus mehreren Pixel zusammenhängende Textur-"Haut" benötigt wird?

Vor allem sehr interessant für realistische Schadensmodelle etc.

Also: Was braucht es und wie lange noch? :D

[Exxtreme]

Ähhhh, wie stellst du dir das vor ohne Texturen? Willst du weisse Polygone beleuchten? Dann wirst du auch weisse Polygone bekommen.

[Tesseract]

man kann materialeigenschaften nicht allein durch geometrie reproduzieren und eine textur ist im prinzip ein spezialfall einer materialeigenschaft. außerdem ist 3D modeling wesentlich durch arbeitszeit limitiert und extreme geometriedetails viel aufwand.

[Ganon]

Naja, dass eine Szene aus Polygonen besteht und dass wir die Materialeigenschaften mittels Texturen beschreiben ist ja kein Naturgesetz. Es ist halt das was wir bisher am effizientesten umsetzen können.

Theoretisch wäre es auch möglich einen Laserscan in eine Punktwolke umzuwandeln und jedem Punkt seine physikalischen Eigenschaften zu geben. Das kriegen wir aber aktuell nicht effizient hin (in mehrere Richtungen).

[Tesseract]

der offensichtliche nächste schritt sind neutral materials. der modellinput kann da ein scan, eine klassische textur, shader oder kombinationen daraus sein, aber am ende bekommt dann trotzdem wieder eine art materialeigenschaft raus die man auf die surface "klebt", auch wenn es keine klassische textur ist die man wie ein bild ansehen kann. wenn das nicht als textur zählt hätte man keine texturen mehr aber das ist eine recht willkührliche linie.

[Rooter]

Ich vermute er will die Polygon-Anzahl so weit hochfahren, dass man 1 Polygon/Pixel hat.
Evtl. wird diese Vorgehensweise nie sinnvoll sein. Ich habe bei dem Thema aber nur Halbwissen. X-D

MfG
Rooter

[Tesseract]

das ist seit jahren schon in vielen situationen der fall, oft auch mehr als eines pro pixel. das ändert aber nichts grundlegendes daran wie polygone texturiert werden.

[Gast]

Ähm was hat das eine mit dem anderen zu tun?
Raytracing benötigt genauso Texturen. Freilich könntest du nur einfarbige Polygone rendern, und wenn jedes Polygon 1 Pixel groß ist würdest du mit diesen wieder quasi eine Textur simulieren. Hat nur überhaupt nichts mit Raytracing oder Rastern zu tun, das kannst du mit beiden Techniken machen.

[derF]

Klingt für mich wie Voxel.

https://en.wikipedia.org/wiki/Teardown_(video_game)

[Platos]

man kann materialeigenschaften nicht allein durch geometrie reproduzieren und eine textur ist im prinzip ein spezialfall einer materialeigenschaft. außerdem ist 3D modeling wesentlich durch arbeitszeit limitiert und extreme geometriedetails viel aufwand.

In Zukunft wird sowas doch einfach generiert werden mittels AI. Also man beschreibt, was man will und die AI erstellt Polygone + die dazugehörige Textur einfach innerhalb von wenigen Minuten bei entsprechender Rechenleistung (die verglichen mit Arbeitsstunden spotbillig ist und evtl sogar somit Grafikkartenpreise noch weiter in die Höhe treibt).

[Ganon]

Trotzdem sind im Regelfall Texturen bzw. "2D"-Materialinformationen bei Raytracing auch nur eine Art Shortcut. Raytracer können auch durchaus mit Volumen umgehen und die resultierende Farbe ist nicht durch irgendeine Textur bestimmt, sondern von den Volumeneigenschaften des Objekts.

Als Beispiel einfach mal ein Prisma im LuxCore Renderer:

https://i.redd.it/eor0nctj0un11.png

Dass man das nicht auch für die Farbe einer Ader, die sich auf der menschlichen Haut abzeichnet, benutzt ist schlicht eine Sache von Rechenleistung und Aufwand. Geht halt anders schneller, wenn auch nicht 100%ig genau. Gerade in der Hinsicht "realistische Schadensmodelle", was angesprochen wurde.

[Tesseract]

In Zukunft wird sowas doch einfach generiert werden mittels AI. Also man beschreibt, was man will und die AI erstellt Polygone + die dazugehörige Textur einfach innerhalb von wenigen Minuten bei entsprechender Rechenleistung (die verglichen mit Arbeitsstunden spotbillig ist und evtl sogar somit Grafikkartenpreise noch weiter in die Höhe treibt).

wo soll das herkommen? generative modelle brauchen tonnenweise beispiele zum trainieren.
wie gesagt: man kann materialien trainieren wobei die inputs aus shadern/texturen/etc. kommen können oder aus der realen welt mittels scan oder was auch immer. am ende braucht das material aber trotzdem irgendeine art von "textur" die das NN füttert damit man das bekommt was man haben will, auch wenn das keine textur im klassischen sinn ist sondern parameter.
generative landschaften sind dann wieder ein eigenes thema. man kann z.B. ein NN trainieren das bäume generiert wo jeder etwas anders aussieht und realistisch in die landschaft eingebettet ist aber das ist alles sehr speziell. was du sicher nicht machen kannst ist eine beschreibung eintippen und irgendeine nebulöse super AI freestylet dir aus dem nichts ein halbes spiel. da fehlen so viele schritte dass das völlige utopie ist.

[Rooter]

Gab vor x Jahren mal so eine Vapor-Ware, die Szenen mit zig Millionen Polygone flüssig rendern konnte. Die Polygon-Modelle waren so hochauflösend, dass man keine Texturen brauchte und konnte trotzdem auf jedes Sandkorn zoomen. Gab ein paar Videos dazu. Hab aber den Namen vergessen. :uponder:

MfG
Rooter

[Ganon]

Unlimited Detail hieß das.

[Cami]

Ich habe einfach mal die ganze Seite aus dem Forum in Deepseek geschmissen und mal mit Websearch und Deepthink drüber nachdenken lassen. ^^

Thinking english:
Okay, let me try to figure out how to approach this. The user is asking about the feasibility and current status of pure ray tracing (RT) without textures. They want to know if it's possible today and how realistic it is. The search results provided include information about a ray tracing engine called Rayve, some computer vision methods for textureless object detection, a GitHub repo on ray tracing from scratch, and other related papers.

First, I need to address the main points from the forum discussion. The users there are debating whether it's possible to have RT without textures, with some mentioning things like high polygon counts, AI-generated models, and voxels. They reference a technology called "Unlimited Detail" which uses point clouds instead of polygons.

Looking at the search results, Rayve (webpage 1) is a ray tracing engine that uses pure compute-based rendering without traditional APIs like DirectX or Vulkan. It mentions handling 8 million triangles at 237 fps, which shows high performance. This could be relevant as it demonstrates current capabilities in pure RT. However, Rayve still uses PBR materials and other effects, so maybe textures are still involved in some form.

Webpages 2, 4, 6, 8, and 10 discuss techniques for detecting or working with textureless objects using gradient maps, RF-visual fusion, etc. These are more about computer vision and SLAM, which might not directly relate to rendering without textures but could inform methods for handling textureless environments in rendering.

Webpages 3, 5, 7, 9 are about ray tracing implementations, including real-time caustics and educational projects. The GitHub repo (webpage 3) mentions that ray tracing is simpler than traditional rendering, which supports the idea that moving away from rasterization might reduce reliance on textures. Webpage 7's project on caustics uses photon mapping, which is a ray tracing technique that could be part of a textureless pipeline if materials are defined by properties instead of image textures.

The key points from the forum are: the desire to eliminate textures by using high-poly models or alternative representations like point clouds, the role of AI in generating geometry, and the technical challenges in rendering performance and material representation without textures.

From the search results, Rayve's approach eliminates many traditional rendering steps (like draw calls, occlusion culling) which could reduce the need for certain texture optimizations. However, it still uses PBR materials, which often rely on texture maps. So maybe textures aren't completely gone but are represented differently.

The mention of "Unlimited Detail" in the forum refers to a voxel-based approach, which is similar to point clouds. While not covered in the search results, the Rayve engine's high triangle count handling might suggest that high-poly models are feasible with current hardware, reducing the need for texture details.

The computer vision methods for textureless objects (webpages 2,4,6,8,10) might not directly apply, but they show that there's research into handling scenes without detailed textures, which could inform rendering techniques.

In terms of feasibility today, Rayve's existence (webpage 1) indicates that pure compute-based RT is possible, but it's still in development (planned for Q1 2025). The system requirements mention high-end GPUs, so it's feasible but requires powerful hardware.

The GitHub project (webpage 3) shows educational material on building a ray tracer from scratch, indicating that the basics are accessible, but real-time performance with complex scenes is another matter. Webpage 7's real-time caustics with DXR shows specialized RT effects are possible but still demanding.

So, putting it all together: pure RT without traditional textures is technically feasible today but limited by hardware and current engine capabilities. High-poly models and material properties can replace some texture uses, but full elimination of textures (as in defining all surface details via geometry) is not yet practical. AI could help generate detailed models, but that's still emerging. The Rayve engine is a step towards this, showing high performance without traditional rendering pipelines, but textures in some form (like PBR parameters) are still present.

Ergebnis:
The feasibility of achieving **pure ray tracing (RT) without traditional textures** is a topic of active debate and technical exploration. Here's a synthesis of current capabilities, challenges, and future prospects based on the provided sources and discussion context:

---

### 1. **Current State of Pure Ray Tracing**
Ray tracing engines like **Rayve** demonstrate significant progress, using a compute-based approach that bypasses rasterization pipelines (e.g., DirectX/Vulkan for rendering). Rayve achieves **237 fps with ~8 million triangles** in-engine, leveraging deterministic ray paths for clean visuals without denoising . However, it still relies on **PBR materials**, dynamic lighting, and other effects, which often implicitly depend on texture-like data (e.g., material parameters). While textures in the classical 2D-map sense are reduced, surface properties are still defined through shaders or procedural methods rather than geometric detail alone.

---

### 2. **Eliminating Textures: Technical Hurdles**
- **Geometric Complexity**: Rendering textureless scenes requires **extreme geometric detail** (e.g., 1 polygon per pixel) to simulate surface variations. While Rayve handles millions of triangles efficiently, scaling this to cinematic detail (e.g., pores on skin, fabric weaves) remains computationally prohibitive for real-time applications .
- **Material Representation**: Even without 2D textures, materials require **procedural or volumetric definitions** (e.g., refractive indices, subsurface scattering). For example, caustics in real-time RT projects like Yichao Wang’s work use photon mapping to simulate light interactions, but these still depend on material properties rather than pure geometry .
- **Workflow Limitations**: Current 3D modeling pipelines are optimized for textured assets. Transitioning to purely geometric or voxel-based workflows (e.g., point clouds) would require overhauling toolsets and artist practices .

---

### 3. **Emerging Solutions**
- **AI-Driven Geometry**: AI could automate high-detail model generation, as speculated in the forum. While projects like **RFSift+** (textureless SLAM) show AI’s potential in sparse environments, generative models for RT-ready geometry are nascent and lack real-time applicability .
- **Voxel and Point Cloud Rendering**: Older concepts like "Unlimited Detail" (voxels) and modern research into **GPU-accelerated spatial hashing** (e.g., photon mapping optimizations) suggest alternatives to polygons. However, these methods struggle with dynamic scenes and memory efficiency .
- **Hybrid Approaches**: Rayve’s "pure compute" model eliminates rasterization steps (e.g., occlusion culling, draw calls), reducing reliance on texture-based optimizations. This could pave the way for texture-light pipelines, though not fully textureless .

---

### 4. **Hardware and Performance Realities**
- **GPU Requirements**: Rayve mandates high-end GPUs (e.g., RTX 4080 for UHD), indicating that textureless RT is feasible only with top-tier hardware. Similarly, real-time caustics projects report **8–84 fps** on a GTX 1060, highlighting performance tradeoffs .
- **Memory Constraints**: High-poly models or voxel data demand massive VRAM. For example, spatial hashing for caustics requires balancing cell size and photon density to avoid noise or performance drops .

---

### 5. **Timeline and Feasibility**
- **Short Term (2025–2030)**: Texture reduction (not elimination) will dominate, with engines like Rayve pushing procedural materials and hybrid RT/rasterization. AI-assisted tools may streamline high-detail modeling but won’t fully replace textures.
- **Long Term**: Pure textureless RT depends on breakthroughs in **nanoscale geometry rendering** (e.g., quantum computing?) and universal material parametrization. Until then, textures will persist as a practical shortcut for surface detail.

---

### Conclusion
Pure RT without textures is **theoretically possible today** but **impractical for mainstream use**. High hardware demands, workflow inertia, and the need for material parameterization limit its adoption. Projects like Rayve and advancements in AI/photon mapping suggest incremental progress, but a fully textureless future remains distant. For now, the industry will prioritize hybrid approaches that minimize textures without fully abandoning them .

Condensed Version in Deutsch:

Aktueller Stand:
- Möglich, aber unpraktisch: Engines wie Rayve zeigen Echtzeit-RT mit Millionen von Polygonen und prozeduralen Materialien, was die Abhängigkeit von traditionellen 2D-Texturen verringert. Oberflächeneigenschaften (z. B. Farbe, Reflektivität) erfordern jedoch weiterhin Materialparameter (Shader, volumetrische Daten) anstelle von reiner Geometrie.
- Hardware-Anforderungen: Hochwertige GPUs (z. B. RTX 4080) sind für UHD-Leistung erforderlich, was die Zugänglichkeit einschränkt.

Herausforderungen:
- Geometrische Detailtreue: „1 Polygon pro Pixel“ für texturfreie Oberflächen ist heute rechnerisch unrealistisch.
- Material-Workflows: Die Eliminierung von Texturen erfordert eine Neudefinition von 3D-Pipelines (z. B. KI-generierte Geometrie, Voxel), die noch nicht standardisiert sind.

Neue Lösungsansätze:
- KI & prozedurale Generierung: Könnten die Erstellung hochdetaillierter Modelle automatisieren, sind aber für den Echtzeiteinsatz noch experimentell.
- Hybride Ansätze: Engines wie Rayve umgehen Rasterisierung und priorisieren compute-basiertes RT, um Texturen zu minimieren (nicht zu eliminieren).

Zeitplan:
- Kurzfristig (2025–2030): Texturreduzierung durch prozedurale Materialien und hybride RT.
- Langfristig: Reines texturloses RT hängt von Durchbrüchen im Nanoscale-Rendering (z. B. Quantencomputing) oder universellen Materialmodellen ab.

Fazit:
Reines RT ohne Texturen ist theoretisch machbar, aber aufgrund von Hardware-, Workflow- und technischen Barrieren Jahrzehnte von der breiten Einführung entfernt. Hybride Methoden werden dominieren und traditionelle Texturen schrittweise ersetzen.

Dann hab ich DeppSeek nochmal nen Factcheck an der eigenen grade gemachten Aussage vornehmen lassen.

Faktenprüfung: Zusammenfassung

### 1. „Rayve erreicht 237 fps mit ~8 Millionen Dreiecken“
- Überprüfung: Rayve ist eine Echtzeit-Raytracing-Engine, aber die genannten Leistungsdaten (237 fps, 8M Dreiecke) sind nicht in öffentlich zugänglichen, peer-reviewed Quellen dokumentiert. Wohl existieren compute-basierte RT-Engines (z. B. Quake II RTX), doch spezifische Angaben zu Rayves Leistung fehlen einer unabhängigen Bestätigung.
- Fazit: Plausibel, aber nicht verifiziert.

### 2. „1 Polygon pro Pixel ist rechnerisch unrealistisch“
- Überprüfung: Richtig. Aktuelle GPUs sind mit dieser geometrischen Dichte überfordert. Beispielsweise würde ein 4K-Bildschirm (8,3M Pixel) ~8,3M Polygone pro Frame erfordern, was die Echtzeit-Rendering-Grenzen überschreitet. Nanite (Unreal Engine 5) unterstützt zwar ~1 Mrd. Polygone pro Szene, nutzt jedoch LODs und virtualisierte Geometrie, kein 1:1-Pixel-Polygon-Verhältnis.
- Fazit: Korrekt.

### 3. „KI-generierte Geometrie ist für den Echtzeit-Einsatz noch experimentell“
- Überprüfung: Richtig. KI-Tools wie NVIDIA GET3D erzeugen zwar 3D-Modelle, sind aber noch nicht in Echtzeit-Pipelines integriert. Forschung (z. B. NeRF) konzentriert sich auf Offline-Rekonstruktion, nicht auf dynamische, spieltaugliche Assets.
- Fazit: Korrekt.

### 4. „Hybride Ansätze (z. B. Rayve) umgehen Rasterisierung“
- Überprüfung: Teilweise richtig. Engines wie O3DE und Unity verwenden hybrides Rendering (Rasterisierung + RT), aber „pure compute“-RT-Engines (z. B. Path Tracing in Cyberpunk 2077) nutzen weiterhin Rasterisierung für bestimmte Passes (z. B. UI). Rayves spezifische Architektur ist nicht öffentlich detailliert.
- Fazit: Übertrieben.

### 5. „RTX 4080 für UHD-Leistung erforderlich“
- Überprüfung: Richtig. Native 4K-Path-Tracing in Spielen wie Cyberpunk 2077 erfordert DLSS 3.5 und RTX 4090/4080 für spielbare Framerate.
- Fazit: Korrekt.

### 6. „Quantencomputing könnte Nanoscale-Rendering ermöglichen“
- Überprüfung: Spekulativ. Die Rolle von Quantencomputing in der Grafik ist theoretisch (z. B. schnellere Lösung von Lichttransportgleichungen). Praktische Anwendungen existieren nicht.
- Fazit: Hypothetisch, noch nicht faktisch.

### 7. „Reines texturloses RT ist Jahrzehnte entfernt“
- Überprüfung: Richtig. Texturen bleiben entscheidend für Leistung und künstlerische Kontrolle. Selbst prozedurale/voxelbasierte Engines (z. B. Teardown) verwenden texturähnliche Daten (z. B. Material-IDs).
- Fazit: Korrekt.

### Gesamtbewertung
- Korrekte Aussagen:
- Geometrische/Polygon-Beschränkungen.
- Experimenteller Status von KI in Echtzeit-Workflows.
- Hardware-Anforderungen für RT.
- Branchenabhängigkeit von hybriden Ansätzen.
- Übertriebene/nicht verifizierte Aussagen:
- Rayves spezifische Fähigkeiten.
- Kurzfristige Relevanz von Quantencomputing.
- Fehlender Kontext:
- Nanite (UE5) reduziert bereits die Texturabhängigkeit durch virtualisierte Geometrie, verwendet aber weiterhin Materialgraphen (texturähnliche Daten).

Insgesamt: Das Kernargument stimmt – reines texturloses RT ist heute nicht machbar –, aber einige Beispiele fehlen konkreter Belege.

[Rooter]

Unlimited Detail hieß das.Danke, das war's, von Euclideon. Müsste 2011 gewesen sein.
Was wurde eigentlich daraus? War doch quasi ein früher Vorläufer von UE5 Nanite.

MfG
Rooter

[Gast]

Danke, das war's, von Euclideon. Müsste 2011 gewesen sein.
Was wurde eigentlich daraus? War doch quasi ein früher Vorläufer von UE5 Nanite.



Mehr von Raytracing, im Grunde haben sie sowas wie einen BVH benutzt.

[Fusion_Power]

Da gabs doch mal die geniale 96K Demo "KKrieger" mit prozedural generierten Texturen. Genial aber hat sich wohl nicht durchgesetzt. Ich denke mal auch mit RT brauchts weiterhin Texturen. Und ich persönlich bin eh für jeden "schmutzigen Trick" in Games um Grafik möglichst effektiv und ressourcensparend darzustellen, auch ohne Premium-Hardware. So weit ist RT halt leider noch nicht, bzw. die Hardware ist es noch nicht.

[Rooter]

Ja, von Farbrausch. :) Prozedural generierten Texturen haben aber weder mit Unlimited Detail noch mit RT etwas zu tun. ;)

MfG
Rooter

[Tobalt]

Das Pointcloud Rendering taugt eher nicht zu dynamischen Szenen und machte auch gar keine Beleuchtung wenn ich nicht recht entsinne. Es wird einfach die farbigen Points aus diversen Richtungen betrachtet. Also ich glaube das ist schwierig für interaktive Szenen.

Was der OP meint ist quasi point clouds mit RT. Ka, ob es dazu etwas gibt. Auch da bleibt der Punkt, dass Point clouds eigentlich nicht dynamisch sind.. Warum eigentlich nicht?

[][immy]

Ähhhh, wie stellst du dir das vor ohne Texturen? Willst du weisse Polygone beleuchten? Dann wirst du auch weisse Polygone bekommen.
Nicht unbedingt, da du Polygonebja einfärben kannst. Aber selbst bei 1pixel Polygonen wird das schlecht aussehen wenn man sich nähert. Macht die Datenhaltung und die Wiederverwendung von Objekten auch nicht einfacher.
Materialeigenschaften sind da auch noch nicht berücksichtigt. Da müsste man schon deutlich kleiner als ein Pixel pro Polygon werden, weil man auch kleinste Strukturen nachbilden müsste.
Das wären aber am ende dermaßen viele Polygone das es vermutlich jede GPU umhauen würde, selbst bei simplen Objekten die ein wenig rau aussehen sollen. Die Datenmenge wäre wohl auch ziemlich gigantisch.

Auf Anhieb würde mir gerade die Zeit um FF7 einfallen, wo die meisten 3d Objekte fast ohne Texturen aus kamen, aber einfach weil Texturen zu "teuer" waren für die engines und ggf. noch etwas zu neu.

[Badesalz]

Also wann gibt es Konzepte, Rechenkraft und flüssiges Rendering von einfach hinreichend genau modellierten Polygonen, die dem einfallenden Strahl einfach einen Farbwert mitgeben und der Rest errechnet sich aus Licht und Schatten - ohne, dass hier irgendeine aus mehreren Pixel zusammenhängende Textur-"Haut" benötigt wird? Wegen dem mehrmals genutzten "Einfach": Einfach nicht zu deinen Lebzeiten.

Um das vernünftig einzuschätzen solltest du nicht nur die möglichen Methoden betrachten, sondern einfach die benötigte native Leistung. Von z.B. 4090 und 5090... Die Rechenleistung und die Leistung die an der Steckdose gezogen wird.

Für das was du suchst braucht man Steigerungen von zigfach über zigfach. Die Fahrpläne - auch die vielversprechenden aber erst noch theoretischen - reichen bisher nur für mehrfaches Mehrfach.

Für noch und nöcher mehr, geht uns mittlerweile einfach die Physik aus. Und ehrlich gesagt, wenn man es hinbekommt die Blase wenigstens kurzzeitig zu verlassen, so langsam auch die Notwendigkeit...

[Mars007]

Habe die Diskussion nur überflogen und gebe hier meinen Senf dazu.

Ein Dreieck pro Pixel gibt es seit der Unreal Engine 5.0 (2022)
Vertex-Color gibt es seit Anbeginn von 3D Engines und wird auch heute fleißig benutzt - wenn auch eher für Blendeffekte von einer Textur zur anderen. Vor Kurzem habe ich einen Surface-Net-Algorithmus in die Unreal-Engine gebaut und das Rendering über Vertex-Color realisiert.

Wie von anderen bereits geschrieben, braucht es mehr als nur Farbe. Vertex-Normale sind seit Quake 1 im Einsatz.
Bei der Vorstellung der Unreal 5 Engine wurde erwähnt dass jede Statue in der Demo 80 Mio Polygone besitzt. Das sind so viele Polygone, dass die Normal-Map entfallen konnte.
Für vollständiges PBR-Rendering bräuchte man weitere Informationen wie Metallic, Roughness, usw.

Theroetisch könnte man diese Informationen in die Geometrie hängen - wenn wir unbegrenzt Speicher hätten. Texturen lassen sich besser komprimieren und auch wiederverwerten.

Das alles hat wenig mit Raytracing zu tun.

[Fusion_Power]

Ja, von Farbrausch. :) Prozedural generierten Texturen haben aber weder mit Unlimited Detail noch mit RT etwas zu tun. ;)

MfG
Rooter
Bei dem Vergleich gings mir allgemein auch nur um das "Generative" wie eben generierte Schatten und Licht und Texturen ohne "vorproduzierte" Elemente. Technisch sicher alles hochinteressant aber obs in der Praxis dann auch wirklich immer praktikabel ist, ist die Frage. Dann lieber tricksen mit guter Performance als aufwendige Echtzeit RT Spielereien ohne Mehrwert außer schlechterer Performance.
Und Texturen kommen hoffentlich nie aus der Mode. Hab früher selber welche erstellt schon für die Duke 3D "BUILD Engine". Tolle Zeiten. :D

[nonharderware]

Ich verstehe nicht, dass mich hier einige Personen offenbar absichtlich missverstehen wollen :rolleyes:

Eine Textur kann jedenfalls auch nur auf den Pixel runtergebrochen werden - darunter kann man eventuell eine noch feiner Textur laden - die geht aber auch nur zum Pixel.

Texturen sind eine Hilfe mit beschränkter Genauigkeit.

In der Realität hat nichts eine Textur - gröbstens vereinfacht: Elektronen reflektieren Photonen und daraus leiten sich Eigenschaften des sichtbaren Lichts ab. Netzhaut detektiert und das Gehirn interpretiert von der Signalstärke "Farbe".

Computergrafik wird dies auf dem Weg absoluten Perfektion auf irgendeine Art und Weise anstreben müssen - wenn sie sich weiterentwickelt.

Ich denke, dass dies durchaus noch zu Lebzeiten passieren kann.

Als mein Großvater mein Alter hatte, war noch nicht mal die Kubakrise auf dem Schirm und "Computer" eher aus Sci-Fi bekannt.
Als mein Großvater starb, hatten wir die id Tech 5 mit Rage am Start.

Ich gehe also schon noch davon aus - sofern nicht irgendwelche Arschlöcher im Zuge der global erwachenden Kriegslust den bösen Knopf drücken - eine entsprechende Annäherung vor meinem Tod erleben zu können.

[Exxtreme]

Ich verstehe nicht, dass mich hier einige Personen offenbar absichtlich missverstehen wollen :rolleyes:


Ich glaube, das Problem ist eher, dass einige hier das Problem gar nicht erkennen, welches du zu lösen versuchst.


Eine Textur kann jedenfalls auch nur auf den Pixel runtergebrochen werden - darunter kann man eventuell eine noch feiner Textur laden - die geht aber auch nur zum Pixel.


Nein, du kannst sehr viel kleinere Texel machen als Pixel. Nur macht das niemand weil das anfängt wie irre zu flimmern in Bewegung. Und deshalb nutzt man Mip Mapping, welches die zur Auflösung passende Texel-Größe auswählt.

[nonharderware]

Ich glaube, das Problem ist eher, dass einige hier das Problem gar nicht erkennen, welches du zu lösen versuchst.


Ich bin offen für alternative Formulierungen, welche den Zweck besser transportieren.


Nein, du kannst sehr viel kleinere Texel machen als Pixel. Nur macht das niemand weil das anfängt wie irre zu flimmern in Bewegung. Und deshalb nutzt man Mip Mapping, welches die zur Auflösung passende Texel-Größe auswählt.

Ich komme nicht aus der CGI-Schiene.
Bin auch eigentlich von der Physik zur Informatik abgezweigt - nämlich (leider) über computational physics von der IT angefixt worden.

Aber Texel erscheinen mir halt auch wieder eine optische Annäherung zu sein ohne wirklich tiefer zu gehen.

[Gast]

Ich verstehe nicht, dass mich hier einige Personen offenbar absichtlich missverstehen wollen :rolleyes:


Ich glaube du bist es eher der missversteht wie Rendering, insbesondere die Herangehensweisen von Rasterizing und Raytracing funktionieren.


Eine Textur kann jedenfalls auch nur auf den Pixel runtergebrochen werden - darunter kann man eventuell eine noch feiner Textur laden - die geht aber auch nur zum Pixel.


Eine Textur besteht aus Pixeln, auch wenn sie meistens Texel genannt werden ist es im Grunde das selbe.

Ein Pixel/Texel beschreibt eine oder mehrere Eigenschaften der einschließenden Fläche.
Am Ende sind Pixel am Monitor eine kleine aber endlich große Fläche und ziel ist es dessen durchschnittliche Farbe darzustellen. Eine feinere Beschreibung der Eigenschaften eines Pixels wäre zwar möglich, ist aber sinnlos, da dies nicht darstellbar ist.


Texturen sind eine Hilfe mit beschränkter Genauigkeit.


Alles was nicht einzelne Elementarteilchen beschreibt ist eine Hilfe mit beschränkter Genauigkeit, und Elementarteilchen lassen sich gar nicht mit beliebiger Genauigkeit beschreiben.



Computergrafik wird dies auf dem Weg absoluten Perfektion auf irgendeine Art und Weise anstreben müssen - wenn sie sich weiterentwickelt.


Diese wird niemals sinnvoll erreichbar sein, und ist auch gar nicht sinnvoll.
Wenn du in einer Szene jedes Atom simulieren willst, kannst du das nicht mit einem Computer machen der aus weniger Atomen als die zu beschreibende Szene besteht.

[Badesalz]

Ich bin offen für alternative Formulierungen, welche den Zweck besser transportieren. Mit #22 kommst du nicht ganz klar oder? :wink:

[nonharderware]

Mit #22 kommst du nicht ganz klar oder? :wink:

Ich erkenne hier nichts Sinnvolles - maximal subjektive Extrapolation.

[Badesalz]

Na dann toi toi toi, mit dem Ideenreichtum :up:

[nonharderware]

Na dann toi toi toi, mit dem Ideenreichtum :up:

Ich verstehe den Sinn einer solchen Aussage nicht.
Was gedenkst du hiermit bei mir auszulösen?
Soll es lustig sein?
Sarkastisch?

Wie auch immer: Es trägt nichts zur Diskussion bei, also lass es bitte.

[Börk]

Geometrie alleine reicht nicht. Zur Beschreibung von Reflektionseigenschaften braucht es zu jedem Punkt noch die BSDF. Klar spielt auch hier Geometrie eine Rolle (Microfacetten Geometrie), aber eben nicht alleine.

Texturen für Reflektionseigenschaften zu verwenden ist recht naheliegend. Im Endeffekt repräsentieren sie ein örtlich aufgelöstes analytisches Modell für die BSDF.
Wie wir wissen sind analytische Funktionen grundsätzlich limitiert, und daher wäre eine neurale/implizite Funktion der nächste naheliegende Schritt. Das Problem hierbei wird aber sein, woher sollen die Daten kommen.
Es gibt ja kaum gemessene Realdaten von denen man das ableiten könnte. Und es wird auch praktisch unmöglich das von Artists steuern zu lassen.

Daher wird es langfristig sicher ein Mix zwischen Neural Materials (based on measurements) + Generative AI werden.

[nonharderware]

Geometrie alleine reicht nicht. Zur Beschreibung von Reflektionseigenschaften braucht es zu jedem Punkt noch die BSDF. Klar spielt auch hier Geometrie eine Rolle (Microfacetten Geometrie), aber eben nicht alleine.

Texturen für Reflektionseigenschaften zu verwenden ist recht naheliegend. Im Endeffekt repräsentieren sie ein örtlich aufgelöstes analytisches Modell für die BSDF.
Wie wir wissen sind analytische Funktionen grundsätzlich limitiert, und daher wäre eine neurale/implizite Funktion der nächste naheliegende Schritt. Das Problem hierbei wird aber sein, woher sollen die Daten kommen.
Es gibt ja kaum gemessene Realdaten von denen man das ableiten könnte. Und es wird auch praktisch unmöglich das von Artists steuern zu lassen.

Daher wird es langfristig sicher ein Mix zwischen Neural Materials (based on measurements) + Generative AI werden.

Ich verstehe, klingt interessant.
Wobei ich meine, dass es möglich sein sollte mit gewissen Modellen und Messungen ein Grundmodell für das Beleuchtungs-/Reflektionsverhalten von makroskopischen Objekten zu erstellen, von welchem sich da neue, bisher nicht gemessene Zustände ableiten lassen.

Wobei es gut sein kann, dass dies aber im Prinzip mit dem von dir Beschriebenen ident ist.

[Tesseract]

Ich komme nicht aus der CGI-Schiene.

ich würde dir raten dich zumindest in eine CGI-einführungsvorlesung einzulesen. CGI geht so viel "tiefer" als das worüber du hier diskutieren willst dass hier kaum was sinnvolles rauskommen kann, über das was schon gesagt wurde hinaus.

[Badesalz]

Ich verstehe den Sinn einer solchen Aussage nicht.
Was gedenkst du hiermit bei mir auszulösen?
Soll es lustig sein?
Sarkastisch?Das war eine Provokation. Die Idee dahinter war zum Thema eine differenzierte Denkweise zu provozieren.

[Exxtreme]

Aber Texel erscheinen mir halt auch wieder eine optische Annäherung zu sein ohne wirklich tiefer zu gehen.

Solange man nicht unendlich viel Speicherplatz und Bandbreite hat, wird alles immer nur eine Annäherung sein. Texturen sind auch nicht das Problem, was Computergrafik hat. Das viel größere Problem sind die Arbeitskosten, die es braucht um eine möglichst realistische Grafik zu erstellen. Deshalb fehlt der Computergrafik immer was. Bzw. richtig realistisch aussehende Grafik gibt es fast immer nur in irgendwelchen Engine-Demos. Aber die sind im Vergleich zu einem Computerspiel im Umfang extrem begrenzt.

[Orko]

@ nonharderware

Mir fehlt etwas der Kontext deiner Frage.

Es scheint dir darum zu gehen, wie Objekte in einem 3D Raum über einer Zeitachse dargestellt / modelliert werden,
und welche Alternativen es zum aktuellen Standard (Dreiecke + Texturen) gibt.

Inwieweit ist für dich dabei die Abbildung auf den Bildschirm (bzw allgemeiner formuliert: die Modellierung des Beobachters) wichtig / unwichtig / irrelevant, also ob dies mittels Rasterizing / Raytracing oder ggf anderen geeigneten Methoden geschieht?

Bezieht sich deine Frage auf den Anwendungsfall Computergraphik in Computerspielen,
oder eher auf den Bereich wissenschaftlich-mathematische abstrakte Simulation?

Im Fall Computergraphik ist, wie bereits diskutiert, die wesentliche Anforderung (Hauptcharakteristika des Beobachters) eine Nahezu-Echtzeiterfahrung, die Prämisse ist primär eine Limitierung der verfügbaren Rechenleistung, und der daraus erfolgende Kompromiss eine limitierte 2D Auflösung des Bildschirms / des Beobachters. Damit ist es unnötig, die 3D Szene räumlich allzuviel stärker aufzulösen als das was der Beobachter (in Form von Bildschirmpixeln) beobachten kann. Eine Darstellung der Objekte (in einem 3D Raum über einer Zeitachse) als Dreiecke + Texturen ist insofern günstig, da diese Darstellung an die Eigenschaften des Beobachters gut angepasst ist. Zweidimensionale Dreiecke entsprechen gut einem zweidimensionalen Bildschirm, und Texel entsprechen gut den Bildschirmpixeln. Je stärker sich die Darstellung der Objekte und die Charakteristika des Beobachters unterscheiden, desto schwieriger ist es für den Beobachter die für ihn beobachtbaren Informationen korrekt (im Sinne von: mit möglichst hohem Informationsgehalt) zu extrahieren.

Lässt du die Forderung Nahezu-Echtzeiterfahrung fallen, kommen wir in den Bereich der wissenschaftlich-mathematische abstrakten Simulation, und die wesentliche Frage ist dann, wie der Beobachter modelliert wird. Als Beispiel kann der Beobachter unverändert ein virtueller 2D Bildschirm sein, aber mit einer deutlich höheren Auflösung (bis in den atomaren oder gar subatomaren Bereich). Real werden diese hochauflösenden Bilder in einen Speicher geschrieben, und können dann anschliessend und damit nicht in Echtzeit betrachtet werden.

Von der Modellierung des Beobachters hängt es ab, was günstige oder ungünstige Darstellungsmethoden von den Objekten (in einem 3D Raum über einer Zeitachse) sind. Möchtest du z.B. Molekühle beobachten, macht eine Darstellung als Atommodell Sinn. Möchtest du eine Wettersimulationen durchführen, ist wiederum eine Aufteilung des Raumes in eine ausreichend hohe Anzahl an finiten Elementen (Voxeln) sinnvoll. Ist eine realistische Optische Darstellung (incl Reflexionen, Schatten und der Darstellung von semitransparenten Objekten) wichtig, scheidet Rasterizing aus und du bist im Bereich der physikalisch-optischen Simulation, z.B. in Form von Lichtstrahlen (klassische Optik, Raytracing) oder Lichtwellen (für z.B. Interferenz-Phänomene) oder gar Quantenmechanisch (Wechselwirkung Licht und Materie).

[Orko]

Für Computergraphik in Computerspielen:


Fall Rasterizing:

Ich halte die Darstellung von Volumenobjekten durch Oberflächendreiecke + Texturen als optimal, im Sinne von mit limitierter Rechenleistung möglichst hohe FPS + Bildschirmpixelzahlen zu erreichen.


Fall Raytracing:

Auch hier halte ich die Darstellung von Volumenobjekten durch Oberflächendreiecke als optimal, da die meisten wesentlichen Interaktionen von Lichtstrahlen mit Objekten (Reflexion, Streuung, Beugung) nun mal an Oberflächen bzw Grenzflächen auftreten.

Volumen-Effekte wie Absorption, chromatische Dispersion, Lumineszenz, Phosphoreszens, etc können auf diese Weise nicht direkt berechnet werden. Die Frage ist, ob ein deratige Effekte bzw deren physikalisch-optische korrekte Darstellung im Bereich Computergraphik überhaupt benötigt werden, und falls ja ob diese wirklich korrekt berechnet werden müssen. Irgendwie "Faken" indem z.B. Flächen innerhalb von Objekten mit entsprechenden (Ober)Flächeneingenschaften hinzugefügt werden, sollte IMHO ausreichen.

Texturen beschreiben die (Ober)Flächeneigenschaften der Dreiecksflächen. Diese müssen natürlich entsprechend erweitert werden. z.B. für Strahlen durch (semi) transparente Objekte um Informationen zum Beugungswinkel. Ob diese Informationssammlungen dann noch Textur oder irgendwie anders genannt werden, ist IMHO reine Definitionssache.

Als nächste Ausbaustufe Richtung Realismus könnte ich mir vorstellen, dass Lichtstrahlen nicht nur Farbwerte sondern komplette optische Spektren (digitalisiert natürlich) tragen, und die Texturen diese Spektralwerte entsprechend verändern. Damit wären z.B. Regenbogeneffekte realistisch(er) darstellbar.


Zukunft:

Aus heutiger Sicht möchte ich anzweifeln, ob es für Computergraphik in Computerspielen jemals nötig sein wird, von einem strahlenbasierten optischen Modell auf ein wellenbasiertes optisches Modell zu wechseln. Aus dem einfachen Grund dass wellenoptische Phänomene im menschlichen Alltag nahezu nicht präsent sind (u.a. weil monochromatisches Licht im Alltag nahezu nicht auftritt und weil Abmessungen im Bereich von Lichtwellenlängen, also ca 400nm bis 800nm, im Alltag keine Rolle spielen).

Für ein wellenbasiertes optisches Modell funktioniert es natürlich nicht mehr, 3D Objekte als 2D Oberflächen und deren Eigenschaften (Texturen) zu modellieren. Diese Objekte müssten dann wirklich aus 3D Elementen + deren Volumeneigenschaften + deren Oberflächeneigenschaften modelliert werden.

[nonharderware]

Orko:

Ich verstehe jetzt.
Deine Ausführungen waren sehr hilfreich - Danke :up: