Как состыковать фрагменты картинки?
 

Сабж. Нарезаю, а затем складываю картинку из фрагментов, появляются вот, такие вот, просветы. Как это утрясти? Координаты типа Number. Если ставлю int то, естественно, потом не хватает снизу и/или сбоку.

Нарезать нужно на целые координаты. То есть не нужно делить 110 на 3 части. Тогда всё встанет отлично.

Даже если 110 на 3 - округлить 110 до близжайшего кратного трем, запомнить разницу, близжайшее кратное поделить, а потом из результата вконце вычесть разницу.
Т.е. например:
близжайшее кратное для 110 будет 111, находим следующим образом: Math.ceil(110 / 3).
разница: 1 (Находим: 111 - 110).
нарезаем: первый "кусок": (111 / 3) * 1 = (0..37). Второй "кусок" (111 / 3) * 2 - "первый кусок" = (37..74). "Последний кусок": (111 / 3) * 3 - ("второй кусок" + разница) = (74..110).

Блин! А, ведь, действительно!
Спасибо, wvxvw! Я знал, что в беде не оставишь! Огромное спасибо! :)

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

В развитие сабжа.
Сегменты строю через shape.graphics.drawPath, задавать ли lineStyle(1, color, 1, true/false), или не задавать вовсе толщину линии - не заметил существенной разницы. К фигуре применяю фильтр, после чего отрисовываю ее в отображаемой Bitmap'e, общей для всех сегментов, через BitmapData.draw(..).
Объект анимирован. Если btm.stage.quality = StageQuality.LOW, то промежутки м/у сегментами исчезнут, естественно, заодно с антиалиазингом, который не был лишним.
Алиазинг, положим, не проблема, - его могу "размазать" фильтром,- но места стыков сегментов выглядят все равно не важно: при определенных углах становятся заметными "тени" - нормали пикселей не стыкуются, как должны.
Возможно, кто-то сталкивался с такой проблемой - как лучше поступить в этом случае: может быть проще смешать цвет граничного пиксела и его соседей в уже отрендеренном соседнем сегменте? Хорошо бы "подмешать" соседей из обрабатываемого сегмента, но тут я не вполне понимаю (а найти указаний на этот счет не удалось) механику обработки шейдером входного изображения - может ли шейдер обратится к уже обработанному пикселу (т.е. может ли оказаться таким samplenearest(outCoord().x+1, outCoord().y+1)?), или входное изображение кешируется на время работы шейдера (тогда "подмес" соседей по сегменту неуместен)?
Шейдеры пишу не в Pixel Bender, a посредством PBJ Assembler, и вследствие муторности этого приема, не хочется экспериментировать лишнего. Да и любой фильтр - тормоз, а здесь, хоть и по граничным только точкам, но опрашивать 9 соседей в отрендеренном сегменте и 8 в своем - это не есть хорошо.
Идеальный случай был бы - состыковать точно фрагменты, но не дается.

Буду признателен за любые идеи.

Я такую штуку делал внахлест на один пиксель. тогда ок. Если полотно совсем уж большое, то можно и больше, но одного как правило достаточно.

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

ещё советую прочитать вот это http://habrahabr.ru/post/147165/

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

to Aquahawk:
И с прозрачностью я уже экспериментировал. Неделя убита на тесты.

Через drawTriangles нормально у меня всё стыковывалось. Там есть параметр smothing.
Ну а вообще надо целочисленные и copypixels в битмапу.

Если произвести триангуляцию сегментов, то, при малых значениях площадей этих самых треугольников, после усреднения нормалей на границах стыков, наверное и будет "нормально все стыковаться". Могу и я "смузить" фильтром границы (хотя сделать это хорошо, или хотя бы "нормально" весьма непросто). Но у меня нет треугольников (и свойство smoothing (?) я вижу лишь в BitmapData для ситуаций масштабирования, но я и не масштабирую ничего ни в процессе анимации, ни в каком другом случае). Целочисленными координатами воспользоваться не представляю как! Возможно, что в этом что-то есть, но посмотрите на рисунок: положение сегмента при визуализации определяет его Rec.topLeft, верхняя левая точка ограничивающего прямоугольника, для примыкающего к этому сегменту сегмента, может лежать внутри него, и может иметь вполне себе целочисленные значения координат, между тем, что первый сегмент (условно) 'сдвинется' после округления координат его topLeft.

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

