Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Halfer

Pages: 1 2 3 4 [5] 6
101
Yeah, that would probably make sense. In the water sections where there is only water blocks the "shadow" part is only 0x01 long which is 8 bytes right after vertex data. That is probably why I had trouble looking at that data because the sea doesn't really need shadowing. However it looks like in continents and other areas where "ground" is present the "shadow" data matches the amount of vertices which may indeed be for shadowing. I'll edit this to structures.

So towns are in wmx.obj? That's interesting. I wonder where the sections are set to match the exact position in world. I looked in FF7 wiki for the world info and in FF7 files it seemed to be separate file which handled the positioning of loaded sections. I'm starting to feel that they are coded in .exe, hopefully not.

EDIT: Also worth to mention that the vertices can be positioned outside it's block and section but the collision settings don't follow the boundaries, but are stitched to its block or section boundaries. In other words the section which is subject to world has priority on its own area. Here's an example:



Here the vertices are stretched on top of other section and while I can walk on the current area, I can't go over the area which is on top of water.

I'm not 100% if this is how it really works or if there are exceptions, but right now this seems logical.

102
As mentioned in the first post, each section is size of 0x9000h with padding and it represents small are on map (see first post).

Sections start with offsets of blocks which are formed inside section. On each offset the block starts with 4 bytes long header.

Code: [Select]
struct
{

        u32 unknown (sections always starts with 4 bytes which affect nothing)
        u32 block_offset[amount of blocks]; // (first offset value/4-1) = amount of blocks
        header headerData ;
        face faceData[amount of faces];
        vertex verticeData[amount of vertices];
        shadows data[size differs]; // possible shadowing, on continents this sometimes match the amount of vertices.
        padding; // to next 0x9000h offset

} Section
       

Code: [Select]
struct
{
        u8 face_count; (mostly triangles or quads)
        u8 vertex_count;
        u8 shadow_count;  // shaders or something related to make shadows
        u8 unknown, never used??

}header, size = 4 bytes

Code: [Select]
struct
{

        u8 vertexIndices[6];
        u8 tex_coordX for v 0;
        u8 tex_coordY for v 0;
        u8 tex_coordX for v 1;
        u8 tex_coordY for v 1;
        u8 tex_coordX for v 2;
        u8 tex_coordY for v 2;
        u8 face type related [3]    // (texture page, type, etc...)
        s8 collision; //needs a bit research

} Face
size = 16 bytes

Code: [Select]
struct
{

        s16 coordinates[3]; // in form of XZY or YZX
        s16 unknown, unused (optional W dimension probably)

} Vertex

Code: [Select]
struct
{

        s16 or u16 unknown data [3]  // shadow possibly on XYZ (XZY) coordinate.
        u16 always zeros ??

} Shadows, under inspection still.

EDIT: texture related values may not be correct since they are not yet inspected properly.

103
Okay, I had spare time to look on the files again and I found an interesting thing in the geometry forming.

In the files it seems that some parts of geometries are duplicated over itself meaning that there is 2 layers overlapping with each other. This led me to remember that in some thread there was discussion about this in some form, but I don't seem to recall/find it anymore. If somebody remembers which thread it was, I would appreciate to know too. I'm pretty sure it was here on Qhimm at least.

EDIT: Good news, I now know how the geometry is read from the file and I'll write an update tomorrow regarding on it.

104
Title updated to not only deal with world map but the whole world container.

105
This is SHA1 for wmset.obj old PC release: 31516E8E2452FF65EF6009BB86AB0D7CC58D0E22 according to this site http://onlinemd5.com/

Seems to be same as steam release. I think the files are untouched, only executable is modified in steam release.

106
Glad to see you again Maki :D and great work!

I feel pretty bad for not being able to contribute frequently (lately at all) on cracking the files. I have so much work in school and right now I'm in middle of moving places and well the change of PC has knocked me a little back, but once I get the files and FF8 installed again and settle down in my new apartment, I'm good to get back in FF8 :D

107
That's cool! :D In addition to what you said in the end of video, it does play in game if you fail to set the error ratio in missile base, happened to me the first time i played :P

108
General Discussion / Re: [WIP] Squall CGI model
« on: 2015-04-04 11:37:55 »
Yeah, I noticed the feedback and I'm on it later but there is still some things I need to handle first before touching the jacket and fur (made with particle system) so it doesn't mess up with physics later on. Also worth to point out now is that the hair looks so "woody" now because there is only a texture applied but later on i'm doing bump maps so the texture has some depth on it. Same goes for other textures as well. Right now i'm struggling with belts, after that I need to finish boots. I'll do gloves last in case of modifying hands and fingers.

109
General Discussion / [WIP] Squall CGI model
« on: 2015-04-03 13:35:21 »
Hello!

First I want to state that I'm not a graphic artist in any way and I like to do 3d stuff in my free time as a hobby mind. I use Blender with cycles rendering engine to make this right now.

