WIP Fixing the dotXSI 3.0 Exporter for 3ds Max...

[Archangel35757]

@@Archangel35757 I'd have to check but before I do I can tell you what really happens. The normals aren't exactly the problem, what happens is the edges along the UV boundaries are disconnected which then in turn alters the normals as that is what happens when you have a boundary edge. You need to get to the source as to why the edges along UV boundaries become disconnected, it seems to be something either with carcass or the MDX format itself.

 

EDIT: Well, seems that it is just limited to 3ds Max because Kain only shows different normals along mesh boundaries, UV seams do not appear to be split, or at least I couldn't see it.

If Carcass doesn't show the same UV splits on your Softimage model then it could be the dotXSI exporter doing something with the UV normals... can you post any screenshots that show your mesh and UV normals?

[minilogoguy18]

Pics from what? Softimage, ModView or in game?

 

EDIT: This brings me back to another topic that needs to be brought back up, ModView really needs shader support and a possible scene light that can maybe be moved around, fuck all the other jargon that was requested for it, this would make the program leaps and bounds more useful for finding issues with models.

[Archangel35757]

Pics from what? Softimage, ModView or in game?

 

EDIT: This brings me back to another topic that needs to be brought back up, ModView really needs shader support and a possible scene light that can maybe be moved around, fuck all the other jargon that was requested for it, this would make the program leaps and bounds more useful for finding issues with models.

Whatever would show the mesh or UV normals. I agree, (@@Xycaleth) Modview needs proper shader & normal map support & light support

[minilogoguy18]

UV's don't have their own normals, what happens is the model gets split around the UV boundaries, import the models and see for yourself.

 

You can view vertex normals in ModView, it seems that the model isn't being split by it's UV islands according to what I'm seeing in ModView.

[minilogoguy18]

@@Archangel35757 if you really wanna narrow it down then why not just give me something exported from 3ds Max.

[Tempust85]

Just discovered this:

 

 

Left is the Max scene, Right is modview. So right now, the normals are borked.

[Archangel35757]

@@Archangel35757 if you really wanna narrow it down then why not just give me something exported from 3ds Max.

Yeah, I'd like to come up with a test case for us to check out. We need a "not-too-complicated" model that we can test both vertex normals and UV seams... between Max & Softimage with Carcass. Maybe you, me and @@DT85 can come up with something.

 

Just discovered this:

 

Left is the Max scene, Right is modview. So right now, the normals are borked.

Yeah... that looks like I forgot to do the coordinate transformation on the vertex normals. I'll fix it when I add the other vertex normal export options.

[minilogoguy18]

All you really need is a model where 1 mesh has more than 1 UV island, the exporter will cut the edges of that mesh along the UV boundaries causing the seam that you'll see due to boundary edges having forced hard edges.

 

You might also wanna look into a way to preserve polygon normals, that may have more to do with carcass and the MDX format though but making sure that normals are preserved by say exporting to dotXSI then importing the dotXSI back into either Max or Softimage to make sure the normals are at least exported on your end properly.

[Archangel35757]

All you really need is a model where 1 mesh has more than 1 UV island, the exporter will cut the edges of that mesh along the UV boundaries causing the seam that you'll see due to boundary edges having forced hard edges...

But can you or someone explain to me why it does that? Does Softimage --> Carcass do the same thing? If so, then we need a fix in Carcass to retain original normals along UV Seams, yes?

[minilogoguy18]

Problem doesn't seem to be there using Softimage.

[Archangel35757]

Problem doesn't seem to be there using Softimage.

Can you post some screenshots showing that is in fact the case?

[minilogoguy18]

@@Archangel35757

 

First image shows the inner part of the thumb which you can see the texture seam where it isn't quite perfect, the vertexes are all welded along that seam. The second image I disconnected and you can see the vertex normal lines now making "V's" from there being 2 vertexes sharing the same space and having different normals. Now, it's hard to see but in the third image you can see that the vertex's along the seam share a common normal.

 

After further inspection carcass is responsible for splitting edges along UV boundaries BUT for some reason my normals are being preserved so that the seam isn't noticeable but I saw the telltale vertex count increase in ModView which means my edges are getting split BUT it's not affecting the normals. Need to dig more but this could also mean that for whatever reason I may be able to work with custom normals where you guys it seems to be ignored when you use your smoothing groups.

 