:) Это такой деликатный способ сказать, что выбранный мной подход к построению этого изображения неудачен, и надо все переделать по "классике" (как она Вам видится), или еще один известный способ сказать on the subject "не знаю"? Последнюю свою курсовую я сдал,- как я подозреваю,- задолго до Вашего рождения (или около того), и хотя это мало относится к делу, как и Ваше недоумение по поводу странности моих предпочтений, но, для построения последующий версий относительно моих надобностей, этот факт отмечу. Я программирую от случая к случаю, главным образом в свое удовольствие, случается, что для своих практических нужд, на всем, "что под руку подвернется", и с недавнего времени, и на ActionScript. Прямо коммерциализовать ничего из написанного не пытался. На будущее, для объяснения моих "странностей" (если окажутся не последними) смело используйте мюллеровское - "трудно понять логику непрофессионала" (к-ф "17 мгновений весны").
Мне не показалась уместной полигональная модель в данном случае (не настаиваю на своей правоте): поверхности все имеют простое аналитическое представление, и не имеют текстуры. Чтобы восстановить 3-ю координату у плоской и даже искаженной перспективным преобразованием точки, и построить нормаль, для моделирования освещенности, требуется вычислить только один корень. Я не решаю проблему 3D триангуляции и не экспортирую из 3DMax'a сетку для грани куба, а имею смехотворно малое количество реперных точек, на которых отрисовываю грань. Скорость рендеринга меня более чем устраивает. Проблема, однако же, есть, но я не уверен, что она стоит того, чтобы все переделать!. Эти раздражающие меня линии видны лишь под определенным углом, хотя этого достаточно, чтобы раздражать перфекциониста. Уверен, что побороть этот дефект как-то можно (может добавив в шейдер, отвечающий за освещенность, механизм дизеринга, или "размазав" края, или что-то еще...), хотелось бы избежать при этом собственных "шишек", воспользовавшись, к примеру, Вашим опытом - если Вы убедительно скажете, что в подобной ситуации, Вы не нашли другого выхода, как применить полигональную модель, то я тотчас же брошу начатое и пущусь по Вашим стопам.
Если Вам фигуры моей речи показались несколько ехидными ;) , то это напрасно, я искренне благодарен за все сделанные здесь советы, и Вами и другими. Один из любимых мною персонажей Рендл Макмерфи: "Я хотя бы попытался...".

Отрадно видеть, человека, который в свои ~60 лет увлекается такими задачами!

Я вижу текстурированную кость.

Кость? Вы имеете ввиду игральную кость, или, - боюсь предположить,- Вы вкладываете некое иное значение в слово "кость" ? "Текстурой " я полагал изображение, перенесенное на отображаемую поверхность или сгенерированное программно на этой поверхности, напр. камень, дерево и т.п.. Изменить цвет пиксела в соответствии с моделью освещения - это тоже текстура?
P.S. Как говорил кот Матроскин: "Я еще и вышивать могу.."

Ок. Начнем сначала.

1. Отрисовали одноцветные сегменты с помощью drawPath
2. Пробежались по всем сегментам и вызвали для каждого соотв. шейдер, чтобы "нарисовать" свет

На этапе 1 все отл., на этапе 2 появились швы.

Вопрос: stage.quality = StageQuality.LOW делается перед первым этапом? Или между первым и вторым после того, как первый этап уже отрисован в BitmapData?

1. Отрисовали один одноцветный сегмент с помощью drawPath
2. Присвоили ему фильтр (соотв. шейдер, чтобы "нарисовать" свет)
3. Для "холста", в котором размещены (будут отрисованы) все сегменты, делаем stage.quality = StageQuality.LOW
4. "Рисуем" (.draw)
5. Возвращаем качество

Я могу передать в шейдер битмапдату рисунка, и внутри шейдера присвоить цвет сегмента пикселу с "неполной" альфой (в этом случае LOW не требуется, но антиалиасинг сохраняется, что кстати). Однако, "тень" полоса все равно заметна. Разница визуально трудноуловима.

Добавлено через 44 часа 24 минуты
Кстати, обращение к свойству stage объекта ведет к перерисовке всей сцены. т.е. без особой надобности лишний раз лучше не беспокоить.

Все расстояния привязываем к topLeft основной BitmapData, В которой производим конечную отрисовку, т.е. пространственная координата любой точки расчитывается таким образом:
например х: float(основная BitmapData).topLeft.x + (int(обрабатываемая вставка).topLeft.x - int(основная BitmapData).topLeft.x + i-положение пиксела в обрабатываемой вставке). В случае моего расчета, когда я восстанавливал координату z по плоским ху, эти малости оказались существенными.