Библиотека моделей и текстур на 2 ТБ: держать так, чтобы открыть с любого ПК

MAATRIX

У любого 3D-художника, который работает больше пары лет, рано или поздно заводится своя вселенная: папка с моделями мебели, техники, растений, персонажей; терабайты PBR-текстур, HDRI-окружений, кистей для ZBrush и пресетов материалов для Substance или редшейдера. Это не мусор — это рабочий капитал, который экономит часы на каждом проекте. Проблема в том, что вся эта библиотека обычно живёт на одном конкретном диске одного конкретного компьютера, и как только вам нужно поработать с ноутбука на выезде или с рабочей машины в студии — начинается ручной перенос гигабайт через флешки и внешние диски.

Библиотека, которая живёт своей жизнью

Личная библиотека 3D-художника растёт не по плану, а органически, проект за проектом. Купленный на маркетплейсе набор мебели остаётся в проекте «на всякий случай». Скачанный набор PBR-текстур бетона пригождается ещё в трёх следующих сценах. HDRI, снятый или купленный для одного рендера интерьера, становится дефолтным окружением для превью материалов. Через три-четыре года это уже не «папка с ассетами», а полноценный архив на сотни гигабайт, а то и пару терабайт: модели в разных форматах (.blend, .max, .c4d, .fbx, .obj), текстурные сеты с картами альбедо, нормалей, рафнеса и высоты, кисти и альфы для скульптинга, пресеты нодовых материалов, референсы, каталоги от Quixel Megascans или Poliigon.

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

Три компьютера, три библиотеки

Классическая ситуация: домашняя рабочая станция с полным архивом на внутреннем диске, ноутбук для работы на встречах и выездах — с урезанной копией «самого нужного», и рабочий компьютер в студии, где лежит своя, третья версия набора, которую туда когда-то скопировали и с тех пор забыли обновлять. Как только на домашней станции появляется новая партия текстур или обновлённая модель, она физически остаётся там, пока кто-то не вспомнит скопировать её на внешний диск и вручную перенести на два других компьютера.

На практике это выливается в конкретные, повторяющиеся неудобства:

• на ноутбуке в командировке нет той самой модели растения, которая нужна прямо сейчас, а интернет в отеле слишком медленный, чтобы качать заново;
• в студии открывается сцена с текстурами, привязанными по относительным путям к папке, которой там просто нет;
• внешний SSD с библиотекой либо забыт дома, либо, что хуже, случайно перезаписан старой версией с другого компьютера;
• потребительские облачные диски (Google Drive, Dropbox, Яндекс.Диск) на бесплатных и даже платных личных тарифах упираются в лимит объёма на паре терабайт текстур и моделей, а синхронизация огромной библиотеки через них тормозит рабочий компьютер.

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

Что меняет сервер как центральное хранилище

Идея простая: библиотека физически лежит в одном месте — на арендованном сервере с достаточным диском, — а все ваши компьютеры подключаются к ней по сети как к общей папке. Не нужно решать, какая копия «главная» и синхронизировать три места между собой: главная копия одна, а домашняя станция, ноутбук и студийный ПК становятся точками доступа к ней.

На практике это выглядит так: сервер с диском под 2 ТБ и больше поднимается один раз, на нём настраивается сетевой доступ к файлам (SMB для удобства на Windows/macOS/Linux или NFS для линуксовых рабочих станций), и дальше библиотека монтируется как обычная локальная папка — 3ds Max, Blender или Cinema 4D работают с ней точно так же, как с диском D: или /home. Разница в том, что эта «локальная папка» на самом деле находится на сервере и видна одинаково с любого устройства, где вы её примонтировали.

Второй слой — защищённый доступ извне. Пока вы дома или в студии на той же сети, что и сервер (или в одном датацентре у арендованного VPS), достаточно прямого SMB/NFS-подключения. Как только нужно работать из кафе, с выезда или из другого офиса — трафик стоит завернуть в VPN, чтобы не открывать файловый сервис в открытый интернет. Здесь подходит связка с WireGuard: поднимаете туннель, и через него сетевой диск монтируется точно так же, как из локальной сети, просто по IP сервера в приватной VPN-подсети.

Подключение диска как сетевой папки: SMB

Для смешанной среды (Windows-станция дома, MacBook на выездах, студийный ПК на Linux или Windows) чаще всего проще всего SMB — его понимают все три операционки без танцев с бубном. На сервере с Ubuntu/Debian это делается буквально в несколько команд.

Ставим Samba и создаём каталог под библиотеку:

sudo apt update && sudo apt install samba
sudo mkdir -p /srv/assets
sudo chown artist:artist /srv/assets

Добавляем шару в /etc/samba/smb.conf:

