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 | 4 Comments

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

JT Version Issues

Does anyone out there have a grasp on what’s going on with the JT file versions?

According to the files themselves, here are the versions of the JT files I have: 8.0 (lots), 8.2, 9.0, 9.1, 9.3, and 9.4. I get pretty decent results from most of the 8.0 files and the 9.0 files. Meanwhile, the two released versions of the JT file standard are labeled 8.1 and 9.5. In other words, I don’t have any JT files that are actually for the exact versions covered by the standard documents.

Meanwhile, ISO/DIS 14306 is an ISO version of the JT standard, apparently based on the 8.1 standard. But the document is 200+ pages longer than the JT 8.1 spec. I think it might include the XT spec, but that’s only approximately 125 pages in the latest version I have. (Though both JT and XT strike me as a bit on the vague side compared to STEP! Maybe they’ve actually defined how things work instead of just vaguely hinting at it.)

Does anyone out there have a solid grasp on the current state of JT? Are most people using 9.5? Or is the ISO standard going to freeze things back closer to 8.1?

(PS I’ve solved the Arithmetic Codec issue I was having, but I don’t have the brainpower tonight to sit down and describe the solution. Of course, now I’ve got a serious Huffman coding issue.)

Posted in Uncategorized | 3 Comments

Utterly Flummoxed By Arithmetic Coding

So, I’m pretty sure I understand the basic algorithm for arithmetic coding — the details may be fussy, but the overall concept is clear. But I’m completely stumped by the details of the JT version. You see, the format specifies that there may be 1 or 2 probability context tables. The algorithm is fairly clear if there is just one probability context table. But nowhere in the specification can I find out what the frak the second probability context table means. And of course, it seems that basically every arithmetic codec example in the file I’m looking at has that second probability context table.

So, you say, why not check the JT spec’s example source code? And in fact, we find this there:

class CntxEntry 
{ 
public: 
 
 Int32 iSym;          // Symbol 
 Int32 cCount;        // Number of occurrences 
 Int32 cCumCount;     // Cumulative number of occurrences 
 Int32 iNextCntx = 0; // Next context if this symbol seen 
}; 

Each Context Entry object has an index to the Next Context in it! Great!

Unfortunately, that iNextCntx symbol appears exactly twice in the source code — once when it is defined, and once when its value is used. Nowhere is the value set. Nor does it correspond to any obvious field in the file’s data structures. Nor do I see any obvious way to derive it.

For instance, here’s the first pair of probability context tables I see in the file I’ve been looking at:

1st count 2
symbol -2 occurs 817 times, value 0
symbol 1 occurs 32 times, value 0
2nd count 2
symbol 1 occurs 244 times, value 0
symbol -2 occurs 31 times, value 0

(Here -2 is the special symbol meaning “insert out-of-band value here”.)

Okay, there is one clue I see here. The symbol count field has value 1124, which is 817+32+244+31. What does the symbol count field mean?

When two Probability Context Tables are being used, Symbol Count specifies the number of Symbols to be decoded by the Arithmetic CODEC. There is a subtlety present in the method CodecDriver::addOutputSymbol() when it is passed an Escape symbol. Only if the Codec is using Probability Context Table 0 when it receives an Escape symbol does it emit a Value from the “Out-Of-Band” data array. Because of this subtlety, the number of Symbols decoded can be larger than the number of Values produced, thus the reason for writing this field distinct from Value Element Count.

And indeed, the value element count is 1093, which is 1124 - 31, so that fits. But it doesn’t really provide any additional insight to me. Unless….

Hmmm. What if it switches over to the 2nd context whenever it sees a symbol 1 in the 1st context (32 times), then stays in the 2nd context until it sees a symbol -2? That would make the numbers fit, and explain why you don’t output the out-of-band value if you hit a -2 in the 2nd context.

Update: Let this be a lesson to me: before I do anything with JT, I need to read fully on the subject on both versions of the spec. In the 9.5 version of the spec, the field marked “reserved” in the 8.1 spec has been relabeled… “next context”. Problem solved!

Though it does make you wonder why they send the number of bits needed for this field, when there are only two possible values for it…

Posted in Uncategorized | 5 Comments

… and problems

Where am I now?

Running what I’ve got now on the first ten TriStrip objects in the file I’m looking at gets me three simple triangle-based objects I can handle. It also gets me a bunch of — guess what? — objects compressed with Arithmetic coding rather than Huffman coding! Which means I get to do the hard bits all over again.

What’s worse, my current code can’t even parse the Arithmetic coded objects correctly. In theory, their layout in the file should be exactly the same as the Huffman coded objects. In practice, something is going wrong between reading the probability tables and the out-of-band data.

What’s even worse: I went looking in the JT 9.5 spec to see if I could find the missing fields there. And then I said, wait, is this an Int32 Compressed Data Packet Mk. 2 I’m looking at? So I tried to see which one the TriStrip object uses.

Whoops. JT 9.5 seems to no longer have a TriStrip object. Instead it has a completely different format for storing triangle information.

Well, I guess we’ll burn that bridge when we come to it…

Posted in Uncategorized | Leave a comment