www.tombraiderforums.com  

Go Back   www.tombraiderforums.com > Community Forums > International > Tomb Raider Forums in Deutsch

Reply
 
Thread Tools
Old 31-10-12, 07:13   #3021
XNAaraL
Professor
 
XNAaraL's Avatar
 
Join Date: Apr 2009
Location: The worthwhile problems are the U can really solve, the ones U can really contribute something to
Posts: 3,198
Default superfluous faces

Quote:
Originally Posted by o0Crofty0o View Post

I never understood what's causing that problem^^
It gets fixed if you export a .obj from XNALara (from the NOT broken model) and make a bone weight copy of that with the broken .mesh.ascii import
Finding superfluous faces hidden in mesh

Ich verstehe es schon. Wenn Du dir die UV-Map eines solchen Modells betrachtest, dann sieht es auf den ersten Blick OK aus. Bei genauerer Betrachtung wirst Du festellen, daß die Schnittpunkte (Ecken) der UV-Map mit den falschen Vertices des Meshes verbunden sind.

Die Ursache ist, daß
  1. daß beim Rippen von Modellen manchmal Kanten (Edges) existieren, die nicht irgendwelchen Flächen (Face) zugeordnet sind, bzw Flächen mit nur 2 Eckpunkten. In diesem Bild als "Linie" zwischen den Flügeln und Füssen zu erkennen:
  2. den Portern unbekannt ist, dass bei einem Modell die "isolierten" Ecken (Vertices) und Kanten (Edges) zu löschen sind. Blender hat dafür ein Script Mesh->Scripts->CleanMesh:
  3. Ein solches, nicht bereinigtes, Modell lässt sich zwar aus Blender exportieren und ist mit XNALara auch zu laden. Jedoch der Versuch dieses Modell zu "modden" ist in der Vergangenheit fehlgeschlagen. Der alte Blender Importer zeigte dann eine Fehlermeldung weil die isolierten Ecken von XNALara entfernt wurden aber die Flächen noch darauf referenzierten.
  4. Es wurde ein neuer Importer verlangt, der diese fehlerhaften Modelle trotzdem laden konnte. Leider hat niemand verstanden dass: http://www.tombraiderforums.com/show...postcount=1272
  5. Der Grund ist also Punkt 1 dieser Aufzählung. Die Unwissenheit über gute 3D Modelle. "Ein 3D Modell darf keine offenen Kanten oder unverbundene Ecken oder verwaiste Flächen aufweisen." Dieses bringt nach dem Exportieren aus XNALara die Indices durcheinander, weil diese Kanten ursprünglich nur mit 2 Ecken verbunden waren, nun aber 3 Ecken aufweisen welche in der Vertex Liste nicht enthalten sind.

Wer Lust hat, der kann gerne diese Stelle im Blender Importer 1.7 mit dem Dateinamen ImportMeshAsciiExtended.py ändern:
Code:
	# Monkey 13
	faceDiffs = 0
	for faceID in range(0, faceCount):
		# print faceID
		try:
			face = mesh.faces[faceID]
			face.image = faceImage
			index1 = indices[faceID][0]
			index2 = indices[faceID][1]
			index3 = indices[faceID][2]
			color1 = colors[index1]
			color2 = colors[index2]
			color3 = colors[index3]
			face.col[0].r = color1[0]
			face.col[0].g = color1[1]
			face.col[0].b = color1[2]
			face.col[0].a = color1[3]
			face.col[1].r = color2[0]
			face.col[1].g = color2[1]
			face.col[1].b = color2[2]
			face.col[1].a = color2[3]
			face.col[2].r = color3[0]
			face.col[2].g = color3[1]
			face.col[2].b = color3[2]
			face.col[2].a = color3[3]
			face.smooth = True
		except:
			# print faceID -- removing this face jumble the uv map
			faceDiffs += 1

	faceCount -= faceDiffs
Also nocheinmal meinen alten Beitrag von vor 2 Jahren:
Quote:
Originally Posted by BlueJ97 View Post
everytime i open some models with blender and the new importer and exporter the faces weirdly rotate just like what happened to monkey 13 !
how do i fix it ?


