Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Mi Jul 09, 2025 20:55

Foren-Übersicht » Programmierung » Shader
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 17 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
 Betreff des Beitrags: Beleuchtungsmethoden
BeitragVerfasst: Di Jun 19, 2007 16:15 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Hi,

ich hab eben ein wenig drüber gegrübelt wie man Beleuchtung via Shader gut und effizient erledigen könnte..

Gibt ja hier im grunde 2 ansätze... alle lichter in einem Pass mit einem "SuperShader" oder für jedes licht einen eigenen Pass.
Beide varianten haben viele vor und nachteile..

Meine idee war jetzt eine etwas andere variante des "one pass per Light" setups, bei dem ja der größte nachteil darin steckt, das jede vertex-transformation für jeden pass neu gemacht werden muß.

Meine idee wäre jetzt folgende, man rendert das bild in mehreren passes:

1 Pass) Die Scene ohne beleuchtung = Constant shading
2 Pass) Die Scene mit einem Shader die die richtung der Normalen als RGB Ausgibt
3 Pass) Die Scene mit einem Shader bis zu vier materialattribute in die RGBA kanäle pro pixel packt.

So.. die 3 Passes steckt man sich alle in eine Textur und macht nun das eigentliche beleuchten als PostEffect für jedes Licht als einzelnen pass... alle wichtigen daten hierfür hat man ja eigentlich..

Nachteil an der sache ist, das man nur 4 materialattribute pro Pixel hätte was evtl zu wenig ist (wenn man AmbientColor, SpecularColor etc nicht nur als Grauwerte nehmen will)... einzige möglichkeit die mir dazu einfallen würde wäre, weitere Passes hierfür zu rendern..

Die frage ist nun.. ich hab das nochnicht ausprobiert, da ich nur eben die fixe idee hatte und noch auf der arbeit rumhocke... aber, denkt ihr das wäre irgendwie sinnvoll?? Oder sind da noch sehr gravierende sachen die ich jetzt vergessen habe? :roll:

Aya~


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jun 20, 2007 09:34 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 03, 2002 15:08
Beiträge: 662
Wohnort: Hamburg
Programmiersprache: Java, C# (,PhP)
Ich meine mal gelesen zu haben das die Source Engine bei HL 2 für eine Scene bis zu 16 Renderpasses nutzt.

_________________
(\__/)
(='.'=)
(")_(")


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jun 20, 2007 10:45 
Offline
DGL Member

Registriert: Mo Dez 20, 2004 08:58
Beiträge: 442
Wohnort: Mittweida (Sachsen)
Ich find die Idee super, da sie nebenbei die Shader an sich vereinfacht (Thema Verzweigungen im Shader).
Amient/specular als grau/rgb könnte man dann ja auch als Performanceeinstellung bieten bzw verschiedene Materialeigenschaften wie Reflexionen, Oberflächenstrukturen (die hinterher z.b. die Normalmap verändern) oder blur Effekte. Da werden dann einfach weitere Passes dazu/weggenommen.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jun 20, 2007 11:09 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Hi,

2 dinge sind mir selbst noch eingefallen die da wahrscheinlich problematisch werden..

a) Es wird schwer komplett verschiedene Materialien zu verwenden... also z.B. Phong und Wasser im selben Frame.. das am ende dann via maske oder so zu trennen wird nicht so einfach..

b) Bei einer maximalen anzahl von 4 TMUs können ja nur 4 texturen an den Shader übergeben werden.. das grenzt das ganze dann leider aufeinmal doch wieder ziemlich stark ein :(

Aya~


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jun 20, 2007 12:16 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Aya hat geschrieben:
b) Bei einer maximalen anzahl von 4 TMUs können ja nur 4 texturen an den Shader übergeben werden.. das grenzt das ganze dann leider aufeinmal doch wieder ziemlich stark ein :(

Du hast eine Karte von NVidia? Lass dich dort von der Konstante GL_MAX_TEXTURE_UNITS nicht in die Irre führen. Das ist nur die Anzahl im Fixed Function Path. Bei ATI sind dort per Default 8 implementiert. Aber nichts destro trotz kannst du mit glsl alle 16 TMUs ansprechen. Die Konstante dafür ist die GL_MAX_TEXTURE_IMAGE_UNITS. ;) Bzw gibt es auch eine Trennung zwischen TMUs und Texturkoordinaten. GL_MAX_TEXTURE_COORDS.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jun 20, 2007 13:11 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Lossy eX hat geschrieben:
Du hast eine Karte von NVidia? Lass dich dort von der Konstante GL_MAX_TEXTURE_UNITS nicht in die Irre führen. Das ist nur die Anzahl im Fixed Function Path. Bei ATI sind dort per Default 8 implementiert. Aber nichts destro trotz kannst du mit glsl alle 16 TMUs ansprechen. Die Konstante dafür ist die GL_MAX_TEXTURE_IMAGE_UNITS. ;) Bzw gibt es auch eine Trennung zwischen TMUs und Texturkoordinaten. GL_MAX_TEXTURE_COORDS.