[assets]
   path = /srv/assets
   valid users = artist
   read only = no
   browsable = yes
   create mask = 0664
   directory mask = 0775

Создаём пользователя Samba и перезапускаем сервис:

sudo smbpasswd -a artist
sudo systemctl restart smbd

Подключение с разных систем:

• Windows: net use Z: \\server_ip\assets /user:artist или через проводник — «Подключить сетевой диск»;
• macOS: Finder → «Переход» → «Подключение к серверу» → smb://server_ip/assets;
• Linux: sudo mount -t cifs //server_ip/assets /mnt/assets -o username=artist,vers=3.0.

Если рабочие станции все на Linux (например, студийный рендер-фарм тоже на Linux), логичнее смотреть в сторону NFS — она легче по накладным расходам и лучше ведёт себя под нагрузкой при параллельном чтении множества мелких файлов текстур. Разница между протоколами и когда какой выбирать разобрана в отдельной статье про NFS против SMB на Linux-сервере — стоит прочитать перед тем, как закладывать протокол в инфраструктуру надолго, потому что переезд с одного на другой потом означает перенастройку всех клиентов.

Важный практический момент: если движок 3D-редактора привязывает текстуры по абсолютным путям, стоит на всех компьютерах монтировать сетевой диск под одну и ту же букву (например, всегда Z: на Windows) или одну и ту же точку монтирования на Linux/macOS — тогда сцены с относительными путями к текстурам открываются одинаково независимо от того, за каким компьютером вы сидите.

Когда SMB неудобен: Nextcloud поверх той же папки

Прямое сетевое подключение отлично работает, пока канал до сервера стабилен и достаточно быстрый — дома, в офисе, через VPN с хорошим интернетом. Но если вы на выезде с нестабильной точкой доступа или на слабом мобильном интернете, тянуть по SMB сотни файлов для одной сцены будет медленно и раздражающе. Здесь пригождается второй слой поверх того же диска — Nextcloud, поднятый на том же сервере и смотрящий на ту же папку с библиотекой через «внешнее хранилище» (External Storage).

Nextcloud даёт то, чего нет у голого SMB: веб-интерфейс с миниатюрами превью изображений и моделей (для многих форматов текстур превью строится автоматически), полнотекстовый поиск по именам файлов и — что особенно полезно для ноутбука — desktop-клиент с выборочной синхронизацией. Вместо того чтобы держать на ноутбуке копию всех 2 ТБ, вы отмечаете в клиенте только те подпапки, которые нужны для текущего проекта — например, набор текстур дерева и металла и пару HDRI, — и на диск ноутбука скачивается только нужный кусок, а не вся библиотека.

Логика простая: SMB/NFS — для быстрой прямой работы, когда канал хороший; Nextcloud с выборочной синхронизацией — для случаев, когда нужно взять с собой подмножество библиотеки offline или показать клиенту превью моделей без скачивания исходников. Оба варианта смотрят на один и тот же каталог на диске сервера, поэтому библиотека остаётся одна, просто с двумя разными способами до неё дотянуться.

Организация, метаданные и бэкап библиотеки

Перенос библиотеки на сервер — хороший повод один раз навести в ней порядок, а не просто переложить хаос с одного диска на другой. Практика, которая себя оправдывает:

• Фиксированная структура папок по типу ассета, а не по проекту: /models/mebel, /models/tehnika, /textures/pbr/metall, /textures/pbr/derevo, /hdri/interyer, /hdri/eksterer, /brushes/zbrush. Проектные сцены ссылаются на эту структуру, а не копируют файлы к себе.
• Единый формат именования файлов и версий — например, суффикс с датой или номером ревизии у обновлённых текстурных сетов, чтобы старые версии не перезаписывались молча.
• Отдельный каталог-снимок (thumbnail) рядом с тяжёлыми исходниками — многие 3D-пакеты и каталогизаторы (Bridge, встроенные браузеры ассетов в Blender и 3ds Max) умеют строить превью сами, но на сетевом диске это быстрее, если превью уже лежат готовыми файлами, а не генерируются заново при каждом открытии папки по сети.

Отдельный вопрос — бэкап. Годы собранной библиотеки — это невосполнимый актив: часть контента куплена на разных маркетплейсах и заново не соберётся за один вечер, часть — ваши собственные скан-текстуры и HDRI, снятые лично. Держать резервную копию библиотеки на том же сервере, где она хранится, — плохая идея: авария с диском или ошибка администрирования снесёт и оригинал, и бэкап одновременно. Базовый принцип независимого бэкапа — не хранить копию рядом с оригиналом — разобран в статье про типичную ошибку с бэкапом на том же сервере; для библиотеки ассетов он работает точно так же, как для любых других данных: нужен второй сервер, другой диск или холодное хранилище, куда копия синхронизируется по расписанию.

Частые вопросы