J3D File Format

[Jeff-Groves]

So far doing a check does jump the header and get me right to the faces section.
Another odd file is the airdepthcharge.j3d
3D Object converter does not like that one.

[Polak2]

Another thing is that in the example of type 212 which we have started this very intriguing conversation, animation parts like 212 periscope 1,2 , snorkel, radar or mentioned ecm antenna are not part of the main 212.j3d model . The sail is empty inside. Those parts seem to be called once the appropriate command is issued.
I believe this happens throughout all other models.

[Polak2]

Another odd file is the airdepthcharge.j3d
3D Object converter does not like that one.

Not that this is of most importance, but I think that airdepthcharge.j3d is not used in the game. DWEdit has some nifty feature linking entities to their j3d models. Air deptcharge according to DwEdit uses depth.j3d and depth3.j3d which looks like the same models to me.

[Jeff-Groves]

As I get the time I'll write a script to export the info from the j3d files as is.
3D Object Converter just does not export all the info and I'd like to know the reason behind that.

I may wipe the old NoteBook and re-install Win 95 or so.
Then I could run the old 3D Studio and j3d exporter to see what the export options are.

[Polak2]

3D Object Converter just does not export all the info and I'd like to know the reason behind that.

I think 3DObject Converter takes all animated parts of surface units (usually guns, radars, torps) and bunches them to one single coordinate ....usually inside the hull so unless one switches to wireframe mode, one may never know that they are there...lol.

[Jeff-Groves]

Originally Posted by Polak2

I think 3DObject Converter takes all animated parts of surface units (usually guns, radars, torps) and bunches them to one single coordinate ....usually inside the hull so unless one switches to wireframe mode, one may never know that they are there...lol.

3D Object Converter seems to be skipping some verts in some cases.
Or maybe just optimizing them and condensing the files.
That's fine for what it does but does not help when looking at a possible new way to convert to the j3d format.

And I have seen the way things may be out of place in the files.
It's much like SH3/4 where the location connection to parent location is ignored by every exporter ever written.

That's due to the way any given exporter is coded.
If a part is assigned as a child of a part at say 1, 5, 9 in the X, Y, Z? Then it inherits that position in the Games.
IF that is not coded into the exporters? You get the true X Y Z but not the inherited position so the weird placement thing.

[Battlewagon3]

Originally Posted by Jeff-Groves

Here's the start of the 010 template for j3d files.
http://www.mediafire.com/file/f93une...bz/j3d.7z/file

This template will take you to the start of the faces.
It reads the file just as is!

I'm replying to thank you now before I forget. It could be a few months before I chase this down properly. I've been very busy learning how to code (really) for my studies, so games modding has taken a backseat. As you'll see from my other posts, though, every few months I come back with questions and try a few more things. I'm not ignoring you!

[HoneyFox]

I took several hours researching the j3d file format, and here is what I've found (see attachment).

It's written in C++ style, although C++ doesn't support declaring array of uncertain length, but... you get what I mean.

PS1: There are still some unknown items, but they seem to be constant during my research over dozens of .j3d files.
PS2: It's still far from having a new exporter. Major challenge is to find a suitable input model format and write a parser for it, especially when dealing with models containing hierarchy.
PS3: Actually I'm not sure if that use_tex and render_order is correct or not, I found no value to store the material index of model, but it doesn't seem to match if we assume it is.

[Polak2]

Interesting work and progress.

Are you trying to make a new exporter plugin like DWj3dexporter2004 which has some limitations of polygons being able to export as well as being compatible with a very old version of 3dsMax?
I assume that you are aware that j3d is part of the 3D ObjectConverter and can load models but not save them back to j3d.

Perhaps there is something we can help with?

[Polak2]

Perhaps of some help would be a structure of DW database where some of the j3d elements are mentioned.

I think it is included in DWEdit1_7_4_1 which was in DW Download section on this forum.

[HoneyFox]

Originally Posted by Polak2

Perhaps of some help would be a structure of DW database where some of the j3d elements are mentioned.

I think it is included in DWEdit1_7_4_1 which was in DW Download section on this forum.

Oh, my aim is to have a tool for exporting j3d models for JFC. I don't know if this file format has changed or not when it comes to DW.

Anyway this is the current workflow: modeling in Blender 3.x -> Blender 3.x Wavefront obj exporter (I modified the wavefront obj exporter so that the hierarchy/offset info can be exported as well) -> Wavefront obj file -> My exporter -> J3D file -> cmpUtils.exe -> GraphicsDB.

Too bad that subsim doesn't allow me to upload .zip file attachment...

[Polak2]

Originally Posted by HoneyFox

Oh, my aim is to have a tool for exporting j3d models for JFC. I don't know if this file format has changed or not when it comes to DW.

Word of caution: as DW j3d plugin had a limit of 32K polys on the models it is very probable that JFC (being the earliest) would have some hard limits on 3D models as well. It was dictated by the HW in those days.

[HoneyFox]

Originally Posted by Polak2

Word of caution: as DW j3d plugin had a limit of 32K polys on the models it is very probable that JFC (being the earliest) would have some hard limits on 3D models as well. It was dictated by the HW in those days.

It's expected since the data structure mentioned in J3DFileFormat.h above has lots of items using “short"/"unsigned short” type, which implies that there will be a limit of 32768(if it's signed) or 65536(if it's unsigned) for both vertices and triangle faces. Similarly there is a limit of up to 128 textures and 256 or 128 materials since it's using "char" type, and up to 32 characters for names of objects in the model.

Luckily for JFC we don't really need that high poly count in most cases. DW's graphics quality is definitely in another level so exceeding-the-limit becomes more often.

[Polak2]

There are not many differences between graphics (3D model-wise)for JFC and DW.



In fact, hardly any.

Which begs the question: are the JFC mission playable on DW? The interface of JFC is a little dated and so is the DW but not as much.

[HoneyFox]

As someone requested, I've pushed my tool to github:
https://github.com/HoneyFox/J3DFileConverter

Feel free to fork/create merge requests.