Spotlight: Señor Casaroja's Noesis

[NMCM]

but when I open the program it crashes before I could do anything. Windows Help and Support says it is Data Execution Prevention.

I just enabled Data Execution Prevention on my end, but Noesis still works fine. (That's Noesis v1.31 on Windows 7.) Maybe you can enable DEP for Windows services/programs only instead of for all programs. Or maybe you should do a virus/malware check in case there's something else going on. (Rather vague suggestions, sorry.)

I've tried all of the above, but no luck. I'm not sure what its...I am running on windows Vista Home Premium.

[epopoe]

2Mr.Adults

Don't know if this issue is game specific (Tekken 6) or concerns some other games.

Code: Select all

Output extension has set output file type to:
.dae - COLLADA
Detected file type: SC4 Model
Writing 'C:\Documents and Settings\Firsak\Desktop\New Folder\ntxr000.dds'.
Writing 'C:\Documents and Settings\Firsak\Desktop\New Folder\ntxr000.dds'.
Writing 'C:\Documents and Settings\Firsak\Desktop\New Folder\ntxr000.dds'.
Cleaned 8.00MB (in 2 pools).

As you can see, files overwrite each other. This only occurs with NMD files that contain textures only.
Is there a workaround for this at the moment? Maybe some command it would be wise to use?

Speaking of commands (advanced options). The only way that I found to get a list of commands was to launch mesh2rdm.

Same problem here.

files overwrite each other, so I cant get all texture files.

Some tip I have. Use 3dvia capture on Noesis .

[Tosyk]

2Mr.Adults

1. Can you add batch convert option?
2. Can you add support for Silent Hill: Homecoming to convert in .smd with bones and weight data?

[hiryu64]

Hey, this is a fantastic tool you've made here. I've been using it on the FFXIII models and it's quite nice. However, I believe I've encountered a bug when exporting to the SMD format. When I export to DAE, I get all the bones and weights in the proper places, but when I export as SMD, some of the bones move to the wrong place, stacking up on others and copying their weights. That is, the bones lose their original weighting and take on the weighting of the bone that they now overlap. Interestingly, they are still parented properly.

I've attached a photo showing what I mean. The DAE import is on the left, and the SMD import is on the right. You can look at her cape and right hand in the DAE shot and see that the bones are arranged normally, but in the SMD shot they appear to be missing. In this case, the cape bones are all on the root bone and the finger bones have all stacked on each other. It's bizarre.

Hopefully you get this and (if you have time) are able to do something about it. You can PM me for more info if you need to. As far as I know, everything else works great. If I encounter more bugs, I'll be sure to let you know. Thanks!

(For reference, I'm using 3ds Max 2011, converting the file "c001_x360.trb" via Noesis -- see this thread for more info. For both I used the Rotate option, and for advanced options, I used -scale 40 for the SMD and -scale 101.5 for the DAE. I used OpenCOLLADA and Wunderboy's SMD Importer.)

EDIT
I've been testing it out on some of the other TRBs, and it seems that the issue only crops up if a model has over a certain number of bones. I can confirm that two of the models with lower bone counts (specifically f085 and c595, Frocobo and Vanille without clothing (yeah yeah, whatever...I chose this one because fewer clothes equals fewer bones)) appear to export with skeletons intact (though I'm not completely sure about c595). Their bone counts are 28 and 156, respectively. Lightning there (c001) has 251 bones, and her skeleton definitely screws up on export, as does c005 (Vanille with clothing), clocking in at 218.

I wonder if it may be an overflow issue or something. I'm not terribly knowledgeable on the subject, but maybe if too many bones are present the SMD export algorithm fails because of how memory is allocated or something...shot in the dark there, but hopefully I narrowed it down a bit. Thanks again, and hope to hear from ya soon!

[MrAdults]

Sorry for disappearing for a couple months longer than expected there. I had a lot of stuff to do, and now I've got to find another job before I go broke. So I don't really have the personal resources to devote to Noesis, but I'm still interested in adding to and fixing it in the long term, if I don't become a hobo. For those of you having any kind of crashes or hangs, I would ask if you can:

A) Provide reliable steps to reproduce.
B) Give me the details of your system (graphics card, CPU, etc.)
C) Super bonus points if you can manage this: Break the process into a debugger and give me the value of EIP (instruction pointer) for each thread, as well as registers for each thread and super bonus points if you can get the surrounding stack dump.
D) PM this info over to me.

There is an in-progress version with various bugfixes that I will try to get up sometime soonish. I haven't touched the project in over 2 months, now, so I've gotta clear some time to sit back down with it.

