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.

Shouldn't make any difference.

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

misc_model_ghoul doesn't work in MP apparently: http://www.lucasforums.com/showthread.php?t=133076

Despite the problem with that surface, I'll make a test version available now lol. It'll help me with finding more bugs, and I can fix that particular bug along with the others that will inevitably come in.

Download link: https://dl.dropboxusercontent.com/u/874909/fbx2ghoul2.zip

This is what it DOES do:

• Converts FBX file to GLM.
• Supports LODs.
• Supports static meshes.

DOES NOT support:

• Animations
• Skeletons

How to use:

From your 3d editor, export the model as an FBX binary file (it might work with text too? I'm not sure). Make sure to triangulate the model, and set Z as up. Drag and drop the FBX file on to the exe file, and the model.glm file will be created in the same directory as your FBX file.

I'm not releasing this on the JKHub files just yet until I'm sure the current features are working as they should.

PLEASE reply back with any bugs you find, and also any improvements or suggestions you have

Well that's odd Now I have to fix more stuff!

And LODs are fixed I have a weird problem with LOD0 of your Stormtrooper though @@DT85. The r_hand_plate surface is in completely the wrong place On LOD1 and LOD2, they are in the right place though. I'm pretty sure it's not a problem with the converter either. (The little white blob below the stormie is the right hand plate.)

Got to have another look today, and it looks like I've done LOD support completely wrong lol. Will need to rewrite a fair amount of code to fix this now

EDIT: How many LODs does your stormtrooper have @@DT85?

The problem with proning on slopes can be fixed by using inverse kinematics. There's some basic support for it in the engine (rancor uses it to grab players) but I don't know how flexible the code is.

I didn't add any LODs to the model I gave you, I'll send you a model that does have LODs.

Oh really...then that simplifies things a bit for me actually

One thing I just thought of. Will this have LOD support?

Yep, there is LOD support - if I've done it right I see 2 LODs on the Luke model you gave me, which are the same. Is that right?

Don't you need to list out player joints? What about creating .surf and .skin files at compile time?

Why would you need to list the player joints? Creating .skin files should be doable, as long as the FBX file has the correct texture paths. I can't remember what a .surf file does off the top of my head though!

Would you guys want a GUI for this? There's not really much to show though to be honest. At the moment you can drag your FBX file on to the program icon and it'll spit out a GLM file, or you can use the command line if you want to specify the GLM file name.

Adding it to ModView could be an option if I ever finish my platform port to Mac and Linux, but for now that's off the table

Forgive me for being the sceptic, but isn't 30 maps a little too much? Especially if they're all reasonably sized.

I would just use oriented bounding boxes for prone. The collision code already checks for when the bounding box is rotated but falls back immediately to using axis aligned boxes (at least I think this was the case). If you replaced this with the appropriate code then there's no reason why you can't use rotated bounding boxes for collision

I came up with my idea way before Disney started coming up with their's lol so it's not new in any sense.

According to Wikipedia, Lucas had already planned out 12 episodes for Star Wars. Lucas' biographer believes that Disney will follow Lucas' outlines, so let's hope they really do

By qualifications, what do you mean? lol.

He's probably asking what modding experience you have had before.

A few more hours of work later, and we can say hello to Luke properly

I just need to fix up bolts, and make the converter usable. And I made a mistake in an earlier post - this first version will only be able to export non-animated models. I haven't looked at fetching the weighting information from the FBX file yet.

For jokes, here's some WIP screenshots while I was trying to get this to work

That didn't seem to fix any problems Looks like I'll have to do things the hard way.

Great work!!!  However, I notice that some (if not all...) of your tags need rotating 90 degrees about the z-axis.  For example, the hands and feet appear to be needing a rotation of 90 degrees about the z-axis (when you compare to an original model in old ModView).  But I'm sure you'll have it all sorted out soon...

 

I do hope you intend to make a .GLM/.GLA to .FBX converter... or better yet, just add a "Save As" feature in your new ModView program to save it back out to .FBX  

Good call on the tags Not sure why that's happened. I've applied the same transformations to the tags as I have to the meshes so they should be correct (or maybe the tags were in incorrect and carcass does some weird magic to fix them up again). I do plan to make a converter back to FBX. This seems easy enough, now that I've seen how the FBX format works

Probably won't add this to ModView, at least not for now. The good thing about having a standalone utility for things like this is you can create a batch script or something similar to convert an entire directory of files to GLM.

Great work Xycaleth, keep it up!  Is it reading off the base JKA humanoid.gla with weighting intact?

 

If you need anything else, let me know.

Haven't got to working on weighting just yet But another quick question! I'm having problems with texture coordinates as 3ds seems to export FBX with more texture coordinates than positions and normals. Are you perhaps preserving smooth groups when you export (if such an option exists)? Can you send me the model with and without smooth groups preserved if possible? Thanks

Almost there Just texture coordinates to go now.

64GB is definitely more likely than 64MB.

Acrobat obviously meant GB

Thanks @@DT85 Looks like I need to do a bit more work to get tags and model rotated/translated properly, but aside from that I can start working on an initial release. It will allow modelers to export player models or non-animated models. No custom animations just yet.

...how much does a master server cost to maintain really?

 

I guarantee Steam sales alone monthly should be able to pay for that many times over.

I own a server capable of running a master server. It costs me about $5 a month.

Virtually nothing, but keep in mind that Raven is Activision's bitch to work on CoD, and CoD is in decline. Raven hasn't put out a decent game imo since Quake 4 (but to be fair I haven't played enough of the new Wolfenstein to really judge), so whether or not they're self-sustainable is questionable.

Add to the fact that the master server is probably on company soil and they have system administrators looking after their other servers, it costs nothing (at least, not in  financial overhead) to maintain the master server.

It really aggravates me off that my computer should be able to compile a large map in 60 seconds, but this old software turns it into something more like 60 minutes.

 

My computer is 64 bit and I have about 64 megs of ram. Should compile this stuff in no time flat so makes me not want to map.

Throwing more memory at your computer won't make it run faster. The limiting factor in compiling maps (and especially the lighting stage) is your CPU. This is why movie CG is rendered using multiple servers, each running the calculations on graphics card (which are very well suited to lighting calculations).

@@DT85 are you sure you exported the model as Z-axis being up? Luke is rotated sideways, as you see in the screenshot with the Z axis pointing up. Maybe the model was already modeled with the Z-axis being up in 3ds so it got rotated again?