Antworten auf deine Fragen:
Neues Thema erstellen

[R15]Projektionsprobleme (+Workarround)

kraid

reMember

Da ich mich sehr viel mit der Erstellung von Lowpoly Spiele-Inhalten beschäftige, war die Einführung von Sculpting in R14 und jetzt die Mesh Projezieren Funktion der R15 ein sehnlichst erwartetes Feature für mich.

Mir war zwar auch vorher schon klar, das das backen des sculptings in C4D keinen hundertprozentigen Ersatz für externe Anwendungen wie xNormal bieten wird, dennoch bin ich schon recht schnell auf ein paar unschöne Eigenheiten gestoßen.

Das Hauptproblem ist nach wie vor der Mangel an echter Highpoly>Lowpoly Projektion, was auch durch die Mesh Projezieren Funktion nicht wirklich gelöst wird.

Da der Focus auf Spiele-Content liegt, arbeite ich aussschließlich mit Normalmaps in tangent-space. Die Projektionsprobleme dürften aber auch auf andere Normalmaparten zutreffen.
Displacements hingegen sollten weniger davon betroffen sein, da dort mit SPD gearbeitet wird.

Zur Veranschaulichung, hier mal ein kleines Beispiel

1 ist das Highpoly mesh, während 1a 1b und 1c verschiedene Varianten darstellen welche alle mithilfe von xNormal entstanden sind.

Reihe 2 sind die Fehlversuche in C4D und Reihe 3 würde ich jetzt mal als Workarround bezeichnen.

2a liegt total daneben, das Ergebnis sollte eher aussehen wie 1a.

2b und 2c entstanden aus einer Projektion mit Kanten Bevel, wobei 2c noch zusätzlich Phong-Unterbrechungen an den Kanten der UV islands hat.
Leider wird hier die entstehende Normalmap extrem verzerrt.

Reihe 3 letztendlich benutzt ein von vornherein gleichmäßig unterteiltes Mesh als Grundlage, was eine sauberes und gleichmäßiges projezieren ermöglicht.
Nach dem backen wurden dann in 3a die zusätzlichen Loops aufgelöst und 3b stellt das finale triangulierte Mesh dar.
3c ist eine weitere Variante mit etwas geringerer Unterteilung des Ausgangsobjektes, was zu einer breiteren Bevel-Kante führt.

Korrekterweise müssten jetzt noch die Normalen von 3a auf 3b und 3c übertragen werden, da durch das wegfallen der Unterteilung noch geringfügige Verformungen Stattfinden, aber ich finde das Ergebnis auch so ausreichend überzeugend.

Das Problem ist nur, das dieser Workarround bei etwas komplexeren Modellen nicht nur sehr Zeitraubend sein kann, sondern evtl. auch neue Probleme aufwirft.

Fazit: xNormal wird bei mir auch weiterhin genutzt werden.
Die Eigenheiten der C4D internen Projektion sind nur in Ausnahmefällen von Vorteil.
 
Zuletzt bearbeitet:

kraid

reMember

AW: [R15]Projektionsprobleme (+Workarround)

Und hier noch ein Beispiel aus der Praxis.

Im mittleren sind schon die Polygone für Beintaschen und Gürtel ausgespart und das linke Baking ist dezent älter,
fehlt aber nur der Reißverschluß.

Insgesammt eher eine zweischneidige Sache.
Während der Cinema bake an vielen Stellen sogar besser rüber kommt, fallen vor allem die Verzerrungen in Bereichen in denen das Einschnüren eingesetzt wurde doch etwas negativ auf.

Der xNormal bake hingegen punktet genau dort, aber hat Probleme an Stellen wie dem Kragen (hab ich schon in Photoshop nachgebessert).
Da ist Cinema im Vorteil, denn jetzt sorgt das Verzerren für eine Artefaktfreie Projektion, während man bei xNormal die typischen Wellenlinien erhält.
 
M

mp5gosu

Guest

AW: [R15]Projektionsprobleme (+Workarround)

Ich hoffe, ihr habt euch Grundlagen zu Gemüte geführt, wie Smoothing Groups, Islandsplitting, Channel-Swizzling und Viewportdarstellungen. Das in Post #1 angeführte Problem exisitert seit Jahren auch in anderen Packages wie Maya und Max. Auf polycount.com im Wiki ist das alles haarklein erklärt, dafür gibts auch Threads mit hunderten Seiten, die sich mit dem Problem befassen.

