Структура файла sldprt

[Kukuev 0]

Не раз уже возникала необходимость открытия файла sldprt для ручного редактирования без участия SW. Например, при создании экспортированных тел или поверхностей, если Солид теряет ссылку. Сейчас столкнулся с самопроизвольным ростом размера файла при изменение всего нескольких размеров эскизов в середине дерева, который увеличился с 17 до 75мб. Все манипуляции типа пересохранения оказались бездейственными и возникло желание посмотреть на код файла - что именно может вызывать такой "рост". Есть ли в природе какие утилиты, способные помочь этому?

[trurl 3]

Врятли. Ибо не было бы проблем с пересохранением в более ранние версии.

[SERoz 201]

Врятли. Ибо не было бы проблем с пересохранением в более ранние версии.

А тот же STEP и т.п. куда????

Kukuev

Попробуйте скинуть модельку в файл внешнего обмена типа STEP, IGES и т.п - и "всосать" обратно в Солид - может файл и похудеет...

[trurl 3]

А тот же STEP и т.п. куда????

Да? А дерево? Вопрос о структуре ж был.

[SERoz 201]

Да? А дерево? Вопрос о структуре ж был.

Дерево естессно остаётся - я же не о JPG говорю...

[Kelny 1 250]

Сейчас столкнулся с самопроизвольным ростом размера файла при изменение всего нескольких размеров эскизов в середине дерева, который увеличился с 17 до 75мб.

...

Есть ли в природе какие утилиты, способные помочь этому?

http://fsapr2000.ru/index.php?s=&show...st&p=160570

[ssv22 16]

Врятли. Ибо не было бы проблем с пересохранением в более ранние версии.

Ну почему же, таких программ полно.

Cамая известная наверное из них "HIEW.EXE" - позволяет напрямую редактировать любой файл, правда в 16-м виде

Потом всякие дизассемблеры, декомпиляторы и т.п.

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

являются противозаконными!

Просмотреть код можно и средствами Total Commandera - по F3, там и в текстовом виде и в двоичном и в 16-ти-ричном.

Посмотрите и прикиньте: способны ли Вы на прямое редактирование...

По поводу файлов SW *.sldprt, как *.sldasm и *.slddrw это своего рода бызы данных, со вполне определенной структурой и это и есть бААльшой секрет кампании!

И для редактирования этих БД и применяется SW :-)

За исключением, конечно AutoDesk, который раскрыл формат и структуру своих файлов. Ну и может ряда других фирм-разработчиков ПО.

Вот на примере структуры файла *.dxf (*.dwg) можно себе представить как все это выглядит примерно.

А обычно все это закодированно, закомпилированно, зашифрованно...

И редактировать напрямую эти файлы - это на 99,99999999% сразу испортить файл. Просто SW скажет : "это не мой файл!".

Кроме того человек, желающий это проделать должен свободно воспринимать 16-тиричный код, как например слова обычного языка. Но я вообще-то не слышал, что такие люди

существуют...

Конечно можно программировать и на Ассемблере и в машинных кодах.

Но одно дело создавать определенную программу, другое дело редактировать файл неизвестного формата...

[SERoz 201]

А обычно все это закодированно, закомпилированно, зашифрованно...

И редактировать напрямую эти файлы - это на 99,99999999% сразу испортить файл. Просто SW скажет : "это не мой файл!".

И наверное ещё проверка на CRC есть, рады вааще хапец с копаняем в кодах...

[MFS 248]

Да? А дерево? Вопрос о структуре ж был.

Дерево естессно остаётся - я же не о JPG говорю...

После STEP и IGES дерево построения пропадет, конечно.

[nokal 2]

По моему, если сам разработчик не дает расшифровки своих файлов или заранее не делает их в понятном формате, например xml, пытаться разобраться в этом двоичном файле даже не стоит.

И дизассемблеры тут не причем, он нужен для поиска в исполнительном файле, который содержит уже заранее известные инструкции для работы с процессором.

А в данном случае, вы сталкиваетесь с неизвестными структурами представления данных, да и еще в двоичном виде.

А вот форматы step и iges известны и понятны, и перевод в них сделали сами программисты солида, и по ним можно судить о чем-либо, только нужно ли оно вам, уже то обрезанное от первоначального файла или нет это вам решать

[ssv22 16]

По моему, если сам разработчик не дает расшифровки своих файлов или заранее не делает их в понятном формате, например xml, пытаться разобраться в этом двоичном файле даже не стоит.

...

некоторые товарисЧи (на букву Ха...называются) еще и не такие вещи делают...

...

И дизассемблеры тут не причем, он нужен для поиска в исполнительном файле, который содержит уже заранее известные инструкции для работы с процессором.

...

на этом я не стал заострять внимание - и так много написал...скажут еще - болтун

...

А в данном случае, вы сталкиваетесь с неизвестными структурами представления данных, да и еще в двоичном виде.

А вот форматы step и iges известны и понятны, и перевод в них сделали сами программисты солида, и по ним можно судить о чем-либо, только нужно ли оно вам, уже то обрезанное от первоначального файла или нет это вам решать

форматы step и iges потому и называются еще "форматами обмена", они для этого и существуют.

А в целом согласен.

[Kukuev 0]

