Как оптимизировать определение границ произвольной фигуры ?

[vitaly_l]

Можете дать простую картинку где фигура из треугольников дает артефакты, а такаяже фигура из четырех угольников не дает?

Там кино где-то вверху по топику, Pavia гиперссылку давал (далее повторно) И в фильме прям увидите, при каких обстоятельствах, довольно часто бывают косяки. Хотя на мой взгляд, те косяки можно поправить нормалями, но не все... некоторые косяки, действительно поправить нереально, а при прямоугольном построении, их не бывает. вот кино: https://www.youtube.com/watch?v=k_S1INdEmdI

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

Придумайте фигуру которую нельзя разбить и я её вам разобью.


.

[Alex2013]

Zub разумеется «не одну собаку съел » в «кадо-строении» но насчёт обязательно четырёхвершинных полигонов для «плотных моделей » как мне кажется неправ (хотя возможно я просто что-то не так понянл ) …
"Давным давно на далеком далеком форуме " я немного возился с ОпенГл и загрузкой 3D моделей


Моя тема на форуме сайта hiasm.com

*(Задача была просто попробовать загрузить и показать хоть немного сложную модель (в конце есть даже что-то на Лазрусе но тогда я уперся в лазрусную реализацию ОпенГл (и библиотек к кол+мск )и дело дальше увы не пошло ... Но возможно когда нибудь к тем задачам еще вернусь Кто же не хотел сделать свой "типа 3д-движок" ? ( хотя-бы для украшения интерфейсов ) ... )

Но в результате я высинил что :
1 Большая часть форматов записи моделей имеют разбиение именно на треугольник ( к кстати и в АвтоКад вроде то-же )
2 Никаких «зазоров» даже при самом примитивном программном пересчёте координат быть не может ( Возможно для физических моделей есть какие-то сложности но я их не вижу)

В общем если :
Есть набор точек определяющих поверхность модели . =>
То все точки всегда можно соединить в набор треугольников (Ага старая добрая триангуляция) =>
Кроме того дополнительные точки вполне можно интерполировать по известным (сделав при необходимости просчитываемые полигоны практически точечными а модель «идеально криволинейной»)

Добавлено спустя 1 час 32 минуты 10 секунд:

Брр... "Без меня меня женили"..
Теги у меня строятся по списку "команд" (что-то вроде ну очень примитивного AutoLISP-а ) и там все с координатами нормально .
Все "эпохальное действие" поиска границ нужно просто чтобы было видно при клике куда он попал и где кончается текущая фигура
(которая может только краем выглядывать из под другой )

Именно об этом вам и говорят!!! Только делается такой поиск, с помощью TRect, а не ScanLine. И действительно, точно также ищутся и теги на html страницах. И масштабирование, как ни странно проще делать с помощью TRect. А TRect - нужно закладывать при создании фигуры, а не вычислять при каждом клике. Это вы можете понять? Вам все, только это и хотят сказать: ДЕЛАЙТЕ TRect - ЗАРАНЕЕ, а не вычисляйте его при каждом клике. Впрочем - решайте сами, вам видней.

Еще раз объясняю: редактор "как-бы не знает" что делает та или или иная "команда" (которая и сама, кстати тоже "собирается" отдельным скриптом для каждого инструмента-элемента ОТДЕЛЬНО и там даже начальную точку иметь необязательно (или например она не будет ни на на что влиять или ее данные могу тут использоваться как-то совсем ИНАЧЕ пример: то-же "демо-куб" где вместо второй точки столь любимого вами TRect сдвигом мышки водится "угол поворота +масштабный коэффициент " )

То есть для получения того, что понадобится по сути ОДИН РАЗ мне если следовать вашей "классической логике" нужно будет написать целый слой слежения за каждой графической операцией вывода из скрипта (!) пересечет и поиск минимума и максимума в том числе и ДЛЯ КАЖДОЙ ПРОЗРАЧНОЙ КАРТИНКИ (про анимированные и/или динамические элементы вообще можно даже и вспоминать ) и так-же уже есть градиент, который как пример может начинаться или заканчиваются фоновым цветом где-то в середине отведенного ему "TRect" - Да сейчас это не учитывается и прозрачность для вставленных картинок отсутствует но это точно "пока" и это только частные случаи те-же самые проблемы например будут и для уличенного штифта и для прозрачных таблиц, диаграмм и тд )

Да все это тоже как-то там решаемо ... наверное !
Но мне видится что-то существенно проще оптимизировать поиск размеров маски тем более что она и так есть и будет .
("Коллекция теректов" это красиво ... звучит ... но "тюкнуть пальцем в небо" все-же надежнее ... просто потому что нельзя даже теоретически представить вариант где можно как-то получить "мертвую зону " )

[olegy123]

Но мне видится что-то существенно проще оптимизировать поиск размеров маски тем более что она и так есть и будет .

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

[zub]

в «кадо-строении» но насчёт обязательно четырёхвершинных полигонов для «плотных моделей » как мне кажется неправ

Правильно кажется, я таеого никогда не говорил и настаиваю на 3угольниках на нижнем уровне, и на примитивах которымми удобно на уровне моделирования телла в движке\кадпрограмме

1 Большая часть форматов записи моделей имеют разбиение именно на треугольник ( к кстати и в АвтоКад вроде то-же )

Это касается "финальных" форматов для загрузки на видеокарту или 3д принтер. Поверь например "моделировать" кубик гораздо приятнее шевеля 6тью гранями-плоскостями, чем 12ю треугольниками. Возможно это Pavia и имеет ввиду, но оно никак не связано с особенностями 3х\4х угольников. Воображаемуй формат из несвязных четырехугольников также легко порвать как и из несвязных треугольников

Еще раз объясняю: редактор "как-бы не знает" что делает та или или иная "команда"

Еще раз объясняю: ты просто ленишся это "как-бы узнать" придумывая всякую хрень

[vitaly_l]

проще оптимизировать поиск размеров маски тем более что она и так есть и будет

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

Правильно кажется, я таеого никогда не говорил и настаиваю на 3угольниках на нижнем уровне, и на примитивах которымми удобно на уровне моделирования телла в движке\кадпрограмме

Всё верно! Я тоже всегда с треугольниками там работал (правда я естественно не кад, а 3D модельки там крутил с текстурами). Но там есть возможность отображеть и многоугольники. Но как они устроены не раскапывал, и вполне возможно что их в итоге тоже делят на треугольники.

Это касается "финальных" форматов для загрузки на видеокарту или 3д принтер. Поверь например "моделировать" кубик гораздо приятнее шевеля 6тью гранями-плоскостями, чем 12ю треугольниками. Возможно это Pavia и имеет ввиду, но оно никак не связано с особенностями 3х\4х угольников. Воображаемуй формат из несвязных четырехугольников также легко порвать как и из несвязных треугольников

Всё верно, это исключительно для упрощения задачи процессору.

[zub]

Еще раз объясняю: редактор "как-бы не знает" что делает та или или иная "команда"

Еще раз объясняю: ты просто ленишся это "как-бы узнать" придумывая всякую хрень.

Но мне видится что-то существенно проще оптимизировать поиск размеров маски тем более что она и так есть и будет ."

Ты наверно прикидываешся... Еще раз объясняю: "мои любимые" TRect нужны чтобы быстро отбраковать то что гарантировано не лежит "под мышкой". Нравится ползать по пикселямм (фу-фу-фу) ползай, но только на тех 2х примитивах которые возможно в данный момент под мышкой, а не на всех 100500 примитивах которые у тебя в файле.
Хотя, да, бесполезно. ЗАКАПЫВАЙТЕ

[Alex2013]

Вдогонку( чтобы не открывать новую тему )....

Народ, как можно красиво и просто сделать саму "обводку" фигуры(рамочку вокруг нарисовать ) что бы она была заметна но не создавала впечатления "вырви-глаза" диким сочетанием цветов ?

Пока остановился на вот этом коде ( рисую красный пунктир в светло серой каёмке )

Код: Выделить всё

procedure TRF1.PaintBox1Paint(Sender: TObject);
var SW,I,SS:Integer;
    SC:TColor;
    R:TRect;
 
begin
...
// Выделение при выборе фигуры
//*****************************
if fCurRec then
with CurCanvas do
  begin
   sc:=Pen.Color;
   SW:=pen.Width;
   Pen.Style:=psDash;// Пунктир
   R:=CurRec;
// Раздвигаю рамку
    dec(R.Top,2);inc(R.Bottom,3);
    dec(R.Left,2);inc(R.Right,3);

    pen.Width:=3;// кайма вокруг каждого "дефиса" 
      Pen.Color:=$bababa;// "Серо буро малиновый" :-) цвет на самом деле "пятьдесят второй оттенок серого"
      // суть в том что на белом почти невидно а на темном нет "вырви-глаза"
      Frame(R);

// главный фрейм 
   pen.Width:=1;   Pen.Color:=clRed;   Frame(R);

  fCurRec:=false;// рамка показывается один раз (любое  действие в редакторе должно ее стирать)  ...
  Pen.Style:=psSolid;
  Pen.Width:=Sw;
  Pen.Color:=SC;
end ;
//********************************
...
end ;

Пробовал разные режимы вывода с Хor Not NotХor c совместно с разными цветами ...
..результат явно хуже ...
Но может есть вариант который я просто не знаю

[vitaly_l]

Народ, как можно красиво и просто сделать саму "обводку" фигуры(рамочку вокруг нарисовать ) что бы она была заметна но не создавала впечатления "вырви-глаза" диким сочетанием цветов ?

Ага...
Рисовать - это к художникам.
Излагаю главный секрет художников по рисованию красивых рамок:
1) Рамка должна быть видна на разных цветах (светлых, тёмных, белых и чёрных).
Из этого следует: рамка, уже как минимум должна быть двух цветов: чёрный и белый.

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

