[Данил Медведев]

Добрый день, уважаемые форумчане.

Таки есть желание работать в ревите на основе связанных файлов - чтобы архитектура разрабатывалась в одной модели, конструктив - в другой и так далее, друг-друга они видели на основе "копирования и мониторинга". Как я себе вижу данную процедуру:
1. Создается файл например для конструктора. Он сохраняется на общем сервере как модель из хранилища. В нем создаются базовые оси.
2. Создается файл архитектора. В него подгружается ссылкой "модель из хранилища" конструктивная. Копируются через совместную работу оси.
3. В файл конструктора копируется ссылкой "модель из хранилища" архитектурная. Мониторятся оси.

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

Далее, каждый работает в своем файле фактически независимо. И в каждом файле можно настроить рабочие наборы для "общих" элементов, такие как несущие стены, колонны, лестницы и прочее, и "уникальные", например у архитекторов "Полы", у конструкторов - "несущая арматура". И выключать свойствах связного файла подгрузку "лишних" рабочих наборов. Общие элементы вполне можно также копировать друг-другу через "копирование и мониторинг".

Но как же без "Но":

За 20 минут эксперементов возникла проблема с "зацикливанием" несущих стен. Сместил стены в архитектурной модели - он попросил их переместить в конструктивной. Переместил. А в архитектурной модели он стал просить снова сместить те же стены. И так до бесконечности. В итоге - решилось только удалением стен. Такая цикличность - это нормально? И как можно от этого уйти?
Второй момент. Есть желание в семейство окон и дверей вставить семейство для установки обрамления отверстий в монолитных стенах. Т.е. архитектор ставит семейство двери, в котором сидит семейство обрамления проема, но до поры до времени параметр, отвечающий за установку типоразмера обрамления стоит в положении "нет". Когда я, как конструктор, начинаю армировать стены, я вижу в монолитных стенах архитектурную дверь, Копирую её к себе в проект с мониторингм, меняю параметр, назначаю параметры для подсчета арматуры в спецификациях, и всё. НО у меня не получилось скопировать с мониторингом окна и двери. Т.е в связанной модели я вижу это окно, а в моей стене даже проема не вырезается. Как быть?

UP! Залез в справку. Есть указание "При мониторинге стен можно задать, следует ли отслеживать проемы, в том числе дверные и оконные проемы." Как - что-то я не нашёл.


И ещё: у связанного файла есть параметр "Общая площадка". Что это такое, и с чем его едят?

[extraneous]

Сообщение от Данил Медведев Сместил стены в архитектурной модели - он попросил их переместить в конструктивной. Переместил. А в архитектурной модели он стал просить снова сместить те же стены.

При появлении сообщения нажмите "Принять изменения".

Сообщение от Данил Медведев UP! Залез в справку. Есть указание "При мониторинге стен можно задать, следует ли отслеживать проемы, в том числе дверные и оконные проемы." Как - что-то я не нашёл.

Указывается это в окне параметров Мониторинга/Координации. Но копируются проемы неадекватно - создаются объекты "Проем в стене", только прямоугольные, и по ним ни марке не поставить, ни спецификацию не сделать, не говоря уже о какой-то вложенной арматуре. У нас для отслеживания положения проемов написан плагин.

Вкладывать арматуру с архитектурное окно - плохая идея, архитектурный файл будет сильно тормозить. Лучше выделять окно в связанной файле через Tab, копировать, вставлять "По тому же месту" и заменять на свое семейство. Если в семействах использованы одни общие параметры - при замене размер будет сохранен.

Сообщение от Данил Медведев И ещё: у связанного файла есть параметр "Общая площадка". Что это такое, и с чем его едят?

Общие координаты.

[Данил Медведев]

Сообщение от extraneous При появлении сообщения нажмите "Принять изменения".

Ну так я так и делал )). Ситуация была такова, что стена в проекте и в связной модели стояли на одном и том же месте, а в окне уведомлений об мониторинге висело предупреждение о смещении стен.
Offtop: Ладно, пока дальше экспериментов не доходит "Сейчас сделаем стадию П по-старнке, да и у архитекторов наработки уже есть, а на рабочке - будем пробовать... ну да, я эту песню уже полтора года слышу.

