[PSX/PC] World map conversion tool - wmx2obj (2015-11-17)

[Halfer]

by the way if you are wondering how I got your code changes is because I was too lazy to ask for source and decompiled your code, sorry about that.

That's totally okay, after all I did say that I will publish the source if anyone wants it. Didn't just do it because I thought I would pull out next version out pretty quickly . It's in github though so I can just link it if needed https://github.com/Halferi/wmx2obj  Well there you have it , that's the same version as the compiled one though.

it still just sends the last created one, which means all other data stored in faces are of no use. or is this just for debugging code and that code will be changed?

Well you can say that from the whole code. I never intended it to be final yet because I knew that I still have to change things for optimization. That also includes the rearranging of functions to easier upgrades in future once the program is "ready". But don't get me wrong, I do really appreciate that you do these optimization checks, also saves time from me .

also, don't know where I read it, but someone somewhere said there was a limitation to how many faces or vertices can be on each terrain chunk, which I can't really see, a pure water tile uses 512 faces, 400 vertices, but the chunk with balamb town for example uses 790 vertices and 1156 faces, which suggests to me that it should be possible to put more detail onto the FF8 world.

I don't think that there is any limitation to it technically. Problems that may occur though is the performance, but testing that comes later. Each section can hold technically 0x9000 bytes which is 36864 bytes in decimals. The world map currently hardly utilizes this space fully at all, in fact I don't seem to remember any section to take over half of the maximum size.

 

[Zervox]

That's totally okay, after all I did say that I will publish the source if anyone wants it. Didn't just do it because I thought I would pull out next version out pretty quickly . It's in github though so I can just link it if needed https://github.com/Halferi/wmx2obj  Well there you have it , that's the same version as the compiled one though.

Well you can say that from the whole code. I never intended it to be final yet because I knew that I still have to change things for optimization. That also includes the rearranging of functions to easier upgrades in future once the program is "ready". But don't get me wrong, I do really appreciate that you do these optimization checks, also saves time from me .

I don't think that there is any limitation to it technically. Problems that may occur though is the performance, but testing that comes later. Each section can hold technically 0x9000 bytes which is 36864 bytes in decimals. The world map currently hardly utilizes this space fully at all, in fact I don't seem to remember any section to take over half of the maximum size.

I also haven't seen any section near that number.
I am a bit curious to the 36864 limit, I am not familiar with any data type which is capped to that range, is this due to a custom size check hardcoded into the segment read code?

 

[Halfer]

I do think that it is related to the padding which was used in psx. There's probably no reason why it should be exactly 0x9000 amount of bytes, but I think that padding was the only reason it exists. Otherwise they would probably be one after another.

 

[Zervox]

I am guessing that there is no lookup data for each block to know beforehand how much data has been encoded because of
Code: [Select]

this.faceIndexOffset = faceIndexOffset;

inside block?
which is used later in Controller
Code: [Select]

int vertexIndexOffset = 0;        int textureIndexOffset = 6;        for(Iterator iterator = segments.iterator(); iterator.hasNext();)        {            Segment segment = (Segment)iterator.next();            segment.generateBlocks(data, vertexIndexOffset, textureIndexOffset);            vertexIndexOffset = segment.getFaceIndexOffset();        }

 

[Zervox]

I was curious about a potential bug I found in extracting the faceIndices, is that alot of the faces would be reversed as to what they should be, you find this by using 3ds max render function, the fix I found was that in findFaceIndices, the first (eg offset+0) is actually the resulting z index and x being (+2)

 

[Blue]

Quickly updated Controller.java to avoid unnecessary loops for faster performance. I strongly recommend upgraded versions of the software apply the same changes to their source code.

wmx2obj on GitHub
Java Archive (JAR)

 

[Blue]

Kudos to Zervox for pointing out run-time inefficiencies in the source code. Most, if not all, remnants of inefficiency caused by code formerly used for debugging should now be removed.

Both the repository and the direct download link are updated for now.

 

[Blue]

Before moving on to new projects, I decided to put the finishing touches on wmx2obj. I fully refactored the source code to remove known bugs and enhance the source code's readability.

The old source code was a giant chunk of iterative work and fairly complex to read. Now, the refactored software should be both efficient and easily readable.

wmx2obj on GitHub
Java Archive (JAR)

 

[Mcindus]

Before moving on to new projects, I decided to put the finishing touches on wmx2obj. I fully refactored the source code to remove known bugs and enhance the source code's readability.

The old source code was a giant chunk of iterative work and fairly complex to read. Now, the refactored software should be both efficient and easily readable.

wmx2obj on GitHub
Java Archive (JAR)

Alright... time to give this a whirl.   

Quick question - is there still supposed to be a .mtl file?  I can't seem to find it.

 

[Blue]

Quick question - is there still supposed to be a .mtl file?  I can't seem to find it.

Not in the program I wrote. Halfer is working on an upgraded version of wmx2obj with material and texture support.