Новый формат встроенной схемы для Parasolid v30?

Question

У меня есть два двоичных файла Parasolid из v30 (внутренняя строка моделира 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-байтовый тип int и неподписанный символ. Черт возьми, поскольку в обоих примерах у меня первые три загадочных байта равны нулю, там даже может быть какая-то строка, которая в данном случае просто равна длине 0, и в этом случае, конечно, это не совсем пять байты всегда, но в моих двух примерах всего пять байтов.

У кого-нибудь есть идея, что происходит в загадочных байтах?

Кроме того, я предполагаю, что эта схема будет активна для типов сущностей 204 и выше. О чем я не знаю, так это о типе сущности 203. Я не думаю, что когда-либо видел файл Parasolid с таким типом.

(Кроме того, есть ли у кого-нибудь понимание того, почему они могут внести не обратно совместимые изменения в функцию, предназначенную исключительно для поддержки обратной совместимости?)

Answer 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

Заметки:

• Код "для каждого поля" совпадает с данными поля, включенными в коды вставки и добавления (I и A) в версии последовательности редактирования.
• Тип "положительное целое число" в двоичном формате аналогичен типу указателя, где он равен 2 байта, если целое число меньше 32767, и 4 байта в противном случае. Поскольку я никогда не видел здесь значения, превышающего 2, и не могу представить, какой тип сущности будет иметь фиксированный размер и больше, чем от 2 до 15 элементов, я этого еще не реализовал.
• Кроме того, это поле n_elts представляется на единицу больше, чем эквивалентное поле n_elements, найденное в стандартной схеме. (Это хорошо видно в тесте n_elts == 2 выше - в соответствии со спецификацией формата файла это должно быть n_elts == 1, но это НЕ работает вообще.)

Минус мои предостережения здесь, эти основные инструкции появляются в версии формата файла 2016 года, на странице 14. Однако форматирование полностью нарушено, что видно по сравнению со старой версией документа V15 - их должно быть два Уровни маркеров не один, а первый ряд таблицы был по ошибке превращен в заголовок!

Я также должен отметить, что хотя мой код работает для типа сущности 204, я, похоже, никогда не видел нового типа в файле X_T, поэтому я никогда не замечал эту дыру в своем коде. Поэтому я не могу подтвердить, что это работает в общем случае - все, что я точно знаю, это то, что оно работает в случае типа 204.