Сообщение от extraneous Лучше выделять окно в связанной файле через Tab, копировать, вставлять "По тому же месту" и заменять на свое семейство.

Но таким образом, при изменении положения или габарита окна не будет меняться арматура. Скорее я уж буду как и раньше вставлять своё отдельное семейство обрамления, ручки формы фиксировать на габаритах отверстия, и с помощью Вашей плюшки "Связь параметров" получать в него текстовые параметры принадлежности арматуры. Как-то так.


Но направление мыслей-то правильное?

[VadimS7]

Сообщение от Данил Медведев Но таким образом, при изменении положения или габарита окна не будет меняться арматура. Скорее я уж буду как и раньше вставлять своё отдельное семейство обрамления, ручки формы фиксировать на габаритах отверстия, и с помощью Вашей плюшки "Связь параметров" получать в него текстовые параметры принадлежности арматуры. Как-то так.

Продублируйте проем архитектурный своим проемом и свяжите их, потом установите свое семейство (с арматурой). У вас будет мониторинг изменений проема в районе вашего семейства. Совместная работа на основе связанных файлов

[Данил Медведев]

Сообщение от VadimS7 Продублируйте проем архитектурный своим проемом и свяжите их

Спасибо! На досуге попробую!

[extraneous]

VadimS7, "связать" через мониторинг? Для этого нужно будет делать проем в специальной категории, и отслеживаться будут только изменения положения, но не изменение размеров.

Я тут писал программку для отслеживания изменения дверей в архитектурном файле, попробуйте во вложении

Программа записывает положение и размеры всех дверей из связанного файла в txt-файл, после изменения файла АР - сверяет с данным файлом и показывает, какие двери перемещены, у каких изменены размеры, какие удалены и какие добавлены. На место удаленных дверей ставит "Кубик" (предварительно сделать семейство в категории "Обобщенные модели" с именем "Box" и загрузить в модель).

[Данил Медведев]

Сообщение от extraneous Я тут писал программку для отслеживания изменения дверей в архитектурном файле, попробуйте во вложении

Покорнейше благодарю! Опять же на досуге, буду пробовать!

[Свиридов]

Я извиняюсь, что встреваю в эту тему - но мой вопрос тоже касается совместной работы со связанными файлами.
Вопрос:
Это "правильно", что размеры, проставленные от элемента связанного проекта до элемента текущего проекта, пропадают из видимости при связывании текущего проекта в другой?
В справке, конечно, написано, что "Размеры, как и все другие аннотационные элементы, задаются только для текущего вида. Они не отображаются автоматически на других видах проекта.- но это же только для проекта, в котором они нанесены.

[Sergfromtlt]

Сообщение от Свиридов Я извиняюсь, что встреваю в эту тему - но мой вопрос тоже касается совместной работы со связанными файлами. Вопрос: Это "правильно", что размеры, проставленные от элемента связанного проекта до элемента текущего проекта, пропадают из видимости при связывании текущего проекта в другой? В справке, конечно, написано, что "Размеры, как и все другие аннотационные элементы, задаются только для текущего вида. Они не отображаются автоматически на других видах проекта.- но это же только для проекта, в котором они нанесены.

Так за что будет "цепляться" ваш размер если вы выгрузите из файла связанный проект?

[PSI]

Сообщение от Данил Медведев 1. Создается файл например для конструктора. Он сохраняется на общем сервере как модель из хранилища. В нем создаются базовые оси. 2. Создается файл архитектора. В него подгружается ссылкой "модель из хранилища" конструктивная. Копируются через совместную работу оси. 3. В файл конструктора копируется ссылкой "модель из хранилища" архитектурная. Мониторятся оси. После данных операций в двух файлах у нас взаимосвязанны оси, т.е. если поменяется у архитектора, это увидит конструктор и наоборот. Если не загружать и не связывать оси в обеих моделях, то изменения будут однонаправленными. Все ли я правильно на этом этапе понимаю, или что-то упускаю?

