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
76
Well you can view them later with textures once I get this fixed :P they are found under the world map.

Can't wait to see the tool complete to place every "alternative" mesh to the right place just to see what changes from one to the other  :P

Haven't really given a thought about this yet but I can see it happening with future updates ;)

77
Seems like this will take at least a day still, it is mostly working correctly like this:


I still do have some problems with galbadia area and some textures for some reason. Have to think about them tomorrow


78
Yeah, I'm aware of the positions, thanks to timviewer, but I'm pretty sure that it is possible to do it automatically, though with some work. Well I'll have to look on that later on.

Yeah I'd like to test the processed textures if you could send them somehow to me. I'll release the program probably today after making sure that I haven't made any UV calculation errors so the corrected textures would be nice :).

79
I've done some progress with my texture exporting using Blue's program as a base:



Texture coordinates should be correct right now.
I still need to figure out the process of changing texture page and CLUT info on the fly while exporting. It may or may not take a while, but after that I'll release an updated exporter ;).

EDIT: Some eye candy without CLUT info:




The program now automatically switches texture pages, however water textures don't still work because they are presented a bit differently due to their animation data, but i'm gonna add it too (without animation of course). aaand they are done.

And of course the next thing is to take CLUT info into account. I'm still not entirely sure how to make this happen :(. The image should be somehow exported as 128x128 whereas every tile has own  CLUT already corrected.

80
Awesome job!




I'll start improving the program by adding a support for texture exporting with the geometry. After that I'll make an importer. In theory the importer could work without texture support but it would be pretty pointless since you would only be able to modify current vertex and face positions.

81
FF8 Tools / Re: [FF8] Battle Stage to OBJ converter [1.1]
« on: 2015-07-04 08:30:20 »
Umm no? It exports battle stages to wavefront files which is also stated in title. I'm not sure if there's is a good FF8 character converter but if there isn't then it's probably coming in the future.

82
Great job! :D

That blue sky car is probably the model for the thing that is blocking access to towns in disc 4 :P

83
http://pastebin.com/GZVNkcL5

Here you go, one block, remember that there are 16 blocks in one section. I guess this was what you meant? The texture section (last 4 bytes of each triangle) has been changed to "88 88 88 88", makes it look like in the very first post and is landable and walkable. Hopefully you can insert the values as in text. At least HxD editor can do this.

Yeah the crash was pretty odd. It seemed like the memory couldn't keep up with the data or something like that.

84
Great! :D Happy to be helpful here!

Looking forward to your tools, seems like you have put much effort for these tools! Keep it up :D.

I think that exporter could be a good thing but leaving it as an exporter/importer wouldn't make much sense. The problem would be the way FF8 engine handles the file, like Aali said earlier. It needs a bit more studying how to implement more complex geometries to FF8 without crashing the game/slowing it down significantly. Speaking of geometries, textures are the underlying problem right now. Maybe for starters the exporter/importer could work as a tester for engine capabilities. Maybe in the future the program could be a proper editor with 3d view.

By the way, MaKiPL, have you encountered to crash on world map with camera zoom (under 300) when flying ragnarok on top of esthar and flying back to bridge? For me it seems to mess up the textures from the bridge and after that crashes.

85
Yeah it does, that's why I'm guessing that this problem occurs on my PC. I posted pictures couple posts back where you can see what happens when i run the game in direct3d. Actually now that I remember it does this only when I set it on windowed mode. Haven't tried it in full screen.

