Русский
Русский
English
Статистика
Реклама

Работа с векторной графикой

Перевод Motion Path введение в современные анимации

07.07.2020 00:22:55 | Автор: admin


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


Для того чтобы выполнить подобные пожелания, актуальные для современного мира веб-разработки, CSS-модуль Motion Path Module Level 1 дает возможность использовать абсолютно новый вид анимаций и позволяет перемещать HTML-элементы по заданной траектории.


Поддержка браузерами


Начнем с неприятных моментов. Придется огорчить поклонников Safari (OS X и iOS) и Internet Explorer (если таковые остались): свойства модуля Motion Path пока не поддерживаются всеми браузерами.


Однако на момент написания данной статьи около 75% посетителей вашего сайта имеют возможность насладиться этой современной технологией.


Обратите внимание, что данный тип анимаций лишь приятное дополнение. Он не является необходимым с точки зрения восприятия контента и опыта взаимодействия пользователя с вашими веб-интерфейсами.

Data on support for the css-motion-paths feature across the major browsers from caniuse.com

Свойства модуля Motion Path


При реализации анимаций задействуются три механизма:


  • определение траектории движения элемента (за это отвечает свойство offset-path),
  • определение положения элемента на траектории (свойство offset-distance)
  • и ориентация элемента во время движения (свойство offset-rotate).

offset-path


Это наиболее значимое свойство из перечисленных. Оно может принимать несколько значений: path(), ray(), url(), circle(), polygon(), inset(), и none.


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

Синтаксис значений offset-path заимствован из языка разметки SVG. Поэтому чтобы освоить анимации, рассматриваемые в данной статье, нужны базовые знания SVG или опыт работы с редакторами векторной графики.


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


Вот пример квадратной траектории, по которой будет двигаться div.


div {  offset-path: path('M10 10 H 180 V 180 H 10 Z'); /* квадратная траектория */}   

Цель данной статьи не изучение SVG, а чтобы подробнее узнать об используемом здесь синтаксисе можно прочитать замечательный перевод статьи с СSS-Tricks на сайте la Cascade (перевод на русский прим. пер.) или подробное руководство на MDN.

offset-distance


Что касается свойства offset-distance, оно определяет положение элемента на заданной траектории. Его значение может быть выражено в любых стандартных единицах (пикселях, rem, процентах и т.д.). Свойство представляет особый интерес, когда требуется реализовать анимацию движения объекта по определенному пути.


div {  animation: move 1s; /* анимация "move" будет длиться 1s */}@keyframes move {  0% {     offset-distance: 0%; /* стартуем в начале траектории */  }  100% {     offset-distance: 100%; /* и прекращаем движение в конце траектории */  }}

Смотрите демо на CodePen:





offset-rotate


И наконец, третье свойство модуля, offset-rotate, определяющее ориентацию объекта на изогнутых участках пути.


Принимаемые значения:


  • auto (значение по умолчанию): ориентация объекта совпадает с направлением участка траектории, на котором он находится. Чаще всего требуется именно это значение.
  • reverse: объект также будет менять ориентацию в зависимости от направления, но при этом будет развернут на 180 вокруг своей оси, то есть все время будет двигаться задом наперед.
  • auto Xdeg (или reverse Xdeg): ориентация объекта будет отклоняться от кривой движения на угол X.

Смотрите демо:





Визуализация траектории


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


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


path() или пропал


Вспомним квадратную траекторию, по которой движется div:


div {  offset-path: path('M10 10 H 180 V 180 H 10 Z'); /* квадратная траектория */}

Наша задача в точности воспроизвести этот же путь в SVG, потому что только так он станет видимым.


В языке разметки SVG путь можно отрисовать с помощью элемента svg со вложенным path, который в свою очередь имеет атрибут d


Таким образом, в SVG у нас получается следующий код:


<svg ...>    <path d="M10 10 H 180 V 180 H 10 Z" fill="none" stroke="gray" /></svg>

Обратите внимание, что большинство значений атрибутов SVG меняются с помощью CSS, так что можно сократить код:


<svg class="svg-path" width="200" height="200" xmlns="http://personeltest.ru/away/www.w3.org/2000/svg">  <path d="M10 10 H 180 V 180 H 10 Z"></svg>

А в таблице стилей будет следующее:


.svg-path {  stroke: gray;  stroke-width: 4;  fill: none;}

Накладываем видимый путь на траекторию


На втором этапе необходимо спозиционировать относительно друг друга все необходимые элементы. А именно нам понадобится:


  • немного CSS-кода, чтобы отобразить путь с помощью path (это мы уже сделали),
  • объект, перемещающийся по своей траектории с помощью свойства offset-path (это тоже готово),
  • контейнер-обертка, относительно которого можно спозиционировать элементы с position: absolute.

А если конкретно, нам нужен следующий код:


<div class="motion-container">  <svg class="svg-path">    <path>  </svg>  <div class="motion-object"></div></div>

И, соответственно, такой CSS:


/* обертка для .svg-path */.motion-container {  position: relative;}.svg-path {  position: absolute;  left: 0;  top: 0;}




Усложняем анимации


Предполагается, что по прочтении этого небольшого руководства вы уже сможете создавать продвинутые CSS-анимации.


Единственное, что вас может в этом ограничить, это ваше воображение. Ну и, конечно, желание рисовать SVG. C последним вам помогут различные SVG-редакторы. Например, значительно облегчить жизнь могут Sketch или Inkscape.


Также с этой задачей отлично справится онлайн SVG-редактор Method Draw.


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



Смотрите демо на CodePen:





И немного к вопросу о доступности веб-контента


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


Рассмотрим существующие подходы к данному вопросу.


  1. Согласно одному из стандартов RGAA 4 длительность анимации не должна превышать пяти секунд, либо необходимо предоставить возможность включить анимацию и поставить ее на паузу или развернуть/свернуть блок с контентом. В ином случае контент должен быть неподвижным. (По поводу стандартов WC3 по обеспечению доступности веб-контента см. следующий обзор и его перевод. Прим.пер.)
  2. Медиа-запрос prefers-reduce-motion позволяет учитывать предпочтения пользователей в вопросе анимаций, принимая в расчет индивидуальные настройки.

Несколько демо и заключение


Чтобы вызвать у вас желание поэкспериментировать с модулем Motion Path, я подготовил на CodePen подборку демо, которые у меня получились лучше всего:



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


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

Подробнее..

Нативный способ покрасить SVG-иконки

22.07.2020 18:16:54 | Автор: admin
Когда вам нужна возможность менять цвет иконок через CSS, что вы делаете? Вариантов не так много.

Обычно используются либо шрифты иконок, либо исходный код SVG скачивается и вставляется в HTML вручную. Шрифт нужно оптимизировать, иначе пользователь загрузит разом все иконки без надобности. Работа с исходным кодом требует тяжелых DOM-операций и потенциально опасна.

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

Давайте посмотрим на еще один способ, доступный в современных браузерах, тэг USE.



Чем нам полезен USE?


Этот тэг задуман для переиспользования символов и целых SVG-блоков на странице. Но в современных браузерах (прости, IE) он может даже доставать внешние ресурсы!

Внешние SVG должны быть на том же домене, так что CDN не подойдет. Пока.

Это позволяет нативным образом вставить SVG в Shadow DOM, почти как тэг IMG с атрибутом src, только с возможностью использовать CSS. И оно даже само работает с кэшем! Но нужно слегка подготовить иконки. Вот что надо сделать:



Сначала в каждой иконке нужно сделать символ с уникальным id и переместить viewBox в него.

Затем надо назначить fill (или stroke) на currentColor, чтобы потом использовать CSS-правило color для задания цвета. Можно также задать эти атрибуты в inherit на других элементах, что позволит сделать двухцветные иконки (подробнее в примере ниже).

Когда наши иконки подготовлены, остается только скинуть их в папку assets и использовать:



Компонент именованных иконок для Angular


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

Нам понадобится токен для предоставления пути до всех наших иконок и простой компонент. Он будет формировать href исходя из имени и заданного пути. Мы даже можем повесить его на нативный SVG с помощью селектора: так мы вынесем наружу заботу о размере.

Надо иметь в виду, что Safari до 12.1 поддерживает только устаревший синтаксис xlink:href. Так что лучше использовать оба варианта.

Сделаем stroke и fill прозрачными для использования нескольких цветов в CSS:



Живой пример: stackblitz.com/edit/angular-colored-svg

Заключение


У этого подхода есть ограничения отсутствие поддержки IE и кросс-доменности. Однако, если они для вас не критичны, данное решение может стать хорошей альтернативой другим способам.

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

Карта метро Москвы с расчётом пути

05.05.2021 22:05:36 | Автор: admin

В своей предыдущей статье про интерактивную карту метро Москвы я описывал процесс создания векторной карты на svg-движке, сравнивая с канвасным отображением.

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