Дерево естессно остаётся - я же не о JPG говорю...

В виде импортированных тел?

ssv22

Хьюшкой посмотрел в первую очередь, потому и стал искать специализированную утилиту. Редактировать я ничего и не думал, просто хотел сравнить с исходным, "нераздутым", файлом. Но раз уж нет, буду искать другие способы.

Насчет размеров файла я прочитал много тем, но решения так и не нашел. Проблема не в версии SW, т.к. пробовал и под 2008, и под 2009 сохранять. UnFrag найти не смог - ссылки битые, но пользовался EcoSqueeze. Практически никакого результата.

А нет ли дополнений, позволяющих сравнить два файла по дереву?

[Kelny 1 250]

UnFrag найти не смог - ссылки битые

В каком месте они битые не знаю, но по указанной ссылке ( <noindex>http://solidworks.cad.de/rev_unfrag.htm</noindex> ) есть даже исходники (в самом низу страницы Unfrag download (137 KB) ).

Так, что можете даже, конечно, при определённых навыках и желании, узнать что же вычищает из файлов сей продукт.

[ssv22 16]

...

Насчет размеров файла ...

А нет ли дополнений, позволяющих сравнить два файла по дереву?

Насчет размеров файла: я как-то заметил, что р-р сохраненного фала отличается в случае, если перед сохранением провести полную "регенерацию" по Ctrl+Q

и "перестройку" по Alt+B.

В первом случае р-р получался больше - ну в моем случае:

после Ctrl+Q = ~ 12Mb

после Alt +B = ~ 3Mb

Потом мне надоело это дело отслеживать, плюнул я на это, а SW, видимо, "обиделся" и практически перестал раздувать свои файлы...

Уж не знаю чем это было вызвано.

[SERoz 201]

после Ctrl+Q = ~ 12Mb

после Alt +B = ~ 3Mb

Хмм... :g:

[nokal 2]

Товарищи, сам я не пробовал так тестировать, и никогда не смотрел на размер, но читаю я и дивлюсь

В первом случае р-р получался больше - ну в моем случае:

после Ctrl+Q = ~ 12Mb

после Alt +B = ~ 3Mb

Странно это вообще, что файл меняет размер на столько.

Вы ведь только вредставьте, сколько это текстовых данных будет, если открыть файл с такой разницей(9Mb) в блокноте

Тут видимо хитрость какаето, и это должно быть где то описано.

Потому что это неправильно, что разработчик такого крупного продукта пропустил такие баги, что один и тот же файл весит по разному.

Пусть он может как то быть модифицирован, например "сокращенные" детали, или еще что либо, но это не проблема сохраненного файла, это проблема программы. В файле должна быть одна структура, и максимум одна пометка, что при загрузке файла - детали должны быть, по тому же примеру, "сокращенные". Но это занимает максимум 1 байт - флажок boolean

(Про сокращенные это всего лишь пример, так как в простых деталях такого вообще не применяется, а только в сборке)

Но запись одного и того же с такой разницей в размере это явно или специально, или мы(а в частности вы, но и я теперь) не разобрались.

Ладно, это были больше рассуждения, тут наверно какаето хитрость если происходит так как вы описываете

[ssv22 16]

Товарищи, сам я не пробовал так тестировать, и никогда не смотрел на размер, но читаю я и дивлюсь

Странно это вообще, что файл меняет размер на столько.

Вы ведь только вредставьте, сколько это текстовых данных будет, если открыть файл с такой разницей(9Mb) в блокноте

...

Конечно странно!

Ну вы прямо предполагаете у меня наличие какого-то злого умысла...

Его нет, честно говорю (злого умысла).

Что видел, то описываю...

PS. наблюдал НЕ во всех файлах и не всегда, короче - закономерности какой-то не обнаружил.

Единственное, насколько сейчас помню такое было заметно при сравнительно больших р-рах файла, т.е. надо брать файл ~5 - 10Mb, может больше...

Было это в SW 2007 SP0.0.

[SERoz 201]

Мысль возникшая случайно...

Возможно такое может происходить при больших построениях без сохранения (в моделях - вставка большого числа жеталей или вложенных сборок, в чертежах - большое чилсо доп. построений (вставка удаление элементов построений) и всё без сохранения или без симафорчика)...

Возможно происходит переполнение буфера отката и новые наслоения остаются в файле...

И Alt+B как-то это всё чистит???

[ssv22 16]

Мысль возникшая случайно...

Возможно такое может происходить при больших построениях без сохранения (в моделях - вставка большого числа жеталей или вложенных сборок, в чертежах - большое чилсо доп. построений (вставка удаление элементов построений) и всё без сохранения или без симафорчика)...

Возможно происходит переполнение буфера отката и новые наслоения остаются в файле...

И Alt+B как-то это всё чистит???

Нет-нет : я очень часто сохраняю и перестраиваю и модели и чертежи.

Потом, я не утверждаю, что разница именно в таких пределах - величина переменная, но заметная. Я почему и обратил внимание-то!

[nokal 2]

Так или иначе, чтобы исследовать врага, его надо поймать

P.S.

Нет-нет : я очень часто сохраняю и перестраиваю и модели и чертежи.

Наверное пару раз солид вырубался когда вы сделали огромную работу и не сохранили, что теперь привычка такая