Dass Cinema da was von vornherein falsch macht, war mir irgendwie klar. Aber das Feature ist nunmal unausgereift und rudimentärer Natur.

edit: Was Du da in Reihe #3 machst ist ein Unding. Das kann und wird nicht funktionieren, weil die Smoothing Groups von der berechneten Fläche abweichen und so falsche Darstellungen verursachen. Auch, wenn es richtig aussieht, so ist das Ergebnis immer falsch. bei komplexeren Geometrien wirst Du das erkennen.
 
Zuletzt bearbeitet von einem Moderator:

kraid

reMember

AW: [R15]Projektionsprobleme (+Workarround)

Das der Workarround in Reihe 3 nicht ganz unproblematisch ist, hab ich ja auch gesagt. Die geringfügigen Abweichungen in der Geometrie fallen bei diesem Beispiel kaum ins Gewicht. Das kann bei anderen Objekten wiederrum ganz anders aussehen.

Der Moment der Wahrheit kommt sowieso erst wenn das Mesh dann trianguliert in einer Echtzeitanwendung betrachtet wird.
Dazu komm ich später noch.

Übrigends, bei einem Abstecher in die C4D Hilfe hab ich gerade noch eine "Kleinigkeit" entdeckt.
Wenn man das Häckchen bei obere Stufen einschließen setzt, dann wird das Baking und auch die Geometrie entscheidend beeinflußt.

Hier mal ein Beispiel

Das Baking auf den einfachen Würfel (2) sieht nun korrekt aus und dürfte dem xNormal Bake sehr ähnlich sein.
Leider wird auch die Geometrie des Objektes verformt, was unter Umständen nicht wünschenswert ist.

Bei höherer Ausgangsunterteilung fällt diese Verformung weit weniger stark ins Gewicht. (4 = obere Stufen einschließen aktiviert, 6 = deaktiviert)

Interessant wird das ganze aber erst wirklich bei Würfel 3 (aktiviert) im Vergleich zu Würfel 5 (deaktiviert).

Die Verformung der Geometrie wirkt der Texturverzerrung entgegen, wodurch ein orginalgetreueres Abbild des Sculptings entsteht.
 
M

mp5gosu

Guest

AW: [R15]Projektionsprobleme (+Workarround)

Na, das sieht ja schon besser aus. Aber das LowPoly zu verformen ist ja auch ne "Frechheit" von Cinema 4D. Wenn das LowPoly keine Rolle spielt, mag das ja ne gute Idee sein, aber generell....? :(
Auf jeden Fall vielen Dank für die Infos und die Mühe, das war sehr aufschlussreich. ;)
 

einfachder

Nicht mehr ganz neu hier

Hey! Schön dass ein Thread offen ist was C4D, xNormal und Smoothing groups etc. angeht. Ich habe da noch einige offene Fragen, da ich schon so einige Nächte mit Experimenten verbracht habe.
Vorweg die Pipeline (Highpoly-Lowpoly):
C4D -> OBJ Export mit Riptide -> UV Layout 2 -> xNormal -> OBJ Import mit Riptide nach C4D
- Also als erstes hab ich Fragen bezüglich dem Phong Tag. Werden die Winkelbeschränkungen mit exportiert? Oder nur ob eine Kante weich / hart ist?
- Wie sind eure Erfahrungen mit dem Phong Tag -> xNormal? Irgendwelche Tipps?
- Welche Dinge sollte ich beim Export / Import mit Riptide beachten, ist es ratsam "Normals" auszuschalten beim Export? (Also nicht die Normalen - die lass ich immer an. Normals sind doch die Vertexkoordinaten/Winkel?)
- Verstellt einer von euch zufällig die Swizzle Coordinates?
- MeshScale Setting bei xNormal -> Ich lasse die Skalierung immer auf 1 - hat jemand Erfahrungen mit besseren Werten? Beispielsweise soll man ja bei Blender "1000" eingeben und bei 3Ds Max "5", wie sieht es mit C4D aus?
- Sollte man bei 90° Kanten die UV Inseln immer trennen?