3) Как это всё уложить в одну рамку и не заблудиться? Всё художественное просто! Нужно нарисовать три рамки подряд с разными типами отрывистой линии: psSolid, psDashDot, psDot и.... вуаля! Офигенно красивая и удобная рамка у Вас на экране...

Ну тут понятное дело аплодисменты художникам и коробки конфет с цветами

.

[Alex2013]

Я если честно надеялся, что кто-то подскажет как сделать одинарную "адаптивную рамку" ...
То есть темную на светлом светлую на темном и меняющую оттенок так что-бы было видно всюду но "без кислотных сочетаний " или "само-сливающихся цветов" .
Есть еще один вариант сделать "анимированную рамку" вроде тех что была модной в старых редакторах .
(но скажу честно лениво мне с этим возится )
Зы
По основной теме :
Мне тут пришла мысль а почему для ускорения типовых работ вроде Сабжа никто не берется применить разные расширения команд процессора начиная с древнего ММX? (Они ведь именно для этого предназначены более того наверняка есть готовые библиотеки )
====
Упс !
Оказывается есть даже специальный ключ компилятора {$mmx+}

[vitaly_l]

так что-бы было видно всюду но "без кислотных сочетаний " или "само-сливающихся цветов" .

дык, я вам такую и дал!

почему для ускорения типовых работ вроде Сабжа никто не берется применить разные расширения команд процессора начиная с древнего ММX

