digitalartforum

hallo!

ich hab da ein paar probleme mit den normal maps und hoffe dass mir jemand von euch helfen kann

also, problem nr. 1 ist, ich möchte bei einer brücke die geometrie flippen, also hier das markierte objekt:



zunächst haut das dann auch mit der normal map hin (abgesehen davon, dass die normal map ansich noch nicht ganz korrekt ist ):



wenn ich dann aber die meshes kombiniere, werden die normals invertiert, also folgendes ergebnis:



das kann ich zwar umgehen, wenn ich die normals vom geflippten objekt vor dem mergen invertiere, aber ich glaub die lösung ist nicht ganz so elegant... weiß da jemand eine bessere lösung dafür?

------------------------------------------------------

und problem numero zwei ist, dass das high quality rendering in maya bei mir nicht hinhaut... die einzige info die ich dazu im internet gefunden hab, war, dass es an der hardware liegt. kann ich mir aber nicht ganz vorstellen, ich hab eine nvidia geforce 8800 gts 512, mit neuesten treibern. bei den options in maya hab ich auch schon alles mir bekannte versucht, aber mehr als den wireframe kann ich einfach nicht sehen. hat da wer eine lösung parat?


danke schonmal, ich hoffe ihr könnt mir aus der patsche helfen

das liegt denke ich am viewport shader von maya - der interpretiert das anscheinend "falsch". weiss nich ob man das umgehen kann. sprich du machst nix verkehrt an sich

aber solange es in der engine funktioniert isses ja halb so wild.

hey, danke für die antwort!

das problem ist - hätte ich vielleicht noch erwähnen sollen - dass es schlussendlich nicht in einer game engine verwendet wird... es wär also wünschenswert wenn ich das irgendwie in maya so hinkriegen könnte dass auch maya es richtig anzeigt

Es liegt schlicht daran dass Du mitsamt dem Model auch die UV Koordinaten spiegelst und somit die Normalmap verkehrt herum sitzt. Die Farben auf der Normalmap sind nämlich Wegweiser für die Normalen der Faces, wenn Du die Farben umdrehst zeigen auch die Normalen woanders hin.

Lösung: Model spiegeln, Model mergen, Normalmap vom gesamten Model erzeugen und dann drauf bügeln.

oder nen shader verwenden der damit umgehen kann, mirrored UVs sind eine absolut gängige technik für Realtime Modelle um Textuplatz zu sparen, Shader die damit umgehen können gibt es seit Ewigkeiten, das die bei den Programmen mitgelieferten Shader und Offline Renderer nicht damit umgehen können ist eigentlich ein totaler Witz

@bruZard: danke für deine antwort, allerdings ist es schon so wie neox gemeint hat, die modelle die ich gerade mache werden zwar in keiner game engine eingesetzt, mein ziel sind aber durchaus modelle, die in echtzeit funktionieren _würden_ - sprich, ich wollte flippen, um texturplatz zu sparen

@neox: danke, gut zu wissen, dass das am shader liegt welche können denn mit mirrored uvs umgehen?

@Neox: Dass viele Engines sich diesen Shader sparen liegt einfach daran dass die Grafiker mittlerweile derart exzessiv Gebrauch von Shadern machen dass man lieber mehr Speicher veranschlagt als noch Mirror-Cycles zu vergeben. Eine Normalmap die gespiegelt wird muss drei Mal durch die Pipe: Einmal um für den "normalen" Teil des Levels verwandt werden zu können, dann durch den Mirror-Stack um die Komponenten zu spiegeln, dann nochmal in die Pipe um auf den gespiegelten UVs angebracht werden zu können.
Nun sind auch noch durchaus Grafikkarten in Gebrauch die Shader mit Subs oder Loops nicht so toll finden, was bedeutet dass jeder Step durch die CPU neu initialisiert werden muss. Systeme mit GraKas dieser Generation sitzen auch selten hinter Prozessoren die besonders stark sind. Ergebnis: Es wird ein Höllenritt mit FPS um Aussentemperatur. Dann lieber einen Megabyte mehr Speicher veranschlagen und die Normalmap in einem Zug durchschleifen.

Mein Szenario ist natürlich "worst case", aber ich selbst habe noch Systeme die diesem Fall entsprechen.

Naja so einfach ists dann doch nicht, der Flaschenhals heutzutage ist eher der Speicher als die CPU/GPU Power, 1MB mag es vielleicht bei kleineren Texturgrößen sein, in diesem Fall ne 512er unkomprimiert, je nach Komprimierungsart entsprechend größer. Wenn man nicht gerade von den neuen Grafikspeichermonstern mit 1024-4096 MB VRam ausgeht, kann man sich darauf verlassen, dass eine Speicherersparnis (natürlich je nach Spiel, denn gibts ja welche die von Natur aus nicht so viel Speicher benötigen) in jedem Fall gegenüber einfachen Umrechnungen bzw kleinen Datenänderungen im Exportformat vorzuziehen ist, da dieser Speicher je nach Anwendungsplattform in andere Dinge wie Animationen (wenns um reinen Grafikspeicher geht) oder auch Sounds und dergleichen bei Shared Memory Lösungen wie auf modernen Konsolen ablaufen soll. Syteme die du ansprichst dürften genausp allerdings auch ein Speicherproblem haben, ist ja nicht so, dass früher einfach mal mehr Speicher drauf war, nur einfach die CPUs zu schwach waren.
Ausserdem ging es mir garnicht um Engines in denen das aus diesen und jenen Gründen nicht funktioniert sondern um mitgelieferte Shader für Realtime und Offline Rendering in Grafiklösungen wie Maya, Max, XSI und Konsorten, denn da ist es herzlich egal wie viele operationen die Umrechnung benötigt, effiziente UVLayouts aber je nach Verwendungszweck, wie zum Beispiel Portfolioarbeiten, einfach ne gute Sache für Zukünftige Arbeitgeber sind.

Was deine Frage angeht, Manticora, da kann ich leider nicht viel helfen, da ich mich mit Maya nicht auskenne, da müsstest du dann mal in Etnwicklungsnahen Foren wie Polycount oder Gameartisans schauen oder nachfragen.

okay danke, dann werd ich mich dort mal umschaun