LINUX.ORG.RU

Что делать дальше с проектом?

 , ,


0

2

Здравствуйте!

Краткая предыстория. ОС FreeBSD, нет программы-рисовалки для создания 2D растровой анимации, быстрая оценка сложности реализации проекта и ... .
Итог: родил нечто (https://bitbucket.org/rndfax/sdp) - OpenGL программа с поддержкой (по крайней мере) планшетов Wacom. Писано на Си с классами, а то и хуже.
По сути, был вдохновлён программой Plastic Animation Paper (http://animationpaper.com/), но которая обладала фатальными недостатками.

Это нечто получилось в виде тестовой площадки (i.e. помойка) со следующими вытекающими:
1) из blender'а вытащил библиотеку GHOST (https://bitbucket.org/rndfax/libghost) - это как GLUT, только с плюшками. Пришлось, правда, отключить фичу drag-n-drop (кажись, она тянет за собой половину blender'а);
2) make происходит с информированием о том, сколько файлов осталось откомпилировать - реализовано через создание директории, которая используются в качестве лока (lock). cmake выводит информацию в процентах, я хотел такое же, но только на голом Makefile. Фигня, но прикольно;
3) есть слои, есть фрэймы, есть заливка, можно как-то рисовать.

На чём застрял.
Этот проект обладает фатальными недостатками:
1) нет GUI. А нужно выводить: слои, фреймы, инструменты и ещё всего разного полезного.
Пробовал CEGUI (http://cegui.org.uk/) и libRocket (http://librocket.com/). CEGUI - типа самая крутая вещь, которая может быть для создания GUI на OpenGL. Поднял, потом посмотрел, показалось, что шаг влево-вправо от стандартных вещей - всё, приехали. Чтобы сделать какой-то свой стиль нужно создать километровый файл с его описанием. Да, может быть, это есть неотъемлемая часть любого создания стиля. Но выглядит всё это устрашающе. Резюме: неосилил.
libRocket - HTML/CSS прямо в OpenGL. Но как оказалось, CSS совсем не тот CSS, который в интернетах, отсутствуют некоторые важные вещи, попытался их исправить и обнаружил, что там много нужно переписывать в самой библиотеки, а разработчики сказали типа «ну пока нам не надо, делать этого не будем» (https://github.com/libRocket/libRocket/pull/202).
Начал реализовывать свой вариант видения GUI для OpenGL (с некоторыми идеями из libRocket);
2) нет хороших кистей (brushes) для рисования. А по-хорошему нужно иметь в наборе простой карандаш, улучшенную версию того, какая сейчас кисть реализована (типа ручки что-ли), а так же smudge какой-нибудь tool (сейчас он есть, но, кажется, работает не так как надо) + lasso tool и трансформации выделенной области;
3) нет умной заливки. Те, кто пользуется GIMP'ом, наверное, заметили, что если что-то нарисовать, а потом залить, то возле контура останутся непрокрашенные части. Здесь у меня сейчас заливка умнее того, что в GIMP'е. У неё есть пороговое значение, когда нужно остановиться - простая константа. Но для решения задачи заливки нужна ещё более продвинутая логика - отслеживание прозрачности контура.

