Risen-XMSH Importscript for 3ds Max / gmax

[Baltram]

I wrote a small script in the MaxScript language that imports basic geometry data from Risen's ._xmsh files. Download it here (http://upload.worldofplayers.de/files8/ImpRisenXMSH_packed2.zip).

Some screens:

http://img14.imageshack.us/img14/8068/schildd.th.jpg (http://img14.imageshack.us/img14/8068/schildd.jpg/)http://img504.imageshack.us/img504/380/viech.th.jpg (http://img504.imageshack.us/img504/380/viech.jpg/)http://img14.imageshack.us/img14/6083/ruinen.th.jpg (http://img14.imageshack.us/img14/6083/ruinen.jpg/)

Please note:
-I tested it only with files from meshes.pak
-I tested it only with gmax but I'm pretty sure it works in Max too
-It doesn't work for very large files
-Only vertices, faces and texture vertices are imported (Update)

To run the script start 3ds max or gmax and select 'run script...' from the MaxScript menu. You should place 'ImpRisenXMSH.ms' in the scripts folder of your max directory.

The script names the imported objects like the texture they need. So you can see what XIMG files have to be converted to TGA (Nico made a XIMG to DDS converter for the second conversation you can use for example this (http://www.dsabstraction.com/dds_converter.htm))

The TGA-files need to be stored somewhere max/gmax can find them (for example in the maps folder). You can define own bitmappaths via 'Customize' -> 'Configure Paths...' -> 'Bitmaps'.

You should know that the script doesn't really read out the texturenames (they aren't stored in the XMESH files) but reads the material names and changes the extension from XMAT to TGA. This may work in most cases but not always.

Note: If you want to keep your images in a different format than TGA, open the script with notepad, search ".tga" and replace it with ".jpg" for example.

[Klabautermann]

Coole Sache :)
Mit Texturkoordinaten wärs natürlich noch deutlich cooler :-P

[Wormer]

Amazing! Now we can create our own small modkit! :D

[Shak-otay]

Amazing! Now we can create our own small modkit! :DNope, as long as the collisionshapes can't be reproduced we won't. Or would you like to walk through walls? And the collisionshapes do work for the PC_Hero only. To avoid NPCs walking through walls you will have to implement navpaths/navzones. So there is a long way to go.

Not to talk about the animations (_xmot).

As soon as the PBs/Deep Silver allow Risen to be modded I would try to release a MeshFaker like the one for G3.
Allowing us to implement new weapons for exam.

This is all to be expected, sry, guys.

[Wormer]

Nope, as long as the collisionshapes can't be reproduced we won't. Or would you like to walk through walls? And the collisionshapes do work for the PC_Hero only. To avoid NPCs walking through walls you will have to implement navpaths/navzones. So there is a long way to go.
But we can create and move objects (chests, items etc). We need only information about .lrent and .sec file format. And some steps to understand it are done. Am I right?
We can do this visually in some 3D environment (imported levelmesh).

[iGim]

Thanks for the script Baltram!
Even if we can´t start until pb release some more info, we can now take a look and get a feeling for further mods. Thanks a lot and keep up modding

[Shak-otay]