Здравствуйте. Я долго пытался понять эту фразу так и не осилил. Может кто то пояснить более развернуто когда какой файл создается, и куда подключается. Либо подсказать способ двухсторонней связи между разделами через ссылки на базе разных шаблонов?

[Setvar]

Сообщение от Данил Медведев архитектура разрабатывалась в одной модели, конструктив - в другой и так далее

Что это такое - и так далее? Внутренние сети, например, разрабатываются в третьей модели? Да это бред, полная деструкция технологии BIM.

[Данил Медведев]

Сообщение от Setvar Да это бред, полная деструкция технологии BIM.

А что для Вас "технология BIM"? Каша, в которой есть все и сразу?
А если серьёзно - разделение информации по разным моделям, но с сохранением взаимосвязей и доступа - не блаж, а насущная необходимость. Даже в сравнительно не большой модели работать всеми специальностями сразу тяжёлом начиная от банально большого количества фильтров, типоразмеров шаблонов видов и прочего, которые у каждой специальности разные, до проблемы, когда на стадии Р у конструктора разложены многие километры арматуры, которая сетевикам не нужна, но тормозит работу модели. Не все, но многие проблемы решаются разделением на разные файлы со взаимной связью

[Setvar]

Вот так у нас и выкручиваются при навязанной технологии. Слабы мы... и не только в коленках.

[Данил Медведев]

Сообщение от Setvar Вот так у нас и выкручиваются при навязанной технологии. Слабы мы... и не только в коленках.

Блин, идите чертите на кульмане с таким отношением

[Nels]

Offtop:

Сообщение от Setvar Что это такое - и так далее? Внутренние сети, например, разрабатываются в третьей модели? Да это бред, полная деструкция технологии BIM.

Вы сначала хоть как-то попробуйте поработать с большими моделями. Судя по вашим фразам вы вообще не в курсе о порядке работы в таких программах, которые позволяют разрабатывать разные разделы проекта в 3D. Например ревит и аллплан. И там и там проект делится на множество взаимосвязанных частей, которые связываются друг с другом, что позволяет видеть общую модель объекта. Причем не только смежные разделы делаются в разных файлах, но и сами разделы на больших объектах делят на части и работают с ними в разных файлах. Даже в текле смежные разделы подгружаются через IFC, а не разрабатываются в одной модели.
С таким наивным мнением, что если BIM, то все в одном проекте-модели вы еще не скоро дождетесь соответствующей программы и аппаратных мощностей, умещающихся в обычный офисный системник.

Сообщение от PSI Здравствуйте. Я долго пытался понять эту фразу так и не осилил. Может кто то пояснить более развернуто когда какой файл создается, и куда подключается. Либо подсказать способ двухсторонней связи между разделами через ссылки на базе разных шаблонов?

Ну там осиливать-то особо нечего. Надо просто взять и пытаться это сделать. Хотя конечно написанное понятно тем, кто уже так делал ). Построение фраз немного не соответствует тому, что делается на самом деле.
Создали два проекта. Допустим ОВ и КР. Каждый на своем шаблоне. В обоих проектах включаете режим совместной работы. При этом файлы становятся файлами-хранилищами. Сохраняете эти файлы-хранилища в сетевом общедоступном каталоге. Закрываете файл-хранилища. Заново открываете эти файл-хранилища с включенной галочкой в меню открытия файлов "Создать новый локальный". Открывать надо именно через ревит, а не через проводник. При этом создастся локальная копия файл-хранилища у того пользователя, который таким образом открыл файл (по умолчанию копия хранится по пути, указанному в настройках ревит как папка для проектов). После этого в проект ОВ подгружается файл-хранилище раздела КР, а в КР - файл-хранилище ОВ , т.е. подгружаются именно те самые проекты, которые лежат на сетевом диске. При таком способе можно одновременно работать в ОВ и КР с синхронизацией локальных файлов с файл-хранилищем. Но обновление связей не происходит автоматически. Допустим ОВ-шник изменил свой проект в локальном файле и синхронизировал его с хранилищем. Чтобы эти изменения отобразились в КР нужно обновить связь через диспетчер связей.
Теперь что касается координации. В данном случае, чтобы оси в разделах соответствовали друг другу. Во-первых создавать их надо только в одном из разделов. В другой раздел их надо переносить через Копирование/Мониторинг. Тогда при изменении положения осей в одном разделе, в проекте другого раздела будет выдаваться соответствующее предупреждение. Подробнее советую почитать справку.