I've been working on this model for a long time, I've got the head model for pretty good state and base models for clothes made in the same time. The reason why it has taken so much time to just make these is that since I'm a beginner I did a lot of mistakes in topologies and such and I had to correct the errors in the same time as i pushed going for next parts. Briefly, I rushed in to work before planning properly (something you don't want to do in 3d modelling, learned it through hard way :D).

So some may ask why I even started doing work of this caliber since I'm a beginner. Well I'm really fascinated of Squall's character (and overally all the FF8 characters and sets) and I wanted to see more CGI stuff like FMV's in FF8. However it has only turned out that the visually stunning models used in FF8 FMV's aren't really used in any other Square games as they were in the game. Yes, there is Dissidia but I don't really like the way they turned Squall visually. So that is why I started to work on this replica model. Also, while right now the purpose is to make Squall's CGI replica, I don't plan to just leave it as that but to hopefully use it for making animations with FF8 setting.

So here are some images of the model I've created so far:













So as you can see there's still a LOT to do and I hope that you can give feedback of this and the most important, point out the errors that I have done and if you have experience maybe help me out with the methods that I should know when making this "huge" project.

I try to keep up with the textures to make a better showcases but right now textures are placeholders.

If you guys want, I can start "blogging" on this thread but only if you guys want to see the progression of this project. I've also thought of asking a helping hands with this project but I don't want to make it a really serious task. So if you have any interest to help in a HOBBY mind, feel free to tell me what is that you want to do for cutting the creating time.

110
I may be completely wrong but why don't you give a shot to mag999_a.dat file. Its size and name could mean that it includes something special, maybe all the ground models for GF animations?

111
FF8 Tools / Re: [FF8] Battle Stage to OBJ converter [1.1]
« on: 2015-03-26 06:52:32 »
Thanks for feedback LeonhartGR. Yes, this is in a pretty early development mostly concentrated on head till now. I do have a model with "real" hair but I prefer the polygon one since it's intended to be a replica. Also the textures are just placeholders.

112
FF8 Tools / Re: [FF8] Battle Stage to OBJ converter [1.1]
« on: 2015-03-25 21:32:25 »
Awesome! :D

Here's a little preview with a0stg101.x (with poor color correction):


Also a bonus pic with my bland Squall model :P

113
FF8 Tools / Re: [FF8] Battle Stage to OBJ converter [0.95]
« on: 2015-03-24 08:21:01 »
I see. I kinda already knew this before posting but had to make sure that I was not missing anything. I used Ps Tim viewer before for researching textures for World map and that program had clut options available for color correction.

P.s. I haven't abondoned World map researching, i'm just very busy with my school currently but on the side note i'm learning java in there which helps me make tools later on :)

114
FF8 Tools / Re: [FF8] Battle Stage to OBJ converter [0.95]
« on: 2015-03-23 21:11:34 »
Yeah my bad, didn't look in to .mtl and realize that the texture needs to be individually exported :D

By the way, I don't know if you have solved this but for example in a0stg101.x the texture (png exported with deling) is blue (clutted?) and thus making the grass appear as blue like the sky. But don't let it hold you back, this is easy to fix manually with material editing.

115
FF8 Tools / Re: [FF8] Battle Stage to OBJ converter [0.95]
« on: 2015-03-23 19:24:45 »
Fantastic job!!! I'm very glad that you got the stage model ripper done.

However, I do have a problem with importing textures to blender. I can't get the textures working on blender. I don't know if i'm doing something wrong or if the .mtl is not working properly?

116
Here is the documentation for world map vehicles http://forums.qhimm.com/index.php?topic=13799.msg193791#msg193791

I'm not sure if there's every model but let me know if/when you export them how they look :). I'm pretty busy this week so I will get back on FF8 on next week, maybe this weekend.

That FF8 movie project looks very nice, looking forward to it!

117
That is very cool! Are you planning on making an application for tools release once the whole file is cracked? Also this should be documented to qhimm wiki page also.

118


First off, huge thanks to MakiPL for inspiring me and hopefully others with his research on ff8 battle fields. Since he's making a very good and much faster progress than i managed to make I decided to hop on to world map data. This concerns wmx.obj for now since I haven't looked on to the other files yet.

Remember that this info may be inaccurate in some parts since it is a huge file (33MB) and it is a pain in the neck to scroll through. However I'll talk about how to handle this file quicker at the end.

Insight:

For now (not sure), the world map seems to consist of 768 sections. Each section contains 16 blocks and each block can have different amount of triangles. Luckily, the sea mesh seems to have 32 triangles  (formation told later) so we can do tests on that more easily. Here are pictures with 1 section/16 blocks and 1 block with 32 triangles:



Header:

Header consists of 68 bytes. Each section contains the same header structure.
  • First 4 bytes are still unknown since changing these don't seem to do anything.
  • Rest 64 bytes indicates the offset of blocks after the header