But we can create and move objects (chests, items etc). We need only information about .lrent and .sec file format. And some steps to understand it are done. Am I right?
We can do this visually in some 3D environment (imported levelmesh).Yep. (I started lrent (http://forum.worldofplayers.de/forum/showpost.php?p=10914058&postcount=170)-decoding. Coords in Navigation class contained in the newest version.)

I also imported a "new" tower (http://upload.worldofplayers.de/files4/KomischerTower.JPG).
And I got the data of the collisionshapes (http://upload.worldofplayers.de/files4/CS_Ruin_Tower.JPG) (this is not the mesh!).

But what I wanted to say is that for me I'm not interested in dealing with format issues like I have done with G3 for 1 and a half year.
If PB doesn't reveal more infos on the formats I will join Dragon age modding.

I will not engage in Risen modding any more if we do not get any modding support.

[Baltram]

Thanks for the feedback! :)

I updated the script. Now also texture coordinates and diffusemaps (pseudo) are imported:

http://img504.imageshack.us/img504/9594/alch.jpg

@Shak-otay
Du scheinst das Format ja schon ganz gut zu kennen. Weißt du was Genaueres über die 40 bzw. 48 Bytes nach jeder Vertexkoordinate :gratz ? Ich habe bisher nur die UVW-Koordinaten und zwei unbekannte Normals identifizieren können (eine ist vllt die jeweilige Vertexnormal).

Und noch ne Frage:
As soon as the PBs/Deep Silver allow Risen to be modded I would try to release a MeshFaker like the one for G3.Worauf wartest du? Risen ist doch quasi freigegeben fürs Modden, es gibt ja ein entsprechendes Unterforum bei DS. :dnuhr:

[Shak-otay]

@Shak-otay
Du scheinst das Format ja schon ganz gut zu kennen. Weißt du was Genaueres über die 40 bzw. 48 Bytes nach jeder Vertexkoordinate :gratz ? Ich habe bisher nur die UVW-Koordinaten und zwei unbekannte Normals identifizieren können (eine ist vllt die jeweilige Vertexnormal).
Die 2 DWORDs (Bytes 36-43) könnten Farbwerte sein; zumindest das 2. DWORD; vielmehr weiss ich auch nicht. Das ist ja das, was mich ärgert; dass man sich alles selbst rausklamüsern muss, wo sie einem ganz einfach mal den Aufbau des Formats mitteilen könnten. Und seis nur für den collisionshape.

Den braucht man nämlich für selbsterstellte Objekte. Es sei denn, es ist Dir egal, dass der PC_Hero z.B. durch einen (eigenen) Alchemietisch durchlatschen kann. Mir ist es jedenfalls nicht egal - dieses "Pseudo-modding" (Zitat: Kushel_Baer) werde ich mir nicht mehr antun.


Und noch ne Frage:Worauf wartest du? Risen ist doch quasi freigegeben fürs Modden, es gibt ja ein entsprechendes Unterforum bei DS. :dnuhr:"Quasi" reicht mir nicht; Herr Rüve hat mit Guantanamo gedroht. Und auch wenn's nur im Spass gemeint war: ohne eine offizielle Freigabe des moddings für Risen wird von mir nichts mehr kommen.

[Klabautermann]

Wow!
Einfach klasse :) Und in was für einer Geschwindigkeit!
Hat schon jemand das Script mit Max getestet? Ist das ganze Versionsabhängig?
Was planste als nächstes? Die Speedtrees? :-P

Find ich auf jeden Fall ne wunderbare Sache, auch ohne Exporter.:gratz

Mir ist gerade was aufgefallen. Ist zwar nur ne Kleinigkeit, aber egal.
Das ganze wird mit deinem Importscript gespiegelt importiert. (Ist die Frage ob an der X oder Y-Achse)

Siehe hier (http://upload.worldofplayers.de/files4/Doncamp.jpg)

Sollte die Rampe nicht genau wie die 2 Häuser rechts anstatt Links sein?

[Wormer]

Mir ist gerade was aufgefallen. Ist zwar nur ne Kleinigkeit, aber egal.
Das ganze wird mit deinem Importscript gespiegelt importiert. (Ist die Frage ob an der X oder Y-Achse)
Siehe hier (http://upload.worldofplayers.de/files4/Doncamp.jpg)
Sollte die Rampe nicht genau wie die 2 Häuser rechts anstatt Links sein?

You can fix this.


Edit the script. Find this code:


if id == 1 then
(
x = f
)
if id == 2 then
(
y = f
)
if id == 3 then
(
z = -f --Change f to -f
append verts[ii] [z,x,y]
)

Then find this code:


if id == 1 then
(
x = f
)
if id == 2 then
(
z = f --Swap y and z
)
if id == 0 then
(
y = f --Swap y and z
append faces[jj] [z,y,x]
)

Now script will work properly.

[Baltram]

I fixed the mirroring, thank you for the hint, kushel_baer!
I really don't understand why there are some coordinates with obviously wrong signs in XMESHes (also one of the UVW-coords is concerned):dnuhr:

There was another minor bug concerning the UVW-coordinates, I fixed it too.

Furthermore I found out where the vertex normals are stored. But unfortunately it's impossible to import them, I think, since max recalculates them all the time based on the smoothing groups (perhaps it has changed in newer versions of max?).

[Klabautermann]

Ok, cool, thanks :)
Is there any reason why I have to reset Max before importing?
Makes it impossible to import more than one Mesh into the same scene.
I deleted the concerning entry and it also works fine...

Edit: @Baltram: Oh man da hätt ich auch drauf kommen können :D Bin irgendwie automatisch davon ausgegangen dass der Vorgang dann abbricht.

[Baltram]

You're right, it works no matter max has been reset or not.
I placed the command in the script just for good measure.

If you don't want to reset you can simply select 'No' in the dialog.

[Klabautermann]

Traumhaft dieses Script. (http://upload.worldofplayers.de/files4/b9UvMWArE3yYFfmRisen%20Hafenstadt.jpg)

Wo wir hier schon beim Thema sind ;)
Mir ist aufgefallen, dass viele Meshes wenn man sie importiert nicht zusammenpassen.
z.B. man importiert das gesamte Level Surface und importiert die Hafenstadt.
Passt.
Importiert man aber das große Levelmesh und das Don Camp, ist an der Stelle wo das Don Camp sein sollte ein Loch und es treibt sich irgendwo rum.
Importiert man nun noch den Staudamm mit dem Haus wo der Sumpfbauer wohnt, passt dieser weder ins Levelmesh noch an das Doncamp.
Und Innenräume sind sowieso immer am Nullpunkt und passen auf keinen Fall.

Liegt das am Importscript oder ham die PBs irgendwie die Positionierung verkackt oder steckt da irgendwas dahinter was ich nicht verstehe?
Könnt ihr so etwas überhaupt rausfinden?

Oh sry dass ich immer Deutsch schreibe..Aber mir fällts immer zu spät auf.

[Baltram]

:eek:Cooles Rendering... Da kann ich dich mit meinem gmax nur beneiden. Vorallem aber weil du das Levelmesh laden kannst, für gmax ist das Teil einfach zu groß.

Zu den Positionen der importierten Meshes:
Es gibt da schon noch einige Stellen in den XMESHes, von denen ich nicht genau weiß, was dort gespeichert ist. Gut möglich, dass da irgendwo eine relative Positionsangabe ist.

Ich hab jetzt gerade leider nicht die Möglichkeit, da groß rumzuprobieren, weil ich (wegen gmax) nicht nachschauen kann, wie weit z.B. das Doncamp verschoben ist.

Wenn du das mal kurz nachsehen könntest und mir die "richtige" Position von dem Camp gibst (so ungefähr) könnte ich das mal mit ein, zwei Stellen vergleichen, wo ich die Daten vermuten würde.

[Klabautermann]

Danke :)
Hab jetzt mal nachgeguckt... Also das DonCamp ist gegenüber dem Weltmesh um:


-37358,961
-28613,226
-9891,241


(X,Y,Z) verschoben, bzw andersrum..? Wohl eher nicht, die Hafenstadt z.B. passt ja.
Bzw bringt dir diese Angabe was oder brauchst du irgendwelche absoluten Angaben?
Verdreht ist da aber nix, nur verschoben (Gott sei Dank)

[billykater]

I think the world is divided into different pieces because
1. To enable streaming
2. Work around floating point imprecision errors with big numbers.
3. To enable the designers to work on one part of game without loading the whole geometry.

Maybe the harbor city fits the world because it uses the same reference point. This might even be (0,0,0) (Can somebody with max confirm this)?

@Baltram
The second of the two normals you mentioned might be the tangent used for normalmapping.

[NicoDE]

You might have a look at the vertex shader input to get hints for unknown values.
(%Risen%\data\compiled\effects.pak/shadermaterial/ge_default_vs.fx)

struct sVSInput_Default
{
float4 vPos : POSITION0; // Vertex position
float3 vNorm : NORMAL0; // Vertex normal
float3 vTangent : TANGENT0; // Vertex tangent (for the texture coordinates used with first normal map)
float4 vCol0 : COLOR0; // Vertex diffuse color 0
float4 vCol1 : COLOR1; // Vertex diffuse color 1
float2 vTex0 : TEXCOORD0; // Texture coordinate set 0
float2 vTex1 : TEXCOORD1; // Texture coordinate set 1
float2 vTex2 : TEXCOORD2; // Texture coordinate set 2
float2 vTex3 : TEXCOORD3; // Texture coordinate set 3
float vInstance : TEXCOORD4; // Instancing index
float2 vBillboard : TEXCOORD5; // Billboard x = u axis scale, y = v axis scale
float2 vLightmap : TEXCOORD6; // Lightmap texture coordinate

// morphing stuff
float4 vPosDelta1 : POSITION1; // Vertex position delta for morph target 1
float3 vNormDelta1 : NORMAL1; // Vertex normal delta for morph target 1
float4 vPosDelta2 : POSITION2; // Vertex position delta for morph target 2
float3 vNormDelta2 : NORMAL2; // Vertex normal delta for morph target 2
float4 vPosDelta3 : POSITION3; // Vertex position delta for morph target 3
float3 vNormDelta3 : NORMAL3; // Vertex normal delta for morph target 3

// some weights and indices
// for skinning and vegetation rendering
int4 vIndices0 : BLENDINDICES0; // misc use
float4 vWeights0 : BLENDWEIGHT0; // misc use
float4 vWeights1 : BLENDWEIGHT1; // misc use
float4 vWeights2 : BLENDWEIGHT2; // misc use
};

[Baltram]

@billicater & nico
Thanks for the hints!

I just looked accurately through some XMESH files - Now I'm almost 100% sure there isn't contained any 'reference point'. Must be stored in some other file.

[NicoDE]

Now I'm almost 100% sure there isn't contained any 'reference point'. Must be stored in some other file.It would not make sense anyway. If you want to use a mesh more than once (e.g. furniture) you would save the translation/rotation in the instance, not the mesh.

[Shak-otay]

Bei G3 waren Koordinaten in tple und lrentdats enthalten. Wenn man eine Waffe im Marvin mode spawnte, ergab sich ihre Position/Orientierung aus dem zugrundeliegenden template. (Sobald sie z.B. vom Hero angelegt wurde, war die Orientierung von den mesh-Daten bestimmt.)

Wenn kein tple für eine entity existierte, war ihre Position in einer lrentdat- (oder node-) Datei festgelegt.

Denke, dass das in Risen ähnlich sein wird. Da es für das DonCamp sicher kein tple gibt, werde ich mal die zugehörige lrent analysieren.

edit: hier mal Koordinaten einer entity aus Levelmesh_DonCamp.lrent:

7fe
818 DonCamp__Dungeon_Main_02_L01

1.000000 0.000000 0.000000 0.000000
0.000000 1.000000 0.000000 0.000000
0.000000 0.000000 1.000000 0.000000 84a:
-27673.560547 9496.450195 45473.800781 1.000000
-29101.224609 8502.310547 43943.019531
-26582.166016 10411.806641 47036.417969 2211.387939
-27841.695313 9457.058594 45489.718750
-1427.664063 -994.140625 -1530.781250
1091.394531 915.356445 1562.617188

1.000000 0.000000 0.000000 0.000000
0.000000 1.000000 0.000000 0.000000
0.000000 0.000000 1.000000 0.000000
8cf:
-27673.560547 9496.450195 45473.800781 1.000000
-29101.224609 8502.310547 43943.019531
-26582.166016 10411.806641 47036.417969 2211.387939
-27841.695313 9457.058594 45489.718750
1.000000 15000.000000 0.000000 0.000000 0.000000 0.000000

Sehe da zwar keine Ähnlichkeit mit den von Kushel_Baer genannten Koordinaten, aber vllt. hat ja jmd eine Idee.
Die Hauptcoords sind cyanfarben. Orange ist der BoundingBox(?)-Quatsch; die Offsets dazu sind blau.

Die LemonChiffon-Koordinaten sollten eigentlich mit den main coords übereinstimmen.
Donnowhy das hier nicht genau passt...

Aja, und "gelb" hab' ich garnicht kapiert.

(Dunkelrot die Rotationsmatrix; wie man sieht, ist die Entity ungedreht, also 0°; Bezug ist die Nordrichtung; so war's jedenfalls bei G3.)

PS: wäre übrigens schön, wenn wir uns darauf einigen könnten, wie die Höhenkoordinate heisst. Bei G3 war das "y"; also hier y=9496.450195 (aber ihr könnt natürlich machen, was Ihr wollt. Ich werde mich jedenfalls nicht ein 2. Mal umgewöhnen...;-)

[Baltram]

Dass die Koordinaten von "DonCamp__Dungeon_Main_02_L01" nicht so ganz hinhauen wundert mich nicht so - kushel_baer hat ja auch vermutlich eher DonCamp_01_L01._xmsh importiert.

Ich habe ja leider keine Ahnung, wie man sich in diesen lrent-files zurechtfindet aber ich habe einfach mal solange gesucht bis ich bei 24C folgendes gefunden habe:

-28613.221
9891.2402
37358.961

das ähnelt dem hier doch ziemlich:
-37358,961
-28613,226
-9891,241

[Klabautermann]

kushel_baer hat ja auch vermutlich eher DonCamp_01_L01._xmsh importiert.
Jawohl ;)



das ähnelt dem hier doch ziemlich:
Allerdings. Vermutlich hab ich mich irgendwo beim ausrechnen vertippt oder Max hat gerundet oder so ;)

Lässt ja hoffen das ganze :)

