dotXSI 3.0/3.5 Importer for 3ds Max / Gmax

[Archangel35757]

Hmmm... it may be complaining about lines like this:

 

readValue inFile as integer, or readValue inFile + 1, etc.

 

Try putting parentheses around the readValue command like:

 

( readValue inFile ) as integer, etc.

 

I'll fix it on my end too...

[Archangel35757]

The script compiles just fine and functions in Max 2011, 2012, 2013. However, I seem to be having skinning issues on files exported with the "v1.8" exporters... whereas the Raven assets import correctly now (...as tested in 8 and 2011)

 

...must continue debugging.

[Archangel35757]

Ok... I'm still having some bugs dealing with dotXSI files exported using the v1.8 exporters.  Good news is the maxscript compiles and functions in 3ds Max 2015, but I'm getting the error that @@DT85 got in Max 2014.  This issue is related to skin modifier and applying the skin weights.

 

Here is the results of my error from the Maxscript Listener:

************************************************** 

   Compile error: Illegal input in readValue
   In line: SI_Envelope h                             

**************************************************

 

--Note to Self:  the script opens and hightlights line# 1297

 

Listener Output:
Welcome to MAXScript.

3 materials placed into Material Editor.
-- Error occurred in n loop; filename: C:\Users\Michael Lawler\Desktop\XSI_Import_Beta_Max_v2_00_Rev-D.ms; position: 39555; line: 1252
--  Frame:
--   tempIndex: undefined
--   vertIndex: 157
--   n: 157
--   vertexID: undefined
--   weight: undefined
--   called in Get_SI_Envelope(); filename: C:\Users\Michael Lawler\Desktop\XSI_Import_Beta_Max_v2_00_Rev-D.ms; position: 39931; line: 1264
--  Frame:
--   meshObj: $head
--   numWeightedVertices: 160
--   tempEnvFilePos: 4264594
--   boneID: undefined
--   numberOfBones: undefined
--   vertWeightArr: #(100.0, 100.0, 0.0, 100.0, 0.0, 75.0, 0.0, 0.0, 0.0, 100.0, 0.0, 75.0, 0.0, 0.0, 100.0, 100.0, 100.0, 75.0, 100.0, 0.0, ...)
--   tempGeomObj: #("MDL", "head")
--   tempNumBones: undefined
--   a: undefined
--   BoneObj: $cranium
--   tempBoneObj: #("MDL", "cranium")
--   s: undefined
--   absentFlag: undefined
--   called in Get_SI_EnvelopeList(); filename: C:\Users\Michael Lawler\Desktop\XSI_Import_Beta_Max_v2_00_Rev-D.ms; position: 41977; line: 1342
--  Frame:
--   lineIn: #("SI_Envelope", "head", "{")
--   called in main(); filename: C:\Users\Michael Lawler\Desktop\XSI_Import_Beta_Max_v2_00_Rev-D.ms; position: 68329; line: 2132
--  Frame:
--   endOfStream: false
--   lineIn: #("SI_EnvelopeList", "both_saberslamdown", "{")
--   prefix: "BASEPOSE"
--   fistr: <File:C:\Users\Michael Lawler\Desktop\testExport.XSI>
--   called in btn_Import.pressed(); filename: C:\Users\Michael Lawler\Desktop\XSI_Import_Beta_Max_v2_00_Rev-D.ms; position: 83792; line: 2637
--  Frame:
--   tempFileName: undefined
>> MAXScript Rollout Handler Exception:
-- Compile error: Illegal input in readValue
--  In line:  SI_Envelope h <<

 

So it looks like I have a little more debugging to do.

[Archangel35757]

@@DT85 -- So I found the bug that is causing skinning errors with v1.8 exporter files. This script bug is also the cause for the "readValue" error posted previously. Actually the original error lies with Raven's custom dotXSI exporter and not the Softimage based v1.8 exporter. It just manifested that way because I designed the script to first process Raven assets-- thinking all others would be good as well.

 

When I get this fixed I will send you another beta version to try out.

[Archangel35757]

UPDATE:  ...so I've sorted out the skinning issues-- they should be resolved.  Unfortunately, there still is a bug in Maxscript regarding the "readValue" command for newer versions.  I say it's a bug... because the script works just fine for all game types from Max 5 to Max 2011.  In Max 2012, all dotXSI 3.x files import correctly (given the WIP status of the script-- still need to finish some things...).  Unfortunately, this "readValue" bug breaks compatibility with the older dotXSI 1.x files in Max 2012.

 

...and in 3dsMax 2013+ the script seems to have more than one problem... even if you uncheck importing of envelopes.  So, I'm going to finish the script targeting versions up to 3ds Max 2011 (which will work in 2012 for dotXSI 3.x files only).

 

...I hope you guys didn't un-install your older versions of 3ds Max.

[Archangel35757]

Ok... so the way I have the script set up to import the model textures is this:

 

First, it will look in the relative path (read from the XSICustomPSet template) and appending it to the base directory path you specify.  If it find's the texture then all is good.  But if the textures are not in the base path then it looks in the same directory as the file being imported, if the texture still is not found, then it creates a composite checker map with a "MissingBitmap.png" texture.

 