Jedesmal , wenn ich mit dem neuen Importer versuche bestimmte Modelle in Blender zu laden, dann sind die Flächen so unheimlich verdreht wie es [B]Monkey 13[/I] passiert ist! : (
Wie kann ich es beheben? : D
Jedesmal, wenn Du versuchst, diese Modelle mit dem alten Importer zu laden, dann wird dir dieses nicht gelingen

Diese MOD's sind fehlerhaft hergestellt. Der neue Importer erlaubt es nur, dass diese Modelle überhaupt in Blender geladen werden können. Den eigentlichen Fehler, also die doppelten oder isolierten Flächen, kann er nicht beheben.

Lösung: Der Hersteller der MOD's muss vor dem Exportieren den Menüpunkt "EditMode-->Mesh-->Scripts-->Clean_Meshes" aufrufen ,
ODER:
Derjenige, welcher entgegen meiner Empfehlung, ein MOD als Basis für eigene Modifikationen benutzt, muss die UV-Map neu erstellen.

ODER
Exportiere zusätzlich das Model als static .OBJ aus XNALara heraus. Kopiere mit Blender die BoneWeights auf den Mesh-Part mit der falschen UV-Map. Der .obj Exporter von XNALara kann doppelte "Faces" exportieren.

Every time, when you try to import this models with the old Importer, then you have no succeed

This MOD's are not well made . The new importer allows only that these models can be loaded into Blender. The real BUG of this models, ie the double or isolated faces, the importer can not resolve.

Solution: The manufacturer needs, before exporting the MOD's, to invoke the menu item "Edit mode-->Mesh-->Scripts-->Clean_Meshes"
OR:
If you want to use a MOD made by somebody else, as the basis for your own modifications, contrary to my recommendation, then generate a new UV map

OR
Use XNALara to export the wrong mesh as static .obj file Inside Blender use Scripts-->BoneWeightCopy and copy the bone weights from the messed mesh part to the right static mesh part and swap both.
[/quote]
__________________
Link removed. - Why ? google, google “Google is your friend!”

Last edited by XNAaraL; 31-10-12 at 07:47.
XNAaraL is offline   Reply With Quote
Old 31-10-12, 15:25   #3022
o0Crofty0o
Relic Hunter
 
o0Crofty0o's Avatar
 
Join Date: Sep 2009
Location: Germany
Posts: 6,726
Default

Ja ich weiss, dass das Problem bei den unnötigen Edges liegt^^ (der neue Exporter löscht die soweit ich weiss gleich mit^^)
Leider sind aber andere uploader mehr auf schnelligkeit als auf qualität aus und importieren und exportieren nur einmal, vermutich mit veralteten tools etc^^
Schade eig.
o0Crofty0o is offline   Reply With Quote
Old 01-11-12, 10:21   #3023
XNAaraL
Professor
 
XNAaraL's Avatar
 
Join Date: Apr 2009
Location: The worthwhile problems are the U can really solve, the ones U can really contribute something to
Posts: 3,198
Default Neues Generic File Format (NGFF) für XNALara/XPS/OglLara

^^^Ja eigentlich schade. --- Das löschen beim Exportieren ersetzt nicht das Clean-Script. Das Problem beim wieder importieren ist in dem Bild gut zu erkennen. Der Trick mit .obj und "Bone Weight Copy" eine "arme Leute Lösung"

Quote wieder sinngemäß gekürzt:
Quote:
Originally Posted by Cochrane View Post
Magic Byte: Wenn das Format ASCII ist, dann sollte es für Menschen lesbar sein.
Mit den Headern bin ich mir nicht 100% sicher, ob die helfen, aber schaden können sie vermutlich auch nicht.

(Ich würde übrigens UTF8 als Encoding vorschreiben. Das spart hinterher viel Arbeit.)

Aber auch OBJ löst das Problem eigentlich schön einfach. Daher sind das auch gute Optionen, und vielleicht etwas einfacher.
UTF8 ist eine super Idee. Jeder der es mit Texture-Pfaden mit kyrillischen Zeichen zu tun hatte wird dir hier Recht geben.

Falls wir uns dazu Entscheiden die Material-Settings im Format ASCII (UTF8) und die 3D Daten im Binär-Format zu realisieren, dann braucht der Header im Bin Teil nicht Menschen lesbar zu sein. Die Versions-Nummer im Header ist neben dem Magic-Byte ein absolutes MUß ! Es erlaubt uns später ein Desugn durch ein bessere Lösung zu ersetzen. Natürlich lässt sich dieses auch mit einem immer neuen Magic-Byte realisieren, aber im Sinne der OOP ist es einfacher mit dem Trippel Magic-Byte/Mayor-Number/Minor-Number das ganze dur "Gamma" Design Pattern abzudecken. Zumindestens ist dieses meine Erfahrung der letzten 42 Jahren (/etc/magic).
PS: Ich tendiere dazu das Magic-Byte als ASCII abzulegen und alle binäry Daten im Motorola Format. Das macht das Format universeller weil es für jedes OS eine Methode "network2host" gibt.

Was ist eigentlich die Meinung dazu das Mesh Objekt einfach zu serializieren, oder das Format so anzulegen, dass es sich direkt in den Speicher "mappen" lässt?

======================

Nochmals einen Punkt zum Wegfall der Render Gruppen:
bisher gibt es 31 verschiedene Render Gruppen. Kaum jemandem ist bekannt, daß innerhalb XNALara dafür nur 11 verschiedene Shader-Techniken bestehen:
  • Diffuse
  • DiffuseLightmap
  • DiffuseBump
  • DiffuseLightmapBump
  • DiffuseLightmapBump3
  • DiffuseLightmapBumpSpecular
  • DiffuseLightmapBump3Specular
  • Metallic
  • MetallicBump3
  • DiffuseBumpEmission
  • NextGen

Wenn ihr nur eine "Diffuse" Texture habt, dann spielt also zum Beispiel keine Rolle ob ihr die Render Gruppe 5,7,16 oder 18 benutzt. Die zusätzlichen Parameter wie "Static Modell" oder "Unterstütze Transparenz" machen die Unterschiede im Render-Ergebniss.
Es macht jedoch einen grossen Unterschied wenn ihr für den gleichen Fall die Gruppen 10, 13 oder 21 benutzt, welche durch den Parameter "Shadeless" gesteuert werden. PS: Dafür existiert noch nicht einmal ein Shader Quelltext
Verwirrender geht es kaum. Warum sich zwischen 7 Render Gruppen entscheiden?
Viel einfacher ist es anzugeben, dass es sich bei der Texture um eine Diffuse Texture handelt. In den Flags steht dann ob mit Alpha und ob es mit Schattierung gerendert werden soll. Ob "Static" oder "Poseable" kann der Loader selbst erkennen. (BoneMatrix.Length == 1)
__________________
Link removed. - Why ? google, google “Google is your friend!”

Last edited by XNAaraL; 01-11-12 at 11:30.
XNAaraL is offline   Reply With Quote
Old 01-11-12, 12:43   #3024
Cochrane
Golden
 
Cochrane's Avatar
 
Join Date: Apr 2006
Location: Germany
Posts: 16,513
Default

Quote:
Originally Posted by XNAaraL View Post
Quote wieder sinngemäß gekürzt:

UTF8 ist eine super Idee. Jeder der es mit Texture-Pfaden mit kyrillischen Zeichen zu tun hatte wird dir hier Recht geben.
Oder einfach Umlaute!

Quote:
Originally Posted by XNAaraL View Post
Falls wir uns dazu Entscheiden die Material-Settings im Format ASCII (UTF8) und die 3D Daten im Binär-Format zu realisieren, dann braucht der Header im Bin Teil nicht Menschen lesbar zu sein. Die Versions-Nummer im Header ist neben dem Magic-Byte ein absolutes MUß ! Es erlaubt uns später ein Desugn durch ein bessere Lösung zu ersetzen. Natürlich lässt sich dieses auch mit einem immer neuen Magic-Byte realisieren, aber im Sinne der OOP ist es einfacher mit dem Trippel Magic-Byte/Mayor-Number/Minor-Number das ganze dur "Gamma" Design Pattern abzudecken. Zumindestens ist dieses meine Erfahrung der letzten 42 Jahren (/etc/magic).
Ich würde Binär und ASCII nicht in einer Datei mischen, zumindest nicht, wenn Menschen das bearbeiten sollen. Da sehe ich eine zu große Gefahr, dass irgend ein Texteditor genialerweise meint, das Encoding oder die Zeilenumbrüche oder so anpassen zu müssen, und dann funktioniert der Binärteil nicht mehr. Was eine gute Idee sein könnte, wie du ja schon vorgeschlagen hast, wären die Geometriedaten binär, und das Material als ASCII, jeweils als eigene Datei (so ähnlich wie das OBJ mit den MTL Dateien tut).

Quote:
Originally Posted by XNAaraL View Post
PS: Ich tendiere dazu das Magic-Byte als ASCII abzulegen und alle binäry Daten im Motorola Format. Das macht das Format universeller weil es für jedes OS eine Methode "network2host" gibt.
Ich bin eher gegen das Motorola Format. Ich habe schon viel Erfahrung damit, Sachen im Little Endian (Intel) Format auf Rechnern mit PowerPC CPUs (Big Endian) zu lesen, und es macht wirklich keinen Spaß. Und schauen wir uns doch mal die möglichen Zielplattformen an: Windows, Mac oder Linux auf Intel bzw. Intel-kompatiblen CPUs, und vielleicht, wenn jemand wirklich verrückt ist, auch mal auf ARM. Das ist alles Little Endian (ARM kann theoretisch beides, aber bei Android und iOS läuft es als Little Endian). Big Endian findet man nur noch in Servern und auf Spielekonsolen, beides keine primären Ziele für jedes betroffene Programm.

Quote:
Originally Posted by XNAaraL View Post
Was ist eigentlich die Meinung dazu das Mesh Objekt einfach zu serializieren, oder das Format so anzulegen, dass es sich direkt in den Speicher "mappen" lässt?
Sehr dafür, was übrigens auch gegen Big Endian spricht. Tatsächlich tue ich das schon in GLLara. Ein Punkt nur: Ich mache immer noch mal einen Test, ob alle Indices im richtigen Bereich bleiben (damit ich nicht auf nichtexistente Bones oder Vertices zugreife). Da sehe ich auch langfristig keinen Weg drum herum. Was man aber abstellen könnte: Derzeit muss ich auch noch manuell die Bone-Gewichte anpassen, weil einige Modelle Vertices haben, die als Gewichte z.B. 0.5, 0, 0, 0 haben. Das ist nervig und sollte verboten werden.

Quote:
Originally Posted by XNAaraL View Post
Nochmals einen Punkt zum Wegfall der Render Gruppen:
bisher gibt es 31 verschiedene Render Gruppen. Kaum jemandem ist bekannt, daß innerhalb XNALara dafür nur 11 verschiedene Shader-Techniken bestehen:
Na ja, es gibt die ganzen Static-Techniken, die eigene Vertex-Shader einsetzen und, wegen der Struktur von XNA, ihre eigenen Kopien der Fragment/Pixel-Shader haben. (und mir fällt gerade ein, dass ich bei denen immer noch nicht die neuen Bumpmaps eingefügt habe. Muss ich noch nachholen, scheint aber niemanden zu stören). Dadurch kommt die Anzahl der Rendergruppen zu Stande.

Aber im Prinzip gebe ich dir 100% recht! Das jetztige System ist Mist, und was du beschreibst ist definitiv besser. Ich finde es auch doof, dass das jetzige System so komplett unverständlich ist. Ohne eine Tabelle, welche Rendergruppe was tut, ist man komplett verloren. Die Tabellen gibt es natürlich, aber wenn man das auch irgendwie logischer implementieren kann, um so besser.
__________________
Güter auf die Bahn!
Cochrane is online now   Reply With Quote
Old 01-11-12, 15:04   #3025
XNAaraL
Professor
 
XNAaraL's Avatar
 
Join Date: Apr 2009
Location: The worthwhile problems are the U can really solve, the ones U can really contribute something to
Posts: 3,198
Default

- Richtig, auf keinen Fall Bin und ASCII mischen. Ich habe impliziert an eine BIN Datei mit den 3D-Daten und eine ASCII Datei mit den Materialien gedacht. Wie beim Wavefront, nur der .obj Teil Binär (macht uns das Leben einfacher).

- Ok, Little Endian. Auch einverstanden.

- Die als Gewichte z.B. 0.5, 0, 0, 0 kommen zustande weil niemand diese mit Blender normalisiert und die veralterten (Ge)MeshAsciiToBin Konverter benutzt. Dusan hat leider mit Version 7.1.6 die Normalisierung innerhalb XNALara verlegt. Dadurch wird es notwendig die .mesh Datei wieder aus XNALara heraus als .mesh.ascii abzuspeichern und zurück zu konvertieren
Quote:
7.16
- XNALara normalize the bone weights by loading a model.
Das Benutzen der veralterten Tools sollte wirklich verboten werden.

Fazit: Konsens zwischen uns. Leider noch keine Kommentare der Modder, Modeler oder Porter
__________________
Link removed. - Why ? google, google “Google is your friend!”
XNAaraL is offline   Reply With Quote
Old 03-11-12, 21:05   #3026
Love2Raid
Tomb Raider
 
Love2Raid's Avatar
 
Join Date: Nov 2008
Posts: 20,580
Red face Help

Ich brauche Hilfe, lol:



Die 'weights' sind perfekt in Blender, aber wenn ich versuche sie zu exportieren, dann bewegt ein Teil nicht richtig (in XNALara). Wenn ich sie wieder importiere, sieht der Teil 'blau' aus. Die 'weights' sind verändert. Das 'normalize weights' Skript hat mir nicht geholfen. Was kann ich tun?

(Tut mir leid für eventuelle Fehler, mein Deutsch ist nicht so gut. )

---

Edit:
Ich sehe jetzt, dass XNAaraL dieses Problem in seinem letzten Beitrag hat erwähnt. Was für ein Zufall, lol.

Edit 2:



Edit 3 :
Ich habe das Problem gelöst (nur mit kleinen Anpassungen)! :-)))
__________________
It’s just an opinion, you don’t have to agree. ¯\_(ツ)_/¯

