More technical updates...

  • Thread starter Thread starter ficedula
  • Start date Start date
Status
Not open for further replies.
Leviathan is viewer-only. For now. I dont know what will be in future.
 
ficedula: Fine. That means I can concentrate on the .p files, and I just need to build in a little viewer for whole models...

 - Alhexx
 
Zangan only displays the *locations* - not the people in it. So all you could export would be a static set of geometry, for the scenery.

Nevertheless, http://www.dcs.warwick.ac.uk/~csuzs/oldsite/Zangan110.zip for the latest version ... only real change being the plugin support (all the info needed to write a plugin is including, if you still want to do it).
Click to expand...
In your description you have for
TPart = packed record
   TexCount, VertGroup, GroupCount:   Integer;
   Texs:      ^Integer;
   Verts:   ^TVertex;
   Groups:   ^TGroup;
   IndCounts: ^Integer;
end;
You have no description for TVertex. I assume this is TPoint3d in reality? :)
For people, you need Mirex's Leviathan (see General forum for an announcement today about that), or a program I'm working on - see http://www.dcs.warwick.ac.uk/~csuzs/oldsite/dio.png for a screenshot.
Click to expand...

Ahh cool.. I'll have to have a looksie then!

However, we don't understand the animation format. We (thanks to Phaeron, I should add) can position the model on its base frame, but not (AFAIK) decode any frames after the first.
Click to expand...
My guess is the animation uses the skeleton information for movement, just a guess I've been wrong before and it won't be the first time! ;)
 
You have no description for TVertex. I assume this is TPoint3d in reality?  
Click to expand...

Ack! No, it isn't, it's TInterleavedVertex ... serves me right for calling the same thing different names.
Each vertex in the list has multiple pieces of information; position, colour, texture coordinates ... so, TInterleavedVertex should be used.

My guess is the animation uses the skeleton information for movement, just a guess I've been wrong before and it won't be the first time!
Click to expand...

Well, the animation almost *has* to work by doing skeleton bone rotations; it's the only decent way to animate a skeleton, and it is how the HRC (field) models do *their* animations. The trick is finding out how they've encoded the frames...
 
Ack! No, it isn't, it's TInterleavedVertex ... serves me right for calling the same thing different names. Each vertex in the list has multiple pieces of information; position, colour, texture coordinates ... so, TInterleavedVertex should be used.
Click to expand...
Oh... hmmm I am just going to dump the textures after I enumerate them (sigh) by going through each Part and finding the highest and lowest Texture ID. Then reiterate and make copies of the textures convert them to Bitmaps and dump the bitmaps to files (wee).  After that comes the fun part of using the image maps that were just defined.
I do have one problem, this thing is expecting files from the PC FF7 which I don't have.  Are there equivalent files I can yank from the PSX version to use with Zangan?
It would be cool to be able to test the plugin I made (grin).

Well, the animation almost *has* to work by doing skeleton bone rotations; it's the only decent way to animate a skeleton, and it is how the HRC (field) models do *their* animations. The trick is finding out how they've encoded the frames...
Click to expand...

Well that goes without saying.. hehehe
I would hazard to say that from there prior use of structures it might be LZS compressed and they might have made the animation by store frame differences in the end points of each skeletal member. IE the meeting points being common locations between bones they have a list of all points (individually) and store a change per each bone per frame. Some positions won't change.  Since bone length won't change they might have included rotation information as well but not likely. It's simpler to store the differences and less space consuming.
So for the animation format they would have a link to a 'bone file' or data or have the bone information in it. Each frame likely indicates what 'joints' or ends are being moved with respect to the last frame as well.

Cybie
 
Well, for texture IDs you could just check the last 'combined' part, since that contains the whole location, and will therefore contain every texture needed for the location...

But, hmm, I don't know much at all about the PSX version, so I can't really help you with regards to getting Zangan working on it...
 
Code: [Select]
Code: 
//---------------------------------------------------------------------------typedef union{   struct { float X, Y, Z; } Point;   float Data[3];} Point3d;//---------------------------------------------------------------------------typedef struct{   float S, T;} TexCoord;//---------------------------------------------------------------------------typedef struct{   TexCoord    TexC;   int         RGBAColor;   Point3d     Vertex;} IntVertex;//---------------------------------------------------------------------------typedef struct{   int   Tex;   int   Min, Max;   int   RSV;   int  *Indices;} Group;//---------------------------------------------------------------------------typedef struct{   int         TexCnt, VertCnt, GroupCnt;   int        *Texs;   IntVertex  *Verts;   Group      *Groups;   int        *IndCnts;} Part;
Ok .. here are my 'structures' etc. for this.. somehow something doesn't make sense with the Groups.. is the Indice Count the same as the Group Count or is it the number of Indices in the group? And for the Indices in the group they are just an array of ints which indicate... what? Min Max those are? First and  Last Vertexs? Indices are a vertex list as well? These values point into the Verts?

As for what I'm doing (as if it were interesting ;) ) I'm moving groups into Meshs.. and then applying the textures however I suspect this is not correct because the Verts have a point to the Texture and a 2d Offset into that Texture where it seems to 'apply' to the object.. hmmm.

Cyb
 
Anyone have any data I can test with the plugin I finished?
I've got the uv_mapping (IE tex coordinates) done and the the texture dumping (amazing considering how clueless I was helps to read the documentation at least twice).

All I really need is some data to debug it with. (and later give a screen shot of the output).

One question did come to mind I take it that no normal information is available at the vertices of the triangle?  That would stink but I'll live if nothing like that exists. I suppose I could try and create normals to it but I would have to make a lot of assumptions.

I suppose I could send it to someone to try except for the fact that it's not debuged yet.
 
Eh, I'd send you a location from the game (I doubt Square'll care about us exchanging 15 files out of the 11,000 in battle.lgp) but my own computer has no net access at the moment. If noone else does, I can do so next week when I return to uni...

As for normals; P files *can* contain them but don't necessarily. HRC models do, I think always. Battle models don't. I'm not sure about the *locations* but I think they don't. Zangan doesn't read them, anyway, although I suppose they *could* be there - I doubt it, though.
 
Eh, I'd send you a location from the game (I doubt Square'll care about us exchanging 15 files out of the 11,000 in battle.lgp) but my own computer has no net access at the moment. If noone else does, I can do so next week when I return to uni...

As for normals; P files *can* contain them but don't necessarily. HRC models do, I think always. Battle models don't. I'm not sure about the *locations* but I think they don't. Zangan doesn't read them, anyway, although I suppose they *could* be there - I doubt it, though.
Click to expand...

Oh... hmmm good point backgrounds don't need normals.. normally ;)

It's not a big deal I wanted to see if it worked and fix bugs if there were any.
(yeah IF snicker).

Anyhow That's done I have to get some other things working I guess :)

Cyb
 
Status
Not open for further replies.
Back
Top