86
Tried it before, no changes :( . That's interesting, I wonder if it was accidentally left out in the old release.

87
Actually these are the low-res textures. The higher resolution textures are stored in texl.obj and as far as I have been informed they are used when not in ragnarok (or any other vehicle?). I'm using Aali's drivers to run the game in direct3d mode, but for some reason my game isn't using these higher resolution textures like it doesn't if running with software rendering on.

Oh and here's a picture with all the texture pages showcased on the 2 top rows:

88
UPDATE!

wmsetusXX.obj contains world map textures. The object textures used for grounds are size of 128x128 pixels. Here's an example:



Here is 1 block which includes the first 4 textures from wmsetusXX.obj. There are 16 polygons and/or 32 triangles in one block. Each polygon has been made to show 4 32x32 texture area which are the small square areas in the image above.

As I described geometry before I wrote UV coordinates also while I hadn't researched it much yet. Turns out I was correct, but here's better struct with explanation after:

Code: [Select]
struct
{

        u8    face indices [6];         // Describes which indices are connected to each other. See first post, there is an example of face indices for blocks used in sea.
        u8    U vertex 1;
        u8    V vertex 1:
        u8    U vertex 2;
        u8    V vertex 2;
        u8    U vertex 3;
        u8    V vertex 3;
        u4    Texture page [4-bits];    // This changes the texture page according to value (0-F)
        u4    CLUT_ID [4-bits];          // The current palettes CLUT info. This needs to point for the texture you are using (first row 0-3, second row 4-7, and so on...).
        u8    Material type;             // Defines if the geometry is mountain, forest, sea or so on.... (00 seems to be forest)
        u8    Unknown;        // I'm not quite sure what this operates, but it seems to change texture pages too. Currently got only the sea textures while changing the value.
        u8    Unknown;       // Also unknown, however the last 4-bits seems to operate collision somehow

}Triangle

Now for the UV's. Each UV must be set according to triangle's face indices. UV values are from 00 to FF. They are set to indicate a rectangular area where the texture is present in current texture page. For example, if you have 128x128 texture and you want to fill a block with 16 polygon, you have to give each U and V coordinate a value in 2D axis where (0,0) indicates top left corner and (FF,FF) bottom left corner. The textures used in wmsetusXX.obj are 128x128 and it contains 16 32x32 textures so if you want to give a specific texture, you set each face indices UV's to the corresponding area by scaling UV's according to texture location on the page.

Here's an example how I did the image above (and great demonstration of my paint skills  :evil:):



Blue dots are face indices. In this example the top left dots values are (U = 0x00, V = 0x00).
Middle dots values are (U = 0x7F, V = 0x7F).
Bottom right dots values are (U = 0xFF, V = 0xFF).

This indicates that the UV area contains the whole area. While there is now 4 polygons used for showing one texture, you can set the area inside 1 polygon also. It's also possible to enlarge it, but it needs more "waypoints" (dots) to determine in between the desired area and making it manually is frustrating.

So, this means that in theory it is possible to use large textures in world, but since the memory space is limited it may be difficult. I'll look on this later.


If you have questions please ask. I'm pretty tired and noticing my own mistakes and the "shortness" of this post makes me think I may have forgotten to explain something so ask if there's something you don't understand or needs a little explanation.

89
Good news guys. I finally managed to crack the UV placements and no wonder it was so hard because I didn't realize they are picked from psx emulated framebuffer. Well I'm gonna do a little more research and write here at evening how it is read from the file. Get ready! :D

90
So, I tried to analyze a bit more wmx.obj and this is what I got.

Near the end are the sections that are placed to world map according to game progression:


And also there is the whole area which is showed in place of esthar.

I also found that the crater done by Lunar Cry is there but for some reason the area is split in two and the parts are next to each other like this:


You can see that they are horizontally next to each other while in game they should be vertically on top of each other.

This led me to think that most likely there isn't a simple algorithm to read this file in the engine, but somehow it's described which sections corresponds which area. So it's either somewhere in wmset files or described in engine which would be unfortunate for us. I'll try to search more info for the placements.

EDIT: Can someone confirm if the wmset.obj contains japanese texts? There seems to be text differences between these files.

91
Oh I think it is because I have software rendering on from ff8config. I'm using laptop with gt 840m and HD 4400 and for some reason with both graphic cards I can't use direct3d acceleration because it does this:





Any solutions for this?

92
Oh, I mean that is how timviewer shows my wmsetus.obj when I nullified the header of tim textures. I nullified 6 or 7 textures from the beginning and 117720 is the first texture offset for me also. I just tried to demonstrate that for me the textures didn't change for some reason while and while not in ragnarok. I wonder if i have some settings differently because I use dxwnd for windowed screen

93
I see.... I can't replicate this for some reason. I nullified the textures from the file like this but I still see all the textures??:

Notice that the first texture is the water textures!





94
I learned a lot by modding the textures using Tonberry for the world map... here are a few notes:

1:  UV's are incorrect on the PC worldmap - textures are not 'seamless' and strange artifacts happen over the textures where the walkmesh is either 'doubled' over itself, causing strange wrapping issues, or some kind of glitch is present.

2:  The Ocean, Roads, and a couple other 'animation' effects that exist in the world map all 'rotate' to the same cycle of sprites.  If you change a 'road' texture from intercepting the textures at ram with hash-codes, unless you use a code that 'overrides' the entire animation, the road blinks between animation sprites.  As for the rails/streets Halfer was talking about - the textures for them are all on one texture page.

3:  When you are using the English version and are on the ground, the world textures are hi-res -- if you're flying around the world in the Ragnarok, textures 'pop' back down to lower resolution, so this behavior might help you guys figure out what's going on.

Thanks for all your hard work!

Really? That's useful, thanks!
Couple questions though. You are saying that rails/streets are on one texture page. Do you know this for sure because tim viewer separates them as own images. Though if they are on same page then the hex values would make sense also.

And the hi-res textures. I don't seem to see any kind of difference in textures while on ragnarok or ground. Is there a setting which operates this behavior in ff8config?

Also, 0x15CC contains placement to world from field. Here's ending replicated in world map :P



95
Okay, little analysis I did today. Here's what I documented:

Tested by nullifying these offsets from the beginning of wmsetus.obj and little inspection from the offset also.
wmsetus.obj:

0xB38 contains texture calls for rails and streets. There are 13 different pieces which have own texture. Each call is 4 bytes long and is somehow connected to their respective texture.

0xB70 contains data for the transition from world to fields. If offset indicator from the beginning of file is nullified you can't enter towns, except ragnarok cockpit (probably garden also).

0x18D0 has something to do with visibility of world models, especially ragnarok.

0x1CE0 has something to do with lunatic Pandora on tear’s point, nullifying offset indicator disables whole entry.

0x21B8 contains world map dialogues, probably all the texts that are shown in world map.

0x1AB04 contains color and lighting options for world map.



96
If by grid map you mean the placement of sections and how they are loaded to match the map, it isn't like FF7. In FF7 they are separate files and in FF8 there is only wmx.obj container which contains the sections and other files which contain textures. However there may be the placements also but I think they are coded in .exe for optimization.

Edit: Well, to be honest, I don't even know that yet. wmx.obj is 30MB big and I'm 99% sure that it contains only the geometry and texture calls. Other files mostly contains textures, but there're still lot to inspect. If these files contains the geometry placements, then it's packed very well compared to what FF7 respective data takes.

Edit 2: As I suspected, I found water geometry and texture calls from wmsetus.obj, but it's only size of a block when comparing to wmx.obj. It does contain much more data than the models itself, probably metadata mostly. I'll take closer look tomorrow for wmsetus.obj since I can't manage to get any information from wmx.obj for now because the texture calls don't make sense.

97
haha :D, seems like there is 2 wmx.obj in the psx image file? That's odd.

98
Well I have PSX version on my parents house, but I can't get it for a while :P. But I hardly doubt that the files differ from each other, it may be instruction related problem with PSX GPU and computer GPU. But if that's not the case then the PC is indeed an older version of world map which is pretty hard to believe because it was released later than PSX.

99
Great breakthrough! Since you're both working on this, is it possible to use the hi-res worldmap textures and the UV coordinates from the PSX version?


This is an interesting question. I still haven't looked on the textures for much but what I've been taking to note is that it should be possible to give faces a bigger resolution texture, so hi-res textures may be possible in the future. As for PSX version, there isn't any reason for PC to be any different when speaking of textures since they are similar. However it seems like the UV calculation for road isn't correct thus making the white lines disappear. It can also be that PSX version uses some polished version of PC world map, one way to confirm this is to get the wmx.obj from PSX files and import it to PC version assuming that the file hierarchy is same.

100
Cool!

In the first post I stated that there was 768 segments in the world map and I based that in that 835 segments value since I found out that the last segments include great salt lake, the bridge and other areas. Seems like in reality it may be even less, maybe half of the size or something, since the sections don't need to be the same size unless they are preset somewhere.

Pages: 1 2 3 [4] 5 6