So if the textures are not found it would come out like this:

 

Regardless, it will write the proper texture file name and relative path as the Diffuse Texture Map Slot Name.  The Top-Level Material name is just sequentially numbered:  material_1, material_2, etc.  These can be renamed by the Artist to whatever they want it to be... e.g., head, torso, etc.  But the new version of the exporter will expect the relative path for the texture (e.g., models/players/jedi_malak/body.tga ) to be the Diffuse Map Name.

 

Once you sort out your missing textures, it's easy to replace the "Missing Bitmap" Checker pattern-- where they should immediately show up on the model.  The checker pattern will always use the first color as RED the secondary color is a random color that doesn't use any red in it's RGB value... and the values are limited so it doesn't get too dark.

 

Any feedback on this approach?

[Archangel35757]

@@DT85, so you might like this new layout (although your request isn't implemented yet... it has a placeholder):

 

 

 

Ok, now on to the issues that remain. So some dotXSI files (so far I'm only aware of the Wampa dotXSI files...) are problematic. For some unknown reason, the SI_Transform BASEPOSE templates in the dotXSI file are messed up:

 

SI_Model MDL-rear_null {

 

SI_Transform BASEPOSE-rear_null {

1.000000,

1.000000,

1.000000,

0.000000,

0.000000,

0.000000,

-0.000000,

5.464221,

-5.272779,

}

 

SI_Transform SRT-rear_null {

1.000000,

1.000000,

1.000000,

0.000000,

0.000000,

0.000000,

-0.000000,

35.464222,

-5.272779,

}

Because the parent of this rear_null is "skeleton_root" which has a transform matrix of identity... these two templates should be identical. I can't explain yet why they are not... but what I did to try and correctly import these "messed" up files was to use the SRT transforms to compute the Basepose as opposed to using the Basepose transforms on frame 0. The SRT and BASEPOSE transforms are related. The BASEPOSE transform is the matrix for an object with respect to World space coordinates; and the SRT transforms is the matrix for an object in local coordinates with respect to where it is in its parent space. Nodes/objects which have no parent or their parent is a node at the origin with the identity matrix as its transform would have equivalent SRT and BASEPOSE matrices.

 

(World space): Basepose Transform = ( SRT transform ) * parent.transform

 

or,

 

(Parent space): SRT transform = Basepose Transform * (inverse parent.transform)

 

**The way I try to remember this to keep things straight as to what space is what, is a little saying I came up with, which is: "A child (i.e., SRT matrix) separated from its parent (i.e., not multiplied by its parent matrix) would be lost in the world. But when a child is with its parent, then it knows its place in the world."

 

So I added a checkbox along with some logic, conditional statements to use the SRT transforms to compute the basepose matrices on frame 0. This worked but for some odd reason the LOD0 mesh object remained in the lower, incorrect position. It was exactly 30.0 units lower than where it should have been-- the exact error between the two templates above (for the Y-axis values, Y is up in Softimage).

The result is this circus act (note: the importer only applies textures to LOD0, but it does put the materials in the material editor for you):

 

 

For those 3dsMax users who ever imported the Wampa with the old Softimage importer then this should be no surprise seeing the LOD0 mesh below the ground plane. Additionally all the caps were misplaced lower as well. The easy fix for this is straightforward, simply select the offending objects (and choose affect objects only) and then, in this case, move them vertically 30.0 in the +Z axis. With all the meshes selected go into the character menu and set these fixed positions as the new skin pose. If you do this correctly, you should get this:

 

 

...for grins, I changed the rear_null template values to match and re-imported (not using SRT values but the Basepose values) and all this did was fix LOD0 to be in the correct position and shifted LODs 1 and 2 to be "riding the shoulders of LOD0". There must be something else I'm doing wrong... because Mod Tool has no problems importing this file correctly.

 

When constructing the meshes from the xsi data face-by-face... I do multiply by the parent transform (which in my case is identity matrix)... perhaps I'm doing something incorrect there... but then again the Importer is working just fine for the humanoid and other creature files I've tested... so maybe it's only the Wampa files that are messed up.

 

[Edit]-- One thing I am not doing is actually storing the BASEPOSE and SRT transforms for mesh objects... because all meshes should have their pivots at the origin, and mesh vertex data has the positions where all the vertices should be... since I'm constructing it poly-by-poly... but I just looked at the hips_1 and hips_2 LODs and their templates have a -30.0 value. So I think I need to be using their SRT and BASEPOSE templates as well.

 

I will investigate this ephiphany later... off to bed now.

 

Feedback is welcome.

[Archangel35757]

@@DT85

 

Well crap... I'm going to have to come up with another solution (other than using the SRT transform for the basepose-- to fix those characters who have their basepose below the groundplane) because that will only work for the root pose files.  In the animated files they did not export frame0 so the first frame in the file is the initial animated pose on frame1-- which is NOT equal to the basepose.  So my fix messes up on animated files.

 

Thinking out loud... I believe I am going to have to let it import as-is... and then check to see if the root basepose on frame0 is below the groundplane... then provide a checkmark option to shift basepose up on frame0.  I'll need to work out those details...

[Archangel35757]

@@DT85. @@Psyk0Sith

 

I just want to verify that all mesh objects, bolts, caps, etc. are supposed to have their pivots at the origin? ...and that this requirement applies across the board to humanoid, creatures, vehicles, etc.

[DT.]

I should think so, yeah.

[Psyk0Sith]

@@Archangel35757

 

Meshes (caps and body parts) are set to origin, but the tags have their own individual pivots set at the 90 degree angle of the triangle if i'm not mistaken. When i move the tags for the caps i use the align tool, which allows to move the tag from its pivot point as the "source" to the center of the corresponding cap mesh.

[minilogoguy18]

Every piece of geometry has their transforms zeroed out (0,0,0 in local space) tags can have whatever origin they want, the game uses I think the local transforms of the edges of the triangles to dictate how they behave, the tags actual local transforms aren't used.

 

I was testing this theory with the tags a little while ago, here is an example of how the game would handle the tags for both GLM and MD3 models since yes, it is different.

 

 

I made it so that the transform gizmo is visible in Softimage just to show how it would appear in ModView and MD3View if you selected an object like a tag and it shows the tranforms (red,green,blue lines).

[Archangel35757]

@@Archangel35757

 

Meshes (caps and body parts) are set to origin, but the tags have their own individual pivots set at the 90 degree angle of the triangle if i'm not mistaken. When i move the tags for the caps i use the align tool, which allows to move the tag from its pivot point as the "source" to the center of the corresponding cap mesh.

 

"bolt" is the terminology for Ghoul2 models... "tag" is the terminology of MD3 models.  So I just want to make sure that I don't mess up in writing the importer to do something it should not.

 

All mesh objects for the character, creature, or vehicle are set at the world origin [ 0.0, 0.0, 0.0 ]. 

 

But currently, the pivots of all bolts are located in world space at the bolt (i.e., NOT at the world origin-- this is what I wanted to confirm to be the correct behavior).

 

P.S. -- I can't seem to figure out how to "fix" the wampa files... (so far it is the only one slightly messed up in some face bones).  @@minilogoguy18-- I saw something in Softimage Mod Tool that talked about making the scene root be co-located with the first bone???  I wonder if this is what is causing the transforms to be exported such that the Wampa seems centered about the origin???  Perhaps it was exported with incorrect settings?  And somehow ModTool is compensating for this during import.

[Psyk0Sith]

Yeah i always called all of them tags since the quake 3 days...bolt would be the right term for ghoul2.

[DT.]

The game uses vert numbering on the tags for the angles, so the pivot of the tag can be wherever and the game will just at you and not change a thing. To change the angle, you need to rotate the mesh itself.

 

Tags & bolts are really the same between the formats afaik. They both use vert numbering for tag/bolt angles, and are used as bolting points for other models & effects. Also, pretty sure Ghoul2 is just an upgraded version of MDR which I think is an upgraded version of MD3. Clues to this is how GLM is called MDXM, and GLA is called MDXA in the game code.

[Archangel35757]

@@DT85 -- I understand their similarity, but in Ghoul2 models they should be labeled as "bolt_" and "tag" in MD3 was my original point.

 

Also, I just uploaded a brand new Maxscript that fixes the broken Softimage dotXSI v1.7 Import Plugin... well, I mean it cleans up the mess and puts the animation in the proper 3ds Max coordinate system...

 

Softimage dotXSI Import (v1.7 Plug-in) Cleaner 0.4 Beta

 

So now the screwed up Wampa animations can be imported into 3ds Max... but I would recommend using my other dotXSI Importer maxscript for all other files.

[Archangel35757]

Ok... the new Maxscript to be used with the Max6 Softimage dotXSI importer should be fixed and working properly now...

 

Softimage dotXSI Import (v1.7 Plug-in) Cleaner 0.5 Beta

 

[Archangel35757]

Update:

 

...only one issue remains to be resolved for the new dotXSI 1.x and 3.x Importer Maxscript (v2.0 Beta)-- which is... there is some sort of bug where some of the rancor's textures are not importing.  This issue doesn't show up when importing other files but it could impact other files and so I need to trace it down and fix it.  I also need to apply the dotXSI 3.x changes to the batch import routine and then it'll be ready to release.

[Archangel35757]

Update:

 

Just submitted the first official release (v2.0 Beta R1) of the Maxscript dotXSI Importer that adds support for dotXSI 3.0 and 3.5 files... status is pending approval.

[Archangel35757]

Update: I've been working to update my dotXSI 1.x/3.x import maxscript to add support for retaining dotXSI 3.x normals in an Edit_Normals modifer.

 

I have that working... but I've been trying to diagnose (with @@AshuraDX) why the script fails in Max versions above 2012. It's really bizarre. The script works just fine in 2011. In Max2015 it appears to be haning up at a specific point in the SI_Envelope parsing. I really want to fix this so it works for 2013-2016.