Data:

Possible render/collision options:
This is very complicated.
After the header, the first 4 bytes seems to remove the whole corresponding block when set to "00 00 00 00", also it creates a collision over it so it can't be fled over. Setting it something else messes with uv's as well as geometry and may cause the game to crash or freeze. Setting it to "30 30 30 30" also affects the next block for some reason. The collision is also changed and in this particular example you can go under the world (something like in ff7 :D).



Triangle data:

The data for 1 triangle is 16 bytes long starting after possible render/collision options.

The next 4 bytes are for triangle vertices. zeroing these gives the following results for one triangle:


Here are the marked triangle vertices:                                                                        And here's how they are formed:





Unknown still:

The next 8 bytes are still unknown, feel free to look at it!
Also the data between in-game blocks in a section is still unknown.

Ground type?

The last 4 bytes for one triangle data seems to contain UV data reference for the corresponding triangle. This is also how I made the example photos for this thread. Changing the value for this changes the triangles type. The marked bytes, when set to "88 88 88 88" gives the ground the type as in in-game example photos:

Also landing on this ground is possible, but as I tested I found out that you can reference to any type of ground with this and I managed to get probably a cliff type where I were unable to land with ragnarok.

Padding:

Following the data for one section comes a bunch of zeros. This is called padding. The data and padding are 36864 or 0x9000 bytes for every section.

How to manage the file:

Since this file is huge I found out a little solution for managing it. One reason for the size of this file is padding. The header, data and padding seems to be fixed amount of 36864 bytes or 0x9000 bytes for easier reading in hex editor. This helps a lot since each section is therefore 0x9000 bytes long (including padding) and for next section you just add 0x9000 bytes more from the beginning of previous section to get for next section.

How to know which section you are editing in game:

This is still TODO. However I think there is 768 sections, but i'm not sure if one section can be larger or smaller than I showcased. For what I know, the first section in the file is top left corner section in-game and the next sections goes horizontally to the top right corner of the in-game map. This way of thinking isn't true in the vertical way however:

If there was 768 sections in the world map and the aspect ratio would be 4:3 like the world map picture, it would mean that the sections would be 32x24. Here's a picture of first block from 12th section of file which possible render/collision options are nullified:


You can see that it is pretty accurately in place.
If we want 12th section vertically it would be (12x32=) 384th section in file, however it isn't correct so the 768 section hypothesis isn't correct.

Although it isn't correct we can use the first horizontal line and maybe the second one for testing purposes with this hypothesis.

Lastly:

I hope this helps someone with their research on this and someone manages to do something huge with this!

Also the very last section includes the model for great salt lake, its train station and little part of the bridge. Just remember if you replace the first section or any other section with this that there is 36864 or 0x9000 bytes in the section including padding.

119
Do 0.3f and 0.3333f differ from each other? Not familiar with the f letter after number

120
IT seems like you are missing 0.3333 from every U value. Can you just take that in note and reduce it with script?

EDIT: now that I read my sentence again I realized how messed up it is :D but you'll get the point if it is that easy to solve.

121
Wow! very nice progress, looking forward to your works! :D

122
This is from the japanese version, the dialogues are similar to beta:





The green car is hidden in several fields of the old winhill. We can see it with a little edit:



Also, there is a field with the green car itself (this shot is taken from spanish version):


At last, I never seen this art before (or I donĀ“t remember to see it.)



PD: In PC  there is a quality version of the background's field "ggroom1".

Normal:


HQ (the field name is "ggroom5":




The disc changing screen looks a lot like fanart but can't be too sure. Seems like "ggroom5" is from japanese version too, that's very cool.

I hope that SE has those renders or even the whole scenes somewhere in their archives for possible future use ;)

123
Thanks anyway! Too bad that I don't have the steam version so can't find that line :/

124
I see, anyway they seem to be "unmodified" particles meaning that every quad is similiar thus the effect seen in first image. The reason why there is still sea left in my screens means that vertice group is modified by landscape and has a different variables in place of 20 19 01 00. That may be a count or reference to something.

125
Okay, I liked to jump a bit for wmx.obj and what i found out is that this file is containing the sea quads of the world:

There seems to be a header starting with 20 19 01 00 , and nullifying every corresponding variables it gave the following results.



Here you can see how to sea is formed from big quads.
EDIT: Also worth to mention that I wasn't able to pass those empty blocks with ragnarok meaning that there is some sort of collision when land (or sea) is removed

That's interesting yagami light. I reversed a big chunk of bytes from that offset and it did very odd stuff following hard lock. Although the ff8.exe seemed to eat my CPU while it was freezed so I don't know what I did wrong :D

Also I would appreciate if MakiPL could say how you managed to hack that camera like that! Would really help a lot! :D

Pages: 1 2 3 4 [5] 6