Author Topic: Decent FF7 Model Viewer (Read 105770 times)

Kislinskiy · « **Reply #100 on:** 2004-07-07 12:07:10 »

Texture transparencies? Can't remember well but try this:
1) Black is transparent
2) First palette entry is transparent

Cyberman · « **Reply #101 on:** 2004-07-07 18:27:21 »

Well actually a bit further Kislinskiy
[list=1]

if bit 15 is of the color is Set (see the Palette) the value is transparent
color zero (4 or 8 bit textures) is transparent

Lord_Skylark · « **Reply #102 on:** 2004-07-08 03:00:47 »

I don't know if it's the textures that are transparent...I think it's the entire pologon...

Here's an example with Brain Pod
actual shot taken ingame: www.ffcompendium.com/~Skylark/BrainPod.jpg
with model viewer: www.ffcompendium.com/~Skylark/Brain.jpg

Then one other problem I ran into with the viewer was with Death Dealer....when viewing one of his cards from the bottom the texture doesn't load and you can see completly through it....but if you view it from the top you can see the back of the card.

www.ffcompendium.com/~Skylark/DeathCard.bmp (sorry for the bmp)

mirex · « **Reply #103 on:** 2004-07-08 09:07:31 »

Quote

Haven't posted here for a little while....did anyone make any more attempt on trying to figure out how the transparencies work with enemy models?

Not me. I was not working on ff7 for a long time ... right now ripping apart HalfLife models

Cyberman · « **Reply #104 on:** 2004-07-08 15:38:47 »

Quote from: Lord_Skylark

I don't know if it's the textures that are transparent...I think it's the entire pologon...

Here's an example with Brain Pod
actual shot taken ingame: www.ffcompendium.com/~Skylark/BrainPod.jpg
with model viewer: www.ffcompendium.com/~Skylark/Brain.jpg

Then one other problem I ran into with the viewer was with Death Dealer....when viewing one of his cards from the bottom the texture doesn't load and you can see completly through it....but if you view it from the top you can see the back of the card.

www.ffcompendium.com/~Skylark/DeathCard.bmp (sorry for the bmp)

I'm not sure what you are getting at. The texture determines what part of the polygon is transparent if at all. Each model consists of a number of objects. Each texture has a palette, the palette (most often several 4 bit ones), is then used to create the texture in the texture cache follow the rules I outlined. If the whole polygon was transparent you couldn't see clouds eyes, instead you would just see the polygons behind the eyes and no eyes. The textured polygons are rendered on the final frame pass.

At least in PS1 FF7 that's the way things are done!

Cyb

Lord_Skylark · « **Reply #105 on:** 2004-07-08 18:40:16 »

I'm must saying...Leviathan currently doesn't support the transparencies.....if you know how this is done - tell mirex so he can add it to the viewer when he gets time...

Is there any way you can fix the little card error with the Death Dealer so I can view what that card actually is? :P

Thanks.

Terence Fergusson · « **Reply #106 on:** 2004-07-08 19:14:19 »

Judging by what's there and what's missing from the Death Dealer's attacks, I'd guess it's The Sun that's missing. (Sun: Magical Change Status, inflicts Silence/Darkness with Class [63] chance)

The other four cards are all there.

mirex · « **Reply #107 on:** 2004-07-09 05:52:42 »

Cyberman: I think that Lord_Skylark has in mind the polygons that are half-transparent. Im not sure if they are on PSX though. For example brain pod has transparent little round window on its side, through which you can see the brain inside the jug.

Quote

Is there any way you can fix the little card error with the Death Dealer so I can view what that card actually is?

Im not sure, but IIRC there is none ... i remember only 7 cards on the texture.

halkun · « **Reply #108 on:** 2004-07-09 11:14:50 »

On semi transparent (Opaque) polys

You know, have you guys maybe thought that one of the vertexs have the mask bit (bit 15) set and it's interpolating the transparency on the polygon itself?