[Setvar]

Сообщение от Nels Создали два проекта. Допустим ОВ и КР. Каждый на своем шаблоне.

Допустим, создали несколько проектов. Помимо АР и КР еще Вентиляция с дымоудалением, ВК, ПТ, Автоматика, ЭОМ, CC. Для всех коммуникаций нужны отверстия в стенах и перекрытиях. Как они будут учитываться и в каком хранилище? Я думаю, что в этом случае лучше всего подойдет одно общее хранилище. Ресурсов не хватит, естественно. Однако, с использованием внешних ссылок прекрасно работали и в AutoCAD MEP. IFC ни к чему упоминать и здесь не про Tekla разговор. Видимо, никто на этом форуме (и не только) понятия не имеет о строительном задании на отверстия в стенах и перекрытиях архитекторам (и конструкторам).

[miko2009]

Сообщение от Nels С таким наивным мнением, что если BIM, то все в одном проекте-модели вы еще не скоро дождетесь соответствующей программы и аппаратных мощностей, умещающихся в обычный офисный системник.

Offtop: Вообще-то в Allplan одна модель, это в Revit разные делают в силу отсутствия необходимого функционала и мучаются погружением. В Allplan у архитектора, конструктора и инженера одна стена , а не три и у каждого своя,
изначально Revit был архитектурной программой и смежные разделы там появились как "эксперимент", в принципе он таким экспериментом и остался. Мифическая совместная работа в Revit возможна , но на коттеджах.

Сообщение от Setvar Я думаю, что в этом случае лучше всего подойдет одно общее хранилище.

Есть и такой вариант и он даже вроде используется в Британском BIM стандарте (и частично даже присутствует в BIM стандарте Autodesk в СНГ) , колхозно конечно для типо BIM платформы но это все же решение, называется "центральное хранилище" оно связанно с хранилищем отдельным по конструктиву , архитектуре , инженерке и тд
Но обычно возникают споры кто отвечает за "центральное хранилище" ? у всех много работы и все складывают на BIM менеджера

[Nels]

Сообщение от Setvar Для всех коммуникаций нужны отверстия в стенах и перекрытиях.

А чем вас не устраивает такой вариант?

----- добавлено через ~36 мин. -----
Offtop:

Сообщение от miko2009 Вообще-то в Allplan одна модель, это в Revit разные делают в силу отсутствия необходимого функционала и мучаются погружением. В Allplan у архитектора, конструктора и инженера одна стена , а не три и у каждого своя,

Я имел ввиду разбивку одной модели на отдельные файлы. Из справки к аллплан:
"Взаимодействие слоев и файлов модели зависит также от следующих факторов:
 Величина проекта и число одновременно работающих с ним сотрудников. Если в обработке одного этажа участвуют несколько сотрудников, то на каждую конструктивную зону (например, восточное крыло, центральная часть, западное крыло и т.д.) следует создать по одному файлу модели.
 Одновременная работа над проектом специалистов узкого профиля. Чтобы обеспечить их параллельную работу в проекте, для специального проектирования всегда нужно создавать собственные отдельные файлы модели."
А уж как организована и насколько удобна работа с этими файлами, это уже другой вопрос.

[miko2009]

Offtop:

Сообщение от Nels Я имел ввиду разбивку одной модели на отдельные файлы. Из справки к аллплан:

у немцев свое понимание некоторых вещей, файлы раньше называли слоями, в Autocad же не отдельные файлы, а слои, тоже самое в Allplan , модель одна и много слоев, каждый моделирует в своем в рамках одной модели. И в это же время можно действительно подгрузить разные модели в одну , как в Revit. В Allplan много чего отличается от Revit в рамках философии привычных названий , от временных размеров и до ассоциативности.Тут скорее к файлам модели Allplan по логике подходят рабочие наборы Revit , только в рамках функциональности и работоспособности примерное соотношение 1 к 10 не в пользу Revit

[Nels]