Oh... ok, cool.. das wusste ich nicht.. yay~ :D

Problem a) bleibt allerdings bestehen... was wenn ich 2 grundverschiedene Shader im bild habe..? Also 2 Shader die auf das licht komplett verschieden reagieren sollen, und nicht phong-mäßig?

Da fällt mir im moment noch nichts gescheites ein, ausser zu maskieren.. aber das ist evtl wieder zu langsam dann :/
wobei mir da noch einfällt.. gibt es eine gescheite methode zu maskieren? dadurch das alle farben float werte sind, kann ich ja nur bedingt sagen "Alles was rot ist..".. denn rot muß ja nicht zwingend 1.0 sein, sondern kann ja auch 0.9999999 oder 1.0000001 sein.. float halt :/ oder?

Aya~


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jun 20, 2007 14:27 
Offline
DGL Member
Benutzeravatar

Registriert: So Jun 04, 2006 12:54
Beiträge: 263
Ganz grob gesehen hast du das "Defered Rendering" neu erfunden. Erst mal ein nettes Paper:

http://fabio.policarpo.nom.br/docs/Defe ... ES2005.pdf

Stat in einen Color Buffer zu rendern, kann man in bis zu 4 Stück (bei der DX9 generation) , einem "Multiple Render Traget" gleichzeitig rendern. Es gibt verschiedene Einschränkungen:

Alle Rendertargets müssen gleiche bit breiten haben.
Für 32bit kommen z.B. GL_RGBA8, GL_RGB10A2 oder GL_ALPHA32F. Nicht geht dagegen GL_LUMINANCE16F_ALPHA16F auf Nvidia GF6/7, da es intern als 64bit format genutzt wird. 32 bit halte ich für die einzige brauchbare variante, da beits 128bit pro pixel ereicht sind. SOnst wird das Bandbreitenlimit schnell ereicht.

Für 64bit, kämen GL_RGBA16F und GL_LUMINANCE32F_ALPHA32F in Frage. Allerhochstens für HDR um jeden Preis brauchbar, 256bit per Pixel verdoppeln die benötigte Speicherbandbreite, so das mit garantie dort der flasschenhals sitzt.


Als light Buffer empfield sich ein GL_RGBA16F rendertarget wenn die Grafikkarte es unterstützt. Da das MSAA eh schon geopfert ist, kann man so wenigstends HDR bekommen, bei vielen Lichtquellen kann man so blending artefakte vermindern.

Ein sinnvolles Basissetup:

Texturen mit erzeugen und an Feste TMUs binden:
TMU15 GL_RGBA8/GL_RGB10A2 G-Buffer 3
TMU14 GL_RGBA8/GL_RGB10A2 G-Buffer 2
TMU13 GL_RGBA8/GL_RGB10A2 G-Buffer 1
TMU12 GL_RGBA8/GL_RGB10A2 G-Buffer 0
TMU11 GL_DEPTH24_STENCIL8 (oder ohne Stencil) G-Buffer Depth/Stencil
TMU10 GL_RGBA16F Lightbuffer

2 FBOs:
GBufferFBO: 11,12,13,14,15
LightFBO: 10 und 11 (depthbuffer beim rendern auf nur lesen maskieren)

Wenn die texturen an ihrne Texture units bleiben kann man sehr viele statusänderungen vermieden, aber man sollte nicht aus texturen lesen, in die geschrieben wird (gibt Algoritmen bei denen das Vorteile bringen würde aber der Cache macht hässliche Artefakte rein)

Rendern ist dann recht leicht:
Verschiedne shader zum Gbuffer füllen:
Ohne Spezielle Transformationen, Boneanimation, Keyframeinterpolator...

