World of Gothic Archiv > Editing
Spacer-Abstürze bei Objekt-Kompilierung
Seite 1 von 1  1 
28.04.2003, 10:16 #1
dinf
Beiträge: 31
Spacer-Abstürze bei Objekt-Kompilierung
hallo liebe mit-modder :D

folgendes problem quelet mein haupt seyt eynigen tagen:
ich habe eine serie von schyldern erstellt, jedoch beim oeffnen dero .3ds-dateien im spacer styrzet dieser gnadenlos ab.

offensichtlich befindet sich der spacer waehrend der oeffnung schon in einem kompilierungs vorgang(ich dachte zunechst, das tut der nur auf knopfdruck oder folter). ich erhalte nemlich folgende gar syltensame fehlermeldung:

ResizeTexture()+130 byte(s)
zCTexConGeneric::ConvertTextureFormat()+2064 byte(s)

man sieht kurz vor dem absturz, dass im okjekt-manager des spacers die texturen auftauchen - jedoch sehen die ziemlich zerfetzt aus =>



um so seltsamer, als die fertig kompilierten .tex-dateien in GoMan voellig i.O. sind und gar huebsch anzusehen!

wie ich an die texturen komme? nunja:

das gleyche mesh kann sehr wohl problemlos in ein bestehendes .zen geladen werden (wie im DevKit Manual beschrieben als oCMobInter). nach "apply" wird es mir dort auch angezeigt, wie dieser byldschyrm-schuss zeiget:



danach finde ich diese texturen auch im _compiled ordner (braves spacerle), wo ich sie mit GoMan anschauen oder auch dekompilieren kann.



aber wir koennen das noch steigern.
noch syltsamer wird das ganze, wenn ich ein anderes schyld aus der gleichen reihe ebenfalls ins gleiche .zen laden möchte (auch als oCMobInter). dann nemlich bekommen sofort nach apply beide schilder das aussehen des zuletzt geladenen. man kann jedoch deutlich sehen, dass sich das nur auf die textur an sich auswirkt - die darunter liegenden .3ds-meshes sind eyndeutig die jeweils originalen.

ich dachte zuerst, es laege evtl. an der texturgroesse. ich hatte nemlich zunaechst beliebig große texturen benutzt, die nicht auf einer potenzen von ^2 aufbauen. doch das habe ich mittlerweile geaendert (und natyrlich alle schon kompilierten texturen und formen aus den jeweiligen DATA-ordnern wieder geloescht). aber auch dann styrtzt der spacer mit o.g. fehlermeldung ab.

ich vergass hin zu zu fygen, dass die texturen nicht allesamten quadratisch seyn. aber das synd die in gothic ja auch nycht. und: alle 4 texturen/schild enthalten jeweils einen alphachannel, wie man unschwer erkennen kann (jaja das klappet nun). vielleycht spendet dies einen wesentlichen hinweys.

dies ist kein verspetetes osterrätsel, sondern eine echt quaelende angelegenheyth. ich bitte also untertraenigst um baldige hilfe von dero gnaden mod-spezies, thx.



D
28.04.2003, 16:35 #2
dinf
Beiträge: 31
halblösung
ein paar stunden später..

zu zweit haben wir die schilder so weit bekommen, dass sie jetzt gemeinsam im spacer zu laden sind :D
leider stürzt mein spacer immer noch bei einzellade-aktionen ab. wer dazu noch eine idee hat...

aus den komplikationen ergab sich folgendes:

- ähnliche modelle sollten evtl. intern nicht identische namen für meshes benutzen
- materialien sollten unterschiedlich heißen, wenn sie unterschiedliche inhalte haben
texturen vermutlich auch (guute idee gell? :D)
- evtl. mag der spacer keine objekte mit (zu) vielen einzelnen meshes

es kann auch sein dass nur eines der 3 vorschläge entscheidend ist, das habe ich jetzt noch nicht getestet.
wie gesagt, wer jetzt noch eine idee hat, warum der spacer beim direkten laden eines einzelnen objektes crasht, bitte melden, thx.