Offtop:

Сообщение от miko2009 у немцев свое понимание некоторых вещей, файлы раньше называли слоями, в Autocad же не отдельные файлы, а слои, тоже самое в Allplan , модель одна и много слоев

Вас там же в комментариях представитель аллплана подправляет: " есть файлы (так называемые файлы модели, а есть слои), так вот файлы это глобальный уровень разделения модели, а слои подуровень в каждом файле моде и комбинация работы со струкутрой проекта". Т.е. большие модели в аллплан точно так же делятся на отдельные части, в каждой части есть еще свои слои. Причем файлов может быть до 9999 шт с выделением пулов номеров для определенных задач. Так что скорее рабочие наборы ревит - это аналог слоев аллплан. А разбивка на файлы - это разбивка на файлы и там и там.

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

[miko2009]

Offtop:

Сообщение от Nels Вас там же в комментариях представитель аллплана подправляет: " есть файлы (так называемые файлы модели, а есть слои), так вот файлы это глобальный уровень разделения модели, а слои подуровень в каждом файле моде и комбинация работы со струкутрой проекта". Т.е. большие модели в аллплан точно так же делятся на отдельные части, в каждой части есть еще свои слои. Причем файлов может быть до 9999 шт с выделением пулов номеров для определенных задач. Так что скорее рабочие наборы ревит - это аналог слоев аллплан. А разбивка на файлы - это разбивка на файлы и там и там.

Кстати, хорошая идея для сравнения, сравнить файловую структуру Allplan с якобы "файловой структурой" Revit

[PSI]

Сообщение от Nels Nels

Спасибо я тут от мышки накидал схему, правильно ли я понял, и как решается вопрос зацикливания? Синим показано движении информации при изменении в одном из файлов

[Nels]

Сообщение от PSI Спасибо я тут от мышки накидал схему, правильно ли я понял, и как решается вопрос зацикливания? Синим показано движении информации при изменении в одном из файлов

Как-то не пытался изобразить это дело графически. В целом похоже, но с некоторыми нюансами.
После того, как в локальном файле (лф) КР вы создали связь с файл-хранилищем (фх) АР и синхронизировали лфКР с фхКР , то фхАР будет вставлено в фхКР. Т.е. если вы даже удалите все локальные файлы, то при создании новых лф с фх связи никуда не денутся. Оба файл-хранилища останутся друг с другом связанными и будут при открытии подгружать текущую версию файла. Допустим вы удалили лфКР. После этого был отредактирован лфАР и обновлено фхАР. Если теперь создать новый лфКР, то в нем будет актуальная версия фхАР.
Но тут надо учитывать один момент. Допустим вы оформили размеры в разделе КР с привязкой к архитектурным объектам модели. Если в дальнейшем архитектор заменит эти объекты, то ваши размеры просто исчезнут. С одной стороны это так и должно быть. Исчезнувшие размеры легче отследить в том случае, если архитектор забыл сообщить о замене объекта. Правда это может обнаружиться не сразу, но у кого-нибудь да возникнут вопросы.
Но все же обычно хочется все-таки сохранить предыдущий оформленный вариант, который бы не зависел от смежников. В таких случаях я в раздел КР вставляю не рабочий фхАР, а его копию. Периодически эту копию обновляю, по мере работы по смежному разделу.

[PSI]

У меня почему то, складывается ощущение что это не штатная функция ревита, а так сказать слегка багнутый способ соединить 2 файла с разными шаблонами, найденный самими пользователями. Неужели нельзя сделать через ссылки отслеживание общих элементов двухсторонней функцией.

[Nels]

Сообщение от PSI У меня почему то, складывается ощущение что это не штатная функция ревита, а так сказать слегка багнутый способ соединить 2 файла с разными шаблонами, найденный самими пользователями. Неужели нельзя сделать через ссылки отслеживание общих элементов двухсторонней функцией.

У меня такого ощущения не возникает, когда работаю с такими файлами. Все вроде штатно. Отслеживание элементов работает через функцию Копирование/Мониторинг.

[extraneous]