Почему свой проект-рисования-анимации.
1) PAP (http://animationpaper.com) - Windows/Linux/MacOS, больше не поддерживается, нет слоёв, ущербный карандаш, lasso-tool чрезмерно кривой, только контуры, ограниченное пространство для рисования (а у меня типа бесконечное). Из плюх: простота.
2) Pencil2D (http://www.pencil2d.org) - глючное поделие, страшный код (хотя чё я на него, смотреть что ли должен?), разработчик его куда-то делся, бесконечное пространство для рисования, но нет границ кадра (один дядька уже писал, типа не видно где начало, а где конец. Ответ был: «используй слой камеры для этого» или как-то так, что не подходит для нормального пользования). В топку такое.
3) Krita (https://krita.org) - в составе комбайна calligra, что под KDE. Заявлена поддержка анимации. Во FreeBSD поставил её, там ещё старая версия, анимации нет, но рисовать настолько неудобно, по сравнению с тем же PAP, что ну его нафиг. Так же очень перегружен интерфейс. Патчить KDE под FreeBSD у меня желания нет, потому что комбайн.
4) TVPaint (http://www.tvpaint.com) - платный (АРРРР, где мой попугай?!) комбайн для анимации. Нет бесконечного поля для рисования, перегружен настолько сильно, что всасывается сам в себя.

TL;DR
Имея у себя силы что-то делать, сделал инструмент, который, с точки зрения меня, является удобным и простым в использовании. Теперь, чтобы довести его до логического завершения, нужно восполнить его фатальные недостатки, и тогда можно будет показать его людям, вдруг кому-то он тоже покажется удобнее, чем XXX. Но как организовать работу? По реализации своего GUI есть вопросы. По реализации кистей есть вопросы. По вообще организации проекта есть вопросы. Но как их разрешить, если чтобы их задать, боюсь, понадобится столь же большой монолог, а то и больше?

OpenGL программа для рисования и при этом без гуя? Продай её в ближайший магазин курьёзов!

anonymous
()

Может, проще форкнуть гимп и изменить в нем то, что тебе не нравится. Возможно, так будет проще.

Aswed ★★★★★
()

Ненужно.

anonymous
()
Ответ на: комментарий от Krieger_Od

GIMP - для своей ниши. Опять же, для анимации, ИМХО, плох - ограниченное пространство для рисования, физика кистей не та, отрисовка не та, работа со слоями не та, странные выборы размера кистей (чуть ли не на миллион пикселей), код, ИМХО, в целом переусложнён, чтобы что-то кардинально изменять. Я его использую для пост-обработки.
Моё творение (в идеале) - это сделать всё просто для создания анимации и отчасти так, как мне видится этот процесс с наименьшим сопротивлением. Зашёл - рисуй, создавай кадры, потом крась - всё, готово. По сути, основной процесс сейчас схож с программом PAP - в правой руке стилус, в левой - клавиатура. Без отрыва левой руки с места и не откладывая стилус - можно создать анимацию.

kapitan-amerika
() автор топика
Ответ на: комментарий от Aswed

Я как-то даже не рассматривал подобного решения, потому что сам фундамент GIMP'а меня не устраивает. Он завязан на cairo, с помощью которого я сначала пытался сделать своё поделие, но наткнулся на то, что не могу сделать простую операцию (год назад было - не помню точно какую). Задал свой вопрос в мэйл-листе типа можно ли сделать так-то, в ответ тишина. Cложилось впечатление, что там всё заточено на решение конкретного круга задач. Шаг влево-вправо - стена.

kapitan-amerika
() автор топика
Ответ на: комментарий от buddhist

1) Разве оно не заточено под vector?
2) Смешные комментарии на youtube про Synfig Studio:

i tried using synfig......2 years ago and im still trying to figure it out.....i drew a dot

HUUUUUUUUGGGGEEE TIP: Do not get synfig...i know how to use it...but its hard to animate on it...for e.g. Make it so the whole body moves by changing frame by frame instead of using keyframes.

kapitan-amerika
() автор топика
Ответ на: комментарий от O02eg

GIMP в своём фундаменте не тот, что нужен. Поэтому плагины - тоже не подойдут.

kapitan-amerika
() автор топика
Ответ на: комментарий от O02eg

Бороться с тепловозом ехать не по рельсам, а по воде - чересчур накладно. Разработчики же преследуют некую свою цель и для определённого круга задач Synfig Studio идеален. А для задачи «открыл-тяп-ляп-кадр-за-кадром» - готовая анимация, он не очень.

kapitan-amerika
() автор топика
Ответ на: комментарий от kachan

Опа-опа: http://en.wikipedia.org/wiki/Make_(software)

GNU Make, BSD Make and Makepp can be configured to look first for files named «GNUmakefile»,[17] «BSDmakefile»[18] and «Makeppfile»[19] respectively, which allows one to put makefiles which use implementation-defined behavior in separate locations.