Verschiednen Lichtshader zum beleuchten:
Point light, Spot light, Gerichtetes Licht, Vartianten mit shadowmap, Bildprojektor...
Zum rendern immer nur das Bounding volume rendern. Optimale bedingung ist ZFail für die Backfaces und ZPass für die Fronfaces, die große frage is ob eine Optimierung mit Stencil für die "und" Bedingung mehr kostet als sie bringt, oder welche von beiden Bedingungen mehr maskiert. Für besonders große Lichtquellen ein Quad über alles zeichnen...

Postfilter
hier muss man nur noch das fehlende MSAA vertuschen. Bluren bis der Augenarzt kommt: Kammerunschärfe, Postfilter Motionblur, noch mehr Blur, Koronas und Bloom ....(nicht übertreiben sonst sieht es nicht mehr gu aus)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 21, 2007 10:26 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Hi,

oc2k1 hat geschrieben:
Stat in einen Color Buffer zu rendern, kann man in bis zu 4 Stück (bei der DX9 generation) , einem "Multiple Render Traget" gleichzeitig rendern. Es gibt verschiedene Einschränkungen

das wusste ich nicht... kannst du mir kurz ein kleines beispiel geben wie ich vier Rendertargets gleichzeitig verwende?

Also, wie greif ich im Shader auf die einzelnen targets zu, und wie binde ich sie im normalen gl Code? :roll:

Aya~


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 21, 2007 12:39 
Offline
DGL Member
Benutzeravatar

Registriert: So Jun 04, 2006 12:54
Beiträge: 263
So in etwa müsste der code zum initialisieren der buffer aussehen

Code:
  1. int GBuffer[5];
  2. int GBufferFBO;
  3.  
  4. glGenTextures( 1,GBuffer);
  5.  
  6. for (int  n=0; n < 4; n++){
  7.     glActiveTexture (GL_TEXTURE12 + n);
  8.     glBindTexture (GL_TEXTURE_2D,GBuffer[n]);
  9.     glTexParameteri (GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_NEAREST);
  10.     glTexParameteri (GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_NEAREST);
  11.     glTexImage2D (GL_TEXTURE_2D,0,GL_RGBA8, WIDTH , HEIGHT ,0,GL_RGBA,GL_UNSIGNED_BYTE,Null);
  12.     }
  13.  
  14. glGenTextures (1, &GBuffer[4]);
  15. glActiveTexture (GL_TEXTURE11);
  16. glBindTexture (GL_TEXTURE_2D,GBuffer[4]
  17. glTexParameteri (GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_NEAREST);
  18. glTexParameteri (GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_NEAREST);
  19.  
  20. glTexImage2D (GL_TEXTURE_2D,0,GL_DEPTH24_STENCIL8_EXT,WIDTH,HEIGHT,0,GL_DEPTH_COMPONENT,GL_UNSIGNED_BYTE,Null);
  21.  
  22. glGenFramebuffersEXT (1, &GBufferFBO);
  23. glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, GBufferFBO);
  24. for (int  n=0; n < 4; n++){
  25.     glFramebufferTexture2DEXT (GL_FRAMEBUFFER_EXT,GL_COLOR_ATTACHMENT0_EXT + n,GL_TEXTURE_2D,GBuffer[n],0);
  26.     }
  27.  
  28.  
  29. glFramebufferTexture2DEXT (GL_FRAMEBUFFER_EXT,GL_DEPTH_ATTACHMENT_EXT,GL_TEXTURE_2D,GBuffer[4],0);
  30.  
  31. glDrawBuffers (4, {GL_COLOR_ATTACHMENT0_EXT,GL_COLOR_ATTACHMENT1_EXT,GL_COLOR_ATTACHMENT2_EXT,GL_COLOR_ATTACHMENT3_EXT});
  32.  
  33. switch glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT){
  34.     case GL_FRAMEBUFFER_COMPLETE_EXT:
  35.         printf ("FRAMEBUFFER_COMPLETE");break;
  36.     case GL_FRAMEBUFFER_UNSUPPORTED_EXT:
  37.         printf ("FBO configuration unsupported");break;
  38.     default:
  39.         printf ("FBO error");
  40.     } 
  41.  
  42. glBindFramebufferEXT (GL_FRAMEBUFFER_EXT,0);
  43.  
  44. int LightBuffer;
  45. int LightBufferFBO;
  46.  
  47. glGenTextures (1,&LightBuffer);
  48. glActiveTexture (GL_TEXTURE10);
  49. glBindTexture (GL_TEXTURE_2D,LightBuffer);
  50.  
  51. glTexParameteri (GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_NEAREST);
  52. glTexParameteri (GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_NEAREST);
  53.  
  54. glTexImage2D (GL_TEXTURE_2D,0,GL_RGBA16F,WIDTH,HEIGHT,0,GL_RGBA,GL_UNSIGNED_BYTE,Null);
  55.  
  56. glGenFramebuffersEXT (1, &LightBufferFBO);
  57. glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, LightBufferFBO);
  58. glFramebufferTexture2DEXT (GL_FRAMEBUFFER_EXT,GL_COLOR_ATTACHMENT0_EXT,GL_TEXTURE_2D,LightBuffer,0);
  59.  
  60. glFramebufferTexture2DEXT (GL_FRAMEBUFFER_EXT,GL_DEPTH_ATTACHMENT_EXT,GL_TEXTURE_2D,GBuffer[4],0);
  61. glFramebufferTexture2DEXT (GL_FRAMEBUFFER_EXT,GL_STENCIL_ATTACHMENT_EXT,GL_TEXTURE_2D,GBuffer[4], 0);
  62.  
  63. switch glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT){
  64.     case GL_FRAMEBUFFER_COMPLETE_EXT:
  65.         printf ("FRAMEBUFFER_COMPLETE");break;
  66.     case GL_FRAMEBUFFER_UNSUPPORTED_EXT:
  67.         printf ("FBO configuration unsupported");break;
  68.     default:
  69.         printf ("FBO error");
  70.     } 
  71.  
  72. glBindFramebufferEXT (GL_FRAMEBUFFER_EXT,0);