Сообщение от PSI У меня почему то, складывается ощущение что это не штатная функция ревита, а так сказать слегка багнутый способ соединить 2 файла с разными шаблонами, найденный самими пользователями. Неужели нельзя сделать через ссылки отслеживание общих элементов двухсторонней функцией.

Связанные файлы действительно являются в некоторой степени вынужденной мерой. Но "разные шаблоны" - самая мелкая проблема.

Есть более серьезные проблемы, которые решаются при помощи связанных файлов:
- возможность вносить "промежуточные" корректировки в "своем" файле, но передавать другим отделам в работу "утвержденный" вариант. Например, архитектору может потребоваться "поиграть" с планировками, посмотреть разные варианты и только после этого передавать утвержденную модель другим специальностям - в рамках "единой модели" непонятно, как такое реализовать. То, что озвучил Nels ("вставляю не рабочий фхАР, а его копию"), на самом деле, и есть решение этой задачи, которое по-научному называется "Среда общих данных" или "Common data environment" (в гугле где-нибудь легко найти, см вложение).
- разграничение ответственности: связанный файл всегда доступен "только для чтения", я могу быть уверен, человек несанционированно не изменит чужие элементы;
- упрощение подсчета спецификаций: например, если делать каждый комплект КЖ0, КЖ1, КЖ2 в отдельном rvt-файле, то для подсчета расхода материалов на комплект не надо будет особенно задумываться - просто сделать спецификацию на все элементы текущей модели. Если же в модели присутствуют элементы и разных комплектов, то для подсчета нужно будет каким-то образом указывать принадлежность к комплекту, что потребует дополнительных трудозатрат. При необходимости сделать спецификацию на всё здание можно включить подсчет элементов "из связанных файлов;
- ограниченность вычислительных ресурсов: мы всё-таки работаем не с супер-компьютерами, а даже для простого здания полная модель может состоять из миллионов элементов. Деление на связанные файлы и подгрузка только определенных - вынужденное решение. Но небольшие здания или какую-нибудь стадию П вполне можно и в одной модели сделать.


Но это решаемые задачи, было бы действительно круто получить ПО, которое позволит сделать весь проект в одной модели. Ревит ближе подобрался к решению, но и тут работы непочатый край. Может быть, будет уже не Ревит, а какое-то облачно-серверное решение на базе Forge. Пока же живем с ущербным "копирование-мониторинг"

[miko2009]

extraneous с твоего позволения напишу как мы это решили при работе в Revit
во первых по моей инициативе заменили Revit на Allplan

Сообщение от extraneous - возможность вносить "промежуточные" корректировки в "своем" файле, но передавать другим отделам в работу "утвержденный" вариант. Например, архитектору может потребоваться "поиграть" с планировками, посмотреть разные варианты и только после этого передавать утвержденную модель другим специальностям - в рамках "единой модели" непонятно, как такое реализовать. То, что озвучил Nels ("вставляю не рабочий фхАР, а его копию"), на самом деле, и есть решение этой задачи, которое по-научному называется "Среда общих данных" или "Common data environment" (в гугле где-нибудь легко найти, см вложение).

архитектор создает просто три файла внутренней структуры и просто называет их :
1. Типовой этаж (рабочий)
2. Типовой этаж (фантазии)
3. Типовой этаж (не утвердил УКС)
переход с разных вариаций осуществляется одним кликом как для конструктора так и инженера моментально

Сообщение от extraneous - разграничение ответственности: связанный файл всегда доступен "только для чтения", я могу быть уверен, человек несанционированно не изменит чужие элементы;

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

Сообщение от extraneous - упрощение подсчета спецификаций: например, если делать каждый комплект КЖ0, КЖ1, КЖ2 в отдельном rvt-файле, то для подсчета расхода материалов на комплект не надо будет особенно задумываться - просто сделать спецификацию на все элементы текущей модели. Если же в модели присутствуют элементы и разных комплектов, то для подсчета нужно будет каким-то образом указывать принадлежность к комплекту, что потребует дополнительных трудозатрат. При необходимости сделать спецификацию на всё здание можно включить подсчет элементов "из связанных файлов;

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