Last edited by Love2Raid; 04-11-12 at 15:28.
Love2Raid is offline   Reply With Quote
Old 04-11-12, 17:46   #3027
XNAaraL
Professor
 
XNAaraL's Avatar
 
Join Date: Apr 2009
Location: The worthwhile problems are the U can really solve, the ones U can really contribute something to
Posts: 3,198
Default

^^^^
I am glad that the problem is solved.

PS: Das Deutsch klingt perfekt.
__________________
Link removed. - Why ? google, google “Google is your friend!”
XNAaraL is offline   Reply With Quote
Old 05-11-12, 12:31   #3028
Cochrane
Golden
 
Cochrane's Avatar
 
Join Date: Apr 2006
Location: Germany
Posts: 16,513
Default

Kurzer Hinweis wegen des Dateiformats: Ich habe gerade wegen meiner Masterarbeit nicht so furchtbar viel Zeit, um mich um XNALara/GLLara/XPS zu kümmern. Ich könnte im englischen Bereich mal einen Thread mit dem aktuellen Stand der Pläne machen, um Feedback von Moddern, Portern usw. zu erhalten.
__________________
Güter auf die Bahn!
Cochrane is online now   Reply With Quote
Old 05-11-12, 13:44   #3029
XNAaraL
Professor
 