EDIT: I'm also just kinda guessing that my edges are getting split along UV boundaries based on the increased vertex count but wouldn't know for sure unless someone imported the GLM file, the dotXSI file has no splits when I import it.

[Archangel35757]

@@minilogoguy18 - What happens if you use the -losedupverts switch?

[minilogoguy18]

I have no idea what that does and where to enter it.

[Archangel35757]

I have no idea what that does and where to enter it.

It is just one of carcass' command switches like (-smooth).

[Tempust85]

Goes in your model.car file. Maybe it just welds meshes?

[Archangel35757]

Quick Update:  So I haven't made the progress I would have liked...

 

...but I have the Max2013 C++ project updated as dotXSI 3.0 v1.9 Beta and I have the export dialog updated with all of the new vertex normal export options.  I also have the class methods updated so that all the new vertex normal methods are there at least in skeleton form (...and both x86 and x64 projects compile successfully).  All I need to do now is write the five new methods (and correct the original two...) -- and then beta test it with @@DT85's help.  Hopefully by the latter part of next week (I have to travel for work the first part of the week) I'll have a plugin for DT85 to test.

 

EDIT:  Once I get the Max 2013 exporter working properly... I will apply the changes/corrections and update all exporter plugins for Max6 thru Max2016 to v1.9.

Edited November 2, 2015 by Archangel35757

[Archangel35757]

Update:  This is going to take longer than anticipated... looking deeper into the code (and knocking the rust off my brain...) and the linear way that they exported the dotXSI templates and nested children templates complicates matters.

 

It's compounded by the fact that the dotXSI format breaks a mesh's data like so:

SI_Mesh  {

 

SI_Shape {
  …
}

SI_TriangleList {
  …
}

 

}

 

And there is a separate class export method (::ExportMesh, ::ExportShape, ::ExportTraingleList, etc.) for exporting each template (SI_Mesh, SI_Shape, SI_TriangleList, etc.).  And they all take a pointer to the original Node container.  So each time they re-get the mesh object contained within the Node container and they process the mesh again to only write out the data required by each dotXSI template.  The SI_Shape template lists out the actual vertex positions (Point3 values), vertex normals (Normalized Point3 values), and vertex UV coordinates in UV space (Point2 values). 

 

It is in the SI_Shape template that I need to do the Max-to-XSI coordinate transformation on the vertex normals... and that should fix the bad normals that @@DT85 posted about.  But it's going to be more complicated to do SmoothGroup/Explicit normals because I'll either have to redo all calculations for each child template to extract the specific data each template requires... or do the calculations once and come up with a clever way to re-access the already computed results in the children templates.  My opinion, is to attempt the latter so as to save processing time.

 

Stay tuned...

[Archangel35757]

I need @@DT85 and @@minilogoguy18 to help make a test case in 3dsMax (DT85) and Softimage (minilogoguy18) ...something simple like a box at the origin and extrude each square face out along the positive X, Y, Z axes (like making a coordinate tripod)... textured in red, green, and blue... coordinate on the dimensions... also something with explicit normals or multiple smoothing groups... (I could do this in Max but I'd fumble for hours using Softimage).

[Archangel35757]

So here are the Type Normals export options I plan to add to the v1.9 dotXSI 3.0 Exporter (shown in red):

 

 

Thoughts (@@DT85, @@AshuraDX, @@Xycaleth, @@Psyk0Sith)?

I think I'm going to reduce these options to only add the "specified/explicit" option... so the artist will have to set smoothgroups or custom normals themselves in 3ds Max.

[Archangel35757]

I've emailed @@DT85 a new v1.9 dotXSI exporter which should fix the bad vertex normal orientations for the legacy export options.  I'm still working on the code for the new vertex normal export options (to support smooth groups and explicit normals).

[Tempust85]

Normals appear to match up with what I see in Max. Here's an in-game comparison of the before and after:

 

 

 

 

 

[Archangel35757]

@@DT85. -- Are the vertex normals correct when you don't rotate the model 90 degrees (I.e. leave it face down on ground) during export?

[Tempust85]

@@DT85. -- Are the vertex normals correct when you don't rotate the model 90 degrees (I.e. leave it face down on ground) during export?

 

Yes, exactly the same and correct.

[Archangel35757]

Ok... so I have the vertex normals being written out properly from the smoothing groups. But I need to sort out the vertex normal indices that map those normals to the vertices for each triangle in the mesh.