D
29.04.2003, 00:51 #3
HornOx
Beiträge: 1.458
Re: halblösung
quote:
- ähnliche modelle sollten evtl. intern nicht identische namen für meshes benutzen
das stört bei den orginal Meshes nicht
quote:
- materialien sollten unterschiedlich heißen, wenn sie unterschiedliche inhalte haben
Materialien bzw Maps sollten wie die Texturendateinamen in Großbuchstaben ohne Pfad und ohne Dateiendung heißen, z.b. wenn die Textur "C:irgendwas.tga" heißt muß der Materialname "IRGENDWAS" sein. Portale sind soweit ich weiß die einzigste Außnahme.
quote:
- evtl. mag der spacer keine objekte mit (zu) vielen einzelnen meshes
ich hab mir ein kleines script gebastelt das vor dem exportieren alle mehes zu einem verschweißt. Ich weiß zwar auch nicht ob das notwendig ist aber zumindest gibt es in den Orginaldateien meist nur ein Objekt.
quote:
wie gesagt, wer jetzt noch eine idee hat, warum der spacer beim direkten laden eines einzelnen objektes crasht, bitte melden, thx.
Wie oben gesagt: Materialnamen anpassen. Wenn es immernoch nicht klappt kannst du mal probieren per 3ds max die Textur wieder vom Mesh löschen, das Mesh im Spacer laden und dort die Textur neu zuzuweisen.
quote:
alle 4 texturen/schild enthalten jeweils einen alphachannel, wie man unschwer erkennen kann (jaja das klappet nun).
Wieso hat's nicht von anfang an geklappt?
29.04.2003, 11:12 #4
Dr.Wieselkopp
Beiträge: 354
Re: Re: halblösung
quote:
Zitat von HornOx
Materialien bzw Maps sollten wie die Texturendateinamen in Großbuchstaben ohne Pfad und ohne Dateiendung heißen, z.b. wenn die Textur "C:irgendwas.tga" heißt muß der Materialname "IRGENDWAS" sein. Portale sind soweit ich weiß die einzigste Außnahme.


Hmm, aus eigener Erfahrung kann ich sagen, dass der Name der Materialien keinen Regeln Folgen muss, mit 2 Ausnahmen.

"[xxx]_[xxx]" und "PI:" sind reserviert für Portale (Indoor + Outdoor)

Und bei der benennung der Texturen gibt es auch eine Sonderform:
"NAME_[BUCHSTABE0][ZAHL0]_..[BUCHSTABEn][ZAHLn].TGA" sind Namen für Mutitexturen.

Allerdings muss man, wie dinf ja anscheinend schon selber festgestellt hat, darauf achten verschiedenen Texturen nicht die selben Materialnamen zu geben. Gothic kennt pro Material nur eine Textur. Wenn also verschiedene Objekte mit ein und dem selben Material Texturiert sind, dann haben sie später beim einfügen in eine Zen auch alle die selbe Textur (Meist die zuletzt geladene ;))

Die Texturen würde ich übrigens nciht mit GoMan compilen, sondern lieber direkt mit Gothic. Da der Spacer schon beim laden der Texturen abstürzt scheint das Problem dort zu liegen. Woran es genau liegt kann man "so" nur schwer sagen.

Achja, ein Tipp noch: Im Spacer normale Objekte nicht als ocMobInter einfügen sondern als ganz normales oCVob.
29.04.2003, 13:10 #5
dinf
Beiträge: 31

hallo!
danke für eure qualifizieten beiträge.

ich muss übrigens Dr. Wieselkopp zustimmen: die erneute änderung der materialnamen nach deinen regeln, hornox, hat leider keine verbesserung gebracht.
die materialien tauchen beim laden des .3ds nach wie vor so wie oben gezeigt im "materials" fenster auf. habe ich vorher _alle_ kompilierten dateien gelöscht und _alle_ objekte & texturen neu im [GDATA] gespeichert, kann ich davon ausgehen, dass der spacer mich ein geladenes schild sogar kompilieren lässt.. :D

