Jetzt hab ich da mal eine Frage eher technischer Natur für die Source-Engine-Experten unter euch !

Gestern hab ich dieses hier gemodelt !

Mein Plan ist jetzt folgender gewesen. Ich wollte jedes Model einzeln kompilieren
mit jeweils der gleichen Textur, die sie sich alle teilen. Ich hab in der letzten Zeit
einiges über diese Art von Modelling gelesen - Vor- Und Nachteile inbegriffen.
Jetzt frag ich mich aber trotzdem. Wie sähe das denn in Source aus, was die Performance angeht ?

Frage:
Ist es egal, ob ich dieses Beispielmodel links als ein großes Model kompilier oder sich der Mapper das selbst aus vielen kleinen Models zusammenbastelt - also rendering-technisch ? Wie gesagt die Textur haben alle die gleiche - sagen wir eine 256er Textur ? Die Polygonzahl bleibt ja gleich, das ist klar...
Aber wie sieht das mit "Texturspeicher" aus - Gibt es da gravierende Unterschiede ?
Oder die vielen kleinen Models haben ja auch mehrere kleine Collisionsmodels anstatt wenige große, wie es anders der fall wäre.
Weil ich steig da immer nicht durch diese höchst technischen Engine-Angelegenheiten durch. Manchmal heißt es ja z.b., wenn ein Model einmal geladen ist, ist das für die Performance nicht sooo schlimm, wenn es mehrmals in einer Szene verwendet wird.

Mir fehlen grad die Worte, sry, in meinem Kopf hatte ich das Problem relativ gut geklärt :D

Also lieber so die Fragestellung: Gibt es spürbare Vor- oder Nachteile wenn ich viele kleine Models statt ein großes Model in einer Map verbaue - von der grundlegenden Mapdownloadgröße einmal abgesehen ?
Vielleicht könnt ihr ja ein bisschen Licht in meinen Tunnel bringen :)
Weil ich fände es halt super, wenn mein Mapper-Schorsch sich da selbst ein paar coole gebilde zimmern könnte !

Als guideline für mich hab ich mir dieses unreal dokument zurate gezogen - unten den teil bei performance vor allem !
vor allem unten steht da halt was mit dem gras, wo ich denk, hmmm, das ist ja das gleiche wie mit den rohren:

http://udn.epicgames.com/Two/WorkflowAndModularity.html

Zitat:

"Avoid having lots of low-poly meshes when creating grass, for example. Instead combine those meshes into single larger meshes. Don't take this concept too far, however, remember the engine cannot cull only sections of a mesh, it has to cull the whole thing."

Combine small meshes into single, larger meshes if they're in an isolated location. Remember meshes get culled altogether. For example, reducing 100 individual grass meshes into a single mesh will be a big performance win

ich würde mich auf jeden fall über einige interessante und aufschlussreiche beiträge von euch freuen, wenn mir da jemand praxisnahes berichten könnte !

Da kann ich dir weiterhelfen. B-o-d hatte mir für mein Fatalityprojekt ja eine Stachelkuppel gebaut, dabei hatten wir dieselben Probleme/Fragestellungen.

Im Wesentlichen kann ich bestätigen, was im Unrealdokument steht: Mehrere große Models rendern viel schneller als viele (identische) kleine.

Die Sache ist halt die, dass man durch das kombinieren zwar einerseits noch (durchaus nicht unerheblich) Performance herauskitzeln kann, andererseits die Models dann ihre universelle Einsetzbarkeit verlieren.

Am idealsten wäre es, wenn Modeler und Mapper eng zusammenarbeiten. Dass erst modulare Models gemacht werden, vom Mapper in der Map zusammengebaut werden und schließlich als allerletzten Schritt in der Entwicklung der Map durch einen exakt angepassten Cluster ersetzt werden.

edit: btw... in deinem Set fehlt noch ein entscheidendes Teil: Ne einzelne Verbindungskappe... falls man mal zwei Rohre mit dem offenen Ende zusammensetzen muss.

edit2: Wenn wir schon beim Thema sind, füg ich noch hinzu: Wichtig ist auch, dass die Pivotpunkte, als die Mittelpunkte, die man im Hammer im Grid einrastet, so liegen, dass sich die Models einfach aneinanderfügen lassen. D.h. aufm 16er oder 8er Grid liegen und nicht wie es Valve bei HL2 gemacht hat: Da passen die Teile nämlich bei manchen Sets nichtmal aufm 1er Grid richtig aneinander. Außerdem sollte man sie nicht an den Rand des Models legen, das kann Ärger mit der Beleuchtung geben oder sogar Leaks, wenn der Aufhängepunkt im Void landet, aber das hängt vom Einzelfall ab. Ist aber mit info_lighting oder nem Zusatzbrush fixbar, macht halt nur mehrarbeit, die man nicht hätte, wenn da noch 8 Units Abstand mit einkalkuliert wären, aber das sei nur am Rande erwähnt...