То есть можно сделать так, чтобы по make проект по-любому собирался, будь то линукс система или бсд.

kapitan-amerika
() автор топика

ОС FreeBSD, нет программы-рисовалки для создания 2D растровой анимации

Где ты такую траву забористую берешь?

peregrine ★★★★★
()
Ответ на: комментарий от kapitan-amerika

cairo

А ты документацию по нему читал? Вообще cario надо не в рассылке gimp-а изучать, это отдельный проект.

peregrine ★★★★★
()
Ответ на: комментарий от kapitan-amerika

Рано тебе софт (тем более рисовалку) писать, там программирование не самое тривиальное. Начни с крестиков-ноликов/калькулятора e.t.c. Подскажу, что GNU Make - прошлый век, его везде стараются выпилить и потихоньку проекты переходят на другие программы сборки, а новый софт вообще почти GNU Make не использует. Почитай про cmake.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

Напомнило как в анекдоте: «Это не трава, это глаза надуло» - придумал хитрый план мотоциклист...

kapitan-amerika
() автор топика
Ответ на: комментарий от peregrine

Может быть не так тщательно, как нужно было бы, но вообще да, читал.

Вообще cario надо не в рассылке gimp-а изучать, это отдельный проект.

Спасибо, капитан!

kapitan-amerika
() автор топика
Ответ на: комментарий от peregrine

Совет был бы дельный, если бы он был подкреплён аргументами на утверждение

Рано тебе софт (тем более рисовалку) писать ...

Почему? На чём основано это утверждение? На что мне обратить своё внимание? Я же как раз и пришёл сюда за тем, чтобы меня носом ткнули в косяки.

Подскажу, что GNU Make...

Спасибо, конечно, но причём здесь GNU Make?

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

kapitan-amerika
() автор топика
Ответ на: комментарий от kapitan-amerika

Почему? На чём основано это утверждение? На что мне обратить своё внимание? Я же как раз и пришёл сюда за тем, чтобы меня носом ткнули в косяки.

Не знание матчасти по программированию в целом и программированию в Linux в частности. Правда может это мне только кажется... Но похоже.

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

Cmake для того и сделан, чтобы некроссплатформенные скрипты для сборки не велосипедить.

peregrine ★★★★★
()
Ответ на: комментарий от kapitan-amerika

Вот я не знаю, будет ли целесообразно тащить для такой простой задачи целый cmake?

ты все правильно делаешь. не слушай фанатиков.

waker ★★★★★
()
Ответ на: комментарий от waker

По-моему новые проекты на make пишут именно фанатики. Разве нет? Тем более, что человек ещё какие-то прогрессбары делает на make. Жесть.

anonymous
()
Ответ на: комментарий от peregrine

Не знание матчасти по программированию в целом и программированию в Linux в частности.

Что ты такого увидел из моей писанины, что сподвигло тебя составить такое предложение? Конкретно можешь показать? Ткни же меня носом уже! :)

Правда может это мне только кажется... Но похоже.

Ну ё-моё.
- Мужчина, вы выходите?!
- Кажется, нет. Но похоже!

kapitan-amerika
() автор топика
Ответ на: комментарий от anonymous

Что значит тащить? Поставить пакет в систему? Или что?

Да, именно. «тащить» в значении «поставить пакет в систему».

kapitan-amerika
() автор топика
Ответ на: комментарий от anonymous

По-моему новые проекты на make пишут именно фанатики.

А если рассмотреть пример, где «проект» - это 5 + пара заголовочных файлов, которые нужно откомпилировать, то для этого тоже без вопросов просто брать cmake и не париться, как считаете?

Тем более, что человек ещё какие-то прогрессбары делает на make. Жесть.

Мне было интересно сделать прогрессбар на make. Получил уйму удовольствия, когда всё получилось как надо!

kapitan-amerika
() автор топика
Ответ на: комментарий от waker

а по-моему, каждый использует то, что ему удобно ...