поддерживаю вопрос как подключать / отключать ММХ и подобные фишки?

[olegy123]

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

У дизайнеров есть цветовая палитра, они руководствуются правилами соотношения цветов. Только так товар становится привлекателен.
как физики штудируют матан, так дизайнеры учат эти правила ..
пример генерации:
http://paletton.com

Мне тут пришла мысль а почему для ускорения типовых работ вроде Сабжа никто не берется применить разные расширения команд процессора начиная с древнего ММX? (Они ведь именно для этого предназначены более того наверняка есть готовые библиотеки )

если внутри библиотек нет явного asm кода - компилятор сам, согласно установленным флажкам генерит код с нужной оптимизацией..
Даже "Hello Word" - может написан с SSE инструкциями..

[Alex2013]

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

У дизайнеров есть цветовая палитра, они руководствуются правилами соотношения цветов. Только так товар становится привлекателен.
как физики штудируют матан, так дизайнеры учат эти правила ..
пример генерации:
http://paletton.com

Спасибо гляну !
(Может даже выдеру настройку палитры в отдельный элемент-инструмент ... Хотя возни там будет немало ! )

Мне тут пришла мысль а почему для ускорения типовых работ вроде Сабжа никто не берется применить разные расширения команд процессора начиная с древнего ММX? (Они ведь именно для этого предназначены более того наверняка есть готовые библиотеки )

если внутри библиотек нет явного asm кода - компилятор сам, согласно установленным флажкам генерит код с нужной оптимизацией..
Даже "Hello Word" - может написан с SSE инструкциями..

Все это замечательно .... но надежнее где надо "ручками вызвать"
(разумеется проверив результат "рукоделия" на "ускорение и перестройку")
Кроме того, оказывается есть даже типы данных вроде tmmxinteger специально заточенные для использования с расширенным набором команд процессора.
----
...И модуль ММX
http://www.math.uni-leipzig.de/pool/tut ... ode14.html
М’да "маловато будет" ...

[Alex2013]

И так новая итерация оптимизации ...
Теперь работает и с фигурами разделенными на вертикальные сегменты .(Проверенно! )
Нашел способ быстрой проверки пустой линии (просто сравниваю с "эталоном" с помощью быстрой функции из модуля System )

Код: Выделить всё

// Номер команды по клику
// и определение границ текущей фигуры
Function GetCMDOnClik(X,Y:Longint):Longint;
Type
  TLine=Array  [0..2] of byte;
Var
B:TBitmap;
I,Y1,X1:longint;
R:TRect;
PLine,ELine:^TLine;
begin
Result:=-1;