wiselkopp:
"Die Texturen würde ich übrigens nciht mit GoMan compilen, sondern lieber direkt mit Gothic. Da der Spacer schon beim laden der Texturen abstürzt scheint das Problem dort zu liegen. Woran es genau liegt kann man "so" nur schwer sagen."

das ist das schöne: kompilieren kann der spacer die texturen immer, die .tex-files sind jedenfalls ganz offensichtlich laut GoMan in Ordnung. Jedenfalls zeigt dieser die files so sauber an, wie er sie auch zurück in .tga's zurück verwandelt..

ich habe jetzt zumindest herausgefunden, dass beim laden eines objektes eine textur nach der anderen im "materials" fenster auftaucht (und währenddessen kompiliert wird). meist bei der letzten, oder kurz danach kommt der absturz. übrigens murmelt der alte spacer 1.41 an dieser stelle manchmal (sic!) etwas von alpha-konvertierungsfehlern ...

"Wieso hat's nicht von anfang an geklappt?"
Nein HornOx. trotz deines hilfreichen beitrages zu meiner Alpha-Frage musste ich noch eine weile herumprobieren, bis der spacer dann doch "ganz normale" .tga's als alpha-transparent annahm. =>


grüß
D
29.04.2003, 13:28 #6
NicoDE
Beiträge: 1.398

Ich gehe davon aus, dass der zSpy nebenbei läuft...
Im Log sollte eigentlich zu finden sein, welche Textur bei der Konvertierung Probleme bereitet hat und welche Probleme aufgetreten sind, _bevor_ es zum Absturz kommt.

Bei der Benennung (Dateinamen) gibt es nicht viel zu beachten (die erwähnten Ausnahmen), außer, daß letztendlich alles in einem compiled-Ordner landet (und somit im Falle von gleichen Rohdaten-Dateinamen in unterschiedlichen Verzeichnissen, die compilierten Versionen sich gegenseitig überschreiben).
Man geht solchen Problemen am einfachsten aus dem Weg, indem man eindeutige Bezeichner wählt (gilt nicht nur für Dateinamen).

- nico

ps: ich hatte schon den Fall, daß sich bei einer bestimmten Kombination aus Windows-Version/DirectX bestimmte Texturen nicht mittels Gothic/Spacer konvertieren ließen...
29.04.2003, 17:24 #7
dinf
Beiträge: 31

Hi Nico :)

Natüürlich ist der kleine Tiefenspion immer mit dabei. auch wenn wir zwei völlig unterschiedliche Sprachen sprechen ..
Es wäre super nett wenn du dir die letzten 20 Zeilen mal angucken könntest? Ich kann da nur raten: Direct3D probleme..
Kurz bevor der Spacer verstarb...(~20 Zeilen)

Übrigens sind die Logfiles immer übersäht mit dem <zError.cpp,#459>
Darüberhinaus: bei welcher textur abgebrochen wird, ist - bei gleichen files - unterschiedlich!
Windoof halt. Die Zeiten von eindeutigen 0 oder 1 sind vorbei, es lebe das 'vielleicht'.. :D

ps: ich hatte schon den Fall, daß sich bei einer bestimmten Kombination aus Windows-Version/DirectX bestimmte Texturen nicht mittels Gothic/Spacer konvertieren ließen...

lass mich raten: Win2K, DirectX 8.1 - und?
Und was meinst du mit "bestimmten Texturen"?

edit: war lötsinn, die letzte frage. die texturen _werden_ ja konvertiert.. nur nicht unbedingt alle auf einmal, beim direkten laden. bringe ich sie als Vob in ein .zen file, wird alles einwandfrei konvertiert und dargestellt, s.o...