XNAaraL's Avatar
 
Join Date: Apr 2009
Location: The worthwhile problems are the U can really solve, the ones U can really contribute something to
Posts: 3,198
Default

Gerne
Und viel Erfolg bei deiner Master Arbeit.

BTW:
XPS 10.9.2 Retro Edition
__________________
Link removed. - Why ? google, google “Google is your friend!”
XNAaraL is offline   Reply With Quote
Old 05-11-12, 22:11   #3030
Love2Raid
Tomb Raider
 
Love2Raid's Avatar
 
Join Date: Nov 2008
Posts: 20,580
Default

Quote:
Originally Posted by XNAaraL View Post
^^^^
I am glad that the problem is solved.

PS: Das Deutsch klingt perfekt.
Danke.

Jetzt habe ich ein neues Problem. Eigentlich ist es ein altes Problem, das jedes Mal erscheint und es ist wirklich...



Gibt es ein Möglichkeit um dieses 'transparency bug' ganz zu eliminieren (mittels einer 'XPS update' zum Beispiel )?
In der Vergangenheit habe ich es ein paar Mal gelöst durch das Modell wieder in Blender zu importieren und zu exportieren, aber das ist nicht immer erfolgreich. :/

Es ist wirklich ärgerlich. In Blender (und alle anderen 3D Programme) sieht alles gut aus, aber in XNALara wie Scheiße.
__________________
It’s just an opinion, you don’t have to agree. ¯\_(ツ)_/¯
Love2Raid is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 10:50.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.