RichW

I never would've seen this if I hadn't replied to that PM to correct Gummelt and seen the notification. So apologies in advance that I will probably forget to ever come back here and check this thread. Feel free to poke me on #ja if there are questions. My suggestions for format improvements would be: Use FP16 instead of the poorly-range-quantized U16. It will work out more handily for both rotations and translations. I recommend pre-filtering IEEE special-cases in the tool, which will make conversion to FP32 actually faster than the scale & bias the engine does with current data.Probably a good idea to just have a format option/header flag to allow F32. Slightly more implementation cruft, but it would also be possible to allow only specific frames/sequences within the format to use FP32.Adaptive delta compression is an option, but honestly, is probably overkill. It would only be really appropriate if you aimed to shrink the data even smaller than what shipped with JK2/JA 15+ years ago.I changed Unity for a commercial title recently to use FP16 instead of FP32 for virtually all of their Hermite coefficients, doing auto-analysis of the error in FP32->FP16 conversion to determine per-sequence which anim curves should be left as FP32. It applied to all forms of animation data (translation, rotation, scale, and other custom splines) and cut around around 70MB off of the game's memory footprint. Absolutely no one noticed when the change went in. So something like this will probably work out just fine without the need to really get any fancier. One other thing: I don't see any particular advantage to RLE encoding or other storage-level compression, as there's always zlib/pk3 for that. Most compression would also be of limited utility if you did go with a very aggressive adaptive delta scheme. (storing n-bit streams for each joint on a per-sequence basis would, however, have somewhat of a downside of needing to "decompress" up to the frame being requested if you need to transform for a frame within a sequence out of order) Probably best to keep it simple here, just switching to FP16 and utilizing the full FP16 range will be a massive win in quality already, with no cost in storage. Giving flexibility to choose FP32 for rotations and/or translations on a per-frame, per-sequence, and/or per-file basis on top of that should be all anyone really needs in this realm. Unless you wanted to develop a brand new state machine driven animation system or something, but that would also necessitate reworking massive swaths of game code and wouldn't be a nice drop-in replacement anymore. Anyway, happy to shove a commandline option into Noesis to export GLA in this format. Let me know how it shakes out.

I didn't actually know there were any until last week. I've fixed quite a bit of stuff DT85 has told me about over the weekend, so I think it's in a good state now. He mentioned he's gonna be working on a Noesis export tutorial, which is excellent. So, about the compression, I'm not sure what carcass was doing. But they kinda got it wrong in the format - the way the engine expects transforms, you're ending up with parent-local matrices which are in base/bind-local space. Bind-local matrices in parent-local space would've been much more efficient for small deltas, where lots of bones would've ended up being stored as identity because they don't animate away from the bind pose when in parent-local space. Lots of stuff moves as a result of hierarchy when you apply the bind-local transform before the parent-local one. Beyond that, all Noesis does is quantize the bones like so: RichMat43 *rMat = (RichMat43 *)mat; RichQuat rQuat = rMat->GetTranspose().ToQuat(); comp[0] = (unsigned short)((rQuat[3]+2.0f)*16383.0f); comp[1] = (unsigned short)((rQuat[0]+2.0f)*16383.0f); comp[2] = (unsigned short)((rQuat[1]+2.0f)*16383.0f); comp[3] = (unsigned short)((rQuat[2]+2.0f)*16383.0f); comp[4] = (unsigned short)((mat->o[0]+512.0f)*64.0f); comp[5] = (unsigned short)((mat->o[1]+512.0f)*64.0f); comp[6] = (unsigned short)((mat->o[2]+512.0f)*64.0f); As you'll notice, the quaternion range is also unnecessarily limiting precision, another legacy limitation of the format. Ghoul2 animation compression could've easily been a lot better with no drawbacks, but I guess no one noticed during development, myself included. After Noesis quantizes the rotations+translations, it uses a simple hash to build up a list of unique q+t pairs. It will only consider something a match if it fits exactly. If I had to venture a guess, that might be where carcass goes wrong, using a looser comparison method and ending up with matches that don't quite match. Either that or the quantization is just wrong.

