2

我有两个来自 v30 的二进制 Parasolid 文件（内部建模器字符串是 3000226，架构字符串是 SCH_3000226_30000_13006）。其中，旧类型的嵌入模式信息在我拥有的 Parasolid XT 格式参考的最新副本中定义。但是，对于实体类型 204（在 28101 模式之后引入），嵌入式模式格式完全不同。幸运的是，它有很多字符串，所以很容易对它的基本形式进行逆向工程：

unsigned byte: number of fields
short string: nodename
short string: description

then for each field
  short string: fieldname
  five bytes: maybe somehow correspond to <transmit 1/0> <node class> <n_elements> ?
  byte: (field) type

byte: possibly <variable 1/0> ?

然后实体按预期开始。

问题是这似乎是对二进制版本的可行解析，但在不知道这五个神秘字节实际对应的情况下，我不知道如何在 Parasolid 文本文件中实现对此的支持。它可能是两个短整数和一个无符号字符，可能是一个 4 字节整数和一个无符号字符。哎呀，因为在这两个例子中我的前三个神秘字节都是零，甚至可能有一个字符串在那里，在这种情况下恰好是 0 长度，在这种情况下，当然，它不是真的五个字节总是，但在我的两个示例中恰好是五个字节。

有谁知道神秘字节中发生了什么？

此外，我假设此方案将对实体类型 204 及更高版本有效。我不知道实体类型 203。我相信我从未见过包含该类型的 Parasolid 文件。

（另外，有没有人知道他们为什么会对仅用于支持向后兼容性的功能进行非向后兼容的更改？）

4

1 回答 1

1

偶然发现自己问题的答案。事实证明，我应该意识到他们不会在这里进行向后不兼容的更改。事实上，我遇到的事情已经记录在案，只是非常糟糕。这是我想出的规则：

当您拥有架构 13006 中不存在的实体类型时，您会得到这种“新”形式的嵌入式架构。（我相信，类型 185 及以上。）在这种情况下，格式为

unsigned byte: number of fields
short string: type name (aka nodename)
short string: description

then for each field
    short string: name
    short int: ptr_class
    positive integer: n_elts
    if ptr_class == 0
        short string: type
    if n_elts == 2
        logical: xmt_code

笔记：

  • “for each field”代码与编辑序列版本中插入和附加（I 和 A）代码中包含的字段数据相同。
  • 二进制中的“正整数”类型类似于指针索引类型，如果整数小于 32767，则为 2 个字节，否则为 4 个字节。由于我在这里从未见过高于 2 的值，并且无法开始想象什么样的实体将具有固定大小和超过 2 到第 15 个元素，所以我还没有实现这个。
  • 此外，此 n_elts 字段似乎比标准模式中的等效 n_elements 字段大一。（这在上面的 n_elts == 2 测试中清晰可见——根据文件格式规范，它应该是 n_elts == 1，但这根本不起作用。）

减去我的警告，这些基本说明确实出现在 2016 版本的文件格式中，第 14 页。但是，格式完全被破坏，与旧的 V15 版本的文档相比可以看出——应该有两个项目符号的级别，不是一个，并且表格的第一行被错误地变成了标题！

我还必须注意，虽然我的代码适用于实体类型 204，但我之前似乎从未在 X_T 文件中看到过新类型，这就是为什么我从未注意到我的代码中有这个漏洞的原因。所以我不能保证这在一般情况下有效——我所知道的只是它在 204 类型的情况下有效。

于 2018-01-18T19:50:38.467 回答