Сама задача поиска по графу потребовалась по работе для визуализации блок-схем в формате UML, DTD для предоставления заказчику. Алгоритм позволит "оживить" их, превратив в подобие задачи с известными решениями.

Я вспомнил про свою карту метро, представляющую готовый сложный, неориентированный граф, и решил апробировать алгоритм на ней.

Алгоритм состоящий из трёх небольших функций я адаптировал для использования массива с координатами станций, добавив условия:

  • Переходы по вершинам (станциям) назад и вперёд возможны только по линиям одного типа

  • Переходы с линии на линию возможны если у них есть общие станции, являющиеся пересадками (массив inches)

  • Размер массива координат станций пересадок настраивается выбором фильтра всех пересадок (тип inch): прямые, кольцевые, строящиеся, мцк. В дальнейшем добавлю в отдельный фильтр также пересадки Большого кольца и Монорельса.

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

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

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

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

В-четвертых, исходный алгоритм поиска был написан по стандарту ECMA2015 с использованием конструкций языка let, const, Set, которые не позволяли мне посмотреть карту на стареньком iPad 3G. Пришлось переписать код на старый формат с var, function.

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

Надеюсь, статья поможет тем, кто интересуется созданием изображений svg, оффлайн-картами с возможностью редактирования и использования в своих проектах.

Привожу отдельные ссылки на карту метро и проект в github.

Подробнее..

Разбор зачем нужны анимации на сайтах 7 полезных инструментов и библиотек для их создания

14.09.2020 20:08:14 | Автор: admin


Источник: Dribbble

Анимации в вебе полезны в большом количестве ситуаций. В этом материале мы разберем, зачем конкретно они нужны, и какие инструменты создания анимированных сайтов стоит использовать в 2020 году.

Зачем нужны анимации на сайтах: повышение конверсии, сторителлинг, оптимизация


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

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



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



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

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

Slides: фреймворк для создания анимаций без кода




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

  • панели
  • слайдеры
  • диалоговые окна
  • сайдбары
  • выпадающие меню
  • контактные формы
  • навигационные элементы
  • поп-апы
  • кнопки

Фреймворк позволяет создавать анимации с помощью HTML, CSS и JS вам нужно будет лишь скопировать сгенерированный код и внедрить его на сайт.

Express Animate: создание видео-анимаций




Этот инструмент позволяет генерировать анимации и специальные эффекты для видео. Затем эти видео можно встраивать на веб-страницы. Проекты можно экспортировать в формате HTML5, flash или GIF. С помощью этого инструмента можно создавать специальные элементы

Koolmoves: создание анимаций и перекодирование flash


Этот инструмент позволяет создавать HTML5-анимации для наложения эффектов на изображение, анимирования элементов навигации, создания слайд-шоу и т.п. Конечный результат можно экспортировать в HTML5, GIF, MP4/AVI. Также Koolmoves позволяет конвертировать flash-анимации в более современные форматы.

AnimateMate: плагин для Sketch
Sketch мощный инструмент, иногда даже слишком. Это очень ощущается в ситуациях, когда нужно создать простую анимацию и не тратить на это много времени. С помощью этого плагина можно быстро создавать простые анимации и экспортировать их прямо из Sketch.

image

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

WAIT! Animate: создание пауз в CSS-анимациях




Этот инструмент решает конкретную задачу расчет идеальной паузы между завершением анимации и ее повторным стартом. CSS не дает простых способов сделать такую паузу, поэтому WAIT! Animate оказывается неожиданно полезным инструментом.

Granim.js: работа с градиентами в анимациях


Эта JS-библиотека позволяет создавать красивые интерактивные анимации. Отлично подходит для создания фоновых изображений с меняющимся градиентом.



iTyped: анимация текстов


Еще одна JavaScript-библиотека, которая красиво анимирует процесс печати. При этом здесь нет никаких лишних зависимотей, что облегчает ее использование.



Заключение


Анимации в вебе не только служат для улучшения внешнего вида сайта. Они выполняют множество конкретных задач, которые облегчают жизнь пользователям, повышают качество взаимодействия с сайтом и, как следствие, конверсию. Грамотное использование анимаций с помощью подходящих инструментов может стать отличным решением, которые позволит улучшить результативность вашего сайта.

Знаете какие-то еще полезные инструменты для работы с анимациями в вебе? Оставляйте ссылки в комментариях.
Подробнее..

Перевод Графика для JVM

02.05.2021 16:16:26 | Автор: admin


Допустим, я хочу создавать качественные десктопные приложения. Я также хочу сделать это на JVM. Не надейтесь мы еще не достигли цели. Но у меня есть план.

Почему именно JVM?


Это производительность на достаточно высоком уровне, но не заставляет вас слишком много задумываться о каждом выделение памяти. Это кроссплатформенно. В нем есть отличные языки Kotlin, Scala и, конечно же, Clojure. C # тоже подойдет, но в нем нет Clojure.

Разве вы уже не можете создавать десктопные приложения на JVM?


Вы можете. Но традиционно AWT, Swing и JavaFX сопровождались множеством недостатков в качестве и производительности. Они были настолько существенными, что только одной компании удалось создать прилично выглядящее приложение на Swing. Это возможно, но требует огромных усилий.

Разве не все пользовательские интерфейсы Java прокляты?


Нет, не совсем. У AWT, Swing и JavaFX есть свои проблемы, но это исключительно их проблемы. Нет фундаментальной причины, по которой невозможно создать высококачественный пользовательский интерфейс на JVM. Просто это еще не было сделано.

Почему это еще не было сделано?


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

Почему не Electron?


Первая причина производительность. JS отличный язык для создания пользовательского интерфейса, но он намного медленнее, чем JVM. Wasm может быть быстрым, но подразумевает C ++ или Rust.

Второй это модель DOM. Это ужасающая коллекция уловок, которые делают простые вещи сложными, а сложные невозможными. Я много раз думал: Если бы я рисовал этот элемент управления/макет напрямую, я бы закончил несколько часов назад.

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

Однако Electron научил нас двум хорошим вещам:

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


Десктоп по-прежнему актуален?


Я верю, что это так!

Недавно я смотрел интервью между разработчиком Android и разработчиком iOS. Один спрашивал:

Кто-нибудь по-прежнему пишет десктопные приложения?

На что другой ответил:

Понятия не имею Может быть?

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

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

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

Хорошо, что же ты предлагаешь?


Путь к качественному пользовательскому интерфейсу на JVM долгий. Нам понадобятся:

  • графическая библиотека,
  • библиотека интеграции окна / ОС,
  • набор инструментов пользовательского интерфейса.


Сегодня я рад анонсировать первую часть этого эпического квеста: графическую библиотеку. Она называется Skija и представляет собой просто набор привязок к очень мощной, хорошо известной библиотеке Skia. Та, которую поддерживает Chrome, Android, Flutter и Xamarin.

image

Как и любая другая библиотека JVM, она кроссплатформенная. Она работает в Windows, Linux и macOS. Это так же просто, как добавить файл JAR. Намного проще, чем массировать флаги компилятора C ++ в течение нескольких дней, прежде чем вы сможете что-либо скомпилировать. Skija позаботится об управлении памятью за вас. И привязки создаются вручную, поэтому они всегда имеют смысл и доставляют удовольствие (по крайней мере, насколько позволяет Skia API).

Что с этим делать? В основном рисовать. Линии. Треугольники. Прямоугольники. Но также: кривые, контуры, формы, буквы, тени, градиенты.

image

Думайте об этом как о Canvas API. Но вроде бы действительно продвинутой версии. Она понимает цветовые пространства, современную типографику, макет текста, ускорение графического процессора и тому подобное.

image

О, и это быстро. Действительно быстро. Если этого достаточно для Chrome, вероятно, этого будет достаточно и для вашего приложения.

Что я могу с этим сделать?


Много вещей! Пользовательские библиотеки виджетов пользовательского интерфейса и целые наборы инструментов, графики, диаграммы, визуализации, игры. Например, мы поигрались с реализацией java.awt.Graphics2D и запуском Swing поверх него похоже, все работает нормально.

Зачем выпускать отдельную графическую библиотеку? Чем это полезно?


Я не большой поклонник объединять все в одном месте. Вы никогда не сможете угадать все детали правильно кто-то всегда будет недоволен конкретным решением.

Независимые взаимозаменяемые библиотеки более гибкие. Филосовия Unix.

Что с остальной кусочками паззла?


Обе вещи находятся в разработке в JetBrains.

  • Для интеграции управления окнами и ОС есть Skiko. Она говорит, что это Skia для Kotlin, но она также реализует создание окон, события, пэкэджинг и все остальное. Она даже интегрируется с AWT и Swing.
  • А для инструментария пользовательского интерфейса есть Compose Desktop. Это форк Android Compose, декларативного UI-фреймворка, работающего в среде рабочего стола.