It could depend on a lot of things, especially which format you're using to go between. Is it FBX? With any format, there are some things to be aware of: 1) Noesis will load a texture even if it doesn't have an extension, by checking for that texture in all of its supported texture formats. (of which there are many) Not all modelers will be able to do the same, they often need an explicit extension on the texture path. 2) Noesis will also load a texture by the material name, if the actual texture path doesn't exist. This isn't standard behavior for any modeler I'm aware of, but Noesis does it to handle formats where "material name" basically means "texture name". So there are a number of situations where Noesis will know how to match the mesh to the material/texture and most other software won't. Best way to figure out what's going on there is to actually drill down into the mesh/material in your modeler. If you can tell me exactly why it's not finding the texture(s), I can tell you if Noesis has an export option to help you address the problem automatically. It usually does, when it comes to this stuff. And if by the textures being "messed up" you mean they're flipped, then yeah, like Psyk0Sith mentioned there, you probably have to flip the UV's on export. y-up/y-down standards are a mess across some formats, like obj.

Well, you're exporting with weighting intact, so you can certainly modify the geometry and retain the weighting data. Chances are, if you modify the vertices/topology significantly, the weighting will look wrong and you'll have to adjust it and/or add weights for new verts, but adjusting the broken portion is a far cry from having to re-weight the whole model if you just want to make selective modifications. A weight is defined as just a bone index and an influence factor for that bone when you're working with this data post-export and modeling in bind space, so a good editor will handle modification of the underlying geometry in a non-destructive way. Max is pretty good at letting you modify the underlying geometry without throwing a fit, since you can just work undernearth the skin modifier on your modifier stack. Max also happens to be my own modeling tool of choice, but I'm certainly not a modeler by trade. Regarding display of textures, Noesis will auto-display them if it can find them on the path or in the model directory, and if they're specified in the surface's shader field. That works well for JK2 models, but JA models usually have their shader string cleared because they rely on the skin file to specify shader/texture for each surface. Noesis doesn't parse that file at the moment, but if you'd find it helpful that'd be simple enough to add. I've generally gone out of my way to avoid adding interactive editing features to Noesis, because I feel like it'd expand the scope way beyond what I could comfortably maintain in my spare time. It is quite possible to make editing tools through the tools plugin system, though, and there's a triangle picker example up on the repository at code.google.com/noesis-plugins-official/. Not that I expect anyone to actually endeavor to make a plugin tool editing suite, but the tools to make tools are there if anyone wants it that badly.

"skeleton shit"? It imports the skeleton, just put the GLA for the GLM in the same directory as the GLM when you open it if Noesis isn't locating it on the path. This is as of 4.0984, if you're still using an older version you'll want to use the auto-update feature under the Tools menu as GLM and GLA export was added over the last couple of versions. You're able to go GLM and/or GLA to FBX/other (I recommend FBX as the most feature-complete target format), and from FBX/other to GLM+GLA. So you're able to export existing models+animations to FBX, modify them, then put them back in the game. For example usage on the GLM side of things, see the .bat files and readme in http://www.richwhitehouse.com/filemirror/Noesis_JediAcademy.zip I've tested re-exporting existing JA models just to make sure that the whole pipeline works, and as a test used Noesis's Final Fantasy 12 support to directly convert a FF12 model and animations to GLM+GLA with no actual modification/tweaking necessary: http://www.richwhitehouse.com/pubimg/ja_vaan.jpg The game-ready converted GLM+GLA were produced with the following command line (not that you need to run it on the commandline, but I find it useful for setting up model conversion batches), for reference: Noesis.exe ?cmode c1004_00.ff12a model.glm -animoutex .gla -scale 25 -rotate 270 0 0 -posoffset 0 0 -24 -g2exanimname "models/players/vaan/rlx_idle00" -g2exanimconfig -renamebone "bone000" "model_root" -g2exfakehierarchy So, enjoy. Keep in mind that Noesis is a tool for asset conversion/preview/processing, not for actual interactive editing, but if there's something else you're referring to that you want it to do, then please do be more specific.

Noesis has GLM and GLA export support now. Feel free to try it out and let me know in #jacoders if you run into any problems.