im fragment shader in der ersten Zeile:

Code:
  1. #extension GL_ARB_draw_buffers : enable

und die daten dann in gl_FragData[0] bis gl_FragData[3] schreiben (stat in gl_FragColor)


Zuletzt geändert von oc2k1 am Do Jun 21, 2007 14:16, insgesamt 2-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 21, 2007 13:28 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Cool, danke :)

Und dann später dann einfach die vier FBOs als Textur binden, ja?

Aya~


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 21, 2007 13:48 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Die Texturen die an die FBOs angehangen wurden sind doch schon an die TMUs 10-15 gebunden. ;)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 21, 2007 13:55 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Lossy eX hat geschrieben:
Die Texturen die an die FBOs angehangen wurden sind doch schon an die TMUs 10-15 gebunden. ;)

Meow.. ok, stimmt... :oops:


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Jun 23, 2007 18:24 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Hi,

ich hab das gestern abend daheim mal ausprobiert und bin auf ein paar probleme gestoßen..

1) Wenn ich im Fragmentshader diese Zeile einfüge:
Code:
  1. #extension GL_ARB_draw_buffers : enable


kommt beim compilieren des shaders diese warnung:
Code:
  1. Fragment info
  2. (2) : warning C7508: extension GL_ARB_draw_buffers not supported


im Extension String ist sie allerdings vorhanden, und eigentlich kann ich mir auch nicht vorstellen das meine GraKa das nich können soll (GeForce 7800GTX, 93.81er Forceware)... irgendne idee was da das problem sein könnte?


2) In deinem Beispiel oben erstellst du 5 GBuffer:
Code:
  1. int GBuffer[5];


wieso 5? Man kann doch maximal in 4 gleichzeitig schreiben? und die vier stück sind doch laut dem Paper Normals, Diffuse, Specular und Depth? Wozu 5? :)


3) In deinem Beispiel rufst du nahc der erstellung der Framebuffer diese funktion auf:
Code:
  1. glDrawBuffers (4, {GL_COLOR_ATTACHMENT0_EXT,GL_COLOR_ATTACHMENT1_EXT,GL_COLOR_ATTACHMENT2_EXT,GL_COLOR_ATTACHMENT3_EXT});

Wozu ist das gut? Braucht man das?