mirex · « **Reply #109 on:** 2004-07-09 11:56:02 »

honestly nope ... but i thought that transparency info could be somewhere in the groups ... because one of Cloud's swords gets more and less transparent, i think it depends on his health or something

Messiah99 · « **Reply #110 on:** 2004-07-09 12:00:38 »

Quote from: mirex

honestly nope ... but i thought that transparency info could be somewhere in the groups ... because one of Cloud's swords gets more and less transparent, i think it depends on his health or something

If youre referring to his ultimate weapon, yea, its shade changes depending on his health...

Darkdevil · « **Reply #111 on:** 2004-07-09 12:49:54 »

Quote from: Messiah99

Quote from: mirex
honestly nope ... but i thought that transparency info could be somewhere in the groups ... because one of Cloud's swords gets more and less transparent, i think it depends on his health or something

If youre referring to his ultimate weapon, yea, its shade changes depending on his health...

And his "Organics" Weapon does that I THINK...Not sure though

Cyberman · « **Reply #112 on:** 2004-07-09 15:58:02 »

Quote from: mirex

honestly nope ... but i thought that transparency info could be somewhere in the groups ... because one of Cloud's swords gets more and less transparent, i think it depends on his health or something

Well its definately not in the textures because there are no textures for weapons. Unless they handle that as an exception to the rule (IE unique operation).
I've almost got textures working on the models.
That and the animation information will make things visiable.

Cyb

Cyberman · « **Reply #113 on:** 2004-08-05 15:33:47 »

Well things have been quiet for a while.

State of things are thus:
We know the (mumble) bone format and length information
It's now pretty fast to decode that information on the PC.

The remaining objective is the animation information.

Unforunately for the PC and PSX this is poorly understood.

This weekend it should meet it's match.. or maker or both

Cyb

halkun · « **Reply #114 on:** 2004-08-05 22:52:24 »

Naru *SHOULD* be up by then, I'm still using a temporary root drive (Read: binaray duct tape) to keep the system from atrophy.

I can catch the information and can toss it into gears.

If anyoe is going to do a write up, for ease of editing, you mind following the header/subheader/trinary header format that's in my latestest version of Gears. That would be great if I can keep it uniform.

Also does any one mind if I convert the European english to American english and clean up the grammer with some of the files? My spell shecker just has a horrable time with some f the stuff you guys write.

Darkdevil · « **Reply #115 on:** 2004-08-06 09:08:05 »

I have no problem with loosing the U out of colour

. As long as its in english (Any form of) Ill read it ^_^

halkun · « **Reply #116 on:** 2004-08-06 12:34:59 »

It's also losing the "z" in realized, and dropping a few extra "u"s, "e"s, and a little clean up in scemantics

Cyberman · « **Reply #117 on:** 2004-08-06 14:58:37 »

Quote from: halkun

It's also losing the "z" in realized, and dropping a few extra "u"s, "e"s, and a little clean up in scemantics

It would be interesting to see if Euro english is more like LEET speak than actually from British origins. Of course the British say Maths (which is very confusing because it could be a plural of Math or it could refer to Mathematics that's why in american English if you say that you get strangled it leavesto much in contention and believe it or not.. it's actually irritating to hear for some people).

Back on subject I actually made some progress, at least with the PC format and also discerning more animation information.

EX using cloud as an example the PC version RTDA file has 94 animations. Oddly examining clouds model there are 94 sections between section 0 (battle model and skeleton information) and the models texture. So that leads me to believe that all sections between 0 and the Texture are the animations. Another thing I believe that the animations may infact only store rotation data, and no translation data per sea. Why? Well I think the FF7 engine itself handles the translation. There are only a few places where anyone leaps into the air etc. This is important because those happen to be the special attacks. The animation for the special attacks like these are likely somewhere else. OR The other possibility is that there is a flag indicating if it's just rotation information or not (you would only need rotation for the static poses Victory Being hit Dead and Standing for example).

Just a thought.