И ведь это может плохо сказаться на последующем использовании уже другими людьми, потому что «на вкус и цвет ...». Вот удобно, например, человеку использовать scons, а у меня в системе нет ни питона, ни, соответственно, самого scons'а. Теперь, чтобы мне собрать его проект, необходимо «тащить» целый python. Не, понятно, что «что тут сложного выполнить команду apt-get install scons?». Но что если система админится кем-то другим, а ты там обычный пользователь? Тогда да, писать админу. Но. Были казусы, когда для сборки проекта необходим был Autotools (например, 1.14). На системе установлен CentOS и для неё доступен пакет, например, только версии 1.9. (вопрос в зал) Что делать в таких ситуациях?

Вот make - это стандартно. Но, к сожалению, зоопарк всё же есть: GNU-синтаксис и BSD-синтаксис.
cmake - нечто стороннее, полезных фич по самое не могу. Но если он есть в системе, то не факт, что нужной версии. То есть получаем, что для cmake-based проектов может понадобится несколько установленных cmake-ов разных версий. Вот что пишут сами авторы (http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix):

... not only look out for changes in the API, but also consider changes in behavior between different versions of CMake.

Однако ещё получается нетривиальным написание правил сборки.

kapitan-amerika
() автор топика
Ответ на: комментарий от waker

Конечно, каждый пишет на чем удобно. Просто объективно на голом make писать дольше и тяжелее, чем на более дружественных системах. Боюсь, что именно make используют из-за отсутствия знаний о других утилитах и/или желания развиваться. Я не конкретно cmake предлагаю, просто что-то попроще в использовании, чем make.

anonymous
()

Что делать

сделай бочку

Deleted
()
Ответ на: комментарий от anonymous

Разве это проблема?

Выше я расписал, в каких ситуациях это может быть проблемой.

Зато не надо мучаться и прогрессбары пилить свои.

Хоспади, что тебе этот прогрессбар покоя не даёт? :)

kapitan-amerika
() автор топика
Ответ на: комментарий от kapitan-amerika