Сообщение от extraneous - ограниченность вычислительных ресурсов: мы всё-таки работаем не с супер-компьютерами, а даже для простого здания полная модель может состоять из миллионов элементов. Деление на связанные файлы и подгрузка только определенных - вынужденное решение. Но небольшие здания или какую-нибудь стадию П вполне можно и в одной модели сделать.

не убиваемый геометрический движок в котором мы работаем в рамках одного из проектов в 12 человек одновременно в рамках одной модели при этом уже создаем в одной модели целый квартал в рамках рабочей документации! а не просто опалубочные чертежи стадии "П"..
Вот так примерно мы решили проблемы в Revit )

----- добавлено через ~18 мин. -----

Сообщение от extraneous Но это решаемые задачи, было бы действительно круто получить ПО, которое позволит сделать весь проект в одной модели. Ревит ближе подобрался к решению

Revit сделал ставку на то что люди получив сырой продукт додумают весь функционал сами и через API сами допишут что им нужно, но чудес не бывает и тот же Allplan в рамках совместной работы в одной модели это ролсройс , а Revit :

Сообщение от PSI слегка багнутый способ соединить 2 файла с разными шаблонами

[extraneous]

miko2009, как там сейчас дела в Аллплане, когда в совместной работе кому-то нужно сделать разрез "по всей высоте здания"? Всем нужно закрыть свои модели, и только тогда можно создать разрез?

Сообщение от miko2009 архитектор создает просто три файла внутренней структуры и просто называет их : 1. Типовой этаж (рабочий) 2. Типовой этаж (фантазии) 3. Типовой этаж (не утвердил УКС) задается доступ для каждого конкретного исполнителя в каждый конкретный файл структуры проекта. С возможностью записи или чтения, несанкционированный доступ запрещен даже при желании.

В Revit задача решается по тому же принципу.
А "слегка багнутый способ соединить 2 файла с разными шаблонами" звучит примерно как "компьютер, Автокад и принтер - слегка багнутый способ нарисовать линии на листе ватмана".

[miko2009]

Сообщение от extraneous как там сейчас дела в Аллплане, когда в совместной работе кому-то нужно сделать разрез "по всей высоте здания"? Всем нужно закрыть свои модели, и только тогда можно создать разрез?

если 6 архитекторов делают здание в километр, то для разреза с возможностью корректировки элементов необходимо всем выйти, нельзя что бы элементы принадлежали всем сразу людям одновременно в одной модели. Но обычно кто занимается конкретной работой у него и доступ только к его работе и просить доступ он может только у себя. Проблемы начинаются тогда , когда например архитектору нужно поменять отметку плиты например на лестнице, он приходит и просит конструктора изменить ее, а конструктор не хочет и просит обосновать "зачем?" и оказывается что это просто "хотелка", вот тут точно начинаются "проблемы" с доступом, нельзя накосячить !!!
При работе на 15 секционном здании, 6 секционном, 2 секционном, паркинге и все это в одной модели проблем не наблюдаем. А сейчас будем целый город в одной модели делать.
А по поводу многих проблем в Allplan ...... в 99% это байки от незнания программы, в том же МОРТОНе монолит чертили линиями в Allplan

Сообщение от extraneous В Revit задача решается по тому же принципу.

ну с таким подходом и в атокаде такой же тогда принцип , Revit не способен на это даже через инструмент "рабочий набор" например из-за древнего ядра, одну секцию кое как а уже типовой этаж 10 секционного здания в нескольких ипостасях , это для него уже мука и тормаза, только коттеджи.
А задание каждому конкретному исполнителю доступ в Revit невозможна и через RevitServer и просто так, нету инструмента для администрирования, любой желающий может зайти и "накосячить"

Сообщение от extraneous компьютер, Автокад и принтер - слегка багнутый способ нарисовать линии на листе ватмана