Cyb

mirex · « **Reply #118 on:** 2004-08-07 17:07:20 »

i think that:
All bones are rotated in each frame, any character pose can be done by rotation. There are needed only 2 positions, player's current position (that should be somehow modified by engine, because it depends on enemy's position) and weapon's position for thrown weapons.

Cyberman · « **Reply #119 on:** 2004-08-12 03:47:19 »

Quote from: mirex

i think that:
All bones are rotated in each frame, any character pose can be done by rotation. There are needed only 2 positions, player's current position (that should be somehow modified by engine, because it depends on enemy's position) and weapon's position for thrown weapons.

Hmmm
There are positions in SCENE.BIN in the BATTLE directory right? For each character I mean.

I think you are right, the system likely translates then generates the information. Thrown weapons are just Yuffie right?

Progress:
Yes I'm making progress, it's slow because I have to deal with C++ classes and there way of handling things. Nothing is as simple as making a COPY of data is it? (geesh)

However Maybe in a week I'll be able to put images up with the new object system. Then maybe the battle scenes and textures will be visable as well.

So my current order of priorities on updates are:
[list=1]

Finish recoding and generating a functional model from FF7's battle models.
Make FF7's battle models viewable with the new system.
Read and decode Battle Scenes into new system.

(note this automatically makes then viewable the way the new viewer is set up)

Initial release distribution made (IE other people can play with it).
BCX files.
BSX files.
Finish deciphering Animation format.
Add export dialog and built export to POV ray include file and texture.
Add plugin support to allow new file type exports.
Scene Script Viewer/Decompilor with dialog.
XML data base of known variables added
Background viewing for FF7
FF8 Model support
FF8 Background viewing.
FF9 Model support
FF9 Background viewing.

halkun · « **Reply #120 on:** 2004-08-12 04:31:57 »

Can you put in the list "find the #%#* field walkmesh and camera locations". I'm about ready to put a bounty on that data for a really nice prize *COUGH* US PSOne *COUGH*

Cyberman · « **Reply #121 on:** 2004-08-12 06:06:58 »

Quote from: halkun

Can you put in the list "find the #%#* field walkmesh and camera locations". I'm about ready to put a bounty on that data for a really nice prize *COUGH* US PSOne *COUGH*

Well I think the walk mesh is possibly in 2 places most likely only in 1 really.

The BSX files we know contain the NPC field models. I think that's all it contains.
The MIM files are the background images, and that's it.
That leeaves the DAT files which also contain the script. I think it would make sense to have the walk meshes there really and likely the camera locations as well. As you only need one angle per scene this shouldn't require a whole lot of data storage.

A PSOne.. I have one of older units you can hook all sorts of things too

I use to play FF7 for HOURS on that thing!

Cyb/Stephen

sfx1999 · « **Reply #122 on:** 2004-08-13 17:28:19 »

The animation method would most likely be whatever is fastest on a PS1.

Anyway, I saw a project a while back that used OGRE (a free 3d engine) to render Tomb Raider cutscenes and levels. You might want to check it out.

It's here: http://www.evpopov.com/

Cyberman · « **Reply #123 on:** 2004-08-13 21:47:40 »

sfx1999:
I'm not sure what you are getting at with what's fastest on the PS1.. most of square FF7 engine is a combination of ideas.
[list=1]

Compactness of data
Mixed 3d data with CGI animation.
Simultaneous operation of several things at once.
Ease of switching between different views and programs handling those views.

mirex · « **Reply #124 on:** 2004-09-01 15:05:41 »

Hey hey. Thanks to Cyberman and his description and also thanks to Kislinskiy i've added reader of LZS's into Biturn ... yet not complete, it cannot read animations and textured polygons coords properly.
Also I cannot read some polygons of HICLOUD.lzs model; but i'll work on that.
Here are some progress pics from cloud.lzs:

here is report what have i read:

