XeNTaX

I've got the rest of the map format charted out as well, with collision and quadtree data, and I've been sitting on these finished "SQLE" models with both of their animation formats and materials supported. I'll probably put up a new build with all of that on the weekend.

Still no idea how blending is specified for the prop-level map objects, despite having accounted for damn near every bit in the map and map geo chunks. I'm thinking there's some external object material database somewhere at this point. Also, regarding the missing sky/moon/water/etc., those objects are generated and driven by the server. There's already an option called -ff11renderunref in the current build, it will shit them all out at identity. You have to figure out how to pull them apart and place them yourself if you want to do something with them. You'll want to use -ff11keepnames with that, unless you want a big terrible inseparable triangle mess. -ff11optimizegeo is probably a good idea too, it will collapse redundancies and remove strip degenerates.

So all the lootables, interactable objects and skybox stuff gets shat out into the map origin if you run those arguments I'm guessing?

I imagine there are plenty of objects that are totally precached and instanced via the server, but yeah, everything explicitly embedded in the file that doesn't have a static object reference will get placed at identity.

-4.168 - Added a new -ff11blendhack option. This uses the Noesis software renderer to render all FF11 map geometry triangles in UV space, and determine how many of each mesh's triangles are only touching zero-alpha pixels in the texture. -ff11blendhack 0.99 is typically a good value to use. This completely demented solution is not foolproof, but catches the vast majority of broken blending cases.
-4.168 - Added support for FF11 SQLE models, including both types of animation.

Don't hurt yourself spanking it, you sick furry bastards. I'm sticking a fork in this now, so if you want anything else fixed/added, you're on your own.

To piece the SQLE models together, you can put a .noesis file in your FFXI directory root (above the ROM directories), like the sample_elf01ff11.noesis file included in the latest build. It looks like this: Modifying for other body/head/animation combinations should be pretty obvious. The bones for the head snapping may change, so figure out which ones you should be using by looking at the models in the Noesis data viewer.

Do you still plan on writing a small gui to make loading player model stuff into Noesis easier? Something like what AltanaView offers?

It's possible that will strike my fancy at some point, but if not, anyone can handle doing it. See tool_windowtest.txt included with Noesis for an example of how to do custom GUI popups. Just use that, write out a .ff11datset text file and have Noesis auto-load it with noesis.openFile whenever you receive a control-changed message. I'd probably just use a scrollbar for each part and reload on the scroll changed message.

I know its a tall order, and I am certainly appreciative of import as it stands, but would it be possible to get an export function?

I realize exporting is sort of a hairier beast.
And you probably don't care. But if I don't ask the answer is a definite no. If I do, there's a 1% chance of yes.
Well I guess that counts as 'added or changed' so that's out I guess.

I glanced at the source you posted, but it seems like its referencing some files that aren't listed on the resource page, like model_ff11_decrypt.h

I also noticed a number of noe and rapi functions in it... if I were to try porting it to blender's python, would I need to know how those functions work, or are they only required to send the data to noesis? (Not sure if that's a clear question)

Probably won't do an exporter until the day comes that there's nothing left to do in life but write exporters for FF games, and I expect to die of cancer or heart failure before then. But, it's possible I'll get to that point, somehow. (but 7, 8, 9, 10, 12, and 13 would come first)

The decryption routines by the guy that wrote ffxitool are in that header, which I didn't reverse myself. I'm not going to provide them publicly, as he could do that himself if he wanted to. If he's still alive. I don't know what his motivation was in ceasing source distribution. Maybe it was because people are turds.

I would encourage you to point people toward Noesis instead of just porting all of the code into a blender importer if that is your aim. Having users is nice and helps bring in new and interesting reports for one-off issues/crashes/etc. Which are provided to me automatically in the case of detectable problems, which is how I know hundreds of thankless bastards are using Noesis on a daily basis despite the complete lack of meaningful feedback outside of when they want a new stupid feature/game. That said, yeah, you need to figure out the purpose of the RAPI functions if you want to port it. Lucky for you, the RAPI uses in that module are pretty obvious.

