Tri-Strip Set Shape LOD Stumper

So here’s what I’m getting (consistently in this file) when I try to read the Vertex Shape LOD in this Tri-Strip:

  1. Vertex Shape LOD Version Number: 1 (quite sensible)
  2. Vertex Shape LOD Vertex Bindings: 0x004a0001 (If I’m reading this correctly, that’s two component vertex coordinates (2D?), texture coordinate 6 has both 2 component and 4 component coordinates, and texture coordinate 7 has 3 component coordinates. That makes no sense that I can see?)
  3. TopoMesh LOD Version NUmber: 0 (quite illegal)

So… hmm. Are we missing something here? If the vertex bindings started with the 004a, they’d be 0x0000004a. That’s 3 Component Vertex Coordinates, Normal Binding, and Vertex Flag Binding. That seems much more reasonable. Let’s give it a try…

Update: If I add a step 1.5 reading an I16 up there, then we get the more sensible vertex binding above, and the TopoMesh LOD Version Number is 2, which is legal. This seems like a promising avenue…

Posted in Uncategorized | 1 Comment

Quick Update

In the last few days (in between work on other projects, mind you) I’ve implemented Point Quantizer Data, Compressed Vertex Coordinate Array, Compressed Vertex Normal Array, and started on TopoMesh Compressed Rep Data V1. Which means I’m, I dunno, about a quarter done implementing v9.5 Tri-Strips? Just the reading from the file part, actually doing something useful with the data is another project altogether.

I’m starting to wonder if this should be called the “translator developer full-time employment standard”! Too bad I’m not getting an hourly rate for implementing this…

Updated: Next batch: Color Quantizer Data, Compressed Vertex Color Array, Compressed Vertex Texture Coordinate Array, Compressed Vertex Flag Array, TopoMesh LOD Data, and TopoMesh Compressed LOD Data.

Posted in Uncategorized | Leave a comment

Tri-Strip Madness

Actually, to be more precise, I suppose this should be called “Vertex Shape LOD Data Madness”. The data flowchart spec for it has an if branch label “If TopoMesh Compressed Rep Data V1”. What does that mean?! It’s not something controlled by the prior two fields, as far as I can see. The TopoMesh Compressed LOD Data does have a version number field which can select for “TopoMesh Compressed Rep Data V1”, but the “TopoMesh Compressed LOD Data” is the alternative not selected by the “If TopoMesh Compressed Rep Data V1” branch. The ISO 14306 standard isn’t any help, it just repeats the same maddening chart.

The good news is, I think I have the Int32 Compressed Data Packet mk 2 more or less implemented now. (It hasn’t been tested yet; I need to figure out the above nonsense to get to a point where it can be.) I started up a completely parallel set of classes for mk 2, only to realize that mk 2 was mostly just mk 1 without the context-shifting stuff. So mostly handling mk 2 just meant initializing the next context field to 0.

Posted in Uncategorized | Leave a comment

Real Progress!

I was starting to get ready to tackle the huge project of implementing Tri-Strip support in the 9.5 importer when I realized I’d seen some JT_LLPROP_XTBREPs scroll by in my dump output. So I tried ignoring the Tri-Strips to see what I’d get; and what I got was a huge number of small B-reps — 864 which I successfully created, to be precise. I was anticipating it being a horrible mess (because I didn’t know if the positioning for each B-rep would be correct) but in fact it was quite recognizable as the model I’ve been working on.

With luck, this nice feeling of success will tide me over as I consider the vast amount of work needed to make tri-strips work…

Posted in Uncategorized | Leave a comment

Object IDs

Okay, I think I understand the statement of my current problem. In 8.1, Base Node Data included an Object ID. The Property Table was a list of keys and values, each of which was an Object ID, whic I would look up through the list of Object IDs read in.

In 9.5 Base Node Data no longer has the Object ID field. So I have no idea what those keys and values refer to any more…

(Posting this in the moment, haven’t had a chance to look up the property table in the 9.5 spec, and it’s time for me to cook dinner now…)