Code: [Select]


 reading 23 bones
 reading objects
    start offset: 0000028C
  reading 26 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 48 triangles
  reading 0 quads
    ending offset: 00000730
    start offset: 00000730
  reading 76 vertices
  reading 0 groups, flag 0020
  skipping 0 lines
  reading 108 triangles
  reading 20 quads
    ending offset: 000013F4
    start offset: 000013F4
  reading 131 vertices
  reading 11 groups, flag 0025
   #00: 10 2E8 78 80 600 7840 2036 39
   #01: 198 10 08 80 2036 7840 600 3A
   #02: 2F0 2E8 10 80 380C 7840 2036 600
   #03: 2E8 2F0 308 80 2036 7840 380C 3932
   #04: 10 198 318 80 600 7840 2036 380D
   #05: 300 368 320 80 AB 7800 37B5 1583
   #06: 10 2F8 2F0 80 600 7840 3400 380C
   #07: 300 310 368 80 AB 7800 BF 37B5
   #08: 2F8 10 318 80 3400 7840 600 380D
   #09: 368 310 3E0 80 37B5 7800 BF 15E6
   #10: 318 198 48 80 380D 7840 2036 3932
  skipping 0 lines
  reading 248 triangles
  reading 5 quads
    ending offset: 00002CA8
    start offset: 00002CA8
  reading 25 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 40 triangles
  reading 3 quads
    ending offset: 000030EC
    start offset: 000030EC
  reading 19 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 8 triangles
  reading 11 quads
    ending offset: 00003340
    start offset: 00003340
  reading 32 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 40 triangles
  reading 10 quads
    ending offset: 00003864
    start offset: 00003864
  reading 24 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 38 triangles
  reading 3 quads
    ending offset: 00003C78
    start offset: 00003C78
  reading 11 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 10 triangles
  reading 4 quads
    ending offset: 00003E0C
    start offset: 00003E0C
  reading 32 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 40 triangles
  reading 10 quads
    ending offset: 00004330
    start offset: 00004330
  reading 14 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 24 triangles
  reading 0 quads
    ending offset: 00004594
    start offset: 00004594
  reading 35 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 50 triangles
  reading 5 quads
    ending offset: 00004B20
    start offset: 00004B20
  reading 17 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 25 triangles
  reading 1 quads
    ending offset: 00004DC8
    start offset: 00004DC8
  reading 11 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 13 triangles
  reading 1 quads
    ending offset: 00004F50
    start offset: 00004F50
  reading 14 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 24 triangles
  reading 0 quads
    ending offset: 000051B4
    start offset: 000051B4
  reading 35 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 50 triangles
  reading 5 quads
    ending offset: 00005740
    start offset: 00005740
  reading 17 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 25 triangles
  reading 1 quads
    ending offset: 000059E8
    start offset: 000059E8
  reading 11 vertices
  reading 0 groups, flag 0025
  skipping 0 lines
  reading 13 triangles
  reading 1 quads
    ending offset: 00005B70

specially to the 'groups' part

Code: [Select]

   #00: 10 2E8 78 80 600 7840 2036 39
   #01: 198 10 08 80 2036 7840 600 3A
   #02: 2F0 2E8 10 80 380C 7840 2036 600
   #03: 2E8 2F0 308 80 2036 7840 380C 3932
   #04: 10 198 318 80 600 7840 2036 380D
   #05: 300 368 320 80 AB 7800 37B5 1583
   #06: 10 2F8 2F0 80 600 7840 3400 380C
   #07: 300 310 368 80 AB 7800 BF 37B5
   #08: 2F8 10 318 80 3400 7840 600 380D
   #09: 368 310 3E0 80 37B5 7800 BF 15E6
   #10: 318 198 48 80 380D 7840 2036 3932

first 3 numbers are vertice references (not indexes but offsets, as in polygons) and the rest should be tex coords. i'd say that repeating value '80' and '7840' are just fillers so only rest 3 nums are texture coords (which is enough, 2 bytes for each vertex)