XeNTaX

shakotay2 wrote: hex2obj uses both but not together, that's the problem.

I wrote a simple program that extracted the data and saved it without offsets, and was able to construct this:


I have a few questions:
a) How exactly did you calculate D190 as the starting address? Was there a calculation involved or was it just a bit of guess-work?
b) Any clue why certain chunks of the map are missing? I can't seem to find a pattern to this, except for the trees that likely aren't fully modelled.

Kneesnap wrote:a) How exactly did you calculate D190 as the starting address? Was there a calculation involved or was it just a bit of guess-work?

it was just a little bit scrolling up and down in the editor (as always ) Oh, I forgot, counting down 80 bytes each (which I think should be 40 only). If you go to 0xd140 you'll experiencea maximum face index of 65323 which I just "felt" to be too big. Also there's a change in the blocksize in the lower address regions (reduced by 4).

b) Any clue why certain chunks of the map are missing? I can't seem to find a pattern to this, except for the trees that likely aren't fully modelled.

see above, I did not include the lower addresses.

Here's some pic using more FIs (9855) and an FI offset of 34: (quads must be used instead of triangles)

yes, it's upside down (to show that interesting spiral at the bottom)

Huzzah! This looks a bit more complete.


Now to figure out how to texture this.

shakotay2 wrote: it was just a little bit scrolling up and down in the editor (as always ) Oh, I forgot, counting down 80 bytes each (which I think should be 40 only). If you go to 0xd140 you'll experience a maximum face index of 65323 which I just "felt" to be too big.

Ah. I see. When I tried that I thought that the data under "GRID" was what I was looking for. (Still a bit new to this )

shakotay2 wrote: Also there's a change in the blocksize in the lower address regions (reduced by 4).

Interesting, I wonder if this is data to some "scenic" models like the leaves on trees.

EDIT: The spiral on the bottom is actually a bunch of rivers connected.

Been working a bit, and have an automatic extractor, along with most of the file format figured out. My issue now is I can't seem to get textures working in the .obj format.

How would I format .mtl files (and obj) to apply textures like this?


I have the UV data but for simplicity's sake I've been using vt 0,0 for the time being. What changes need to be made to the files below to make the textures above work?

These files were my attempt to just get any texture at all to show. I'd like it if I could see a working example of any textures being applied to this model in different places. I can make the extractor automate everything if I understand the pattern.

Kneesnap wrote:I have the UV data but for simplicity's sake I've been using vt 0,0 for the time being.

bad idea

In blender for example, in the uv image editor you can load a texture
(in newer versions of blender you may need to create a material before)
but you'll need a proper uv map for that.

With all vt being 0.0 0.0. in your FOR2.obj it's impossible to show.

shakotay2 wrote:

Kneesnap wrote:I have the UV data but for simplicity's sake I've been using vt 0,0 for the time being.

bad idea

In blender for example, in the uv image editor you can load a texture
(in newer versions of blender you may need to create a material before)
but you'll need a proper uv map for that.

With all vt being 0.0 0.0. in your FOR2.obj it's impossible to show.

Hmmm I think I'm misunderstanding the format then. Since this isn't a single texture for the entire object but each face using a texture from a list of tiles is anything different?

EDIT: Nevermind, earlier today I managed to get this:


The textures aren't right because the game has a hardcoded list of texture ids in its code while I just used them by their index. However, I'm unsure why the UVs don't work. I'm performing the same calculation I believe the game performs.
U = ((unsigned byte) Stored U Value * (unsigned byte) Texture Width) / 0xFF
V = ((unsigned byte) Stored V Value * (unsigned byte) Texture Height) / 0xFF
However, that doesn't seem to work, I get the image from above. I don't expect you to have an answer to this without more information, which I'm happy to provide.

Woohoo, I've figured it out.
While I still need to make by hand some manual data for each map to be extracted, I've figured out the format woohoo!


(I haven't finished writing the texture remap data so some places still have incorrect textures, but overall it works )

Thanks @shakotay2 I would have never gotten this far if it weren't for your help a few months ago.

Working on a level-editor next.

It's been a while since I've posted here. Thought I'd give an update. We've made progress on our complete Frogger modding tool.

@shakotay2 Once again, thanks for your help back when. Just needed a little push in the right direction.