Но прелесть в том, что это даже не обязательно эти двое!

Не нравится AWT? Принесите свою собственную библиотеку окон.

Kotlin не подходит Вам? Используйте любой другой язык JVM.

Compose плохо справляется с нагрузкой? Молитесь, чтобы кто-нибудь написал альтернативу или написал что-то свое (извините, но хорошего решения пока нет. Это еще только начало).

И, конечно, если вы хотите развернуть свою собственную библиотеку окон или набор инструментов для виджетов пожалуйста, сделайте это! Мы надеемся, что это произойдет.

В заключение


Skija это часть более широкой картины. Прогресс пользовательского интерфейса Java был заблокирован некачественной Graphics2D. Но все меняется. Что из этого выйдет? Время покажет.

Пожалуйста, попробуйте Skija и поделитесь с нами своим мнением. Или, может быть, начните ей пользоваться мы были бы счастливы, если бы вы это сделали! Вот ссылка:

github.com/JetBrains/skija

14 ноября 2020 Обсуждение на HackerNews



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Из песочницы Адаптивное разбиение кривых Безье 2-го и 3-го порядка

15.06.2020 00:20:27 | Автор: admin


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


Введение


На предыдущей работе я был оператором ЧПУ-станка, делал мебельные фасады из МДФ. Работа разнообразная: то сидишь за компом и чертишь в CAD/CAM-программе, то стоишь контролируешь резку, то приносишь заготовки и уносишь готовые детали.


До того, как я пришёл в фирму, там был довольно скудный каталог рисунков, которого явно не хватало клиентам, поэтому они всё время просили сделать как на фото из интернета. Все специфичные рисунки я рисовал вручную, стандартные же были довольно просты, а так как я увлекался программированием, то решил генерировать их G-код для станка напрямую без участия CAD/CAM-программы.


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


В данной статье я не буду затрагивать саму программу, поскольку это тема отдельной статьи. Я расскажу о том, с чем мне пришлось столкнуться в самом начале, а именно как представить кривую Безье в виде прямых отрезков с точностью, при которой будет создаваться минимальное количество промежуточных точек при сохранении визуальной плавности на изделии. Станок очень хорошо передаёт издаваемыми звуками то, насколько плавно он движется по траектории. Я ориентировался на звук при резке чертежей, созданных профессиональной CAD/CAM-программой.


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


С чем мы собираемся бороться?


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



Рис. 1 Крутой поворот



Рис. 2 Перегиб



Рис. 3 Узкая петля


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


Кривые 2-го порядка


Первый пример будет с кривой Безье 2-го порядка. Начальная и конечная точки эталонной кривой совпадают с таковыми у исходной. Опорная точка находится посередине, т.к. кривая 2-го порядка, а значит мы делим её на две части.



Рис. 4 Кривая Безье 2-го порядка


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


from math import sqrtdef b2(x0, y0, x1, y1, x2, y2, d):    mx1 = x1 - (x0 + x2) / 2    my1 = y1 - (y0 + y2) / 2    d1 = sqrt(mx1 ** 2 + my1 ** 2)    if d1 < d:        print(x2, y2)    else:        x01 = (x0 + x1) / 2        y01 = (y0 + y1) / 2        x12 = (x1 + x2) / 2        y12 = (y1 + y2) / 2        x012 = (x01 + x12) / 2        y012 = (y01 + y12) / 2        b2(x0, y0, x01, y01, x012, y012, d)        b2(x012, y012, x12, y12, x2, y2, d)

Кривые 3-го порядка


Второй пример будет с кривой Безье 3-го порядка. Начальная и конечная точки эталонной кривой совпадают с таковыми у исходной. Опорные точки находятся на 1/3 и 2/3 её длины, т.к. кривая 3-го порядка, а значит мы делим её на три части.



Рис. 5 Кривая Безье 3-го порядка.


Аналогично предыдущему примеру, расстояния d1 и d2 на рисунке показывают отклонение опорных точек от их эталонных значений. Если оба расстояния d1 и d2 меньше заданной нами величины, чертим прямую линию из точки 0 в точку 3 и заканчиваем аппроксимацию, если нет делим кривую пополам и рекурсивно для каждой половины повторяем проверку. Пример кода прилагается.


from math import sqrtdef b3(x0, y0, x1, y1, x2, y2, x3, y3, d):    px = (x3 - x0) / 3    py = (y3 - y0) / 3    mx1 = x1 - x0 - px    my1 = y1 - y0 - py    mx2 = x2 - x3 + px    my2 = y2 - y3 + py    d1 = sqrt(mx1 ** 2 + my1 ** 2)    d2 = sqrt(mx2 ** 2 + my2 ** 2)    if d1 < d and d2 < d:        print(x3, y3)    else:        x01 = (x0 + x1) / 2        y01 = (y0 + y1) / 2        x12 = (x1 + x2) / 2        y12 = (y1 + y2) / 2        x23 = (x2 + x3) / 2        y23 = (y2 + y3) / 2        x012 = (x01 + x12) / 2        y012 = (y01 + y12) / 2        x123 = (x12 + x23) / 2        y123 = (y12 + y23) / 2        x0123 = (x012 + x123) / 2        y0123 = (y012 + y123) / 2        b3(x0, y0, x01, y01, x012, y012, x0123, y0123, d)        b3(x0123, y0123, x123, y123, x23, y23, x3, y3, d)

Выведение


Поскольку массово используются только кривые этих порядков, копать дальше считаю лишним. Этот код несколько лет помогал выполнять мне мою работу. Требования к плавности на станке высокие, вибрация его убивает. Станок жив до сих пор, поэтому код прошёл боевое крещение. При работе на станке все мои размеры были в миллиметрах, переменная d в моём случае была 0.025 мм.


Также есть материал по рациональным кривым тех же порядков (это те, что с весами). Если будет интерес, про это тоже напишу. Благодарю за прочтение.

Подробнее..

Опубликован Scheme Request For Implementation 203 A Simple Drawing Language in the Style of SICP

18.09.2020 18:11:01 | Автор: admin
Функциональная геометрияФункциональная геометрия

SICP

Обложка SICPОбложка SICP

Structure and Interpretation of Computer Programs -- это один из самых известных учебников программирования в мире, на основе которого несколько десятков лет преподавался начальный курс программирования в MIT, а во многих унивеситетах, в том числе в Беркли, преподаётся до сих пор.

SICP использует Scheme в качестве основного (практически единственного) языка программирования. Тем не менее, нельзя сказать, что это учебник Scheme, потому что он выходит далеко за пределы того, что обычно входит в программу "изучения языка". Стоит только упомянуть, что в программу входят системы распространения ограничений, интерпретаторы языков программирования, симуляторы цифровых схем, а также симулятор целого процессорного модуля.

Большая часть тем, входящих в учебник, выполнимы на "стандартной" (в смысле, соответствующего последнему на текущий момент стандарту Revised^7 Report on Algorithmic Language Scheme) Scheme.

Особенные темы

Цифовой сумматор, реализуемый в качестве одного из упражений SICPЦифовой сумматор, реализуемый в качестве одного из упражений SICP

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

Принятая по-умолчанию в учебнике реализация MIT/GNU-Scheme содержит необходимые примитивы, расширяющие базовый язык так, чтобы курс становился проходим.

За многие годы, прошедшие с момента выхода SICP, некоторые реализации Scheme также реализовали многие примитивы, требуемые для прохождения курса.

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

SRFI

Логотип community processЛоготип community process

Scheme Requests for Implementation -- это community process, принятый в семействе языков Scheme. В некоторых аспектах он Java Community Process или Python Enhancement Proposals. Так или иначе, это главный инструмент обсуждения развития языкового семейства, а также главный инструмент обеспечения переносимости кода.

Написание SRFI показалось автору сей заметки естественным выбором для формализации требований к программным системам.

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

Функциональная геометрия