Ich bin mit meiner Pipeline noch relativ am Anfang, konnte einige Ergebnisse erzielen, aber ich wäre sehr dankbar Gleichgesinnte hier zu finden, die schon jegliche Szenarien durch hatten. Es sind einfach so viele Faktoren :(
Die Manuals und Videos der tools (xN, UVL2, Riptide) hab ich durch - aber sie beantworten nicht alles, vorallem nichts was mit C4D zutun hat :p

lg,
Vito
 
M

mp5gosu

Guest

Phong Tag wird beim Export automatisch zu "Normalen". Das Phong-Tag ist eine C4D-interne Lösung.
Mit R12 hatte ich immer das Problem, dass der Exporter keine Normaleninformationen mitexportierte, daher Riptide->Export Normals (eigentlich am wichtigsten), Vertexnormals kann man machen - von haus aus kennt C4D keine manipulierbaren Vertexnormalen, aber es gibt da ein Plugin. Ist also Dir überlassen.
Swizzle kommt auf das Target an. Also die Zielumgebung. Normalerweise X+ Y+ Z+ (bei Max, Marmoset, etc. Y-)
Mesh Scale (in xNormal) kannst Du lassen, wie es ist. Es sei denn, es kommt ne Fehlermeldung von wegen Mesh zu klein. Aber man kann den Wert auch dazu nutzen, das Baking zu optimieren - das ist aber eine Fallsache und immer unterschiedlich.
>85° = Immer trennen. Alles andere führt entweder zu Verläufen oder Nähten. Auf die entsprechende Naht in der UV achten!
 

einfachder

Nicht mehr ganz neu hier

Danke für die erste Antwort. Das mit dem Baking optimieren interessiert mich. Gibt es da einen gewissen Einheiten-Rahmen, also nehmen wir als beispiel ein 1000cm großes objekt in C4D - wie sollten dann die verhältnisse beim export bzw xNormal sein?

Das mit den Vertexnormals ist wohl eher unwichtig für mich, oder wie schätzt du das ein? Hört sich so an, als ob du das nie verwendet musstest / bzw. nicht brauchst.
Wie sieht es mit den Einstellungen bei xNormal aus wo man den Durchschnitt der Vertexnormalen einstellen kann aus der DropDown Liste... Ist damit was anzufangen?
lg
 
M

mp5gosu

Guest

Huhu,

Die Einheiten sind relativ und bestimmen einfach nur die Genauigkeit beim Backen. Heißt: ist das Objekt bspw. nur 0.2 Einheiten klein, gibt's Einbußen bei der Genauigkeit. Beispiel: xNormal nutzt beim Rendern Fließkommawerte. Sagen wir, für eine Vertexnormale fällt bei einer Skalierung von 0.1 ein Wert von 0.01299956 an. Wenn Du jetzt eine Skalierung von 10 hast, liest sich der Wert etwas anders: 1.29995634. Wie Du siehst, ist also die Genauigkeit erhöht. Ob man das nachher aber tatsächlich sieht, ist ne andere Frage. Bei zu kleinen Werten gibts jedoch einen deutlichen Unterschied. Das wirkt sich auf alle Backoptionen aus (Normale, AO, etc.)
Da C4D nichts mit Vertexnormalen anfangen kann und die eigentlich auf dem Phong-Shading basieren, kannst Du die außen vor lassen.
Durchschnitt der Vertexnormalen brauchst Du niemals, Du brauchst immer nen Cage. Leider ist C4D auch hier hinterher. Man kann zwar ein Duplikat des Lowpoly erstellen und einen Cage "faken" - allerdings muss der Cage bestimmten Regeln gehorchen, welche in C4D schwer einzuhalten sind, bei gleichzeitiger Flexibilität. Also würde ich in xN den Cage erstellen und per Autoassignment zuweisen.
Der "Smooth normals" Parameter sollte eigentlich immer auf "Use exported Normals" stehen - schließlich haste ja die Normalen mitexportiert. S.o.. :)
 

einfachder

Nicht mehr ganz neu hier

Danke für die gute Erklärung!
Weisst du zufällig warum C4D nichts mit Vertexnormalen anfangen kann? Beeinflusst das den Workflow in irgendeiner Weise?

Leider ist C4D auch hier hinterher. Man kann zwar ein Duplikat des Lowpoly erstellen und einen Cage "faken" - allerdings muss der Cage bestimmten Regeln gehorchen, welche in C4D schwer einzuhalten sind, bei gleichzeitiger Flexibilität.