Писано на Си с классами, а то и хуже.
Пробовал CEGUI (http://cegui.org.uk/) и libRocket (http://librocket.com/). CEGUI - типа самая крутая вещь, которая может быть для создания GUI на OpenGL. Поднял, потом посмотрел, показалось, что шаг влево-вправо от стандартных вещей - всё, приехали. Чтобы сделать какой-то свой стиль нужно создать километровый файл с его описанием. Да, может быть, это есть неотъемлемая часть любого создания стиля. Но выглядит всё это устрашающе. Резюме: неосилил.
Начал реализовывать свой вариант видения GUI для OpenGL (с некоторыми идеями из libRocket);

А вот и велосипедостроение

Ну да ладно, есть ещё 3 вещи, которые кажутся мне странными: вместо поддержки готового проекта писать свой (ну да ладно, может там код плохо документирован или архитектура плоха, а может нет желания копаться в чужом коде или хочется свой написать). Как мне кажется - переоценка своих сил. Написать более-менее приличную рисовалку анимации одному, на крестах быстро не получится. А теперь - самое главное, в школах каникулы и что мы имеем: человека, который собрался написать супер-пупер рисовалку (круче гимпа), на крестах, не справившись с Cairo. Самому то не смешно?

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

А вот и велосипедостроение

Да неужели? А то, что я расписывал, что мне не понравилось во всём другом - это мы уже не учитываем?

Ну да ладно, есть ещё 3 вещи, которые кажутся мне странными: вместо поддержки готового проекта писать свой (ну да ладно, может там код плохо документирован или архитектура плоха, а может нет желания копаться в чужом коде или хочется свой написать). Как мне кажется - переоценка своих сил.

Ну это ради бога, кажется тебе, так и пусть.

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

Мне не горит.

А теперь - самое главное, в школах каникулы и что мы имеем: человека, который собрался написать супер-пупер рисовалку (круче гимпа), ...

Э, алё! А ну-ка, покажи, где это я говорил, что собрался написать супер-пупер рисовалку, да ещё которая круче гимпа! Не п*зди тут.

Ты вообще в курсе что это за тема? Начальный пост читал? Хоть ту секцию с TL;DR почитай что ли, взрослый ты наш. Специально для тебя скажу прямо: программу я уже себе создал. Всё работает как мне надо.

kapitan-amerika
() автор топика
Ответ на: комментарий от kapitan-amerika

Почему свой проект-рисования-анимации.
1) PAP (http://animationpaper.com) - Windows/Linux/MacOS, больше не поддерживается, нет слоёв, ущербный карандаш, lasso-tool чрезмерно кривой, только контуры, ограниченное пространство для рисования (а у меня типа бесконечное). Из плюх: простота.
2) Pencil2D (http://www.pencil2d.org) - глючное поделие, страшный код (хотя чё я на него, смотреть что ли должен?), разработчик его куда-то делся, бесконечное пространство для рисования, но нет границ кадра (один дядька уже писал, типа не видно где начало, а где конец. Ответ был: «используй слой камеры для этого» или как-то так, что не подходит для нормального пользования). В топку такое.
3) Krita (https://krita.org) - в составе комбайна calligra, что под KDE. Заявлена поддержка анимации. Во FreeBSD поставил её, там ещё старая версия, анимации нет, но рисовать настолько неудобно, по сравнению с тем же PAP, что ну его нафиг. Так же очень перегружен интерфейс. Патчить KDE под FreeBSD у меня желания нет, потому что комбайн.
4) TVPaint (http://www.tvpaint.com) - платный (АРРРР, где мой попугай?!) комбайн для анимации. Нет бесконечного поля для рисования, перегружен настолько сильно, что всасывается сам в себя.

Ты думаешь, что сможешь лучше?

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от peregrine

можно подумать, что никто и никогда не создавал программ лучше, чем перечисленное. с чего ты взял, что он не сможет? было бы желание, и мозги. а если думать как ты — типа «не, я такое не смогу» — то конечно не сможешь.

waker ★★★★★
()
Ответ на: комментарий от kapitan-amerika

Специально для тебя скажу прямо: программу я уже себе создал. Всё работает как мне надо.

Думаешь я её не смотрел? Да, похоже школу ты окончил, но ВУЗ врядли, ибо вот почитай свой код тут, тут и тут.

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

Теперь прямой ответ на то, что делать: писать комментарии. Со временем, если ты не забросишь проект, то всё обрастёт большим количеством кода и ты в нём просто утонешь, когда у тебя на весь код 5-6 комментариев.

peregrine ★★★★★
()
Ответ на: комментарий от waker

У него нет желания. Было бы желание, он бы знал чего хочет и не приходил бы на ЛОР с вопросом: Что делать? А просто бы делал это.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

Ты думаешь, что сможешь лучше?

«Лучше» - это как судить о красоте. Я перечислил недостатки программ, из-за которых мне не удобно ими пользоваться. И притом уже говорил:

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

То есть по сути я _уже_ сделал лучше. Но это «лучше» чисто с моей точки зрения. Вопрос твой не имеет никакого смысла.

kapitan-amerika
() автор топика
Ответ на: комментарий от peregrine

Я не верю своим глазам! Ты ли это? Неужели ты сказал впервые что-то по делу?!

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

Но всё равно, слабенько. Кроме «магических чисел» и сказать больше нечего? Всё это можно было бы сказать: «Вот тут-то и тут-то у тебя стоят числа. Замени на константы, чтобы можно было видеть их смысл». Да я бы тебе спасибо сказал тут же!

Вот! Это действительно дельный совет:

Теперь прямой ответ на то, что делать: писать комментарии. Со временем, если ты не забросишь проект, то всё обрастёт большим количеством кода и ты в нём просто утонешь, когда у тебя на весь код 5-6 комментариев.

За него тебе реальное спасибо. Всегда бы ты так говорил - нейтрально и обоснованно - цены бы тебе не было.

kapitan-amerika
() автор топика
Ответ на: комментарий от peregrine

У него нет желания. Было бы желание, он бы знал чего хочет и не приходил бы на ЛОР с вопросом: Что делать? А просто бы делал это.

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

kapitan-amerika
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.