Was macht es eigentlich für einen Sinn dass diese Koordinaten alle so extrem genau sind?
Max arbeitet standardmäßig mit 3 Nachkommastellen (Wobei eine Einheit einem cm entspricht), im Spiel selbst sieht man wahrscheinlich nichtmal nen Unterschied wenn die Vertices auf den ganzen cm gerundet werden.
Wieso also diese 4 Nachkommastellen?

[Shak-otay]

[...] solange gesucht bis ich bei 24C folgendes gefunden habe:

-28613.221
9891.2402
37358.961

das ähnelt dem hier doch ziemlich:Fein.§wink

Das sollte der header der root-entity sein; eigentlich logisch§cry (lichtwicht würde sich totlachen...).

Habe leider im Moment keine Zeit, die lrent-Analyse zu komplettieren.

Aber jetzt sollte klar sein, wie bzw. wo die Verschiebungen der meshes festgelegt werden.


Wieso also diese 4 Nachkommastellen?
Hängt vom verwendeten Datenformat ab; bei "float" sinds 6 Nachkommastellen. Mit weniger würde es bei diversen Matrizen-Berechnungen zu zu großen Rundungsfehlern kommen, würde ich sagen.

[Baltram]

Noch eine Frage an dich, Shak-otay:
Woher hast du denn die Daten der CollisionShape, die du vor drei Tagen gepostet hast?

