FF9 models: how to match the right anims and textures?

  • Thread starter Thread starter Chev
  • Start date Start date
Status
Not open for further replies.
I see... so in order to export at all, you still need a way to store the animations... or at least the first frame of one...

Couldn't you use the first frame of the standing animation for more models?
 
well, each model has its animations in its own order so choosing an appropriate pose can't be automated. But really, my interrogations revolve around which format to choose to keep the hassle to a minimum, not whether to include the anims or not.
 
well, each model has its animations in its own order so choosing an appropriate pose can't be automated. But really, my interrogations revolve around which format to choose to keep the hassle to a minimum, not whether to include the anims or not.
Click to expand...
Ok, well... if you're using DX9... 3D Ripper will work on it... so we could capture any frame from any animation...

Or, you could make a manual animation scrub-through option and use whatever frame is currently showing as the bone position, thus taking away the automation issue...


As for formats... if you can transcribe the vertex positions relative to the bone positions into absolute positions then OBJ would be fine. But you wouldn't, obviously, have animations themselves...
 
Collada (.DAE file) Might be a good choice. the FFX/FFX-2 model viewers use it to export model and animation data together.
 
I know collada is supported by maya and I believe it is with max as well... but I have no idea how flexible it is for programming...
 
The bind pose issue certainly is an interesting one though.  Makes sense when you explain it.

My problem with COLLADA is I've not been able to take any scene in max export as a DAE and reimport it and get back to effectively the same scene or vice-versa.  And usually its not even close.   I've tried 2 different max plugins and get different results when using one vs the other.   Skin and animation are frequently corrupted in my attempts to use it.  Then again this is true with a lot of formats.  Last time I looked at it there were not a lot of decent helper libraries.  The official one was C++ only.

I've tried transferring assets from Maya to Max with it and ultimately it didn't go that badly but lost a lot of detail like IK Chains and what not.  But it was the only thing I could use to make it work (FBX was also tried with similar results but its probably because its basically the same code base).

Anyway, this is just my limited experience.  Take a look at and see if you like it.  Its probably is one of the better open standards because it seems to supports everything and xml makes it easier to write tools for it.  I didn't like the support tools for it on the programming side when I tried it a few years ago.  Flexibility and support for a lot of different objects makes learning it more difficult as well but there is pretty good documentation for the file format on the official website.

Overall COLLADA is ok in my opinion.  Its basically XML so its really flexible.  In practice, it works well for me in cases where OBJ also works well.  Ultimately my complaints aren't with the format but with the modeling tools support around it and how most dont seem to fully support the format. 

I've been sort of planning to use collada or rather the FBX library from autodesk (which supports fbx, collada, obj, and 3ds for format conversion) for a new project this fall but not really in a position to recommend it.  Its Visual C++ only and binary libraries.  My hope would be using that would give better max/maya/blender/xsi support without having to completely write something from scratch.  Given its from Autodesk more people would likely be used to working around its quirks in the way it exports its files.
 
That's right! You could technically just export all the data as a random filetype of your own design or whatever, and use a blender python script as an (re)import tool.


it wouldn't *cough* be the first time I've seen it done...


Which is all moot if you don't know python...
 
Only problem with that is, people with anything other than Blender wouldn't be able to import it. i think there's something called "Maxscript" for 3dsmax, but it looks complicated O.o
 
Well, maxscript has the problem it only works in Max. If I turn to blender, since it's free anybody can install it if only to import the model through a custom script and then re-export it in their fave format, sicne Blender exports to a lot of format IIRC.

Collada's also a good idea since most programs can import it.
 
Blender, much as I loathe it, seems like the best option in terms of simplicity so far...
 
dunno. but since i very interesting   :-o with this post, i would try the experiment myselft. perhaps, i will post my project in this forums too. :roll:
 
Well, I'm still on it but there's a lotta work still to do. I've learned python and can make custom Blender exporters fine, but not yet importers, plus I'll also need to rework the interface of my program to something user friendly, still gonna take some time. I also have to add some stuff to my data chunk methods so I can start figuring out how the summons directory works, because it's still a complete mystery to me.
 
Well, it all depends on your affinities, they're totally different things. HTML is a markup language, ie a way to write documents with annotations, and Python is a programming language, ie a way to write computer programs. For me it was easy to learn python because I'm a programmer by trade and already knew quite a few other programming languages (most of them being what we call object-oriented, a specific approach to writing programs, and python is too, which makes them all quite similar) but for someone who isn't familiar with object-oriented programming it's gonna take a bit longer.

if you wanna have a go at it you can go there and download "a byte of python", a very good python tutorial aimed at both newbies and experienced programmers:
http://www.swaroopch.com/notes/Python

Also worth noting I'm only using python for importing/exporting from Blender, the actual FF9 viewer is written in C# and using XNA
 
So, the viewer is working, just not "user friendly"? Is it directX based?

3D's Via and Ripper DX can steal from DX9 applications....

Via can supposedly rip from Open GL as well...

And, while that isn't as preferable as a full file conversion with animations and all... It would be nice to just be able to get the models at all at this point...


Why not make a sort of WIP release... something so we can at least look at the models for now...
 
It's XNA-based (so yeah, DX9 behind it), grafted on another application of mine which isn't quite meant for distribution because it had a lot of things useful for a model viewer, with a custom WIP GUI system, has to be recompiled when you want to change the active model directory and will crash on any machine but mine because the FF9 resource file location is hardcoded. That's what I call user-unfriendly. It's all small details stemming from the fact it was originally a hack job.

Not really hard to fix apart from the fact it needs a decent UI (a lot of the necessary functions are there already, implemented for other parts of the program), but those fixes take time, and I got in somewhat of a slump while searching for the missing textures and turned my attention to other subjects for a bit.
 
Last edited:
ok, I see what you're saying. Rather than actual "user-friendly" stuff like pretty GUI buttons telling you what you can do, you meant it doesn't have the flexibility to run without the exact setup you are running it from.

That would be a real issue. Well... I can see that it won't be done in the next few seconds (or probably days, likely weeks, considering the whole unfunded programmers having personal lives thing)...

Regardless of how long it takes, I am eager to get an up close look at the models.


I'll be waiting with high hopes for progression speed, but low expectations thereof.


(In truth I generally just slap a bunch of random-ass buttons on things that each do another process that I've already built... but I don't know if XNA is quite as forgiving as standard C#...)


In any case good luck with whatever you're currently working on.
 
XNA is standard C#. I reiterate, all that stuff is a consequence of the way I did things, not the way XNA makes you do things.
 
XNA is standard C#. I reiterate, all that stuff is a consequence of the way I did things, not the way XNA makes you do things.
Click to expand...

XNA is C#, yes, but as I haven't messed with it before, I am unsure of the special methods and revisions that exist that make it separate from normal C#.

I'm assuming XNA uses an SDK of some sort and isn't built directly into C#. After all, it wouldn't need a name like XNA if it were a standard part of existing C#.


Invariably when using an SDK of some kind, there are changes in the way certain tasks need to be handled, some are more drastic than others. I was simply stating that I don't know enough about XNA to know how drastic the changes in handling of basic windows forms is.


Quoth the Satoh: Nothing more.


Again, good luck on whatever your current project is.
 
Yeah but I mean, it's like saying using DirectX necessitates some changes. Sure, it does, but they're unrelated to ease of use of the final application. Here the only practical difference is people need to get the XNA runtime to run XNA apps, just like they need the directX runtime to run DirectX apps. Every problem here stems from the fact I've been experimenting more than turning the experiment into a final product.
 
Last edited:
Status
Not open for further replies.
Back
Top