FBX to GLM converter

[Xycaleth]

I've updated the exe with storing the texture paths, try again  https://dl.dropboxusercontent.com/u/874909/fbx2ghoul2.zip

[DT.]

@@Xycaleth

 

Ok it works with both ASCII & binary versions of FBX.

 

It's grabbing the full filename and path (C:\blah\blah\) when we need the material name that the user can input themselves so it will work with JKA. Below is the ASCII version of the file, and it looks to have the material name here (I inputted myself in 3ds Max) for each object:

 

 

 ;Material::models\players\dt_stormtrooper\bodysuit_D.tga, Model::hips
 C: "OO",437751040,1555348056

 

So if you could have it grab the texture path & name from the material name, that'd work nicely.

 

 

EDIT:

 

Btw I re-weighed the r hand plate and it's now fixed and looking fine.

[DT.]

Ok some bugs:

 

- There has to be another mesh object (whether it's a LOD or just another object) in the exported FBX that isn't connected to the original models hierarchy or it will come up with "failed to create GLM".

- I can't seem to get it to compile all 3 LODs when not testing out on a player model. Is there a certain amount of model parts required or a certain number of triangles/vertexes the original model needs to be to allow all 3 LODs to be generated?

 

These things aside, it looks to generate a world weapon model that matches the MD3view generated ones.

 

 

EDIT:

 

Here's a pic of the e-11 with no scope:

 

 

(I edited the ASCII FBX file to point to the correct texture path)

[Xycaleth]

Ok some bugs:

 

- There has to be another mesh object (whether it's a LOD or just another object) in the exported FBX that isn't connected to the original models hierarchy or it will come up with "failed to create GLM".

- I can't seem to get it to compile all 3 LODs when not testing out on a player model. Is there a certain amount of model parts required or a certain number of triangles/vertexes the original model needs to be to allow all 3 LODs to be generated?

 

These things aside, it looks to generate a world weapon model that matches the MD3view generated ones.

My bad... these are caused by some pretty lame assumptions I made about the scene. Should be pretty easy to fix.

 

Here's a pic of the e-11 with no scope: ..

Yay, awesome I've fixed the problem with the texture path now. Will upload a new version when I add in the fixes for the other things you mentioned.

[DT.]

@@Xycaleth

 

 

One thing I'm curious about. If/when this compiles characters & animations, would it be possible to update the Ghoul2 format to allow smoothing groups? I've noticed it currently smoothes surfaces by how the UVW map islands are made which causes splits/breaks in the smoothing of objects. While it is tolerable in most of the time, it can sometimes be quite troublesome when trying to have the best lighting on your model. That, and it will look pretty bad IF (and I say IF, because rend2 isn't a sure thing to work) at some point there are normal maps in JKA.

[Xycaleth]

@@DT85 I don't have the smoothing group information in the FBX file as far as I can tell. And I'm pretty sure that where two groups meet, the exporter which creates the FBX file duplicates the vertex positions so that the duplicate can have different normals from the original (to create a hard edge). Might be wrong though...

[DT.]

Yeah I didn't export them as I think you said not to at one point lol. Ideally I'd at least like to have the ability to have the entire object completely smoothed with no splits/breaks/hard edges along the UVW island edges. I can send you another file whenever you want to give this a go, just let me know.

[DT.]

I'll post this here incase you lose the pic:

 

 

UVW edges defining model surface continuity, for those who don't get the pic.

[Xycaleth]

I'm almost there with the vertex weighting Just need a model to test with which uses the JKA skeleton *hint hint @@DT85*

[DT.]

@@Xycaleth

 

The FBX file I sent you last of my Stormie should be ready to go, it just has it's own animation that I use for testing purposes.

[minilogoguy18]

The problem with edges being disconnected at UV seams would be a huge plus if it can be fixed, that alone increases models vertex count on export and in turn reducing performance.

[DT.]

I talked with Xycaleth on IRC and he might have an idea of what to do, but it's pointless until we can get animated models + animations running through the converter. After everything is working, I'd like to have XSI 3.0/3.5 file processing so we can still work with the Raven source files otherwise it will be a BIG job to have to convert them all to FBX.

[Psyk0Sith]

The problem with edges being disconnected at UV seams would be a huge plus if it can be fixed, that alone increases models vertex count on export and in turn reducing performance.

 

All UV coordinate borders create extra verts, it's always been like that, even if you didn't detach the polygons or set smoothing groups. It's still true in today's AAA engines. Which is probably what's happening here.

 

"On the most basic level, the triangle count and the vertex count can be similar if the all the triangles are connected to one another. 1 triangle uses 3 vertices, 2 triangles use 4 vertices, 3 triangles use 5 vertices, 4 triangles use 6 vertices and so on. However, seams in UVs, changes to shading/smoothing groups, and material changes from triangle to triangle... are all treated as a physical break in the model's surface, when the model is rendered by the game. The vertices must be duplicated at these breaks, so the model can be sent in renderable chunks to the graphics card. Overuse of smoothing groups, over-splittage of UVs, too many material assignments (and too much misalignment of these three properties), all of these lead to a much larger vertex count. This can stress the transform stages for the model, slowing performance. It can also increase the memory cost for the mesh because there are more vertices to send and store."

 

source:

http://wiki.polycount.com/PolygonCount

 

So in other words, if the mesh splits are happening at UV borders, then they are "free" and don't impact performance, they just look ugly for now

[DT.]

I haven't seen splitting anywhere on any models in:

 

- source engine (MDL format)

- UDK (FBX format)

- Quake 4 (MD5 format)

- any COD game from MW1 up (no idea what format)

- SWTOR (no idea what format)

 

So not sure what AAA engines you mean. Maybe when using smoothing groups in formats that support it, the splits don't occur. Otherwise, we would see splitting all over the place when around lights in games (like my alora pic).

[Xycaleth]

Just because a vertex gets duplicated doesn't mean it has to be different. If you have duplicate vertices with matching normals and texture coordinates then you won't be able to see where they meet

[Psyk0Sith]

@@DT85

Like Xycaleth said: It won't be visible. I was refering to it being ugly because of how the FBX conversion treated the splits, which should be easily fixed, that option is present in the assimilate interface in case something goes wrong (they call it "remove duplicate verts" or something like that)

[DT.]

Yeah I kinda didn't fully understand what you meant. I tried to explain the problem with the splits to Xycaleth and it just came out horribly so a pic was more useful.

 

Btw I never found a difference in using lose duplicate verts option, good or bad. :\

 

 

@@Xycaleth

 

Will there be a script file to use with the converter once there's more features/options? One thing I can think of right now we would need is setting the scale.

[Xycaleth]

@@Xycaleth

 

The FBX file I sent you last of my Stormie should be ready to go, it just has it's own animation that I use for testing purposes.

I need a model that is weighted to an existing GLA It looks like your Stormtrooper uses its own skeleton. It needs to be an existing GLA as I can then test the weighting stuff separately from generating the GLA file.

 

@@Xycaleth

 

Will there be a script file to use with the converter once there's more features/options? One thing I can think of right now we would need is setting the scale.

Yes, that's an option. I'll need some help on what kind of settings would be needed though.

[DT.]

@@Xycaleth

 

It's not meant to be using its own skeleton, it's a clone of the file I used for my JKA stormie. I'll send you fresh files anyway.

[minilogoguy18]

Maybe someone then should just try to break the model at the UV seams before export in an attempt to preserve the normals, in the game the 'hard' edges are noticeable when light hits them.

[Xycaleth]

Well, back on to animations, I'm almost there for models using the humanoid GLA

[AshuraDX]

Maybe someone then should just try to break the model at the UV seams before export in an attempt to preserve the normals, in the game the 'hard' edges are noticeable when light hits them.

tried that , have to wait for this converter to be finished or find my old max 2010 installer

[minilogoguy18]

Yeah I would try it myself but I don't have anything to export.

[Xycaleth]

Let's try that again  (ignoring the floating armour from the right hand for now lol)

 

So looks like exporting models which use the humanoid GLA file works now! I'll tidy up the code, and then upload a new version of the exporter tonight

[DT.]

Doesn't matter if you break the model at the UV seams or not, there will always be a seam line where you don't want it.

 

 

@@Xycaleth

 

Looking great!

 

What's up with the lradiusX & rradiusX bones? They look a bit odd lol.