grüß
D
29.04.2003, 18:20 #8
NicoDE
Beiträge: 1.398

quote:
Zitat von dinf
[...]Es wäre super nett wenn du dir die letzten 20 Zeilen mal angucken könntest? Ich kann da nur raten: Direct3D probleme..
Kurz bevor der Spacer verstarb...(~20 Zeilen)
[...]
...
BE_METAL-C.TEX (512x512x4, mips: 1)
...
Versuchs mal bei eben dieser mit 512x512x8.

quote:
Zitat von dinf
[...]lass mich raten: Win2K, DirectX 8.1 - und?[...]
Treffer, versenkt.

quote:
Zitat von dinf
[...]Und was meinst du mit "bestimmten Texturen"?[...]
IIRC, waren es meist TGAs mit selten benutzter Farbtiefe (Details hab ich vergessen (verdrängt)).

quote:
Zitat von dinf
[...]edit: war lötsinn, die letzte frage. die texturen _werden_ ja konvertiert.. nur nicht unbedingt alle auf einmal, beim direkten laden. bringe ich sie als Vob in ein .zen file, wird alles einwandfrei konvertiert und dargestellt, s.o...[...]
Nicht unbedingt.
Wenn Du neue Texturen hast, dann versuche sie erstmal mit der Gothic(Mod).exe zu konvertieren.
Und versuche es dann, wenn sie bereits konvertiert wurden, im Spacer nochmal.

- nico

ps zum Thema oben: ein Vob hat nur ein Visual (in dem Falle ein Mesh).
30.04.2003, 14:21 #9
dinf
Beiträge: 31

quote:
BE_METAL-C.TEX (512x512x4, mips: 1)
...
Versuchs mal bei eben dieser mit 512x512x8.

yo das klappet. doof ist nur, dass die datei eigentlich _garkeinen_ alphachannel hat. dh. ich habe jetzte 1 plane mehr als nötig. in photoshop ist eindeutig keine weitere zu erkennen. auch wenn ich den grafikviewer zum abspeichern nehme, kommen absturz und 4 bit wieder..

ich versuche gerade, das ganze auf einem 2. rechner und unter W98 zu testen. wie könnte es anders sein: das netzwerk will heut mal nicht...


quote:
IIRC, waren es meist TGAs mit selten benutzter Farbtiefe (Details hab ich vergessen (verdrängt)).

hm. 24 bzw 32bit empfinde ich bei TGA eher als normal. vielleicht sieht es das windoof ja anders. "exotische" farbtiefen bekomme ich mit PS eigentlich nicht hin. ich hab jedenfalls noch nie probiert ein CMYK- oder eines mit 16bit-planes zu erstellen *grins*

öhm sag mal, habe ich keine alternative bei den texturen - mit oder ohne alpha? _nur_ TGA? was anderes will der spacer nicth adden, und weitere formate finde ich weder im DevKit beschrieben noch in den VDFs.

und: ist das normal, dass nach dem klick auf "kompilieren" im spacer zwar die texturen konvertiert sind (was sie ja schon beim laden werden), aber kein .mrm file im _compiled ordner ist? *staun* - da landets jedenfalls wenn ich es als ocMobInter in ein .zen lade


quote:
ps zum Thema oben: ein Vob hat nur ein Visual (in dem Falle ein Mesh).

worauf beziehst du das? ich probierte - nach dem einführende tutorial - idR das ocMobInter, auch wenn das schild nicht zur interaktion ist. das hat bislang gut geklappt. wobei ich spätfolgen natürlich noch nicht absehen kann :D


nettgrüß

D

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

Nachtrag:
Das Nettwerk geht jetzt netterweise hin und wieder (deshalb heißt es wohl so :D), daher konnte ich meine nicht-alpha-TGAs auch mal unter W98 + DirectX 8.1 testen. der spacer crasht trotzdem *tiefseufz*
30.04.2003, 19:52 #10
NicoDE
Beiträge: 1.398