Основой главы, посвящённой графической подсистема компьютера, в SICP послужила статься Питера Хендерсона "Функциональная Геометрия". (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.137.1503, https://eprints.soton.ac.uk/257577/1/funcgeo2.pdf)

Образец рисунка, сделанный методом функциональной геометрииОбразец рисунка, сделанный методом функциональной геометрии

Знакомым с творчеством Морица Эшера это изображение может показаться смутно знакомым.

В основе техник функциольнальной геометрии лежат две идеи.

  • Первая идея в том, что должен существовать некоторый языковой объект painter, который при активации должен рисовать в нужном месте холста (экрана) что-то заданное программистом. (В Scheme painter -- это функция.)

  • Вторая идея в том, что нужен какой-то способ комбинировать painter'ы, получая новые painter'ы.

В КДПВ вынесена иллюстрация этого подхода.

Реализация

В предложенном SRFI не предоставленно исчерпывающей реализации метода функциональной геометрии. Однако, предложен субстрат, достаточный для того, чтобы активный студент мог сам реализовать подмножество функциональной геометрии, предложенной в SICP на любом интерпретаторе, поддерживающем SRFI-203 (результат работы автора сей заметки).

Полный текст предложения находится по ссылке:

https://srfi.schemers.org/srfi-203/srfi-203.html

Абстракт и технические детали можно найти здесь:

https://srfi.schemers.org/srfi-203/

SRFI находился на обсуждении два месяца, и за это время было предложено две реализации, для интерпретатора Chibi, и для интерпретатора Kawa.

Логотип Chibi-SchemeЛоготип Chibi-Scheme

Заключение

Автор сей заметки (он же автор SRFI) надеется, что предложенное им расширение языка будет позитивно воспринято сообществом. (Те, кто уже сейчас пользуются Scheme, могут предложить поставщикам своего интерпретатора включить это расширение в следующий выпуск.) Автор также надеется, что тем, кто начинает изучать Scheme, SICP или компьютерную графику, данное расширение также поможет сэкономить усилия, затрачиваемые на технические детали, и там самым освободить больше ресурсов для собственно обучения.

Подписка

Те, кому кажется целесообразным выполняемая работа, приглашаются задонатить по PayPal-ссылке. Также все желающие приглашаются подписаться на обновления.

  • Telegram :: http://t.me/unobvious

  • GitLab :: http://gitlab.com/lockywolf

  • Twitter :: https://twitter.com/VANikishkin

  • PayPal :: https://paypal.me/independentresearch

Подробнее..

Паттерны Архитектурного проектирования (v.1.0)(Archicad)

12.01.2021 16:20:24 | Автор: admin

Небольшое вступление

Всем добрый день, работаю в маленькой компании на должности bim-manager и по совместительству ведущим архитектором. Увлекаюсь, изучаю программирование. И чем больше разбираюсь, тем больше завидую.

Архитектура как отрасль очень сильно отстает от IT в плане инстурментов и методов разработки проектов. В IT давно есть среды разработки, а мы по прежнему создаем отдельные файлы и затем долго и нудно собираем их в один проект; ретроспективу после проекта некоторые основатели платных курсов называют своей уникальной методологией которую они придумали; и самое главное нету паттернов. Каждый раз в каждом проекте приходится подолгу объяснять одни и те же решения одних и тех же задач. И вот постепенно такая ситуация привела к решению что пора сформировать/сформулировать эти самые паттерны для архитектурного проектирования. Прежде всего описанные ниже паттерны применимы к разработке в программе Archicad.


Перечень паттернов

По аналогии с программирование показалось не лишним структурировать их в зависимости от типа решаемых задач

Сборочные (или структурные)

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

  • Горизонтальная типовость

  • Вертикальная типовость

  • Компоновщик (или древовидная типовость)

  • Сам себе режисер

Преобразования элементов

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

  • Подмена (или заменитель)

  • Проводник

  • Тянущая привязка

  • Лосины (или натягивание на рельеф)

  • Единственный экземпляр

Координационные

Отвечают за способы взаимодействия проектировщиков или файлов с разными ключевыми задачами

  • Наблюдатель

  • Главный файл

  • Фантом

Вариантные

Определяют каким образом внутри проекта будут создаваться варианты

  • MODный вариант

  • Вариант через фильтр реконструкции (не придумал пока как короче назвать)

Подробное описание каждого

Горизонтальная типовость

Ссылка на файлы с примером реализации

Основной принцип - определение этажа как тип целиком

Задача: разбить по типовости большой многоэтажный комплекс. При этом часть элементов может повторятся с 5 по 24 этаж, часть только с 7 по 22, еще часть с 8 по 20.

Решение: распределяем типы буквально как идет повторение по этажам тип1 -> для 3-6, 23-24 этажей, тип2 -> 7,21-22 и тип3 -> 8-20

Плюсы: самая простая для понимания структура сборки. Минимум типовых этажей.

Минусы: будет много повторений элементов (ctrl+c, ctrl+v) и много лишней работы. В чистом виде дальше стадии ПП данный паттерн применять нецелесообразно, т.к. одно малейшее отличие и надо создавать другой тип с вытекающим дублированием огромного количества элементов. И каждый раз добавляя, изменяя элементы на одном типе - нужно будет повторить для идентичных элементов в другом типе

Схема:

Spoiler

Вертикальная типовость

Ссылка на файлы с примером реализации

Основной принцип - определение как тип отдельные группы элементов

Задача: такая же как и у предыдущего - разбить по типовости большой многоэтажный комплекс. При этом часть элементов может повторятся с 5 по 24 этаж, часть только с 7 по 22, еще часть с 8 по 20.

Решение: распределяем, дробим по повторяющимся группам элементов типы как тип1 -> для 3-24 этажей, тип2 -> 7-22 и тип3 -> 8-20, координация типов осуществляется через фоновую ссылку

Плюсы: нету повторяемости элементов. Относительно простая для понимания модель

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

Схема:

Spoiler

Компоновщик

Ссылка на файлы с примером реализации

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

Задача: такая же как и у предыдущего - разбить по типовости большой многоэтажный комплекс. При этом часть элементов может повторятся с 5 по 24 этаж, часть только с 7 по 22, еще часть с 8 по 20.

Решение: дробим по аналогии с Вертикальной типовостью. Создаем тип1 для частей которые повторяются на 3-24, создаем тип2 для 7-22 и в него подгружаем уже готовый тип1, создаем тип3 для 8-20 и в него подгружаем уже готовый тип2

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

Минусы: очень тяжелая для первого понимания модель, долго обновляются связи в основной модели (в сборке)

Схема:

Spoiler

Сам себе режисер

Ссылка на файлы с примером реализации

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

Задача: собрать простую бим модель. Для упрощения архитектор сразу старается закладывать какую-нибудь типовость. Групп типовых элементов не так много что бы создавать и выстраивать структуру из отдельных файлов.

Решение: создаем все в одном файле. У нас есть этажи основной модели (например с -1 по 5). Делаем небольшой отступ ниже ( -2, -3, -4) и начиная с -5го принимаем как этажи на которых будут располагаться типовые группы элементов. Затем эти типовые подгружаем в пространство основной модели. Таким образом получается что файл влагается сам в себя. Сам себе служит .mod-ом

Схема:

Spoiler

Подмена

Ссылка на файлы с примером реализации

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

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

Решение: Ставим колонну, или перекрытие как автоматически вычитающий элемент (можно балку и стену но не рекомендуется из-за возможных сложностей с привязками).

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

Минусы: подходит только для декоративных элементов, инженерии и для локальной пробы вариантов на ранних стадиях проекта.

Схема:

Spoiler

Проводник

Ссылка на файлы с примером реализации

Проводник - файл в котором происходят минимальные изменения или дополнения группы элементов для дальнейшего использования в проекте

Задача: Есть собранная база юнитсов (группа элементов которые отстраиваются и специфицируются как один объект) например перемычки или вентблоки. И нужно их затянуть в разные проекты. Глобально в базе если жёстко замаркировать то в проектах в ведомостях могут получиться разбежности типа ВБ-01 ВБ-04. В каждом проекте используется разный набор вентблоков. Дублировать файл чтобы перебить на свои тоже не имеет смысла тк в случае глобальных корректировок или дополнения, расширения - нужно будет повторить всю работу.

Решение: В исходном файле, основном в котором собраны все типы не индексируем, а подгружаем его как связь в мод юнитсов самого проекта. Маркировку будем обозначать и снимать с ID. Назначаем ID через "ID связи"(Master ID)

Схема:

Spoiler

Тянущая привязка

Ссылка на файлы с примером реализации

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

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

Решение: Стены пляшущего фасада конфигурируем таким образом чтобы привязка всегда располагалась в одном месте. Стены внутренние на каждом этаже будут ловить привязку и автоматически заполнять меняющееся пространство. Зоны так же корректно обновляются

Минусы: Мы больше не можем использовать линию привязки как объективный параметр (напр. "длина линии привязки")

Схема:

Spoiler

Лосины

Ссылка на файлы с примером реализации

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

Задача: Быстро (не для Р) концептуально но красиво отстроить все дороги, дорожки, площадки на рельефе. Вылепливать вершинами 3д сетки - долго.

Решение: В плане отмоделиваем все элементы ГП которые нужно натянуть на рельеф. Назначем им всем низ - ниже чем самая низкая точка на рельефе (можно 1м, но лучше брать с запасом около 5м), высота - выше чем самая верхняя точка на рельефе. Заходим в "операции твердотельного моделирования", все элементы благоустройства определяем как "целевые элементы", рельеф как "элементы оператора", Если рельеф имеет толщину(тело) то операциях твердотельного моделирования выбираем параметр "пересечение", иначе параметр "вычитание с выталкиванием вверх", жмем "Выполнить", преобразовываем элементы в морф. Далее у нас есть 2 варианта. 1- поднимаем морфы на 20+мм над рельефом. 2- с помощью того же инстурмента вычитаем морфы из земли. Элементы благоустройства получаются как бы натянуты тонким слоем ровно по рельефу.

Примечание: Заметно только с ближних статичных ракурсов. Люмион и твинмоушен может некорректно понимать, что есть верх в такой натянутой дороге и машины/люди могут пойти по самому рельефу, как бы проваливаясь на несколько сантиметров в текстуры.

Spoiler

Единственный экземпляр

Ссылка на файлы с примером реализации

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

Задача: Отстроить типовые элементы колонн/пилонов, диафрагм жесткости в которых нету проемов в многоэтажном ЖК (18+ этажей). Традиционный способ не очень эффективен с точки зрения использования ресурсов компа - колонна в высоту этажа и поехали по 10+ этажей тиражировать одинаковые модули.

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

Spoiler

Наблюдатель

Ссылка на файлы с примером реализации

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

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

Решение: Отделяем все сопутствующие задачи от модели в отдельные файлы. Модель собираем и редактируем конкретно в одном файле. В остальные подгружаем целиком как связь и проводим там все нужные операции. Например так можно отделить в файл задачу по анализу инсоляции. Грассхоппер будет связываться со специальным для этой задачи файлом, а не моделью над которой работают архитекторы. Можно отделить подсчет объемов материалов, оформление заданий и выпуска и т д. В конечном итоге заведем шаблоны с уникальными для каждой задачи пресетами вместо того чтобы утежелять основной шаблон.

Spoiler

Главный файл

Ссылка на файлы с примером реализации

Главный файл - основной файл в котором собирается бим модель, пригоден для выпуска, и с которого возвращается как подложки PMK

Задача: Проектировщики параллельно создают варианты планировок, варианты фасадов. Их надо между собой как-то координировать, чтобы после без длительной подгонки выпустить все необходимые чертежи, визы, и тп.

Решение: выделяем в структуре проекта главный файл в котором будет собираться конечная модель из модели с планами + модели с фасадами. Для обратной связи выгружаем из главного файла PMK и затягиваем как подложки в модели планов и фасадов. Так же главным файлом может быть объявлен файл модели планов или фасадов

Spoiler

Фантом

Ссылка на файлы с примером реализации

Фантом - способ координации двух моделей, при котором подложенные модели не существуют на тех этажах на которых отображаются.

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

Решение: Отстраиваем модель фасада с параметрами отображение элементов "все релевантные этажи". Остраиваем модель планов этажей с отображением элементов "все релевантные этажи". В одном файле (напр с фасадами) ниже этажей основной модели +несколько этажей для отступа набиваем структуру этажей идентичную основной модели, подгружаем на доп этажи все планы и вручную в 3д стягиваем на отметки в область основной модели. В другом файле проворачиваем тоже самое с фасадами, но на этажах выше основной модели + неск этажей для отступа.

Плюсы: будут подгружены все элементы модели включая вложенные модули. Будет осуществлятся взаимодействие с самой моделью а не фоновой ссылкой или 2д чертежами. Каждый владеет полной бим моделью.

Минусы: Не подходит для невнимательных, т.к. можно запустить тяжелейшую рекурсию. Не подходит для слабых компьютеров

Spoiler

MODный вариант

Ссылка на файлы с примером реализации

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

Задача: В процессе разработки стадии П или ПП вам подкидывают идею/задание "а давай это место попробуем сделать вот так". Получается надо локально и быстро сделать другой вариант, при этом не запороть собранную модель и не перелопачивать всю структуру проекта.

Решение: Те части, которые необходимо заменить - выделяем, вырезаем и сохраняем как мод из буфера обмена, это будет исходный. Дублируем мод, называем как вариант и в нем уже его разрабатываем. В основную модель подгружаем/переключаем моды с вариантами

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

Минусы: На переключение между вариантами уходит время

Spoiler

Вариант через фильтр реконструкции

Ссылка на файлы с примером реализации

Вариант в фильтре реконструкции - способ создания вариантов, путем прикрепления геометрии к конкретному фильтру реконструкции и отображению только в нем.

Задача: Такая же как в предыдущем. В процессе разработки стадии П или ПП вам подкидывают идею/задание "а давай это место попробуем сделать вот так". Получается надо локально и быстро сделать другой вариант при этом не запороть собранную модель и не перелопачивать всю структуру проекта.

Решение: создаем фильтр реконстуркции "исходный вариант" и "вариант " скидываем все элементы, которые надо заменить на фильтр реконструкции "исходный вариант" или базовый, в котором разрабатывается основная модель. Для этого дела нам может пригодиться панель "Фильтры реконструкции". Варианты делаем с привязкой к фильтру конструкции "вариант ."

Плюсы: быстрое переключение между вариантами; всё в одной модели

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

Spoiler

Ссылка на папку со всеми файлами примерами на всякий случай

Подробнее..

Ретроспектива создания своего мультфильма

20.06.2020 18:10:45 | Автор: admin
Мы живём в удивительное время. То, что раньше было невероятным, сегодня у нас буквально валяется под ногами. В наши дни любой человек может сделать свой собственный мультфильм. Анимационные программы упрощают и ускоряют этот процесс настолько, что даже один человек ну будучи аниматором, может сделать настоящий анимационный фильм.
С удовольствием поделюсь полученным мною опытом. Речь будет идти о 2D-анимации, но многие моменты равно применимы и к 3D. Кому будет интересно ссылка на сам мультфильм в конце поста.

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

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

Анимация это не самое важное. Анимация на втором месте. История важнее анимации. Она должна быть интересной, стоящей, поучительной. Анимация лишь раскрывает вашу историю.

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

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

Ускорение развития навыков. Чередуйте, банально переключайтесь между теорией (20%) и практикой (80%). Не впадайте ни в одну, ни в другую крайность. Понятно, если вы ограничитесь теорией, то вы ничего, никогда и не сделаете. Но часто многие ограничиваются практикой, силовым методом и это тоже снижает скорость развития. Из 5 часов 1 час изучайте, 4 делайте. По-моему опыту это заметно ускоряет.

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

Всегда понимаешь, что сценарий плох. В процессе работы над своим мультом, у вас будут появляться более лучшие идеи, решения. Стоит ли следовать изначально утверждённому плану или на ходу перелепливать пельмени? Мой совет перелепливать, в итоге получится лучше!

Название мультфильма. Лучшее название для вашего фильма появится в самом конце. Вы сразу его узнаете. Мультфильм вы начинаете делать просто с рабочим названием.

Зритель видит по-другому. Рассказывать истории очень сложно. Имеет значение всё. Зритель не увидит так как хочешь ты, он увидит так как он видит. И отсюда сразу два урока:
Чётко управлять вниманием, фокусировать на важном (прежде всего движением, в т.ч. камеры, контраст, световой/цветовой, выбивание/отличие из ряда и т.д.).
Обязательно устраивать предпоказы узнаешь как видят твою историю другие люди (зритель не смотрит туда, куда нужно посмотреть, упускает нить повествования, внимание рассеивается, расфокусируется, и т.д.).

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

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

Чёрного цвета не существует. Чёрного не существует, это выдумка америкосов. Никакого абсолютно чёрного цвета. Для контуровки и деталей используйте очень тёмные оттенки. Результат будет лучше.

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

Рисование фонов. Фоны нужно рисовать с учётом предполагаемого композитинга:
Каждый элемент фона на отдельном слое, чтобы можно было на этапе композитинга передвинуть объекты и использовать эффект параллакса.
Рисовать фоны важно в перспективе (Прямые анфас и профиль не интересные, всегда интересны перекрестки, углы, склоны, подъёмы).
Одинаковости в мире не существует (даже одинаковые элементы должны различаться деталями).
Аккуратно с детализацией (изляшняя проработка фона может отвлечь внимание зрителя с важных событий).

Риггинг. Риги нужно конструировать, учитывая:
Характер, особенности персонажа (какой он, какие движения ему потребуются, в каких ракурсах он нужен в сценах, планируются ли диалоги). Если не спланируете риг заранее, это может значительно затянуть время производства мультфильма.
Персонажа рисовать прежде всего стоит в ракурсе 3/4, спереди. Самый важный ракурс персонажа. Он чаще всего будет использоваться. Если вы планируете делать диалоги, то хорошо разнообразят картину 3/4 сзади собеседников персонажа.
Максимально упрощайте своего персонажа (без лишних деталей, текстур) гораздо ценнее вложить время в качественную анимацию, что в красивые риги с плохими движениями.
Наименование слоёв для быстрого ориентирования (и здесь тоже).
Важность установки осей вращения (Pivot Point) в темплейте.
Требуемый стиль (реалистичность, резиновость), возможности и ограничения техники перекладки.

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

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

Полиш создаёт новые ошибки. Полишовать сцены можно бесконечно. Кроме того, исправление
одних ошибок часто приводит к появлению новых.

Ну вот, кажется, все основные выводы, к которым приходишь, получая реальный опыт. Наверное, самым ценным уроком для меня стало понимание насколько огромен мир анимации и сколько возможностей в нём таится.
Как и обещал ссылка на сам мульт. Там же можно посмотреть расширенный разбор моего опыта.
Подробнее..

Шаблон удостоверяющей печати, когда нужно правильно и не как у всех

14.05.2021 22:04:58 | Автор: admin

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

Началось всё в 2009 году, когда вместо того, чтобы, для документов в электронном виде, отсканировать печать (как это обычно делается), я, по разным причинам (включая уже заметную на тот момент деформацию полимера действующей печати), запланировал отрисовать её заново. Но перед этим решил проверить: не была ли она сделана при помощи одного из популярных генераторов. Моё предположение оказалось верным и, через несколько минут, печать, со 100% точностью, я получил просто, выбрав подходящий шрифт и введя нужные данные в поля программы. Результат выглядел примерно так:

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

Эту ситуацию нужно было исправлять при первой же возможности, и она не заставила себя долго ждать: когда в банке попросили заменить поплывшее клише печати, в связи с выходом оттиска за пределы допустимых отклонений от контрольного, я принялся за работу над новым шаблоном. Но сперва предстояло определиться в выборе между лазерной гравировкой и флэш (flash) технологией изготовления печати. Полимер, как вариант, по понятным причинам, больше не рассматривался.

Флэш технологию часто называют новой, что не совсем верно: первые серийные образцы оборудования для производства красконаполненных печатей по флэш технологии появились в 1964 году в Японии. Создаваемые по этой технологии печати могут иметь элементы разного цвета в полях произвольной формы. Вокруг полей разного цвета выдерживается определенное, зависящее от оборудования, минимальное расстояние. Такие печати имеют хорошую разрешающую способность, а их оснастки компактны и бесшумны при проставлении оттисков. Заполняются они краской устойчивой, после высыхания, к воздействию воды и спирта.

Однако, именно лазерная гравировка качественной резины на хорошем оборудовании позволяет добиться наибольшей разрешающей способности, что и стало главным аргументом при выборе мной этой технологии. Есть возможность использовать и разную по своим свойствам краску и, при помощи специальных штемпельных подушек, получать оттиск с разными цветами. Формат оснастки можно подобрать под условия эксплуатации печати: от металлических настольных, повышенной прочности, до легких карманных, со встроенной штемпельной подушкой и без.

На следующем этапе нужно было определить минимально допустимую толщину линий и размер элементов микротеста для печати, но не найдя ничего конкретного, пришлось ориентироваться на ГОСТ Р 51511-2001, относящийся к печатям с воспроизведением государственного герба Российской Федерации, а именно на п. 6.2.3: Наличие линий толщиной 0,08+0,01 мм., и п. 6.2.1, 6.2.2: Размер элементов микротекста от 0,5 до 0,8 мм.

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

Но, не смотря на все попытки сделать это при помощи эффекта арки (arc) в Photoshop, желаемого эффекта добиться не удалось, пришлось спешно знакомиться с Illustrator и, попутно, регистрироваться на профильных форумах в поисках решения. И найдено оно было далеко не сразу, кажущаяся простой задача сопротивлялась не один день.

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

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

То же самое изображение:

Так это выглядит на самом деле (одинаковый размер печатей):

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

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

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

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

Как работает защита от секторного копирования в моей реализации можно понять, по следующим кадрам:

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

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

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

Подробнее..

Формирование диаграммы телефонных звонков в SVG формате при помощи Excel

22.07.2020 10:16:05 | Автор: admin
В данной статье описывается, как с помощью программы Microsoft Excel обрабатывать информацию из детализации телефонных вызовов, получая на выходе векторную диаграмму, которая наглядно отражает данные телефонные вызовы во времени и по дням. Сама по себе данная диаграмма напоминает диаграмму Ганта, которая чаще всего применяется для иллюстрации плана работ по какому-либо проекту.

Диаграмма Ганта представляет собой совокупность горизонтальных полос на плоскости. Горизонтальное направление соответствует величине времени, и данная величина, в общем случае, может быть непрерывной. А в вертикальном направлении данная плоскость разбита на множество горизонтальных зон фиксированной ширины. Для классической диаграммы Ганта, отражающая график работ, каждая такая зона соответствует определённому виду работы (рис. 1). Полосы диаграммы изображаются в пределах данных зон. Полоса, изображённая в конкретной зоне, характеризует соответствующий данной зоне вид работы, а левая и правая границы полосы характеризуют соответственно время начала и конца данной работы. Следовательно, длина полосы характеризует продолжительность данной работы.


Рис. 1. Диаграмма Ганта для иллюстрации графика работ.

В случае с диаграммой телефонных звонков, описываемой в данной статье, зоны в вертикальном направлении будут характеризовать дни (сутки). При этом по горизонтали шкала времени диаграммы соответствует интервалу от 0 до 24 часов, протяжённостью в одни сутки. Каждая полоса на такой диаграмме будет соответствовать одному телефонному звонку. Левая и правая границы полосы время начала и конца вызова, а номер зоны (по вертикали) день, когда был произведён вызов. Диаграмма подобной конфигурации позволяет наглядно проиллюстрировать и оценить, насколько часто совершаются звонки, оценить их среднюю продолжительность, распределение по времени суток и т.д. Более того, к данной диаграмме можно добавить ещё одно свойство: цвет полосы. Раскрашивать полосы можно по разным признакам. Во-первых по типу вызова (входящий или исходящий). Во-вторых по телефонному номеру вызова. В первом случае достаточно двух цветов. Во втором гораздо больше, но, как правило, достаточно не более десятка цветов на самые популярные телефонные номера, фигурирующие в вызовах чаще всего. В данной статье описывается формирование диаграммы за период в пять календарных месяцев и с учётом наличия двух мобильных операторов (двухсимочного телефона). Цвета полос на диаграмме будут выбираться по признаку SIM1/SIM2 входящий/исходящий, то есть, потребуется четыре различных цвета.

Формирование диаграммы, в отличие от построения, предусматривает именно генерацию выходного файла с данной диаграммой. А что касается построения, то, как правило, построение диаграммы в Excel подразумевало бы соответствующую операцию именно в Excel одним из стандартных средств. Даже если такая операция и возможна (диаграмма Ганта), то она вряд ли будет удобной в отображении и масштабировании на больших объёмах входных данных. В случае с формированием файла векторного формата SVG с подобной диаграммой программа Excel применяется в качестве программного инструмента, где удобно работать с табличными данными. Вместо Excel можно было написать стороннюю отдельную программу и формировать SVG файл с помощью неё. Но Excel в данном случае я выбрал не случайно. Во-первых, в своём роде, имеется некая наглядность обработки информации, а во-вторых специфичность выходного формата SVG. Данный формат является форматом масштабируемой векторной графики и содержит внутри текстовые данные, форматированные по принципу XML. Это своеобразный язык разметки, содержащий определённый набор команд и параметров, характерные для рисования того или иного графического элемента. Команды, к примеру, могут быть такие: нарисовать линию, многоугольник, окружность, написать текст. А параметры координаты углов многоугольника, цвет заливки, размер и шрифт текста и т.д. По сути, зная язык разметки SVG, можно с помощью обычного текстового редактора (Блокнот) вручную создать ту или иную картинку из разряда простейших. SVG файлы для просмотра можно открыть любым распространённым Интернет браузером.

Прежде чем приступить к формированию SVG диаграммы, необходимо не только скачать детализации вызовов с сайтов мобильных операторов, но и предварительно их обработать. Как я уже отмечал, будут рассмотрены два мобильных оператора. Один из них Теле2, другой Мегафон. Детализация звонков Теле2, которую можно скачать в личном кабинете на соответствующем сайте, представляет собой PDF документ с большой таблицей, которая поделена на страницы (рис. 2).


Рис. 2. Вид детализации вызовов Теле2.

В случае с Мегафоном всё практически аналогично, за исключением, что детализация представлена в XLS (Excel) файле (рис. 3).


Рис. 3. Вид детализации вызовов Мегафон.

И ту, и другую детализацию необходимо по-разному обработать, отсеить лишнее и привести в порядок. Данный текст имеет некую регулярность, поэтому легко подвергается автоматической обработке. Её я производил в отдельном документе с помощью функций (формул) Excel. Думаю, что не стоит останавливаться подробно на данном вопросе. В результате такой обработки получилась аккуратная большая таблица с минимально необходимыми полями: дата, время, длительность, тип звонка, номер телефона, симкарта (рис. 4). Всего получилось 2102 записи телефонных вызовов. Кстати, на рисунке 3, где изображён лист Excel с исходным текстом детализации, можно видеть наличие других листов. Данные листы я добавил как раз для реализации промежуточных этапов обработки, как продолжение исходного документа.


Рис. 4. Смешанная детализация, приведённая в порядок.

Получившуюся таблицу я скопировал в новый документ на лист A, тут же дополнив её дополнительными полями: адрес цвета полосы, левая граница полосы (a) (в секундах от начала суток), правая граница полосы (b) (рис. 5).


Рис. 5. Дополнительные параметры на первом листе.

Данные поля легко рассчитываются при помощи формул Excel. Адрес цвета указывает на один из четырёх адресов ячеек конфигурационного листа C, в которых он прописан в HEX-RGB формате. На данном листе указаны не только цвета, но и все дополнительные параметры SVG документа: координаты, сдвиги, масштаб и т.д. (рис. 6).


Рис. 6. Лист с параметрами.

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

Забегая вперёд, диаграмма получилась размером 4420 на 1800 пикселей. На самом деле сложно говорить о пикселях в векторной графике, но в описании SVG формата присутствует дискретная система координат, отсчёты которой я называю пикселями. А вообще, даже исходя из аббревиатуры, данная графика масштабируемая. Как я уже писал, диаграмма будет отражать звонки за 5 месяцев, а именно с мая по сентябрь включительно. Если посчитать, это соответствует 153 суткам. Ровно столько должно быть зон для полос на диаграмме. Заранее я определился с масштабами. По вертикали я решил отвести 10 пикселей на одну зону. При этом ширина полосы в зоне будет 8 пикселей, (с зазором в один пиксель сверху и снизу). Величиной зазора (отступа) в ячейке B8 листа C можно регулировать ширину полос в зоне. Масштаб по горизонтали можно выбрать, в принципе, любой, однако имеет место быть практическая наглядность диаграммы, приемлемое соотношение её сторон и вместимость. В итоге я решил взять 3 пикселя за протяжённость одной минуты, или иными словами, 20 секунд на пиксель. Итого, активная область диаграммы имеет следующие размеры. По горизонтали: 24*60*3=4320; по вертикали: 153*10=1530. Слева на диаграмме напротив каждой зоны должно быть написано её название. Названия зон полностью соответствуют датам. Для этой цели я решил отвести место шириной 100 пикселей. Вверху над диаграммой желательно (для удобства) написать метки времени, хотя бы часы. А внизу под диаграммой будет располагаться гистограмма, про которую я писал выше, а также дополнительная информация. Для этих целей я отвёл 270 пикселей, округлив высоту всей диаграммы до 1800. Кроме всего сказанного, на диаграмме я решил отразить светлые горизонтальные линии между зонами (днями), чуть более тёмными между неделями, а чёрными между месяцами. Кроме горизонтальных линий присутствуют также и вертикальные, расставленные через каждый час для границ часов. И ещё одна немаловажная деталь. На левой границе каждой изображаемой цветной полосы будет изображаться чёрная метка её начала в виде квадратной открывающейся скобки. Это нужно для того, чтобы предотвратить слияние двух полос, которые могут соответствовать подряд идущим телефонным вызовам.

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


Рис. 7. Лист с основными расчётами.

В колонке A извлекается номер дня (зоны) из даты вызова. В колонке B время вызова в секундах от начала суток. Это такое же значение, что и в колонке I листа C. В колонке C округлённая в большую сторону продолжительность вызова в минутах. Здесь стоит сделать оговорку, для чего введена такая неточность. Казалось бы, нужно брать продолжительность вызова с точностью до 20 сек, то есть до одного пикселя диаграммы (исходя из принятого масштаба). Однако очевидно, что очень короткие полосы шириной в 1-2 пикселя будут плохо отображаться на диаграмме. Поэтому минимальная длина полосы будет соответствовать хотя бы как минимум трём пикселям. И вообще, длина любой полосы будет кратна трём. За счёт округления длительности вызова в большую сторону (с точностью до минуты) диаграмма будет слегка переполненной, по сравнению с реальной ситуацией, однако это переполнение весьма незначительное. В колонке D с помощью формулы ДВССЛ извлекается значение цвета из параметров (Лист C) по рассчитанному адресу на листе A. Далее рассчитываются координаты углов полосы. Как я уже писал, там много лишних промежуточных расчётов, но я не стал переделывать. В колонке U вычисляется наличие выделения и цвет окантовки полосы, если телефонный номер текущего вызова совпадает с одним из четырёх приведённых телефонных номеров для выделения (на листе C). Забыл выше написать о том, что в выделяемом вызове на соответствующую полосу накладывается не только метка, но и серый цвет окантовки полосы (этот цвет также можно поменять на листе с параметрами). В обычном случае полоса не имеет окантовки. Наконец, в следующих трёх колонках происходит окончательное формирование текста на языке разметки SVG графики. В данной статье я не буду рассматривать описание и синтаксис данного языка. На самом деле в этом нет ничего сложного, я разобрался за несколько минут. В столбце V формируется код, рисующий полосу с окантовкой.
Пример:
<path fill="#FF5050" stroke="#808080" d="M1598,51L1598,59L1601,59L1601,51L1598,51" style="stroke-width: 1px;" stroke-width="1" stroke-dasharray="0"></path>.
В столбце W код для левого края полосы.
Пример:
<path fill="none" stroke="black" d="M1599,52L1598,52L1598,58L1599,58" style="stroke-width: 1px;" stroke-width="1" stroke-dasharray="0"></path>.
В столбце X код для отображения текста метки (цифра 1, 2, 3 или 4) только для тех вызовов, где она нужна. Данная избирательность выполняется с помощью формулы ЕСЛИ(U2<>none;;).
Пример текста 3:
<text x="1601" y="58" style="text-anchor: middle; font-family: times; font-weight: bolder; font-size: 8px;" stroke="none" fill="black"><tspan>3</tspan></text>.
На рисунке 8 представлен скриншот этих трёх столбцов в очень маленьком масштабе, так как иначе продемонстрировать практически невозможно из-за громоздкости текста. Также видно, насколько громоздкой получается запись формулы СЦЕПИТЬ со всеми её аргументами.


Рис. 8. Столбцы с результатами основных расчётов.

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


Рис. 9. Лист, формирующий надписи.

На листе Границы формируются все вспомогательные линии диаграммы, служащие границами зон (дат) и часов. На рисунке 10 показан скриншот, где видно формирование горизонтальных линий по зонам. В первых двух столбцах номер зоны (начиная с нуля) и её относительная вертикальная координата. В третьем столбце формируется код для SVG, рисующий линии. Здесь в формировании кода применяется не только привычная формула СЦЕПИТЬ, но и две формулы ЕСЛИ, вложенные одна в другую. Это необходимо для реализации рисования линии трёх различных цветов, в зависимости от ситуации. Как писалось выше, чёрные линии отделяет месяцы, серые недели, а светло-серые дни. Последние два цвета задаются на листе C в ячейках B17 и C17. В аргументах формулы ЕСЛИ присутствуют формулы ДЕНЬ и ОСТАТ. Первая формула распознаёт число из даты, заданной в виде целого числа, которое получено путём смещения значений номера зоны (из первого столбца) на заранее подобранную константу 42491. В частности, производится проверка на равенство числа из даты с единицей, распознавая тем самым начало нового месяца. Формула ОСТАТ применяется для распознавания начала новой недели (классический алгоритм). Во втором аргументе данной формулы стоит число 7, так как в неделе 7 дней. В частности, производится сравнение остатка от деления со значением 1. Этим значением (от 0 до 6) можно регулировать смещение дней недели на диаграмме, и оно подобрано таким образом, чтобы было соответствие реальному календарю. После формирования горизонтальных линий формируются 25 вертикальных линий уже более простым способом (23 линии на каждый час и ещё две граничные).


Рис. 10. Лист, формирующий границы.

На листе Мелочи (рис. 11) прописаны формирования дополнительной информации о свойствах диаграммы. В столбцах B и C прописаны координаты смещения для каждого элемента.


Рис. 11. Лист, формирующий дополнительную информацию.

На вкладке Занятость формируется гистограмма распределения плотности звонков во времени (рис. 12). Она представляет собой набор вертикальных линий различных длин, плотно стоящих рядом друг с другом и расположенных прямо под диаграммой. Число таких линий соответствует числу элементов времени (по 20 сек.), а именно 24*60*3=4320.


Рис. 12. Лист, формирующий гистограмму плотности вызовов.

Длина линии (высота столбика гистограммы) в точности соответствует сумме занятых элементов времени по всем 153 дням. То есть, если на текущий элемент времени в текущем дне приходится телефонный вызов, то он учитывается в гистограмме. Такой числовой массив я рассчитывал с помощью отдельной простейшей программы на Си. С помощью ячеек Excel такой расчёт сделать невозможно из-за многомерности операций. Можно было воспользоваться VBA, поместив туда соответствующий программный код, но на тот момент времени я этим средством вообще не владел. Код программы для расчёта массива значений гистограммы приведён ниже.
#include <stdio.h>#include <windows.h>int main(){int a,b,n,c,k;int q[4320];for(n=0;n<4320;n++){q[n]=0;}FILE *f,*f1;f=fopen("ab.txt","r");f1=fopen("Out.txt","w");for(c=0;c<2102;c++){fscanf(f,"%i\t%i\n",&a,&b);for(k=a;k<b;k++){q[k/20]+=1;}}for(n=0;n<4320;n++){fprintf(f1,"%i\n",q[n]);}fclose(f);fclose(f1);system("PAUSE");return 0;}

Входными данными программы служит текстовый файл ab.txt. В данный файл скопированы два столбца из листа A значений секунд начала и конца каждого вызова (об этом я уже писал выше, см. рис. 5). Рассчитанные значения массива выводятся в выходной файл Out.txt. Алгоритм расчёта простой, поэтому описывать его не стоит. Данные из выходного файла копируются в столбец D на листе Занятость. Первые три столбца условные обозначения элементов интервалов времени и их номер. Столбец E те же значение гистограммы, но масштабированные в 5 раз с округлением до целой части. Это сделано для удобного размещения гистограммы, наглядности и исключения громоздкости. Кроме того, каждое значение смещено на единицу. Это нужно для псевдо прорисовки горизонтальной оси. Даже если значение гистограммы нулевое (что характерно для ночного времени суток), один пиксель гистограммы всё равно будет изображён. Таким образом, будет прорисована ось абсцисс.

Наконец, на листе Результат объединены все сформированные коды SVG по каждому листу документа в определённом порядке (надписи и границы в первую очередь). Данное объединение я произвёл при помощи обычного копирования столбцов вручную (рис. 13). При необходимости можно написать в VBA функцию автоматического экспорта SVG файла, пробегаясь по результирующим столбцам всех листов. В самой первой строке сформирован заголовок файла. В нём указаны, прежде всего, ширина и высота картинки. Самая последняя строка, дописанная вручную, закрывает документ, точнее главный блок svg. Всего получилось около 6800 строк.


Рис. 13. Лист с объединением результатов.

Затем нужно скопировать всё содержимое этого листа в текстовый редактор (я пользовался программой AkelPad) и сохранить документ в файл с расширением svg в кодировке UTF-8. После этого, при отсутствии ошибок, файл открывается в Интернет браузере для просмотра. На рисунках ниже приведены виды различных участков получившейся картинки с различными масштабами.


Рис. 14. Общий вид получившейся диаграммы в Chrome.


Рис. 15. Левый верхний угол диаграммы (виды различных границ и названия зон).


Рис. 16. Полосы диаграммы с метками.


Рис. 17. Полосы диаграммы и гистограмма под ними.


Рис. 18. Дополнительная информация на диаграмме.


Рис. 19. Полосы диаграммы и метки часов над ними.

Подробнее..

Рисуем молекулы с помощью PostScript

18.04.2021 18:19:42 | Автор: admin

Векторная графика очень удобна для иллюстраций. Молекулы состоят из атомов соединённых связями. Хочется, чтобы операции редактирования рисунка химической структуры осуществлялись согласно физическому устройству молекул: выделил атом, перенес его, повернул фрагмент молекулы, подписал Практически все визуализаторы атомных структур экспортируют вид в растр, что усложняет подготовку иллюстраций. В этой заметке я расскажу о способе отрисовки 3D структур в векторном формате, а также о том, как в этом поможет язык PostScript.

Вместо красивой растровой картинки (слева) получим винтажную иллюстрацию (справа).Вместо красивой растровой картинки (слева) получим винтажную иллюстрацию (справа).

Достаточно много программ умеют экспортировать структуру в векторную графику: SVG, PDF, EPS. Однако, часто это сделано лишь формально - полученные изображения состоят из множества примитивов, разобрать их по атомам и связям практически невозможно. Размер такого векторного файла тоже большой, словом, беда. Из множества молекулярных конструкторов лишь два удовлетворяют по качеству кода векторной картинки: GaussView и Molden. Последняя программа доступна всем желающим, так что примеры построены с её помощью, тем не менее, все приведенные ниже рецепты применимы (с некоторыми модификациями) и к векторным иллюстрациям сделанными программой GaussView. Итак, Molden!

MoldenMolden

Открываем файл со структурой, сохраняем в PostScript.

PostScript

В файле видим человеческий текст:

%!PS-Adobe-2.0 EPSF-2.0%%Title: Molden%%For: Schaft%%Creator: Drs G Schaftenaar%%DocumentFonts: Courier%%Pages (atend)%%BoundingBox: 0 0 612 792%%EndComments%%###### User Preferences ############%%---- SIZE AND ORIENTATION OF THE PLOT ---%/size    {  0.24 } def%---- These number can be negative -------/originx {  39.0 } def/originy { 753.0 } def/angle   { -90.0 } def%For Portrait use%/originx { 40.0 } def%/originy { 240.0 } def%/angle   { 0.0 } def%and BoundingBox: 25 255 535 765

За отрисовку сфер-атомов отвечает процедура \doatom, за стержни - \dorod. Сначала отключим вывод логотипа Molden.

%---- Include Tabel & Logo, Fontsize -----/tabel {true} def/titleandlogo {true} def % ставим здесь false!

Без дальнейших модификаций рисунок будет таким, 4082 графических примитива. Несколько неудобно.

4082 примитива4082 примитива

Число примитивов можно значительно сократить небольшой правкой.

%---- SET BOND RENDERING:  ---------------%---- shadedrod, whiterod, blackrod  -----%/doatom { dosketchysmoothatom } def /dorod  { sketchyshadedrod }    def%% облегченные версии (меньше примитивов)/dosketchysmoothatom  % вместо прежнего doatom{ gsave  rx ry translate  90 -15 1 % вместо прежнего цикла 90 1 1 - это единственное изменение  { gsave    dup cos hue exch satu exch sethsbcolor sin dup scale    newpath    0 0 rad 0 360 arc    closepath fill grestore } for    grestore } def/sketchyshadedrod{ gsave  x1 y1 translate  x2 x1 neg add  y2 y1 neg add  {atan neg rotate} stopped not {  85 -15 0 % вместо 87 -3 0 - это единственное изменение  {dup  gsave  newpath   cos 1.0 cosb 0.5 mul neg add mul   hue exch satu exch sethsbcolor   sin 1.0 scale   1 cosb scale   0 0 hd 0 180 arcn   x2 x1 neg add dup mul   y2 y1 neg add dup mul   add sqrt  0 cosb eq {/cosb 1.0 def} if 0 exch cosb div translate   0 0 hd 180 360 arc  closepath fill  grestore } for  } if  grestore } def
Здесь уже 410 примитивов вместо 4082.Здесь уже 410 примитивов вместо 4082.

Пойдем дальше и напишем на сей раз свои собственные процедуры!

/doatom { docirclecoloratom } def/dorod { dostick } def% ширина связи, цвет её линии, толщина штриха/stickwidth {16} def/stickgreycolor  {0} def/strokelinewidth {4} def/docirclecoloratom{ gsave    strokelinewidth setlinewidth    rx ry translate    newpath 0 0 rad 0 360 arc closepath    gsave    hue satu 1.0 sethsbcolor fill    grestore    stroke    0 0 rad 0.75 mul -60 0 arc    stroke    grestore} def% процедура dostick уже создана Molden

Этот код произведет такую картинку:

Это очень простой рисунок, легковесный. Каждый атом - 3 примитива. Окружность, окрашенный круг, дуга. Связь - одна линия. Легко разобрать на запчасти и сделать всё что угодно.

/docircleatom{ gsave    strokelinewidth setlinewidth    rx ry translate    newpath 0 0 rad 0 360 arc closepath    gsave    1 setgray fill    grestore    stroke    gsave    1.00 0.55 scale    0 0 rad 0 180 arc    stroke    grestore    0.55 1.00 scale    0 0 rad -90 90 arcn    stroke    grestore} def

Этот код радикально сведет рисунок к черному и белому. Как в старых книгах.

Я добавил подпись - длину водородной связи. Я добавил подпись - длину водородной связи.

Заключение

PostScript удивительно хорош в создании иллюстраций. Он лёгок в освоении. В этой заметке я привёл способ как сделать простые, но подчас очень и очень нужные вещи при подготовке публикации или постера на конференцию. Однако, можно пойти дальше! Очень рекомендую книгу Mathematical Illustrations.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru