Exports happen on another thread, so if Havok is pissy about stuff happening on anything other than the thread that created a given world/context and you're doing initialization outside of your handler (or persisting any data across invocations of your handler), that could do it. Best to do all of your init/shutdown within the handler to make sure it all happens on the same thread. Or have a dedicated Havok thread that does all of the work, and just implement your own mechanism for communicating commands (or whatever synchronization method you prefer) to push/pull data with that thread.

It's also possible that Havok would object to doing anything outside of the main application thread, but I don't think it should have any notions of what the main thread is, again unless you're performing an API call on another thread at some point.

You can make the ads go away by registering

Spot on! I think there's an example using havok that creates another thread, could be the docs, hkxcmd or havok2fbx idk haha, just finished exporting animations though so wonder how much I care

Edit: now that I think about it, I allocated some memory in init because loading consecutive files would crash, but changing this back to load would probably have solved exporting files... fair enough, have my cares!

Support for various PBR materials, post effects, and a slight rendering overhaul. Coming soonish with a universal CPU disassembler/debugger and a bunch of other crap I've been chipping away at for months.

MrAdults, thanks for your great progress. I have one request though I mentioned some years ago. If you could make this tree view and othe windows a switchable Noesis could became a simple viewer. Gosh it would be so great. Right now all this available Noesis windows just loads for so long and not quick at all.

_________________
Thank you for all you do here
my blog | my forum

What sorcery is this?!

It's called shading =D

_________________

There's already a build out that avoids expanding the tree view outside of the direct hierarchy leading to the file, so if you drag & drop or use File->Open to browse it won't slow things down. There has also been a "No Browse to Target" option for years which effectively deactivates the shell views unless you use them directly. And you can uncheck "Type Info" to avoid having Noesis hit files as you're running through the file list to validate their types. These three things combined should leave you with pretty much zero overhead, unless something's wrong with your system that's causing heavy stalls during very limited file enumeration.

this is freaking awesome! working like a charm. much appreciate!

p.s.: btw there's a way to turn off the Debug Log by default?

_________________
Thank you for all you do here
my blog | my forum

It is off by default - you have a script installed where someone left the noesis.logPopup() call in.

thanks for point that out!

EDIT:
can I set default shading or viewport FOV?

_________________
Thank you for all you do here
my blog | my forum

This looks amazing Mr Adults! Cannot wait!

_________________
Click the thanks button if I helped!

Went back and fixed up FO4 this evening (bitangent in w components was obvious, jonwd is such a tool), and added an option to use PBR materials:



Currently making assumptions about roughness (rather glossiness) and metal, since I haven't touched the material support, but they're good assumptions for most things that are metal.

FO4? Fall out 4 models?

Looking great there btw

Despite the fact that the selected "Source (* .mdl)" used a third-party plug-in (from finale00) "Astebreed (* .mdl)".

Hey guys, quick question ...
Besides the following function in Noesis,

Which doesn't seem to work for me on the Final Fantasy XIII series, is there any other way to export the characters and such in only one mesh and also to keep its skeleton/skin/weight and such intact and animations too?
Preferably in FBX format.

cheers