512x512x4 = 512x512 Pixel mit 4 Bit Farbtiefe pro Pixel = 16 Farben.

Es ist nicht nötig, die Originale in der Farbtiefe deart zu reduzieren (DTXC, die verwendete Komprimierung der Gothic-Texturen, ist nicht palettenbasiert).
Es gibt Schlüsselwörter nach denen bei der Konvertierung der Textur im Dateinamen (inklusive Pfad) gesucht wird, um Mipmaps zu verhindern ('nomip') und/oder 16-Bit Texturen zu generieren ('16bit').

Ja, es werden nur TGAs unterstützt (ist eben ein simples Format, welches jedes brauchbare Grafikprogramm unterstützt). Deine Frage verstehe ich nicht ganz - 24bit TGAs haben kein Alpha.


- nico

ps: das mit den Meshes bezog sich auf die Frage, wieviele ein Vob haben sollte.
01.05.2003, 12:17 #11
dinf
Beiträge: 31

Hallo!
quote:
"Es ist nicht nötig, die Originale in der Farbtiefe deart zu reduzieren (DTXC, die verwendete Komprimierung der Gothic-Texturen, ist nicht palettenbasiert)."

Wenn ich dich richtig verstehe, glaubst du aufgrund der Fehlermeldung, dass die Metalltextur BE_METAL.TGA schon indiziert oder bit-reduziert sei?

Die Originale sind nicht farbreduziert, sondern standartmässige 24 (ohne Alpha) oder 32 BIT (mit Alpha), s.o..
Mir ist klar, dass 24 bit keine Alphas enthalten. Aber genau das tut die zum Absturz führende Metalltextur auch nicht: es ist eine alpha- & harmlose, pure Colormap.

Die Texturen liegen aus Qualitätsgründen im NOMIP-Ordner. Die Ergebnisse sind wesentlich schärfer und klarer, auch bei größerer Nähe, als MIP-basierte Texturen.
(Wer sich die Mühe machen will zu vergleichen: hier ein Link zum gleichen Schild wie oben, mit MIPs. So nah kommt man im Spiel selten an ein Objekt heran..)

Ich habe auf deine Anregung hin auch die Konvertierung über den GothicStarter ausprobiert. Der stürzt zwar nicht ab, erzeugt aber laut zSpy ebenfalls eine 4bit .tex. Ich weiß noch nicht ob ich dem dafür wirklich böse bin :D - vielleicht ist die Qualität für manche Objekte ausreichend.

Ja, ich erinnere mich an die Hinweise über DXTC/S3TC im DevKit (ist das eine Weiterentwicklung der DXT1/3/5 Formate?)
Mir wird aus dem Text jedoch nicht so ganz klar, was die anderen beiden Formate 16BIT und 32BIT leisten/nicht können. Deshalb habe ich die alle mal mit NOMIP durchprobiert, also in NOMIP_16BIT bzw NOMIP_32BIT Ordner gelegt. Ich gehe erstmal mal davon aus, dass auch die 16 bzw 32 bit die planes unterschiedlich aufteilen (zB 4444 oder 5551 RGBA bzw 555 RGB usw..)

Es ist sehr interessant, was da so alles passiert. Ich muss zugeben, dass mich die verschiedenen Ergebnisse auch irritieren, allem voran die unerwarteten Qualitätseinbussen bei zB 32bit bzw dass sie zT im Spacer nicht korrekt angezeigt werden, wenn Alpha enthalten.

Alles in allem habe ich jetzt jedenfalls eine Möglichkeit, mit der ich arbeiten kann =>
- enthalten die Texturen und sollen scharf sein, bleiben sie in NOMIP
- andere kommen je nach Qualitätswunsch im TEXTURE Ordner oder in NOMIP_16BIT

Würde es darüberhinaus hier den Rahmen sprengen, die beiden anderen Formate über die Erklärung im DevKit hinaus zu erklären? ("Die Benutzung von expliziten 16/32 Bit Texturen kann Sinn machen, um bestimmten visuellen Problemen und Artefakten des DXTC-Formates aus dem Weg zu gehen.")