MrAdults wrote:Probably won't do an exporter until the day comes that there's nothing left to do in life but write exporters for FF games, and I expect to die of cancer or heart failure before then. But, it's possible I'll get to that point, somehow. (but 7, 8, 9, 10, 12, and 13 would come first)

The decryption routines by the guy that wrote ffxitool are in that header, which I didn't reverse myself. I'm not going to provide them publicly, as he could do that himself if he wanted to. If he's still alive. I don't know what his motivation was in ceasing source distribution. Maybe it was because people are turds.

I would encourage you to point people toward Noesis instead of just porting all of the code into a blender importer if that is your aim. Having users is nice and helps bring in new and interesting reports for one-off issues/crashes/etc. Which are provided to me automatically in the case of detectable problems, which is how I know hundreds of thankless bastards are using Noesis on a daily basis despite the complete lack of meaningful feedback outside of when they want a new stupid feature/game. That said, yeah, you need to figure out the purpose of the RAPI functions if you want to port it. Lucky for you, the RAPI uses in that module are pretty obvious.

I was only trying to port it so there wouldn't be any intermediary format swapping... I was also going to try handling the exporting. (It is still an active game and there are model mods...my main reasons)

Intermediary formats generally lead to lossy conversions. However, after spending several hours remembering I don't actually understand C++ despite it looking relatively simple on the surface, I've decided against trying to straight port the code.

I do regularly try to push people toward Noesis for model viewing though. I love Noesis. Its probably in my top 5 most used programs.
...
I'm also somewhat guilty of sending useless crash reports... >.> Then again, I stopped doing that when I realized it was basically my own fault most of the time. My method of scripting involves a lot of hammers and screws.

I see. The character geo + anim data will be pretty much lossless in terms of data storage if you use FBX, but what your FBX importer does on the other side could change that. The mirroring data can be recalculated from the unmirrored data, which a good exporter would want to do anyway to support new geometry from targets that don't support mirroring. You could also just be lazy and not support mirroring and set everything unmirrored, although you would probably not want to do this under the assumption that most people will be wanting to just import new geometry while keeping the mirrored skeleton + anims intact. The animation keyframes can also be recalculated, as the keyframes themselves are preserved as FBX keyframes and we can eliminate all of the unnecessary ones again by checking the error for spherical/linear interpolation at a given point on the animation curve. In these cases, I also typically expose an optional error threshold, so that the export target can enjoy a greater level optimization if the user wants at typically no discernible visual penalty. There's an option for this already rolled into the FBX exporter. In this case, there could potentially be some FP32 precision loss from transforming between matrices with baked scale and T+Q+S, but it's likely to be imperceptible.

Levels on the other hand, it's baking all the instanced geo out and transforming the actual verts, so you wouldn't be able to restore that trivially. The importer could be modified to preserve instances and transforms, but I doubt you were aiming to make a level exporter, as you'd run into a whole lot more trouble there than just instance preservation.

Well, thanks for supporting Noesis. I don't look at any crash report as useless unless it's someone writing a native plugin and causing a crash by feeding bad data into the API or crashing in the plugin itself, or it's someone using an old version of Noesis and the crash is already fixed in newer versions. The Python implementation should, in pure idealism, always protect the user from crashes even when they're doing awful things. Although achieving this in practice is often not worth it, depending on the complexity and overhead of that validation phase. I like to see the instances where this happens either way, though, so I can evaluate what might be done to highlight the bad usage with Python exceptions. I'm typically working with nothing but some thread contexts in a crash report, though, so if you find a case where you find the issue and you think "it shouldn't have been a big deal for Noesis to catch that and tell me about it", you can help a lot and save me some time by sending me your broken script and some data to reproduce the crash.

