XeNTaX

The contents of this post was deleted because of possible forum rules violation.

The contents of this post was deleted because of possible forum rules violation.

Hi to everybody in this community,

1. Being new here and not yet knowing who's who (with just one exception below ), I guess this is best be addressed to MrAdults -- I think it will be a near perfect hit:

Seems like Noesis 3.33 sometimes fails to display simple BMP's correctly if they have odd sizes like in the following screenie taken under my XP Pro Sp3 on a 2.2GHz Intel Core2 Duo w/ GeForce 8600 + newest drivers installed:The original picture size is 659x342 pixels -- I can't attach it here as the forum doesn't permit me a second attachment. I think something may be wrong with BMP scanline padding to DWORD boundary in this AfxFrameOrView100su window's code. Incorrect padding usually produces visible distortion of that kind for arbitrarily-sized bitmaps uncommon to the honorable 3D community.

2. Codeman sonny boy, do drop in at home at least once in a while, will ya'?

This is how this picture looks properly textured on a plane:

Scanlines weren't being padded to a 32-bit boundary for import or export. New release is up that fixes it. BMP support is pretty halfassed anyway though, and only supports 24-bit non-rle images.

Yo MrAdults any chance you're gonna make noesis support shadow heart covenant model too ??

Thanks for the input MrAdults,

Why wouldn't you bundle Noesis with the DevIL pack -- I think it could've been a perfect match. Of course, with just a few exceptions of the rare texture formats that DevIL doesn't support yet but which can easily be added directly to Noesis.

Hi Mr. Adults,
I was browsing your other website and found out how to properly (a year late, but I am now a little wiser none the less).

I've noticed that for the most part Noesis can handle alot of the Final Fantasy games, but FF12 is missing from that list. I was just curious if those models require more time than you've got. Or if there is just too many issues with these models? Or if they are even in your interest in the foreseeable future?

Either way, I appreciate all the effort you've put into Noesis, keep up the great work.

I've never looked at FF12's data, so as far as I know it could take a day or a week. No idea. It's been on the list of games to eventually look at for a very long time. Unfortunately I don't have a lot of time these days to look at new games, between work and other active hobby projects, so it's become rare for me to work on Noesis at all outside of quick bug fixes and simple variant-format additions. (like the recent update to include Record of Lodoss War formats, they're mostly just njcm containers and a custum pvr-format texture header)

I would be happy if someone else made a plugin for FF12, but so far revelation is still the only other person to manage to produce a Noesis plugin. This is despite the fact that I continue to see standalone native-Windows-binary model viewers, which in those particular cases makes it seem like people are just being weird about wanting to make everything "theirs". I can't think of another reason you'd want to code your own viewer/export frameworks from scratch, when you could implement the given format in Noesis with about 200 lines of code instead.

Is there a way to do batch exports with noesis?
I must've missed the instructions for working in command-line somewhere.

Also, in the event that two plugins conflict with each other somehow (like when trying to auto-detect format), how does noesis handle it?

MrAdults wrote:Stuck 3.34 up with a quick fix.

Thank you very much, but I'm afraid that a new bug kicked in.
When converting from certain formats to other formats, Noesis adds a lot of underscores to the bone names for some reason.



Attached to this post is a PSK file that, if converted to DAE, gets underscores added to bone names.

finale00 wrote:Is there a way to do batch exports with noesis?
I must've missed the instructions for working in command-line somewhere.

Also, in the event that two plugins conflict with each other somehow (like when trying to auto-detect format), how does noesis handle it?

You did indeed miss the instructions for working in command-line somewhere. Try looking in the ReadMe.txt where it says "Command Line Mode". And of course there is also a batch export tool in the Tools menu. Also, if two plugins are both looking for the same data *and* extension, whichever plugin is loaded first will be the one to get priority.

firsak: New bug? This has been the behavior forever. Your PSK has a shitload of spaces after the bone names. FCollada just doesn't like spaces in scene joints (for some reason) so it converts them to underscores.

MrAdults wrote:This has been the behavior forever.

Never noticed it before for some reason...
That PSK was exported by me from 3dsmax with the official tool and it didn't have any spaces in bone names. It also imports back using Gildor's ActorX Importer and there are no spaces as well. So it should still be a bug in Noesis.

I think all the 0x20s if not followed by something else should be simply ignored in case of PSK format.

MrAdults wrote: You did indeed miss the instructions for working in command-line somewhere. Try looking in the ReadMe.txt where it says "Command Line Mode". And of course there is also a batch export tool in the Tools menu. Also, if two plugins are both looking for the same data *and* extension, whichever plugin is loaded first will be the one to get priority.

I think command-line instructions should come first
Anyways I guess I can play with the plugin template some time. Hopefully it's a matter of just filling in a parser function.

firsak wrote:

MrAdults wrote:This has been the behavior forever.

Never noticed it before for some reason...
That PSK was exported by me from 3dsmax with the official tool and it didn't have any spaces in bone names. It also imports back using Gildor's ActorX Importer and there are no spaces as well. So it should still be a bug in Noesis.

I think all the 0x20s if not followed by something else should be simply ignored in case of PSK format.

Just look at your PSK in a hex editor, you can clearly see the bone names are followed by tons of spaces before the terminating character. I've exported PSK's with the official ActorX plugin from Max before too, and it does not add spaces to my bone names.

If you can find me an official PSK spec doc that confirms trailing spaces should be ignored, I'll implement that functionality. Otherwise I'm going to leave it as is.

Edit: Hm, Googled it and found "- improved compatibility with Epic's ActorX Exporter (dropping trailing spaces from bone names)" in Gildor's changelog. That's weird. I'm exporting a test scene with ActorX right now and it is not giving me trailing spaces. Although my ActorX plugin is probably years old now. I guess I'll add it with a -pskkeepspace option or some shit to go back to old behavior. I also don't see why it's only padding out to 32 bytes with spaces in your file, when the bone names are 64 bytes long.