grüß
D

edit---------

Ist mit "DXTC" vielleicht "DirectX Texture Compression" gemeint? Dazu gibt es ein Photoshop Plugin von NVidia, das erlaubt direkte Speicherung mit DX Compression als .dds Format. Kann ich damit auf direktem Wege .tex Dateien erzeugen?

grüß
D
01.05.2003, 13:02 #12
HornOx
Beiträge: 1.458

quote:
Die Texturen liegen aus Qualitätsgründen im NOMIP-Ordner. Die Ergebnisse sind wesentlich schärfer und klarer, auch bei größerer Nähe, als MIP-basierte Texturen.
AFAIK "flimmern" Texturen ohne mipmaps in G1 wenn man sie aus großer Entfehrnung betrachtet. Außerdem sinkt die Framerate(war zumindest bei der ersten Version der "bedrohung" so)
IMHO stört es wenn alle neuen Textuen wegen der Schärfe und Farbsättigung als neu und "gothicfremd" erkennbar sind.
02.05.2003, 11:46 #13
dinf
Beiträge: 31

hi hornox!
quote:
AFAIK "flimmern" Texturen ohne mipmaps

Ich habe gerade versucht das per Auge nachzufühlen, und ich muss sagen, du hast recht. In Bewegung kann ich ein permanents Flimmern wahrnehmen.

Was deine 2.Aussage betrifft, so muss ich sagen, liegt mir fern: nur weil ich Gothic-Fan bin, auch den kompletten Look zu übernehmen. :D
So, wie m.E. nicht alle Mods im gleichen "Zeitalter" oder Universum spielen müssen, um interessant zu sein. "Wegen der Schärfe und Farbsättigung" war deshalb genau der Grund, warum ich zunächst die nomip's haben wollte. Mehr Farbmöglichkeit heißt ja nicht automatisch auch "bunter". Mit mehr Farbe kann ich durchaus das "schmuddelige Mittelalter-Feeling" - im positiven Sinne - noch aufrecht erhalten, wenn nicht sogar verstärken.

nettgrüß
D
02.05.2003, 12:34 #14
HornOx
Beiträge: 1.458

Eigentlich hab ich gemeint(vielleicht sollte ich mir angewohnen zu schreiben was ich meine ;)) das du die Texturen nachahmen sollst damit du nicht unterschiedliche "texturarten" mischst und nicht damit das deine Mod aussieht wie G1. Eine Mod mit nur scharfen Texturen auszustatten(ohne die orginalen unscharfen Texturen zu verwenden) ist mehr Arbeit als ich mir persönlich machen würde.
Bringt es eigentlich einen schärfe-gewinn wenn man die Texturen einfach in einer höheren Auflösung speichert? Dank Mipmaps sollte die höchste Auflösung die Grafikkarte ja erst belasten wenn man direkt davor steht...
02.05.2003, 15:24 #15
dinf
Beiträge: 31

quote:
Dank Mipmaps sollte die höchste Auflösung die Grafikkarte ja erst belasten wenn man direkt davor steht...

Tut sie aber nicht, wie du am Vergleich oben erkennen kannst. wenn ich das als Referenz nehmen darf, erreichst du die Schärfe, die die original-Textur hat, mit den MipMaps nie, da man nicht (jedenfalls nicht nennenswert) nah genug an das objekt heran kommt.

quote:
Eine Mod mit nur scharfen Texturen auszustatten (ohne die orginalen unscharfen Texturen zu verwenden) ist mehr Arbeit als ich mir persönlich machen würde

Die original-TGAs sind - zumindest in meinem Beispiel - klarer als die kompilierten, s.o.. Also wenn du neue Objekte benutzt, haben die meist auch neue Texturen. Die Arbeit des Kompilierens übernimmt das Programm für dich :D
Wenn du dann noch Texturen aus dem Spiel übernehmen willst (und darfst..) kannst du sie ja vorher per GoMan o.ä. in TGA exportieren *g*