--- Die ganzen Infos müsste man eigentlich mal in ein Tutorial schreiben...

Es gibt 2 Möglichkeiten, eine Kristallkugel zu benutzen:
a) um damit Spekulationen über ein Problem eines Users zu machen und
b) um sie einem besonders unkooperativen User über den Schädel zu ziehen.
- bloggt jetzt auch selbst auf Sclavia.de

doch das teil hab ich, habs nur net mitgerendert :D

aber ja, das was du schreibst, das hat ich mir auch überlegt. der mapper tut das dann so hinzimmern, wie er das braucht und ich setz das dann in dem modelprogramm als großes model zusammen, so haben beide parteien was davon ! glaub, das zahlt sich am ende der entwicklung dann echt aus - muss ja nicht der erste schritt sein :)

das mit dem pivot, das ist interessant, was du schreibst !
hast du da zufällig ein bildbeispiel parrat ? also, weil ich kann mir das grad nicht so gut vorstellen.
weil gerade das mit dem pivot steht ja im unreal-wiki so, dass der auf jeden fall an den rand soll, damit man das besser drehen und anpassen kann.
ich merk das ja sogar schon in meinem modelprogramm. Wenn da der pivot ganz am rand ist, wird das super easy die einzelnen elemente zusammenzufügen, wegen dem erleichterten rotationspunkt....aber wenn dann ja hier das lighting nicht stimmt, wäre das ja doof.
hmh, das ist echt verzwickt :/
glaub das müsste ich dann echt mal mit dem mapper abklären, wie er das besser fände, wenn man das wirklich mit nem zusatz-entity lösen könnte, wobei das natürlich bei großen sachen ungünstig wäre....ein einziges hin und her :/

weiß jetzt nicht genau was Agamemnon-Hellmapper mit cluster meint aber sämt-
liche rohre zu einem gebilde zusammen-mergen würde ich unterlassen.
dein zitat Acumen sagt ja schon

Zitat:

... remember the engine cannot cull only sections of a mesh, ...

in eile geschrieben, deswegen etwas löchrig..

fr?her "M.D.Freezer"

ich glaub da sind wir uns einig, so hatte Agamemnon-Hellmapper das glaub auch gemeint, zumindest hab ichs so verstanden.
also der mapper baut sich z.b. für raum2 sein röhrengebilde zusammen mit den einzelteilen, zeigt mir bilder davon, ich setz es genauso im modeling-programm zusammen und das wird als ein einziges zusammenhängendes model für diesen raum2 kompiliert (kann natürlich dann auch in anderen eingesetzt werden, aber für den mapper wär es ja eine schöne und praktische sache, denk ich), da ja alle einzelteile gleichzeitig sichtbar sind !

wie gesagt, das mit dem pivot ist echt ne heikle geschichte, wenn da wie Agamemnon-Hellmapper sagt, das licht je nach ort des pivots anders berechnet wird. bei den einzelnen rohr-segmenten hab ich im moment den pivot immer links außen am einzelteil. beim zusammenbauen in dem modeling-programm ging das wirklich super einfach. wird im hammer denk ich genauso sein.
dann bei dem großen zusammengesetzten model, ist das wohl wieder eine andere geschichte :D

Also bei Bäumen wird es schon kritisch. Setzt man die nämlich auf Displacements, landet der Pivotpunkt unter dem Boden und da kommt kein Licht hin - der Baum wird schwarz. Deswegen hab ich den Pivotpunkt doch lieber in der Mitte vom Model. Bei Lampen oder Dingen die man immer an Brushwände montiert, ist es allerdings sinnvoll, den Pivot an den Rand zu legen.

Wenn man tatsächlich so vorgeht und am Schluss die Einzelteile zu clustern zusammensetzt, ist es allerdings tatsächlich Latte, wo der Pivotpunkt liegt. Man sollte es aber auch nicht übertreiben. Man muss mit einkalkulieren, dass das Model nur anhand dieses Referenzpunktes beleuchtet wird. Hat man einen auffälligen Helligkeitsgradienten (z.B. in Schächten und Tunnels) wird die Sache schnell unansehnlich.

Hier mal ein Beispiel, wie man es nicht machen sollte:
Dieses Model ist eine "außenkurve"

Wenn man das Kurvenstück um eine Außenecke legt, landet der Pivot im Void und leakt.

Noch ein schlechtes Beispiel:

Die HL2-Geländer passen nichtmal aufm 1er Grid zusammen.

Was die Röhren angeht, so teile ich Acumens Meinung, dass der Pivot am Rand die Montage im Editor sehr erleichtert. Nur sollte man es eben nicht bei diesen Einzelteilen belassen, da diese sonst auch sich gegenseitig beschatten. Liegt der Pivot dann am Rand zum - oder sogar im nächsten Model, bekommt das erste von dieser Seite garkein Licht mehr, es sei denn man macht die Schatten aus.