Updated: Okay, I think I’ve got it. But this is pure conjecture, I haven’t tried coding it up yet. If you look at the graph for the Element Header, 9.5 has added a very mysterious “I32: Texture Coord” field. (It’s “I32: Texture Coord Channel” in the ISO 14306 document.) If you actually read the descriptions of the fields, where the “I32: Texture Coord” should be explained is “I32: Object ID. Object ID is the identifier for this Object.”

So somehow they appear to have made a major typo THE most important field in element. And in the ISO 14306 it’s a slightly different version of the typo. What the heck? Did anyone actually try to implement this specification before making it a standard?

Final Update: I can confirm that the “I32: Texture Coord” field definitely appears to actually be the Object ID. I have this implemented now, and the import is getting a lot further before it falls apart. Alas, the tri-strip storage code seems to have utterly changed since 8.1…

Posted in Uncategorized | Leave a comment

First v9.5 Progress

So, as I mentioned yesterday, I found a JT v9.5 file to work on, but it died very early in the import process. After a long, unproductive evening trying to figure out why the Tri-Strip Set Shape Node Element read was failing, I quickly started making progress this morning. Turns out there are several significant differences between 8.1 and 9.5 for this element:

  1. The Base Shape Node rules added an I16 version number field.
  2. The Vertex Shape Node rules are completely different. They added a version number, combined the former three binding fields into one, much more complicated U64 field, and then duplicated that U64 field (but only if the version number is not 1).

This gets the Tri-Strip Set Shape Node reading properly. Of course, the very next field in file also has a catastrophic failure, but still, progress!

Update: Oh, the next one was just adding version number fields to Base Attribute and Material Attribute. That gets me a lot further into the file.

Also, I’ve got to say using an UUID to identify what kind of element you have is really handy for this sort of debugging — the odds of accidentally generating a meaningful UUID from the next 128-bits in a file is very very low, so you always know which element’s import was incorrect.

Update the Second: The Base Property Atom has replaced the I32 object ID with an I16 version number. The Late Loaded Property Atom has added a version number and a couple of other fields. The String Property Atom has added a version number. (If you wondering how I’m generating these updates, I’m updating when I do a git commit of my changes.)

Update the Third: The Floating Point Property Atom has added a version number — I guess in case they decide to use a double instead of a float in the future? And with this change, I can read the entire elements section of the file.

Posted in Uncategorized | 2 Comments

Resuming JT Work

It’s now been two-and-a-half years since I last posted in this blog. During that time I pretty much completely ignored JT. However, I’m itching to take another stab at it. In addition, I’ve gotten a couple of comments on the blog recently showing I’m not the only person puzzling over these issues. With any luck we can all work together and beat this thing.

So what are the issues I think I need to be tackling first here?

  1. What’s going on with JT versions? As I commented in my last post here, there are three published versions: 8.1, 9.5, and ISO/DIS 14306. To the best of my knowledge, I’ve never seen a JT file which identified itself as being in one of those formats. But then, I haven’t been actively looking for several years. Is it too much to hope that everyone is using 9.5 and/or ISO/DIS 14306 now? (Is there even a difference between those two?)
  2. The great Huffman ambiguity issue. (Strangely, I don’t see signs I did a post on this?) Basically, there are cases where two subtrees have the same height, and as far as I know the specification does not say what to do then. The most recent JT work I’ve done was actually trying to compare what happened depending on what assumption I made here. But I got sidetracked before I actually made any progress on it.
  3. Does anyone out there actually have 9.5 files? I don’t know how fast it is taking over, but given that a version of 9.5 became an ISO standard two years ago, it certainly seems like a logical place to start.

I’m sure I’ll think of more things in short order.

Readers, do you have answers to any of these questions? Do you have questions of your own?

Update: Hey, I just grabbed a 9.5 file off of GrabCAD! It completely killed my importer, but still, that’s progress!

Posted in Uncategorized | 2 Comments