Also bei mir hat das bisher ganz gut geklappt? Ich skaliere immer mein LP über "Skalieren (Normalen)" - und der Abstand darf von Ecke zu Ecke variieren falls es mal enger wird.
Welche Regeln? Der Cage muss doch nur die gleiche Topo habe und HP & LP einschließen....
(Thema: Flexibilität... Ja jedesmal einen neuen Cage erstellen ist doof :D )

Für mich wäre interessant ob ein Blocker soviel anders arbeitet als ein Cage. Weil dort ist die Topo ja egal, könnte man nicht so eine Art Antiportal Cage um das Model bauen und dann einfach als Blocker laden (nur rein theoretisch) - welche Nachteile hätte das bis auf die verschiedenen Ray Distances
 
M

mp5gosu

Guest

Richtig, die Topologie muss exakt gleich sein. Du kannst in C4D zwar mit dem Move Tool und aktivierter Option "Along Normals" bei gleichzeitiger Z-Beschränkung einzelne Vertices verschieben, verlierst dadurch alelrdings absolute Kontrolle über den Cage. In anderen Programmen ist ein Cage parametrisch, kann also per Schieberegler genauestens eingestellt und notfalls zurückgesetzt werden. In C4D ist das einfach nur unnötiges Gefummel, selbst in xN geht's schneller.
Ein Blocker-File macht eigentlich nur dann Sinn, wenn Du AO, Displacement und ähnliches renderst oder bei schwierigen, dicht aneinandergrenzenden Partien. Ray Distances = schlecht (bei komplexen Modellen). Die verursachen zwangsläufig immer Lücken oder Überlappungen. Daher nimmt man nen Cage, so werden Ray Distances hinfällig, da ja der Cage selbst aufgrund seiner Topologie quasi die Ray Distances und Richtungen "bereitstellt". Rays Distances sind mehr ne Art einfache Lösung für planare Objekte.
 

einfachder

Nicht mehr ganz neu hier

Ja nichts geht über einen Cage, das habe ich direkt am Anfang gelernt.
Diese ganze Phong Geschichte wirft mir trotzdem noch einige Rätsel auf :D
Arbeitest du persönlich mit smoothing groups? Das wär ja in C4D ein Phong Tag mit unterbrochenen Phong Kanten oder irre ich mich?

Wie macht man das eigentlich am besten mit dem Phong Tag, sollte man ihn beim LowPoly oder beim HighPoly einstellen oder bei beiden? Wäre es schlimm wenn das highPoly garkeinen Phong Tag hat?
- Ist beim Cage der Phong Tag egal? Wird der überhaupt ausgewertet?

Also zusammengefasst
Was sind die Dinge....
- die dir wichtig sind beim Lowpoly export aus C4D
- die dir wichtig sind beim Highpoly export aus C4D
- die dir wichtig sind beim Cage export aus C4D

Und was noch interessant wäre, verändert ein Programm wie UV Layout 2 irgendwas an den Normalen / Phong Winkeln? Und ist es vielleicht ratsamer ein OBJ ohne Riptide zu importieren?

Ich kann mit sovielen Fragen im Kopf immer schwer einschlafen :D
Sorry dass ich soviele Fragen habe, habe schon soviele Doku's und Artikel durch (Auch polycount etc) - Ich will auf dem Gebiet keine offennen Fragen haben.
Die Leute die mit 3DS arbeiten haben es wohl einfacher^^

Und ich bin echt froh in dem Forum hier auf Gleichgesinnte zu treffen!!

Danke im Voraus,
Vito
 
M

mp5gosu

Guest

Ich persönlich arbeite mit Max, C4D gibt mir nur eingeschränkte Möglichkeiten.
Smoothing Groups (Bsp. Max) und Phong Tags usw. sind anwendungspezifische Sachen, die im jeweiligen Package nur der Darstellung dienen. Erst beim Export werden diese Informationen in ein eigenes Format (Normaleninformationen) umgewandelt.
Das Phong-Tag wirst Du nur bei Deinem Lowpoly brauchen, beim High-Poly vermutlich auch, damit die Oberfläche glatt wird. ;) Hier gilt beim Highpoly: What you see is what you get.
Der Cage braucht keinen Phong-Tag, da er mehr oder weniger nur eine einfache Repräsentation Deines Lowpoly und Deiner UV-Map ist. Hier sind einzig und allein die Vertices wichtig.
Dinge, die wichtig sind:
LowPoly:
  • Korrekte Topologie
  • Genügend Geometrie
  • Korrekte UV-Map
  • Phong-Breaks entsprechend der UV-Map
  • Phong-Winkel 180°
  • Sollte nicht zu stark vom HighPoly abweichen
