Heyas -- new to the boards.

I've spent some time working on the EQ .wld format files attempting to decode them, and it sounds like the entire structure of the file format has already been mapped out. Any chance there's a reference to this information somewhere? Source code is also fine.

My goal is to be able to import the zone and character models into Blender so I can render some images for tactical maps and the like. However, there's two problems.

One is that it is my understanding WLD armatures define the X-axis to travel down the length of the bone. Blender defines this as the Y-axis instead. I had lots of fun dealing with the Quaternions, but I got the meshes to deform properly by brute force. However, this won't work at all for the skeleton animations because of this difference in definiton.

Second is that I have NO idea how to even unpack the EQG files into useable files, much less attempt to decode the format just yet. If someone could point me in the direction of how I can unpack the files it would be grand. Beyond that, I'd love to get cracking on the file formats for the new zones and models.

The newest reference to .WLD files can be found here:

http://prdownloads.sourceforge.net/e...c.pdf?download

Good luck...

Hey, thanks a ton for the reference. Looks exactly like what I've been wanting for the WLD stuff. Still no info on the new EQG format just yet? I'd like to at least be able to unpack the files in the archive.

Another question:

In the WLD Reference, under Fragment 0x12 -- it lists the 8 elements of each Data1 Item to be:

RotateDenominator
RotateXNumerator
RotateYNumerator
RotateZNumerator

ShiftXNumerator
ShiftYNumerator
ShiftZNumerator
ShiftDenominator

I interpreted the first four to be a Quaternion defining the rotation. Using Blender, I deformed the Mesh Vertices using this method (converting the Quats to Matrices), and here's what it looks like:

http://www.pancua.net/wyndam/final_d...ges/regrua.jpg

Or the Wireframe View Here:

http://www.pancua.net/wyndam/final_d...egrua-wire.jpg

I'm assuming you got the same or similar results using the method outlined in the WLD documentation?

Did you download the newest version? I thought I revised that section. The first four values are actually Euler values that describe a rotation about an arbitrary axis (what I guess you mean by a quaternion). The results you show are exactly what I get when I treat them as such...you're on the right track.

Hrmm ... Euler Values? Interesting.

Quaternions can be defined in two different ways. One is axis/angle. The other is similar to a 4d vector (x,y,z,w). I treated these as the 2nd, and got the pictures you see.

I *believe* I've downloaded the latest WLD reference. In case it hasn't been updated (or I'm a moron and didn't get the latest), can you briefly describe how to put these together? From the Documentation I've read (admittedly most of it from Blender), Euler Rotations only require 3 components. Am I off my rocker?

The reason I'm asking so many questions is because while the deformed meshes look correct, the animations don't look correct. While this may in fact be a bug in Blender, I'm also entertaining the possibility I interpreted these fragments incorrectly. Prehaps a SS of the Skeletons might help clarify a bit more, and see if we're on the same page.

Also, it appears SOE defines the vertex groups such that the X axis travels down the length of the bone. Am I correct in this assumption?

You'll notice on the pictures below, the resulting deformed mesh has the Left Arm of the model on Positive-Y, the Top (head) of the model on Positive-Z, and the front of the model on Positive-X. Did you see similar results?

Here's some quick screens of the Skeleton for the Regrua Above. See if it looks anything in the zip code of what you've got.

http://www.pancua.net/wyndam/final_d...egrua-skel.jpg
http://www.pancua.net/wyndam/final_d...grua-skel2.jpg

Aha! Now I see we actually are talking about the same thing. :-)

http://mathworld.wolfram.com/EulerParameters.html

Euler Parameters are four components. These are also called Quaternions, or so it appears.

So, for those of you scoring at home, I finally went back and re-wrote my code to import the Armature Fragments. After a few hours, I managed to finally crack the import, and I now have the animations working in blender for the older format WLD files.

I'd still REALLY like to know what information has been acquired from the EQG format files thus far, as my guild is fighting mobs in these new zones and I'd like to be able to make some renderings of them.

.
 

Excelent work!

Well, I downloaded the OpenEq Sources from the Subversion Repository, and I looked them over. Using them, I was able to decode the entirety of the MOD and TER format files. It appears, from the ter.hpp/cpp and mod.hpp/cpp files, the loaders do not fully understand the material segment. I manage to decode it.

I wrote a new version of the Loader for the TER format files based upon the interfaces and data structures already defined in the OpenEQ Header Files. This Loader at least compiles, thought I cannot test it currently as I don't have SDL on my machine. I compiled it with g++ on cygwin. The Header and Implementation files should be found at the bottom of this message (so long as I don't forget to attach them, hehe).

For those of you not familiar with C++ code, here's how the Material Segment Works:

The Material Segment looks like this:
[ long mat0_index ]
[ long mat0_name0_offset ]
[ long mat0_name1_offset ]
[ long mat0_parameter_count ]
[ long param0_name_offset ] [ long param0_value_type ] [ (long|float) param0_value ]
[ long param1_name_offset ] [ long param1_value_type ] [ (long|float) param1_value ]
...
[ long paramN_name_offset ] [ long paramN_value_type ] [ (long|float) paramN_value ]

[ long mat1_index ]
[ long mat1_name0_offset ]
[ long mat1_name1_offset ]
[ long mat1_parameter_count ]
[ long param0_name_offset ] [ long param0_value_type ] [ (long|float) param0_value ]
[ long param1_name_offset ] [ long param1_value_type ] [ (long|float) param1_value ]
...
[ long paramN_name_offset ] [ long paramN_value_type ] [ (long|float) paramN_value ]
...

• long index : 32-bit integer material index.
• long name_offset0 : 32-bit integer offset. Reading from this location in the string table gives the material name.
• long name_offset1 : 32-bit integer offset. Reading from this location in the string table gives another name string, which I'm not really sure what this second string is for.
• long parameter_count : 32-bit integer number of 12-byte parameters belonging to this material.
• long param0_name_offset : 32-bit integer offset. Reading from this location in the string table gives the parameter name. (Example: "e_TextureDiffuse0")
• long param0_value_type : 32-bit enumeration of what type the param0_value will be. (These values are always the same size of 4 bytes, just interpreted differently).
• (long | float) param0_value : If param0_value_type is '0', this value is a 32-bit float. If param0_value_type is '2', this value is a 32-bit integer offset into the string table.

EQG TER Format and EQG MOD Format use the same structure for their material segments. The Material records specify a number of different parameters, including texture names, shinyness values, and normal map textures. The current structures inside the openeq sources written didn't provide locations to store them, so I just stored the same information the original loader did with respect to the textures.

I hope you guys find this information helpful. :-)