XeNTaX

You can copy the decompress script over to the unpacker and just have it decompress while unpacking the files.

-combinemeshes is working perfectly for me. It produces a FBX/DAE with the same number of meshes as exporting the same model to PSK. What is your problem with it?

finale00 wrote:You can copy the decompress script over to the unpacker and just have it decompress while unpacking the files.

i CAN successfully convert full skinned models from SF4, even if i don't have automated procces:
- Street Fight 4 (pc/xbox360)
- Super Srteet Fighter 4 (pc/xbox360)
- Street Fighter X Tekken (xbox360)

but as i said before: i wish that everything will be in one place

MrAdults, i'm trying to convert this model (smd), but -combinemeshes doesn't work for me (fbx, dae)

ALSO, i found this, looks like info about reversing SF4 formats

That's because it's already been combined, silly. It has 21 meshes when loaded because it uses 21 separate materials/textures. If you export to any format with or without combinemeshes is still has at least 21 meshes. If you export to PSK is still has 21 meshes.

As far as I know the SF4 model/anim viewer (that I think revelation worked on, could be wrong, I forgot) is already opensource and should provide all the info anyone could need about the formats.

MrAdults, if i export to fbx, dae with/without 'combinemeshes' i get 21 meshes with Skin modifier on them
if i export to psk with/without 'combinemeshes' i get just 1 mesh with Skin modifier on it

i'm doing something wrong?

Tosyk wrote:MrAdults, if i export to fbx, dae with/without 'combinemeshes' i get 21 meshes with Skin modifier on them
if i export to psk with/without 'combinemeshes' i get just 1 mesh with Skin modifier on it

i'm doing something wrong?

Actorx imports a single mesh eventhough you have a hundred of materials mean while collada-fbx imports unattached meshes.

Just for curiosity, what are you trying to do with sfxtk models in 3dsmax?? importing them with the skin modifier??

I just noticed a quirk of the GMO importer... All the texures are labeled diss_## on export as opposed to something more relevant. I assume this is unaltered behavior from the original importer you made for Dissidia oh so long ago...

Also I've noticed that many models, usually OBJ and Collada DAE, import with reversed normals, is there any chance we could get an option to flip the normals in the preview window?
(I realize I've probably mentioned that before, and I believe you said you couldn't reproduce the phenomina... but still...)

Back on the topic of the GMO texture output, the GMO I open is named C022.GMO and contains C022_00.GIM - C022_04.GIM... I don't know whether all GIM's use 4char_##.GIM naming format, but I assume the contained GIMs all have proper names.

Any chance you could tweak the GMO import to remember those names instead of defaulting to diss_##? I've accidentally overwritten several textures because they output to one folder.


On a side note is there a way to access the GMO import function from another plugin? I noticed all the character models for Jeanne D'arc are inside some rather simple packages containing a few GMO's and sometimes an extra file of some sort... It hardly seems like a call for a completely new importer... but I don't know anything about the current GMO module, so I don't know if I can simply use a call to it and give it an address to look from, or of I'd have to copy the entire function and change what's necessary... Just something I was curious about.

rather simple packages containing a few GMO's

Why not just unpack it? Or are those GMO's all part of the same model?

They're effects that are related to that character. I suppose unpacking it would be probably a simpler way of doing it, but I'd then have to much better understand the archive format. As it stands, there is a pattern to the archive layout, in that GMO's for the character appear first, then an effect model,(if there is one) and occasionally a set of sound files or an extra image for portrait display or such...

It's a personal preference, for me, to be able to simply open up the archive to see its contained models, rather than having to export all... idunno...4,500 packages into their own folders and have to surf through to look at the models...

Or to put it more simply, the character models are just about the only real pertinent file contained in the package, as all other things (effects, portraits, etc) are redundantly stored...aside from maybe the sound files, which noesis doesn't deal with anyway.
I suppose another word for it is laziness. I'd rather be able to search through the entire folder and see what's what directly, instead of dumping everything first...I'm a stubborn old man of 24.

That brings up a question though, is it possible for Noesis to open an entire archive for viewing? It seems like it shouldn't be difficult (in theory; I fail every time I try to write a plugin). It would just be an extra step of adding the model format parser into the archive reader, right?