ну ты же вроде на программиста учишься и все выкручиваешь не в ту степь.
компьютер содержит клавиатуру- средство ввода информации понятной человеку для машины
принтер - средство вывода информации понятной машине но уже для человека
А когда ты одну модель Revit вставляешь в другую и она просто весит мертвым грузом и ее еще нужно в ручном режиме обновлять каждый раз и ты не знаешь где что меняется, это явно не равноценные вещи.
Я могу 100500 примеров привести что это зло, например берем 11 секционный дом , в одном файле колонны, в другом плиты , в третьем ЛЛУ. Например изменились совсем немного ЛЛУ, архитекторы поменяли пару лестниц на пером этаже, при обновлении этой связанной модели слетают абсолютно все что связанно с этой моделью на всех чертежах в рамках размеров, марок, уровней и тд. И все приходится оформлять заново.
Есть вариант замарозки видовых экранов, этот вариант действительно решает вопрос переделки заново всего оформления, но он сводит весь процесс в одной модели и вносимых изменений сразу в чертежах, на нет. Помню когда то, надоело редактировать приямки из-за незначительных изменений лифтов, взял и заморозил и забыл. Потом внес небольшое изменение и получилось так что один из семи приямков не изменился , а должен был, ребята на стройке потом работали отбойниками.

[Schmurgeff]

Только Revit!!! Только хардкор!!!

[jzgte-2]

Добрый день! Извиняюсь, если немного не в тему. Работал с файлом под стандартным именем пользователя "User", но один элемент случайно отредактировал под другим именем пользователя и теперь он является владельцем этого элемента и User не имеет права его редактировать. Чтобы редактировать этот один единственный элемент приходится в revit'е менять имя, что весьма неудобно. Подскажите пожалуйста, как сделать так чтобы владельцем всех элементов был один пользователь.

[S-Y]

Нужно будет разработать шпунтовую стенку для укрепления котлована. Что лучше: 1)сделать сам котлован в отдельной файле и подгружать в проект раздела КЖ
2)все делать в одном файле?
Ни разу не работал с топографией - как настроить шаблон вида для корректного отображения как конструкций, так и котлована?

[Nels]

Сообщение от S-Y Нужно будет разработать шпунтовую стенку для укрепления котлована.

Как-то пока не приходилось делать шпунтовые стенки, но с топографией немного работал. Обычно удобнее, когда топография сидит в отдельном файле. Так проще подгонять ее по высоте, двигать объект по площадке.
Но при этом к поверхности топографии сложно привязаться. Если верх шпунтовой стены идет не по рельефу, а по каким-то определенным проектным отметкам, то и необходимости привязываться к топоповерхности не будет.
Если шпунт должен копировать рельеф, то тогда лучше сделать их в одном файле. Напрямую привязать шпунт к рельефу наверное не получится, но есть способы через другие элементы. В 2019 ревите к по рельефу можно строить ограждения.

[S-Y]

С построением кажется разобрался. Остается не ясным вопрос: как инструментом "Разделение поверхности" определить границу так , чтобы откос был под заданным уклоном?

[Nels]

Сообщение от S-Y как инструментом "Разделение поверхности" определить границу так , чтобы откос был под заданным уклоном?

Разделение поверхности позволяет задать разные материалы разделенным участкам топоповерхности. Чтобы создать откосы нужно менять отметки поверхности.

[S-Y]

Сообщение от Nels Чтобы создать откосы нужно менять отметки поверхности.

Все так. Если поверхность ровная - угол откоса постоянный. В реальности - ситуация иная и откос имеет различный уклон вдоль стороны. По иному наверное не получится?

[Nels]

Сообщение от S-Y Если поверхность ровная - угол откоса постоянный. В реальности - ситуация иная и откос имеет различный уклон вдоль стороны. По иному наверное не получится?

Ну отметкам точек вообще-то можно смоделировать любые уклоны. Только надо расставить их в нужных точках. Можно хоть надписи изобразить на склоне, при желании и наличии свободного времени.
Алгоритм получается такой. Создается топоповерхность. Затем делается вертикальная планировка путем удаления лишних отметок и задания новых. Если делать таким образом, то ревит может показывать объемы выемки и насыпи. Может оказаться полезным.

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

Можно смоделировать топоповерхность в civil и импортировать ее в ревит.

[S-Y]

Сообщение от Nels Ну отметкам точек вообще-то можно смоделировать любые уклоны. Только надо расставить их в нужных точках.

"Об чем и речь". Топоповерхность построена по импортированным данным 3D горизонталей в dwg.