inter nett grüß
D
20.05.2003, 07:36 #16
dinf
Beiträge: 31

hi nico!

quote:
512x512x4 = 512x512 Pixel mit 4 Bit Farbtiefe pro Pixel = 16 Farben.
Es ist nicht nötig, die Originale in der Farbtiefe deart zu reduzieren


Dem stimme ich zu. Da das aber der Spacer macht bzw dabei abstürzt, die Bilder jedoch gewöhnliche RGBA-Bilder sind, frage ich mich & Dich, woran das liegt?

Eine Folgefrage die sich für mich daraus entwickelt:
Da Texturen meiner 'jungen Erfahrung' nach schärfer werden wenn ich sie per NOMIP compilieren lasse, aber dabei flimmern - gibt es eine Möglichkeit die Texturen scharfaberunflimmrig zu speichern? Die Klarheit & Schärfe hat mich doch sehr begeistert.

In dem Zusammenhang stand auch die Frage: Wozu genau brauce ich die Funktionen NOMIP_16 und NOMIP_32 - wobei ich nicht immer alle nutzen kann, weil der Spacer öfter mal hops geht wenn ich daraus compile.
Die übrigen TExturen werden jedenfalls scheints standartmässig als 8Bit compiled. Wenn ich Deine Aussage richtig interpretiere, dann ist das nichtmal nötig ?!

Und als letztes: kann man das NVidia-Plugin/Standalone zum Abspeichern als DXTC/S3TC benutzen? (bevor ich die 200 Einstellungsmöglichkeiten durchprobiere, frage ich lieber :D)
Ich kenne leider nur den Link zur UDN-Seite. Sorry für meine frevlerische Tat, solch fremdes Spiel hier aufzuführen *g*
=> DXT-Tool, ganz unten
4all: der Rest der Seite erklärt ein bischen was zu verschiedenen in Games bentutzen Texturstandarts..

Danke & internett grüß
Dinf


.. und morgen enter ich die Matrix :D
20.05.2003, 08:33 #17
NicoDE
Beiträge: 1.398

Die erste Version von nVidias DXTC-Kompressions-Beispiel hatte einen Bug bei der Berechnung der Palettenwerte bei DXT1 (ist kaum jemand aufgefallen, und die Dokumentation von DXT1 von Microsoft war lange so schlecht, daß die Spezifikation in diesem speziellen Fall mehr als undeutlich war - ist inzwischen von Microsoft klargestellt/verbessert worden. Ich hatte aber nicht die Zeit, um mir die aktuellen DXTC-Quellcodes von nVidia anzusehen).

Es gibt kein Tool (außer GoMan), mit dem man ZTEX erzeugen kann. Es gibt aber einige, die das ZTEX-Format kennen. Ein Programmierer mit etwas Hintergrundwissen, sollte keine Probleme haben, das nVidia-DXTC-Plugin für Adobe Photoshop oder das DXTC-Tool von Microsoft (falls Quellcode vorhanden) umzuschreiben.

- nico
07.06.2003, 17:59 #18
MarGon
Beiträge: 121
Re: Re: halblösung
quote:
Zitat von HornOx
Materialien bzw Maps sollten wie die Texturendateinamen in Großbuchstaben ohne Pfad und ohne Dateiendung heißen, z.b. wenn die Textur "C:irgendwas.tga" heißt muß der Materialname "IRGENDWAS" sein. Portale sind soweit ich weiß die einzigste Außnahme.


is eigentlich egal was fürn name hauptsache ein andres material mit ner andren textur hat net den gleichen material namen .. mir pasiert es offt das ich die default #1 usw dastehen hab ... und dan is die textur die man zuletzt mit den material namen läd die textur die benutzt wird
Seite 1 von 1  1