HighPoly:
  • WYSIWYG (what you see is what you get)
  • Polypaint (gibt's in C4D nicht :p )
  • korrektes Modeling/Shading
Cage:
  • Einschließen des HighPoly
  • Cage-Splits nur wenn nötig (entsprechen UV-Seams)
  • so viel wie nötig, so wenig wie möglich extrudieren
  • evtl. nacharbeiten/Blocker-File benutzen
Zusätzlich: Es kann Sinn machen (und das macht es meist auch), Objekte zu "exploden", also um eine gegenseitige Überschneidung zu verhinden.

Ein Programm wie UV-Layout kann durchaus was ändern, auch wenn das nicht so sein sollte. Nämlich beim Export. Die Objekte sind natürlich von ihrer Position/Größe abhängig, sie müssen deckungsgleich sein. Auch die Triangulation sollte man nicht außer acht lassen. Vor dem Backen einfach nochmal alles in ein File packen und prüfen. Evtl. kannst Du auch einfach nur die UV-Map importieren (wenn's da ne Möglichkeit gibt - dazu weiß ich grad nix).
Auf polycount findest Du eigentlich das gesamte Kompendium an Wissen zum Thema Normalmap. Mehr wirst Du nirgendwo finden. :)

Und ja, es ist einfacher in Max. Allerdings muss man auch da Abstriche machen. Da es beim NormalMap-Baking keinen einheitlichen Tangentbasis-Standard gibt, muss man so oder so Kompromisse eingehen. xN hat einen Tangent-Basis Calculator, der sehr viele Probleme (Symmetrie, Degenerierte Flächen, Index-Abhängigkeiten, hard Edge-Splits, etc.), die die meisten haben, umgeht bzw. behebt. Daher nutze ich meist xN - ist ohnehin der schnellste.

Am einfachsten ist immer Learning by Doing und das gilt besonders bei Normal-Map Generation. :)
 

einfachder

Nicht mehr ganz neu hier

Eine wahre Geschichte.
:D
Ich bin froh eine so ausführliche Antwort von Leute wie dir zu bekommen, ist keine Selbstverständlichkeit in Foren heutzutage! Danke

Das mit dem 180° war mir neu

Zitat:
  • Phong-Breaks entsprechend der UV-Map
  • Phong-Winkel 180°
Ich soll also überall einen Phong Break einfügen, wo die UV-Polygone keinen Anschluss haben?! o_O

Zitat:
"Cage-Splits nur wenn nötig (entsprechen UV-Seams)"
-> Versteh ich nicht :D Genauer?

Ich gehe jetzt einiges ausprobieren.

Polypaint ist doch nur in der Characterwelt sinnvoll oder irre ich mich. Bzw bei Kästen, Blöcken, o.ä.
 

kraid

reMember

Ich selbst nutze die in C4D integrierten UV-Tools, kann deshalb also nichts über die verlässlichkeit der Konvertierung von UVL2 sagen.
Je mehr Programme an irgendwas beteiligt sind, desto mehr mögliche Fehlerquellen gibt es.

Ich exportiere auch immer das triangulierte LP direkt aus C4D meist mit fbx.
Phongtag mit Winkelbeschränkung hab ich mir auch ganz schnell abgewöhnt, ich setzte immer Harte Kanten an den entsprechenden Stellen und stell den Phongwinkel auf 180°.
Dann, wie gesagt, triangulieren und letztendlich mit dem Vertex Normal Tool einen Normal-Tag erstellen und ggf. ein paar problematische Normalen noch etwas nachjustieren.

xN verdaut das ganz gut, wobei zum baken dann eh meist die smb meshes benutzt werden, da man fast immer einen Cage benötigt und der meist am schnellsten im xN 3d view erstellt ist.
 

einfachder

Nicht mehr ganz neu hier

Moin kraid! Interessant. Kannst du mir mehr dazu sagen, wieso du triangulierst??
Was meinst du mit dem "Vertex Normal Tool" (Kenn ich nicht) und was wären problematische Normalen?