Es gibt 2 Möglichkeiten, eine Kristallkugel zu benutzen:
a) um damit Spekulationen über ein Problem eines Users zu machen und
b) um sie einem besonders unkooperativen User über den Schädel zu ziehen.
- bloggt jetzt auch selbst auf Sclavia.de

hmhm, so langsam gelangt licht ins dunkel :)
die bilder ham mir jetzt noch mal das etwas besser verdeutlicht, wenn ich auch eine nacht drüber schlafen musste, wie du das mit der außenkurve meinst, aber jetzt ists klar !
das mit dem zusammenpassenden geländern auf grid, werd ich denk ich selbst mal in der praxis mit meinem mapper-schorschl ausprobieren, damit ich da auch selbst mal ein gefühl dafür bekomme.

ich bedanke mich recht herzlich für eure hilfe ! wieder ein problem weniger in meiner kleinen welt :)

Berichte auf jeden Fall bitte weiter von deinen Erfahrungen.

Es gibt 2 Möglichkeiten, eine Kristallkugel zu benutzen:
a) um damit Spekulationen über ein Problem eines Users zu machen und
b) um sie einem besonders unkooperativen User über den Schädel zu ziehen.
- bloggt jetzt auch selbst auf Sclavia.de

Die Rohre find ich Klasse.
Wär schön wenn ich dich (und die Rohre) für gaming-models gewinnen könnte wenns in ein paar Tagen online geht.

"Kloetengott: Ich finde Leute die sich selbst zitieren echt armseelig!"

Kloetengott: Die Models haben schon eine zunächst dedizierte Verwendung, die stehen vorerst under Verschluss.

Also was ich zum Thema gehört habe begründet sich nicht auf irgendwelchen Ausarbeitungen, das ist eher von überall mal aufgeschnappt..
Aus OpenGL-Programmierung weiß ich, wie Elemente in den Speicher der Grafikkarte gelegt werden, um schnell abrufbar zu sein, und ich gehe davon aus, dass Valve bei seiner Engine ähnlich vorgeht (bzw. den Grafikspeicher natürlich auch direkt nutzt). Solche Elemente sind allein für die Anzeige natürlich keine Erschwernis, weil so ein Rohrfetzen wahnsinnig schnell gerendert ist. Das, was die Performance drücken kann, sind natürlich eher die dynamischen Anteile. Kollisionsberechnungen, gegebenenfalls dynamisches Licht, etc.
Anzumerken ist auch, dass jedes einzelne der Models ja die Sichtbarkeitsprüfung durchläuft, das lookahead beim Playertracing mit macht und so weiter. Daher ist auch meine Information - wie hier schon mehrfach angemerkt - dass kleine Modelfragmente zwar für den Mapper gut sind, aber für die Engine später eher sehr schlecht zu berechnen sind. Meshes werden nicht zerteilt, daher ist es selbstverständlich auch totaler Blödsinn in riesigen Arealen alle Models zu vereinen.

Dennoch ist es sinnvoll, die Models für den Mapper als Einzelteile zu kompilieren (ohne Kollisionshülle, vllt ohne Skin), damit dieser daraus konzeptionell basteln kann, was er braucht. Wenn die Models in die Szene passen, dann muss der Modler nochmal ran und muss aus den einzelnen Stücken clusterweise größere Meshes zusammensetzen, die dann kompiliert werden und in der Map eingesetzt werden. Dementsprechend können die Ankerpunkte der Einzelteile auch ruhig am Rand des Models liegen, weil dies die Arbeit für den Mapper ungemein erleichtert.

Die Clustergrößen hängen dabei natürlich nur von der Umgebung ab, da muss man wohl einfach ein wenig abschätzen.

Ist schön, auch mal technisch begründet zu hören, was einem ein Feldversuch zeigt.

Nachteil dieser (#009) Vorgehensweise ist halt die erwähnte notwendige enge Zusammenarbeit, da sollte man schon ein wenig aufeinander eingespielt sein, sonst wirds da wohl hakelig.
Wenn das klappt, dürften sich die Vorteile aber auch bemerkbar machen.

ziemlich interessant das ganze ... und auch das mit dem Pivotpunkt wusste ich bis dato noch nicht ... allerdings wundert mich das ein wenig ... (ok ich bin neu und ihr habt wahrscheinlich 1000% mehr erfahrung als ich) aber unterstützt die Source Engine nicht auch dynamische Schatten und dynamisches Licht ??? Sonst hätte ja z.B. ein Model dessen Pivotpunkt in einem beleuchteten Teil ist die gleiche Helligkeit auch im Schatten ... oder irre ich mich da jetzt und hab alles falsch verstanden ???

Sie haben mehr Tod und Zerstörung gesehen, als ein anderer Soldat in Zehn Leben erblickt hätte.
General Sejanus am Ende des Macharia Feldzuges!

Die Pivot-Sache gilt afaik nur für statische Belichtung.