EDIT: Danke! Werde ich mir auch mal anschauen.
Ich kapier grad nicht mehr ganz, was das Problem mit dem CS ist, wenn du doch weißt, wie es aufgebaut ist. Kannst du es nur lesen aber nicht reproduzieren?
(Sorry, wenn das ne dumme Frage ist, ich hatte mit Gothic 3 Modding wirklich nichts am Hut)

[Shak-otay]

Aus G3_Object_Ruin_Castle_01_COL.xnvmsh.
Sry, war natürlich MiniLocation_Ruin_Tower_01_L01_COL._xcom

edit: das Problem mit einem selbsterstellten CS bestand bei G3 darin, dass die engine ihn nicht "angenommen" hat. Obwohl er mit crtl-Q ingame sichtbar war. Ich hab' dann irgendwann vorhandene CS manipulieren können; aber das war nicht das Gelbe vom Ei.
(link (http://forum.worldofplayers.de/forum/showthread.php?p=10651986&#post10651986)) Hatte dann noch BoundingBoxen berechnet. Das hat das Problem aber nicht endgültig gelöst.

Vllt. existiert das Problem ja bei Risen garnicht mehr; aber ich habe iwie Null Bock, das jetzt zu testen. U.a. aus den von mir schon genannten Gründen.

Und heute kommt Dragon Age. Da werde ich mich hier sowieso rar machen, denkich...

Da Du ja mit vertices etc. ganz gut umgehen kannst, löst Du das Problem sicher (wenn es denn überhaupt existiert).

(Wenn Du da was machen willst, würde ich es aber mit kleinen _xcom-Files versuchen. Musst nur beachten, dass bei weniger als 256 vertices die face-indices als BYTE angelegt sind.)

Hier mal die problematische Stelle in Obj_Furn_Table_Broken_02_COL._xcom:
(Orange sollte die BoundingBox sein. War jedenfalls bei G3 so.)

1. 26a:
0.000000 0.000016 0.000000 0.000026 0.000017 0.000025
0 0 3 0 E3 0 85E3 7 0

0.000000 -0.003782 0.526429
0.015793 1.070574

-0.836900 -0.038432 -0.821397
0.836900 1.102375 0.821397
1.281406
0.496936 0.090016 0.000917
0.090016 0.378463 -0.009055
0.000917 -0.009055 0.468329
-0.115619 0.410084 0.016247

2. 2f9:

PS: _xmot sollte auch kein Problem darstellen, wenn man sich lange genug damit auseinandersetzt.

(Die Oger- und troll-xact in G3 hatte ich ja schon gezoomt; für G3-xmot hatte ich dann nur keine Böcke mehr.)

[Baltram]

Danke, damit kann ich denk ich was anfangen. :)
Das xmot-Format ist vermutlich einfach ne Frage der Zeit... mal sehn wie lang ich mich motivieren kann.

Und heute kommt Dragon Age. Da werde ich mich hier sowieso rar machen, denkich...
Das ist schade, allein schon deine G3-Vorkenntnisse wären dem Risen-Modding sehr zuträglich. ich hoffe du schaust hier dann trotzdem noch ab und zu rein.

[Shak-otay]

[...] ich hoffe du schaust hier dann trotzdem noch ab und zu rein.Na loggisch.;)

Sobald nämlich jmd. das _xmot-Format geknackt hat, werde ich ein G3ToRisen-Konverter-Projekt starten. Ein mesh habe ich ja schon transferiert. Am CS werde ich noch etwas basteln; habe da schon wieder eine Idee...

[magische Nautilus]

Is it possible to export?
Would you be able to make an exportscript?