Das mit Herr UVLayout hab ich geklärt, ich hatte mit ihm ein Gespräch wo wir uns drauf geeinigt hatten dass ich nach dem UV'n NUR den UV Tag auf mein Original LP in C4D verschiebe. Er war einverstanden. Somit müsste dort keine Problemquelle in Zukunft sein.

Warum FBX? OBJ ist doch nice - Unity, UE usw. schlucken FBX wohl besser? Aber wenn ich in dem Bereich rummachen würde, wäre ich eh bei Max oder Maya gelandet.

Edit:
FBX wegen Animationen?

Viele Grüße,
Vito
 
Zuletzt bearbeitet:

einfachder

Nicht mehr ganz neu hier

Habe es so wie ich es wollte geschafft.
Späßchen am Rande (vorhin im WhatsApp mit einer Freundin):
=========================================
Sie (7:27 Uhr):
was machst du? :)

Ich:
Backen :))

Sie:
Was denn? :D

Ich:
Ich weiss das wird sich gleich komisch anhören...

Sie:
ja
sag

Ich:
Ich backe eine normal-map, displacement-map, ambient occlusion-map und eine convexity-map welche von einem highpoly-mesh auf ein lowpoly-mesh mit Hilfe von xNormal (Santiago Orgaz) "projeziert" werden unter Berücksichtigung bestmöglicher ray distances dank eines Käfigs (cage) der in Cinema4D (Maxon) durch eine Normalenverschiebung (auch extrusion genannt) erstellt wurde und danach wurden alle drei polymeshes sauber mit Riptide (Skinprops) ins *.obj Format (wavefront) exportiert, eine Triangulation fand nicht statt. Natürlich wurden vorher saubere UV Koordinaten mit UVLayout2 (Headus) unter berücksichtigung der smoothing groups (in meinem Fall gebrochene Phong Kanten) erstellt und der UV-Tag auf das original lowpoly-mesh hinzugeladen (UV-Tag kopieren). Die ambient occlusion map wurde mit 512 Rays und einem 150° spread Winkel gerendert und für feinere Details danach in Photoshop mit dem red-channel der convexity map multipliziert (75%). Die AO selber wurde ganz sanft etwas weich gezeichnet. Alle maps liegen in 4k und 4xAA vor. Ich habe exakt 150400 Polygone eingespart (800 polys nach dem backen) und das Render entspricht genau meinen Vorstellungen.

Sie:
okay...

Ich:
Den Prozess nennt man auf deutsch Texturen backen

Sie:
Hört sich aber nicht nach schlaf an
=========================================

Ich war mir an der stelle mit den ray distances nicht sicher - der cage dient doch als Hilfe für bestmögliche ray distances oder seh ich das falsch
:D :D
 
M

mp5gosu

Guest

Ich soll also überall einen Phong Break einfügen, wo die UV-Polygone keinen Anschluss haben?! o_O

Ja, denn dort, wo die UV-Nähte sitzen, werden die Punkte entsprechend der Anzahl gemeinsamer Punkte berechnet. beispiel: Unwrappst Du einen Würfel, hast Du 6 Flächen. Jeder dieser Flächen besteht aus 6 Punkten. Wenn Du alle Flächen voneinander trennst, landest Du bei 24 Punkten, in der Geometrie hast Du aber lediglich 6 Punkte. Allerdings wird jeder der UV-Vertices in die Berechnung mit einbezogen. Daher sollte man das Shading dort unterbrechen, da ansonsten 2 Rays oder mehr auf einen Punkt kommen und so ein Durchschnitt berechnet wird - ergo gibts ein falsches Ergebnis.
Daher macht man das so, dass Edges, die einen großen Winkel aufweisen (>80-90°) splittet, um diesem Umstand entgegenzuwirken. Andernfalls endet das in falscher Berechnung und Nähten oder Gradienten (je nachdem, ob man das Shading, aber nicht die UV trennt, oder ob man zwar die UV trennt, jedoch nicht das Shading).

"Cage-Splits nur wenn nötig (entsprechen UV-Seams)"
-> Versteh ich nicht :D Genauer?

