|
FROSTY. Специализированный САПР 3D для мебели.
| |
| Тяп_Ляпыч | Дата: Среда, 30 Сентября 2020, 00:27 | Сообщение # 1 |
был не раз
Сейчас нет на сайте
| Жанр: 3D САПР
Пространство: 3D для разработки модели изделия, и 2D для подготовки документации.
Вид: меняется (аксонометрия/чертежные виды/перспектива). Основное время пользователь проводит в окне 3D View.
Описание (Сюжет): Моим коллегам хорошо известно чувство реактивной тяги в районе задницы, возникающее в тот момент, когда приходится в тысячный раз воспроизводить одни и те же рутинные задачи. Или когда софт тупо дропается, без объяснения причин. Или когда приходится рисовать ручками то, что легко можно было бы сделать автоматически. Задумка данного проекта в том, чтобы охладить себе, и коллегам, реактивные двигатели. А воспламеняются они, я вас уверяю, почти ежедневно.
1. Кто главный герой Вашей истории?
Сотрудники мебельных компаний. В первую очередь конструктора, и сотрудники цеха, работающие по конструкторской документации(далее КД) В перспективе можно охватить компанию целиком, от дизайнера, и до монтажника на адресе.
2. В чем основной конфликт истории?
Рынок специализированного САПРа очень узкий. На данный момент, в СНГ есть один почти монополист, и еще несколько придатков, не принципиально от него отличающихся. В итоге монополист выставляет ценник, за пакет на одного конструктора, эквивалентный стоимости ZBrush. При этом зебру не назвать забагованной, и прямо скажем, может она очень много чего. Тогда как наш пациент разваливается на ходу. То функцию или комаанду не забиндить на горячие клавиши, то одна из базовых функций отвалится, то ошибка в логике вычисления пролезет, то и вовсе, "вот тебе полезная функция, но пользоваться ты ею не сможешь, потому как мы её не допилили, и допиливать не будем.", потому как задача была не в том, чтобы тебе жизнь упростить, а в том, чтобы была красивая плашка в названии, с которой мы твоему нанимателю продадим и наш кусок софта, и сверху еще три курса обучения, сопоставимые по цене с самим софтом. Следом встает второй конфликт истории! Софт делали программисты, для программистов. Программисты - клевые ребята, кто б спорил. Но когда они дают конструкторам софт, а те, интерпретируют, в меру своей испорченности, и передают документы в цех, из цеха начинают выпадать рабочие, с синими экранами смерти на лицах, и звуком тонового модема. Оно конечно весело, но это время и деньги. Как разрабы умудряются игнорировать фидбеки, и не угадывать с решениями я без понятия, но по оконцовке есть много всякого, но оно либо не работает вообще, либо работает криво. Если говорить не про монополиста, то там либо аналогия, либо универсальные САПРы, которые адски не удобны для узких задач. Оно и понятно, они не для этого.
3. Какая у главного героя (злодея или тп) цель?
Тут, я думаю, лучше описать цели самого софта. А цель можно выразить фразой: "освободить людей от рутинных задач."
Как именно это сделать?
1.В основу концепции ложится принцип матрешки. Дело в том, что вся мебель состоит из блоков, блоки из других блоков и т.д. Например, кухня состоит из модулей, модуль состоит из самого корпуса, и ящиков, ящик состоит из деталей корпусных, и фурнитурных, фурнитурные детали тоже состоят из составляющих, и так до последнего самореза. Так вот смысл тут в том, чтобы блоки были взаимосвязаны, как матрешка. Нельзя упихать большую матрешку внутрь маленькой. Аналогично нельзя упихать ящик глубиной 500мм, в модуль 400мм. Весь фокус в том, что у каждого блока есть свои, присущие ему свойства, которые современные САПРы вообще никак не учитывают. Например, глубина ящиков идет с шагом в 50мм. При редактировании глубины модуля ящик будет изменен линейно. Пропустил этот момент - ошибка. Не пропустил, но не заменил наименование фурнитуры - ошибка. А каждая ошибка - это деньги. Принцип матрешки должен учитывать этот момент, и в автоматическом режиме, при изменении блоков более старшего уровня, замещать компоненты более младших уровней, согласно типу блока, и допустимым параметрам. Иногда бывает надо обойти такие ограничения, но это происходит раз в год от силы, а те же ящики штампуются, порой, по три заказа в день.
2. Система нодов. Каждый заказ, это не просто набор деталей, а совокупность модели, входящей и исходящей документации. Алгоритмы образования документации очень сильно разнятся от фирмы к фирме. Задача САПРа помочь в оформлении, на основании заранее заданного конструктором шаблона. Залил в редактор входящие, в нем же подредактировал, если нужно (сноски, правки размеров дизайнера, и т.д.), сформировал модель из сетки блоков, сапр сам сформирует пакеты документов по заранее заданным шаблонам, выведет на печать для проверки, а затем сам распихает по нужным папкам. О да, распихивание по папкам ничего не забыв и не перепутав - это особая история.
3. На этом пункте я, пожалуй, остановлюсь, дабы не разматывать полотенце текста. Пунктов еще очень много. Начиная с того, что необходимо сделать документы в печати читабельными (сейчас шрифты меньше 1мм после печати надо ручками править), через необходимость изобразить внятные схемы сборки, настраиваемые, по принципу матрешки документы, т.к. чертежный штамп стремительно устаревает, и заканчивая подключением графического планшета, для быстрой отрисовки простых моделей, создания набора инструментария для дизайнеров (да, с дизайнерским софтом тоже все очень тухло), создания приложения для замерщика, которое позволило бы не читать его чудесный почерк всем коллективом, а ему не рисовать ручкой на бумаге помещение, и т.д. по списку. Там поля не паханные идут далеко за горизонт.
4. Препятствия, с которыми он столкнется на пути к достижению цели
Тут тоже скорее не про ГГ, а про проект. Препятствия тривиальны. Все новое всегда сталкивается с сопротивлением старого. По началу будет адски тяжело. Слепить быстренько проходняк тоже не получится. Финансировать это на данный момент некому и нечем. Проект с одной стороны сложный, с другой, это работа на долгие годы. Мебельный рынок обвалить может только война, или другое механическое уничтожение мебельных фабрик. Даже не смотря на эпидемию, и незначительную просадку, сам рынок никуда не делся. Однако в долгосрочной перспективе, даже война не смертельна. После войны люди несут мебель в восстановленные дома. Основной сложностью, на мой взгляд, станет выведение продукта на прибыль, которая сможет кормить костяк коллектива разработки.
А ВЫ, простите кто, и зачем ВЫ в этом проекте?
Это типичный вопрос, под подобными постами. Я конструктор! В 04-08 году закончил столярку, и с тех пор занят в мебели. Попилил, покромил, пособирал, поконструировал. В виду этого имею представление о конкретном потребителе этого софта. Знаю что где и как должно работать. Имею возможность позвонить некоторым директорам и конструкторам, и предложить Frosty, в формате "привет, как жиза молодая? Я тут с другом программульку собрал для конструкторов. Дай своим на обкатать, обратная связь нужна". Плюс, когда руководители фирм начнут разговоры в духе: "ну вы понимаете, у нас заказная мебель, прифуговки, заказные ножи, и вообще 3D фрезеровками с пятью осями балуемся". У меня найдется технически обоснованный аргумент в нашу пользу. И в конструкторской документации, если потребуется, я тоже могу разобраться. Да, это не ракеты строить, но как показала правктика, конструкторам планетарных редукторов, и двигателей речных судов, мебель не по зубам. Сам удивился, но есть такое наблюдение.
Почему ты решил, что это получится? Может это никому не надо?
Еще как надо! Еще как получится! Начнем с того, что это надо мне, а я как раз и есть целевая аудитория. Фраза "удали свой "не будем называть бренды", поставь вот это, и работай с каефом" убедит как минимум троих коллег, с которыми я работал, пристально изучить предложенный вариант.
Что же до вопроса получится или нет, в действительности я ничего нового не придумал. Я просто взял то, что было написано в учебниках технологии мебельного производства годов этак 70-80х, и применил к этому современные технологии, и адаптировал под сегодняшнюю действительность. Делал ли кто-то так до меня? Странно, но нет. Все имеющиеся творцы САПРа наглухо отрицают технологический опыт производства времен СССР, и изобретают велосипед. Возможно это связано с тем, что все они произрастают из начала 90х, сложно сказать, почему так. Я имел удовольствие наблюдать, как в производство внедрялись некоторые административные наработки времен советов. Работает очень не дурно. Аналогичным путем движется Николай Пак, владелец франшизы "Лига роботов", и человек озадаченный вопросами автоматизации производств.
На чем будем разрабатывать?
Это однозначно свой движок. Специфика САПРов такова, что игровые движки не подойдут. Язык разработки, в моем представлении, C++. Возможно имеет смысл использовать OpenGL. Однако, это не принципиально для меня, и этот момент подлежит обоснованному обсуждению.
Как быть с пиратством?
Вшить в движок рандомайзер, включающийся при отсутствии отклика от стима. Суть в том, что он тупо добавит от -10 до 10 к каждому размеру, при формировании карт раскроя, и карт кромления. После таких приколов, скачаивание пиратки будет бессмысленным. Проверка и правка таких значений вызывет адскую душевную боль, даже у самого крепкого человека. А если движок еще и рандомно материалы из базы перетряхнет, то вообще можно пойти и удавиться. Но для ознакомления прога все еще остается пригодной. Ну а если рандомайзер отключен, то весь движок работать откажется. Предполагаемый основной конкурент платит конские суммы за USB ключик. Который бесит, а еще конструктора его порой приворовывают. Потерять 80к ру-рублей для фирмы потому, что разработчик хотел защитить свой софт от взлома - это не дело. Не наш метод. В любом случае этот момент обсуждаемый. Просто привел размышление на тему.
Как продавать?
Через стим. По подписке на месяц. 2 часа каждый месяц даром (для студентов и ознакомления) а дальше подписка на 31 календарный день, или больше. Фирмы находят денег на такие нужные вещи, как присадочные станки, CRM системы 1С системы и т.д. на конструкторский, а позже общий по фирме, софт найдут. Главное наглядно показать, что оно того стоит! Да, онлайн нужен всегда, но сегодня это уже не такая большая проблема.
Что будем делать по этапам?
1. Собрать Frosty-R. Софтина для раскроя методом ввода размеров деталей, указания кромки, пазов и т.п., и вывода пакета бумаги на все это добро. Тут важно сделать программу всеядной. Есть разные способы, как делают раскрои, но транзитным обычно выступает Excel документ. Разный софт формирует документ по-разному. Надо научить софтину считывать эти данные, и корректно отображать. Это даст первый плацдарм. Там много тонкостей, не буду углубляться сейчас.
2. Собрать первый образец основного Frosty. Начать с простой утилитки для деталировок, и дальше развивать по нарастающей. Тут особое внимание на исправность вычислений, на удобство пользования. Особо пристально на горячие клавиши. Эталоном можно считать Blender 3D, по горячим клавишам. Пользователь, зачастую, простит нам недобор функционала, если основной функционал не ломает глаза, и бережет нервы. Конструкторам не привыкать идти на компромиссы. Разумеется, весь функционал поэтапно добавляется, месяц за месяцем.
3. По мере того, как основной Frosty крепнет, с определенного момента начинаем интеграцию функционала для дизайнера. Картинка не обязана быть фотореалистичной, но она должна быть красивенькой. Её показывают заказчику, а заказчик любит красивенькое. При этом, Frosty должен дать дизам простой функционал редактирования, для молниеносной правки. Дизы очень много правят, это надо учитывать. Далее, важно дать хороший функционал вывода на печать, для подписи. Чтобы заказчик подписал красивенькие и понятные ему документы. При этом надо помнить, что диз - это девочка, у которой нет задачи знать много кнопочек, у нее задача - нести в фирму много денежек. Поэтому интерфейс должен быть одноклеточным, и только при крайней надобности разворачиваться в глубину. Этот фрагмент программы должен продавать! В самом прямом смысле! Разумеется у меня есть представления о том, как это должно выглядеть в итоге. Но не буду грузить. Модуль этот тоже не за день строится,
4. Далее добавляем блок функционала для отделов закупки. Тут уже не так трудно, на фоне двух предыдущих. Исходя из пакетов документа конструктора и дизайнера, нужно сформировать списки в закупку. Тут надо дать логистам и закупщикам возможность выстроить шаблон заполнения документов в закуп. Сейчас они ручками переписывают циферки. Потому как у всех контор поставщиков есть свои формы подачи заявки на закупку, или изготовления.
5. Доп приложение на смартфоны и планшеты, которое сможет распознавать углы и плоскости в помещении, и отрисовывать по ним схему в телефоне. В этой схеме замерщик сможет поправить то, что считалось не корректно, добавить размеры, сноски и т.д. По этому пункту есть ряд соображений, но я еще не продумывал его так основательно, как предыдущие. Почва хорошая, но есть над чем помозговать.
6. Приложение для выездных дизов на смартфон. Задача данного приложения - дополнить реальность в помещении шкафом. Сейчас доходит до маразма. Очень дорогие дизы привозят с собой бригаду грузчиков, и таскают по дому заказчика макеты мебели. Само собой, это не дешево, и доступно далеко не всем. Описанное приложение позволит любому дизайнеру освоить его, и прямо на месте показать заказчику как будет выглядеть его мебель. При этом яркость образа только выиграет!
7. Блок функционала для руководящего состава. Нечто отдаленно похожее на CRM системы, но касающееся не столько ведения сделок, сколько ведения хозяйственной части. Если прям совсем кратко, то он позволит оценить сроки, пропускные способности станков, и составить ясную картину о том, какие места работают хорошо, а какие требуют наладки, или докупки оборудования. Тема сложная и обширная, грузить сейчас не буду.
8. Дополнительное усиление. В настоящее время, тенденция идет к тому, что заказы будут кроить удаленно. Имеющийся на рынке софт этому мешает, т.к. делает не понятные рабочим документы, возникают вопросы, и технари должны сидеть на производстве. Однако прогресс идет своим ходом, не обращая внимание, на такие пустяки. В виду этого будут образовываться мелкие КБ, которые раскроят ваш заказ за деньги. Точнее они уже появляются, но пока они еще достаточно эфимерны. Еще не сформировался этот рынок. Я думаю, что организовать такое КБ, прям при отделе разработки, это не только не плохое финансовое усиление, но и отличный способ самим испытать свой же продукт в деле. Пороха, патрончиков, толщины кишок, и опыта у меня на такое КБ хватит, т.к. опыт управления парой конструкторов есть.
Кого я ищу?
Нужен 1-2 программиста энтузиаста. Строго 21+, точно съехавший, или уже прошедший через ВС. Пол не важен. Приоритет Санкт-Петербург. Есть верифицируемый опыт - плюс в карму. Самодисциплина должна быть железной. Ходить и уговаривать работать и заработать - не в моем стиле. Я больше склонен пригласить одного кодера, но если аргументированно будет разобрано почему нужно два, то ок, не вопрос, я не жадный. По шкуре не убитого медведя, 51/49% или 34/33/33%, с правом моего последнего слова. Да, я не жадный, но опыт показывает, что во-первых, чем меньше владельцев, тем бодрее они пашут, а во-вторых, если доли поровну, то лебедьракощук будет, а не Змей Горыныч, а это не является искомым результатом. Разумеется, когда проект станет окупаемым, программисты будут наниматься за зарплату, а не за долю. Равно, как и все остальные сотрудники. Я бы и сейчас так поступил, но собирать на кодера буду не реально долго. Зарплаты конструторов поменьше, чем у программистов. Плюс проект подразумевает, что должен быть, как минимум, один программист на долгие годы. Сразу оговорюсь, что проект не подразумевает всемирной славы. Максимум потянет на статус "широко известный, в узких кругах". Ну и прибыли пропорционально. На стометровую яхту точно не хватит.
Риски
Зная специфику, я понимаю, что скорее всего будет поднят вопрос в духе "А с чего бы кодеру так много работать, не получая зарплаты? а вдруг не взлетит? Это же большой риск выкинуть время!". Согласен, работа большая. Я бы сказал - огромная. И риск большой. Но за большой риск, подразумевается приличный профит. И тут уже каждый сам решает, какая тактика по жизни ему ближе, минимального риска, или таки вписаться в блудняки, чтобы попытаться ухватить судьбу за жабра. Сам я исповедую тактику минимального риска, и влезаю в блудняки только в том случае, если вероятный куш заметно перевешивает весь тот головняк, который меня ждет по дороге. Собственно, по этому принципу я построил карьеру от подсобника, до конструктора. В данном случае, куш достаточно велик, чтобы я зашевелился. Пойти со мной по этому пути, или нет - дело каждого. Мне же нужен попутчик, и потому я тут.
В качестве заключительного слова.
Если вдруг, кого заинтересовал проект, и хотите поучаствовать, пишите на почту spbmebelmaster@gmail.com В заглавии укажите FROSTY, чтобы я вас точно заметил. Почта рабочая, наваливают туда ежедневно и много.
Если у кого есть содержательные замечания, или советы, по части где лучше искать программиста, как лучше организовать процесс, и т.п. рекомендации, связанные с опытом разработки, то буду рад почитать.
Спасибо, что прочитали до конца!
Для модератора
Технически, это не игра, и отношение с геймдевом тут крайне отдаленное. Однако, по сути, это разработка движка, и 3D софта на нем. Я почесал репу, и решил, что таки тема должна быть в этом разделе. Если не прав - поправьте. Благодарю, за понимание!
Аскетизм - наше всё!
|
|
|
| |
| manonedge | Дата: Воскресенье, 11 Октября 2020, 21:02 | Сообщение # 2 |
|
почетный гость
Сейчас нет на сайте
| Написать нормальный редактор, со всем его функционалом (базовым: все эти 3D/2D операции, работа с сущностями объектов, форматы хранения проекта сохранения-загрузки, очереди Undo-Redo, интерфейсы, инструменты и небазовым: всё, что непосредственно в специфику мебели) у пары разработчиков на фултайме уйдет год-два, после чего надо еще тестить, работать в этом, и продолжать допиливать под клиентов и перепиливать под хотелки, делать импорты, экспорты.
При том программисты для написания такого с нуля, должны быть не студенты 21+, а дяди с опытом 10+. Потому что надо еще уметь правильно заложить архитектуру проекта, использовать правильные технологии и как минимум иметь опыт работы в таких средах или с такими проектами.
Зарабатывайте деньги, создавайте свою компанию разработчиков, и платите им зп, контроллируя разработку.
|
|
|
| |
| Тяп_Ляпыч | Дата: Четверг, 15 Октября 2020, 02:12 | Сообщение # 3 |
|
был не раз
Сейчас нет на сайте
| Пожалуй таки соглашусь. Однако зарабатывая деньги, проще свалить в программирование на юньке, и забыть нахрен про мебель, как про кошмарный сон.
Наверное, это будет оптимальным решением, в моей ситуации. Ну а коллегам, могу только посочувствовать.
Аскетизм - наше всё!
|
|
|
| |
|
