Jump to content

FBX to GLM converter


Recommended Posts

@@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. :D

 

 

EDIT:

 

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

Link to comment

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:

 

656v.jpg

 

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

Link to comment

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.

Archangel35757 and Tempust85 like this
Link to comment
  • 2 weeks later...

@@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.

Link to comment

@@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...

Link to comment

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. ;)

Link to comment

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. :P

Archangel35757 likes this
Link to comment

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 ;)

Link to comment

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).

Link to comment

@@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)

Link to comment

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. :P

 

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.

Link to comment

@@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.

Link to comment
  • 2 weeks later...

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

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...