Brauchst Du eignetlich auch nicht. Aber es kann Sinn machen. Ein Beispiel wäre das "Wavy Lines"-Phänomen bei Zylindern. Als erstes wirst Du bei solchen Anfragen zwar immer "Add more Geo" ins Gesicht geknallt bekommen, es geht aber auch anders.
Stell Dir vor, Du hast einen Zylinder mit 16 Seitenflächen (Highpoly mit 256 - also schön rund). Setzt Du nun einen Cage und fügst eine Extrusion hinzu, Hat der Cage überall den gleichen Abstand. Da aber 16 Flächen recht wenig (und Deckfläche zu Mantel rechtwinbklig) sind, wird die Interpolation von einem Punkt zum anderen sichtbar - das Resultat sind Wellen.
Wenn man jetzt den Cage an den Deckflächen trennt, kann man die Deckflächen so nah wie möglich an das Highpoly ransetzen, um den Fehler zu minimieren; da ja auch die Abstände zum Highpoly geringer werden.

Polypaint ist doch nur in der Characterwelt sinnvoll oder irre ich mich. Bzw bei Kästen, Blöcken, o.ä.
Nö, Polypaint ist immer sinnvoll, besonders bei HighPoly-Objekten. Du sparst Dir das Unwrappen, kannst munterlustig, basierend auf der Topologie, auf dem Objekt malen, musst Dir keine Gedanken über Alphas u.ä. machen und kannst bei Bedarf alles in eine Textur backen.

edit:
Ich bastel gerade an einem Projekt mit Früchten. Hier sind 2, mit denen ich angefangen hab. Beide komplett per Polypaint texturiert:
[url=http://abload.de/image.php?img=fruit2q2up3.jpg] [/URL]
 
Zuletzt bearbeitet von einem Moderator:

kraid

reMember

Moin kraid! Interessant. Kannst du mir mehr dazu sagen, wieso du triangulierst??
Was meinst du mit dem "Vertex Normal Tool" (Kenn ich nicht) und was wären problematische Normalen?

Das Vertex Normal Tool:

Die Lite Version ist kostenlos, aber bietet eben weniger Funktionen, d.h. mehr handarbeit beim Ausrichten der Normalen.

Wissenswertes zum Thema:


Problematische Normalen sind z.B. das hier:


Links ist das Shading i.o. aber sobald der Zylinder trianguliert wird ändern sich die Vertex normalen und das Shading wird schief.

Um das gerade zu rücken gibt es zwei Möglichkeiten.
Die Erste funktioniert nur bei gerader Seitenzahl des Zylinders und besteht darin die Triangulierung manuell im Zickzack durchzuführen.
Die zweite nutzt das Vertex Normal Tool oder vergleichbare Tools/Modifier in anderen Programmen, funktioniert unabhängig von der Seitenzahl und auch bei anderen Formen.

Zu deinem WhatsApp Späßchen:
Ich backe eine ....Bahnhof, Bahnhof, Zug kommt, weißes rauschen....
So in etwa dürfte das am anderen Ende angekommen sein.
Aber ich denke mal das war auch so beabsichtigt.
 

einfachder

Nicht mehr ganz neu hier



Hier das aktuelle Projekt. Es gab viele Hindernisse :p
Das erste Bild ist mit Normalmap & AO, das andere sind einfache highpoly screens

die harten Kanten bei den Übergängen auf screen2 sind behohen, das aktuelle Model hat kein Macken.
beim ersten screen sind es 800 polys, runtergerechnet von 150 000
(Dies ist natülich kein Modell für eine Gameengine :p )
 
Zuletzt bearbeitet:
Bilder bitte hier hochladen und danach über das Bild-Icon (Direktlink vorher kopieren) platzieren.
Antworten auf deine Fragen:
Neues Thema erstellen

Willkommen auf PSD-Tutorials.de

In unseren Foren vernetzt du dich mit anderen Personen, um dich rund um die Themen Fotografie, Grafik, Gestaltung, Bildbearbeitung und 3D auszutauschen. Außerdem schalten wir für dich regelmäßig kostenlose Inhalte frei. Liebe Grüße senden dir die PSD-Gründer Stefan und Matthias Petri aus Waren an der Müritz. Hier erfährst du mehr über uns.

Stefan und Matthias Petri von PSD-Tutorials.de

Nächster neuer Gratisinhalt

03
Stunden
:
:
25
Minuten
:
:
19
Sekunden

Flatrate für Tutorials, Assets, Vorlagen

Zurzeit aktive Besucher

Statistik des Forums

Themen
118.614
Beiträge
1.538.351
Mitglieder
67.525
Neuestes Mitglied
mgtaucher
Oben