Yeah it is left over from that. I haven't seen a real reason to change it, cause the name is rather arbitrary. If I recall correctly I don't parse original names out of GIM's because the metadata chunk containing them has unreliable formatting and may not actually contain a name at all.

Do you mean reversed normals (which would only affect lighting) or reversed triangle windings? It the latter, simply disabling face culling (red half-sphere button) will fix the appearance in most cases.

The -texpre option exists so that you don't end up stomping over common texture names on export. That's why it's a default option in the batch exporter.

Jeanne d'Arc GMO's have self-contained models, textures, and animations, so I don't really see a need to have Noesis load anything else in conjunction. Those are the only 3 components it would care about anyway, and anything else can be loaded separately. I'd say you should just whip up a quick Python script to dump those packages. But no, GMO loading is not directly exposed through the API. Nor is NJCM loading, which is why I keep adding new Dreamcast formats to the core so I can cheat and call directly into my NJCM module for support functionality.

MrAdults, can you help me with -combinemeshes?

Darko wrote:Just for curiosity, what are you trying to do with sfxtk models in 3dsmax?? importing them with the skin modifier??

i'm collecting models, also studying on how artists make models

Tosyk wrote:MrAdults, can you help me with -combinemeshes?

Darko wrote:Just for curiosity, what are you trying to do with sfxtk models in 3dsmax?? importing them with the skin modifier??

i'm collecting models, also studying on how artists make models

Lol ok, it's just I'm using smd there right now with emo2smd by magnum, but it has some uv's problems.

My apologies, I said normals... I meant to say UV's. Reversed normals would be a much worse issue, as there's no way to export them inverted, but the issue I have is UV's...
can't believe I said normals...


That... doesn't give me the best idea what the actual model looks like. And I have to check UV Flip when I export anyway, so an option to flip it in the preview window would be helpful.

EDIT: I also noticed you fixed the issue with Zell and Kiros' weapons not showing up properly. That awesome.

Tosyk: It's like Darko said, the ActorX importer is importing the whole model as 1 surface. That is actually because of another crappy limitation of the PSK format, but if you actually find it desirable here, then... I guess that's good. Personally, I would just use FBX and combine the surface in Max.

Satoh: Oh, I see. Well then I guess you won't care about the "Culling flag" I just exposed in the data viewer in the new build I just uploaded!

Displaying flipped UV's would be a mild pain in the ass, because I use buffered rendering, and the majority of rendering is not done by shader except when necessary for displaying lighting with normal maps (for compatibility's sake), so there's no easy way to flip UV's in the preview without duplicating the UV buffer or incurring a performance hit. But I guess a small performance hit isn't a big deal for a non-default diagnostic option. It's still a pain in the ass to implement though.

Have you tried the "UV view" option in the data viewer under the mesh? At least with that, it should be immediately apparent if the model looks screwy because the UV's are flipped.

Edit: Just shoved a couple of UV flip options in there and put a new build up. It's so gross. But that rendering code died and went to hell a long time ago anyway. I'm tempted to start up a D3D rendering plugin and start migrating over to that exclusively just so that I never have to look at the old GL renderer again.

Hmm... UV View... as far as I can tell, just draws a red wireframe on the model... It looks exactly the same as highlighting a Mesh base entry...

As for the culling flag, I can't say I don't care, because I do have models that have odd normals, and it still saves me the time of exporting and reopening.... etc. (which takes more time than I care for, just to 'look')


On a different note, I had a thought about attempting to integrate Noesis into a Blender plugin module, which would save me a lot of struggle finding a format that Blender can reliably open...
(DAE is not well supported these days, and FBX is apparently not open for distribution or some legal crap like that)

But now I realize that wont work because the actual Noesis executable does some of the work, yes? It wouldn't be as simple as making Blender see the DLLs and Python scripts... Some of the important stuff is part of the EXE?
Shame I have so many ideas and so little talent XD

EDIT: Ahhh that UV flip option is brilliant. Much thanks for work you obviously didn't feel like doing.