If drawlist= Nil  then exit;
If drawlist.Count=0  then exit;
B:=TBitmap.Create;
B.SetSize(rf1.PaintBox1.Width,rf1.PaintBox1.Height);
Getmem(ELine,b.Width-1); // ! Эталонная линия 
FillChar(ELine^,b.Width-1,$F2);// Заполнение
CurCanvas:=B.Canvas;
     For I:=DrawList.Count-1 downto 0 DO
      begin
       b.Canvas.Brush.Color:=$f2f2f2;//!  С нулевым цветом бывали глюки
       CurCanvas.FillRect(0,0,b.Width,b.Height);
       CurCanvas.Pen.Mode:=pmWhite;// ! Режим создания маски (все рисуется белым )
          RF1.FastDrawFig(I,1); //Рисую одну фигуру на чистом битмапе 
        CurCanvas.Pen.Mode:=pmCopy;
     
      if  TLine(b.ScanLine[Y]^)[X*3]<>$f2
         {Старый вариант  b.Canvas.Pixels[X,Y]<>$f2f2f2}
          then
            begin
    //Дополнительно определение границ
    // текущей фигуры

   {Начальные значения "выворачиваю на изнанку" }
   R.Left:=b.Width;R.Top:=b.Height;   R.Right:=0;R.Bottom:=0;
   {========================================}

// от текущей точки сканирую ввниз
     for Y1:=Y to b.Height-1 do begin
       PLine :=b.ScanLine[Y1];
       If CompareWord(PLine^,ELine^,b.Width-1)<>0 then
        //Быстрая проверка на пустую линию       
        for X1:=0 to b.Width-1 do
          if PLine^[X1*3]<>$f2 then
           begin
            If Y1<R.Top then R.Top:=Y1;
            If X1<R.Left then R.Left:=x1;
            If X1>R.Right then R.Right:=x1;
            If Y1>R.Bottom then R.Bottom:=Y1;
           end;
     end;
// от текущей точки сканирую вверх
            for Y1:=Y downto 0 do begin
             PLine :=b.ScanLine[Y1];
             If CompareWord(PLine^,ELine^,b.Width-1)<>0 then
              for X1:=b.Width-1 downto 0 do
                if PLine^[X1*3]<>$f2 then
                 begin
                 If Y1<R.Top then R.Top:=Y1;
                 If X1<R.Left then R.Left:=x1;
                 If X1>R.Right then R.Right:=x1;
                 //If Y1>R.Bottom then R.Bottom:=Y1;
                 end;
           end;
//============================
           CurRec:=R;
           fCurRec:=True;
           Result:=I;// Номер в списке
           break;
        end;
     end;
CurCanvas:=rf1.PaintBox1.Canvas;
FreeMem(ELine,b.Width-1);
b.Free;
end;

Вопрос: почему вариант с CompareByte не работает после левого края фигуры (R.Left) больше 225 (даже меньше 255! )?
Ну ладно мне сейчас все равно CompareWord или CompareByte... Но в других случаях может быть иначе !

[zub]

>> так новая итерация оптимизации ...
дада, проходите, на что жалуетесь?

>>b.Canvas.Brush.Color:=$f2f2f2;//! С нулевым цветом бывали глюки
с f2 будут такиеже глюки, только пореже и понеобьяснимей))

>>b.Canvas.Brush.Color:=$f2f2f2;//! С нулевым цветом бывали глюки
>>FillChar(ELine^,b.Width-1,$F2);// Заполнение

«Что за 42?» или Магические числа (Magic numbers)

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

[Alex2013]

Я про "Фому" а мне про "Ярему"...

с f2 будут такие же глюки, только пореже и понеобьяснимей))

Написано ведь ...

CurCanvas.Pen.Mode:=pmWhite;// ! Режим создания маски (все рисуется белым )

То есть цвета $f2f2f2 или любого другого быть не должно .
(Почему с нулем есть какие-то трудно уловимые проблемы действительно неясно ...
поэтому НЕ 0(clBlack ) и НЕ $FFFFFF(clWhite) но "Магические числа" не причем, а $f2f2f2 в место $f2 стало потому, что
появилась быстрая проверка "горизонтали" ( нужно было заполнить эталон и проверить побайтово ) )

дада, проходите, на что жалуетесь?

Опять-же написано вроде ....

Вопрос: почему вариант с CompareByte не работает после левого края фигуры (R.Left) больше 225 (даже меньше 255! )?
Ну ладно мне сейчас все равно CompareWord или CompareByte... Но в других случаях может быть иначе !

Да и не жалуюсь я, просто решил поделится очередным УСПЕШНЫМ ОПЫТОМ до которого додумался в результате "мозгового штурма " в том числе обдумывая и твои советы ... Кроме шуток, спасибо !