Regarding import/export bugs that only happen with specific format, just keep posting them here and I will deal with them as I get to them.

[firsak]

Bug: textures are always referenced as PNGs in DAE when exported, even if texture output was set to TGA or DDS, so one has to manually edit DAEs with a text editor
Bug: crash on export if texture output is set to PNG or TGA with certain files (sample)
Bug: Problem with some of Tekken 6 NMDs that contain textures (sample)
Bug: crash on opening certain SMDs (sample)
Bug: application sometimes takes a lot of time to open for no apparent reason (usually if you open a Noesis associated file type directly)
Request: FFXIV support (samples). Some say that the format is almost identical to FFXIII and even can be opened with Noesis if the files are hexed properly
Request: remember the last export settings
Request: export to PSK/PSA (a good replacement for SMD, which, unfortunately, doesn't have reliable importers)
Request: help button in export dialog that, when pressed, pops up a window with a list of available commands
Request: ability to load files on top of already opened files to export as a whole (again, Tekken 6 would be a good example - you open someone's torso, then open legs, head and so on and export the result as one model)

[MrAdults]

Edit: Oops, double-posted. It's taking me literally 2-5 minutes to view forum pages at the moment for some reason.

[MrAdults]

Ok, I devoted a couple hours tonight to sitting down and addressing some of this stuff.

First, hiryu64, I'm sorry to have to say it's a bug in Wunderboy's SMD importer. Check out the SMD imported back into Noesis, and you'll see the skeleton is preserved perfectly. I have found similar bugs in that importer in SMD files not exported from Noesis, too. It's rather annoying to me, as it's also the SMD importer I use for Max.

And now...

Bug: textures are always referenced as PNGs in DAE when exported, even if texture output was set to TGA or DDS, so one has to manually edit DAEs with a text editor

Hm, I think this depends on your importer and suite. For me, Max 9 seems to automatically load the right file regardless of extension, as long as the path is right (using the OpenCOLLADA importer). But I can look into stripping or correcting extensions on import sometime, probably not for the next version though.

Bug: crash on export if texture output is set to PNG or TGA with certain files (sample)

Fixed for next release.

Bug: Problem with some of Tekken 6 NMDs that contain textures (sample)

Has been fixed for a long time, but haven't gotten around to making a release with the fix yet.

Bug: crash on opening certain SMDs (sample)

Fixed, but that SMD is really screwed. Bad normals, bad weighting (lots of weightless verts).

Bug: application sometimes takes a lot of time to open for no apparent reason (usually if you open a Noesis associated file type directly)

Cannot reproduce, but I would venture a guess that you are opening a file somewhere deep in a folder hierarchy, so it takes the MFC shell viewer a while to load that path up (due to the recursive nature of the thing). That's kinda out of my control, unless I want to start digging into Microsoft's control code and making my own overrides to optimize it, and I don't.

Request: FFXIV support (samples). Some say that the format is almost identical to FFXIII and even can be opened with Noesis if the files are hexed properly

FF14 files from some alpha/beta a while ago all opened just fine with no modification, allowing such horrible abominations as this to be created. If they changed the format, I'm not gonna bother following along. Maybe once the game's final, which will also lessen the chance of SE getting pissed off and throwing C&D's at poor Mr. Casaroja.

Request: remember the last export settings

Maybe some day.

Request: export to PSK/PSA (a good replacement for SMD, which, unfortunately, doesn't have reliable importers)

I'm generally not opposed to new formats, but I don't really like PSK as an export format. It lacks support for vertex normals, and only supports per-triangle smoothing groups (which often translate from vertex normals inefficiently). Unless there is an updated spec that I am not aware of. In any case, I think there are far more deserving (and more flexible) formats that ought to come before PSK.

Request: help button in export dialog that, when pressed, pops up a window with a list of available commands

Been done for a while.

Request: ability to load files on top of already opened files to export as a whole (again, Tekken 6 would be a good example - you open someone's torso, then open legs, head and so on and export the result as one model)

Maybe some day, but it's extremely low priority.

Next version will be up on the Oasis at some point in the coming days.

[Acewell]

Bug(?): It has trouble reading all objects within non-character(vehicles, weapons etc) .glm files, some parts are missing from these when imported.

[MrAdults]

Bug(?): It has trouble reading all objects within non-character(vehicles, weapons etc) .glm files, some parts are missing from these when imported.

That's probably not a bug, and is just the default GHOUL2 behavior. Most GHOUL2 implementations (like in Raven's Jedi Knight games) have "tag" and "off" surfaces invisible by default. Since that path was written before the advent of surface toggling via the data viewer, it just excludes those surfaces entirely by default on import.

However, you can keep them intact when exporting, with these "advanced options" flags.

Code: Select all

-g2exportoff - exports off surfaces for ghoul2.
-g2exporttag - exports tag surfaces for ghoul2.

[Acewell]

That's probably not a bug, and is just the default GHOUL2 behavior. Most GHOUL2 implementations (like in Raven's Jedi Knight games) have "tag" and "off" surfaces invisible by default. Since that path was written before the advent of surface toggling via the data viewer, it just excludes those surfaces entirely by default on import.

However, you can keep them intact when exporting, with these "advanced options" flags.

Code: Select all

-g2exportoff - exports off surfaces for ghoul2.
-g2exporttag - exports tag surfaces for ghoul2.

Thanks for replying but it didn't work, i'm aware of those objects not meant to be visible but parts of the actual model which are meant to be seen are not being imported(or read at all) and are not exported even using the advanced options, this doesn't seem to be an issue with the character models which import and export fine.
For example; if I import a weapon then the scope geometry will not be imported etc.

If you need to see some examples then I can send them to you.

[MrAdults]

If you need to see some examples then I can send them to you.

If it's an actual bug, you would need to send some examples then, yeah. Can't fix what I can't see!

You mention a "scope" on a weapon so does this mean you are working with SoF2 glm's, JK2's disruptor, or what? Never did test any of those SoF2 models. I'm not sure if the format was changed there at all. It had the whole WRAITH system internally, but I'm pretty sure that was just a ridiculous and unnecessary API abstraction for animation-related crap.

[hiryu64]

First, hiryu64, I'm sorry to have to say it's a bug in Wunderboy's SMD importer. Check out the SMD imported back into Noesis, and you'll see the skeleton is preserved perfectly. I have found similar bugs in that importer in SMD files not exported from Noesis, too. It's rather annoying to me, as it's also the SMD importer I use for Max.

D'oh, I didn't even think of testing it out that way. I'm sorry I ever doubted you! *bow* I'M NOT WORTHY! I'M NOT WORTHY!

I'll shoot Wunderboy an email alerting him of the problem, and hopefully he'll address the issue. DAE suits my purposes fine for now, but SMD is nice because of the whole one-mesh, one-smoothing group thing. Anyway, keep up the good work, and hopefully things begin to work out for you in the real world. Cheers!

[MrAdults]

I'll shoot Wunderboy an email alerting him of the problem, and hopefully he'll address the issue. DAE suits my purposes fine for now, but SMD is nice because of the whole one-mesh, one-smoothing group thing. Anyway, keep up the good work, and hopefully things begin to work out for you in the real world. Cheers!

Cool, I hope he gets around to fixing it.

By the way, new Noesis is out: http://oasis.xentax.com/index.php?content=downloads

===============
What's New
===============
Version 1.6:
-New "Special Thanks" section in ReadMe, as I realized I was being a thankless bastard for all of the awesome people on XeNTaX.
-Fixed a .glm import bug, which would cause some surfaces to be missed entirely. (thanks to AceWell for submitting this bug)
-Added global JPEG reading/writing. (did this mainly to have auto-loading for JK2 model textures)
-Fixed another .glm bug, where path to .gla would be treated as working-directory-relative instead of file-relative.
-Made scene lighting not rotate with model when changing the base rotation axis.
-Added read support for very old RenderWare (I think) DFF format. (used in Sub-Culture for Windows/PC)
-Added limited BMP read/write support. (24bpp with no RLE)
-Fixed bad interface state when drag-and-dropping anims to apply to open models.

[MrAdults]

And now 0.7 is out! As usual, latest file can be downloaded at http://oasis.xentax.com/index.php?content=downloads

===============
What's New
===============
Version 1.7:
-Generic vertex morph handling. Only implemented so far for Sub Culture's DFF format, DOAX2/NG2, and MD3. Preserves vertex morphs on export (to some formats) and displays them in previewer as animations.
-Quake 3 MD3 import and export. (useful for exporting those morph target meshes, though there is usually precision loss in the format)
-Fixed a path bug, which might've shown up in situations where a file is processed in a working-directory-relative path.
-Support for converting skeletal models+animations to pure vertex morph animations, via the MD3 path. Bone-based tags are also supported. (see -md3tbone advanced option)

Boobie morphs seen in DOAX2/NG2 can be played as animations, but they are really meant as reference frames, so when you play them at the default framerate you will just see some hyperboobie jittering.