I looked into the state of FF11 a little when I was doing this format, and was somewhat surprised to see so many people still playing or going back to it, and horrified by the associated furry community as usual. I played it for a few months not long after its release in 2002 or 2003. After getting to around level 50 as a dark knight, I deleted my account and character upon realizing how much of my life I'd just wasted playing what is objectively a pretty awful game. Yet despite knowing it's an objectively awful game and not finding anything about the story particularly engaging, I still felt some strange underlying desire to go back to it, kind of like an abused spouse. If I were jobless, had no family, and in a state of helpless depression, it might've gotten me. Not this time, though, FF11. Not this time.

MrAdults wrote: If I were jobless, had no family, and in a state of helpless depression, it might've gotten me. Not this time, though, FF11. Not this time.

Ha! I tried, but just couldn't get into it.

hm... I just now noticed that the animation reading is bugged. Only half the body's animation actually gets loaded for most of the animations. I'm not sure where to start with trying to get around that problem.
For an example, anyone can take a look at ROM/51/89.dat and see that the legs move for most of them, while the torso stays stark still...

EDIT: oh I see... they're separated into different animations, upper and lower... and they don't all seem to have equal parts for both... but its a lot more obvious when viewing them one animation at a time through the data viewer.

Hey, I'm having a bit of an issue here. Whenever I try to export an FFXI model using Noesis and then import that model into another program (such as 3Ds Max or Unity), the model imports upside down. Am I doing something wrong, or is this a bug in Noesis?

Also, how do I view the models of player characters, considering they're an amalgamation of multiple files?

MrAdults wrote:[...]

Character sets are also supported, via a new format called "ff11datset". An example sample_hume01.ff11datset will be included in the Noesis scenes directory. It works like this:

Code: Select all

NOESIS_FF11_DAT_SET
;^ must be the first line of the file

;search for dats using a path retrieved from a registry key
setPathKey	"HKEY_LOCAL_MACHINE" "SOFTWARE\PlayOnlineUS\InstallFolder" "0001"

;search for dats on a path relative to this file 
;setPathRel	"./"

;search for dats on an absolute path
;setPathAbs	"c:/whatever/ff11/"

dat			"__skeleton"	"ROM/27/82.dat"
dat			"__animation"	"ROM/27/82.dat"
dat			"face"			"ROM/27/87.dat"
dat			"head"			"ROM/27/103.dat"
dat			"body"			"ROM/28/7.dat"
dat			"hands"			"ROM/28/52.dat"
dat			"waist"			"ROM/28/84.dat"
dat			"legs"			"ROM/28/116.dat"
dat			"weapon"		"ROM/29/20.dat"

That's how.
I find its helpful to have Model Viewer or Altanaview open to find the dat numbers (they're displayed at the bottom of either program when they're loaded from the drop list)

As for loading upside down.... no that's not a bug.
It's due to the fact that all 3D programs consider "up" to be a different direction chosen by whomever wrote said program.
It would be nice if you could specify a global Noesis 'up' axis, butas of right now I don't think there is one. There may be an advanced option to export with a custom rotation in the export options... but I'm not sure.

In any case it shouldn't be that hard to fix it on import... most importers have an option to specify an Up axis simply because not all formats and programs use the same one.

And back on my previous post I did notice that one upper body animation is missing, when it should be present. I'll have to look through the source again to see if there's any loop -1 errors or such... god I hate debugging C++

There is a way to specify "up" in Noesis, that's why the models appear oriented correctly in Noesis. Noesis doesn't rotate the geometry itself, it changes what's considered "up" in the scene. This is The Right Thing To Do.

Most formats on the other hand don't support arbitrary scene orientations. The FBX exporter supports z-up using -fbxzup if you happen to be exporting from a format that uses this convention, or you can rotate the actual geometry using -rotate # # # where # # # are pitch, yaw, and roll. Or you can take the raw unrotated data into your modeler of choice and specify a correct "up" axis, if your modeler of choice allows. Most programs suck in this regard or only allow y-up/z-up.