Ich hab das ganze bei mir auch schon ausprobiert.. also den Framebuffer ge'bindet, Scene reingerendert und im Shader die 4 gl_FragData's gefüllt, dann den Framebuffer wieder ge'unbindet und dann ein normales Quad im Ortho Modus gezeichnet wo ich im Shader dann die Textur vom normalPass zuweise.. allerdings ist es immer schwarz = keine textur infos da anescheined.

Das kann jetzt an dem Problem liegen das dieser ExtensionFehler in dem einen shader kommt, oder irgendwo anders dran... mal sehen.. :p

Aya~


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Jun 24, 2007 03:28 
Offline
DGL Member
Benutzeravatar

Registriert: So Jun 04, 2006 12:54
Beiträge: 263
1. Ignorieren oder schauen ob die extension doch anders heist?

2. Der Depth buffer ist die fünfte textur. Sicher braucht ein einfacher renderer keine 16 Farbwerte, aber die können trotzdem schnell knapp werden...

3. Es wird ein Array aus konstanten übergeben welches die aktiven Drawbuffer enthält ohne die bleibt es schwarz...


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Jun 25, 2007 09:34 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Hi~

so hab das ganze gestern zuhause fertig gebastelt, klappt jetzt auch alles wunderbar.. allerdings ein paar fragen hab ich noch.


oc2k1 hat geschrieben:
2. Der Depth buffer ist die fünfte textur. Sicher braucht ein einfacher renderer keine 16 Farbwerte, aber die können trotzdem schnell knapp werden...

Also kann ich 4 Color Buffer + 1 Depth Buffer haben, obwohl die Grafikkarte nur 4 MRTs unterstüzt?
Wenn ich den Depth Buffer dann als GL_DEPTH_ATTACHMENT_EXT benutze, wie komm ich denn an den dran im Shader? also klar, einfach als Textur binden.. aber als was? GL_TEXTURE_2D? Und dann im Shader? sampler2D? :roll: Muß ja irgendwie nen float zurückgeben..


2) Mein aktuelles Setup sieht so aus:
Ich hab einen Framebuffer mit 4 Colortargets in den ich die scene rendere als NormalPass, Spec, Diffuse und Depth.
Wenn das fertig ist, binde ich einen anderen Framebuffer (MainRenderTarget) und zeichne immer Fullscreen-Quads zur berechnung des Lichtes in diesem Buffer.. nach den lichtern benutz ich den Buffer dann noch für PostFilter sachen.
Das klappt zwar gut, allerdings schreibst du, das es nicht gut ist in eine textur zu schreiben von der grad gelesen wird.. bei meinem aktuellen Setup tue ich das aber bei den PostFiltern... Ich lese den inhalt des MainRenderTargets, verändere ihn und schreibe ihn direkt wieder... ist das schlimm?

Sind da noch patzer drin irgendwie?


3) Mit 3 Lichtern die ich aktuell habe (ohne optimierungen durch sachen wie ScissorRect etc) habe ich bei 1024x768 und 100.000 Triangles ca. 80 fps.. wenn ich es wie früher mit einem "SuperShader" mache, der alle 3 Lichter gleichzeitig berechnet komme ich auf ca. 150fps (selbst wenn ich so nah an der geometrie bin, das jeder pixel geshaded werden muß).

ein kurzer Test hat dann ergeben das mit jedem Renderpass den ich in den Framebuffer packe es ca. 10fps langsamer wird (1 Licht = 100fps, 2 Lichter = 90fps, 3 Lichter = 80fps etc.)..

Aber mal schauen.. wenn erstmal alle optimierungen drin sind, wird es hoffentlich wieder schneller.. :)
Oder hat irgendwer noch ein paar tolle tips zufällig? :p

Aya~

EDIT: Hab es grad auch mal hier in der firma an meinem rechner gestartet... hier "läuft" es mit sagenhaften 10fps..
Grafikkarte ist eine GeForce 7800GT.. allerdings 78.01er Treiber. Können die Treiber daran schuld sein das es hier so lahm läuft? Also es sieht alles richtig aus, nur ist halt langsam.. :p
Treiber updaten kann ich leider nicht, da Maya nur mit 7x'er treibern gescheit läuft (8xer Treiber machen Viewport darstellungs fehler, und 9xer Treiber haben ja das problem mit der Selection (GL_SELECT) welches super lahm ist.. und Maya nutzt das leider sehr excessiv -.-)


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 17 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » Shader


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.009s | 16 Queries | GZIP : On ]