> [39] novarm   (24.12.07 14:10)

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

Матричных операций у нас нет, тут они просто не нужны. Это уже потом как будем 3D визуализацию встраивать.

См. статью Triangle Rasterization Rules из DX SDK.
Каких-то особых настроек здесь нет, разве что D3DRS_LASTPIXEL, но это не совсем то.

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

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

Вот она и формируется из залитых треугольников (два в середине и два веера на концах с кол-вом от 0 до 12 в зависимости от масштаба/ширины).

Неужели сложно в этом месте поставить If Offset < MinOffs then Offset := MinOffs, где MinOffs определяется в зависимости от текущего масштаба.

Вообще в данном случае, ИМХО, вполне можно перейти на ручной пересчёт в пиксельные координаты. Это же не 3D, всего 2 умножения и сложения на каждую вершину.
Или (в свете последнего заявления, что матричные операции не используются) так и делается?

Ещё относительно D3D/OGL для CAD (и в частности линий):
http://rsdn.ru/forum/message/2743638.flat.aspx#2743638

В D3D решили вопрос изменением треугольников - вроде работает. Всем спасибо за помощь.

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

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

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

Я же давал ссылку на обсуждение. Там, в частности, есть другая ссылка, где демонстрируется, насколько по-разному могут рисоваться OpenGL-ные линии и точки на разном железе:
http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html
Да и относительно скорости:
Но главное — нарисовать отрезок стоит гораздо дороже чем два треугольника, его образующие — буквально в разы.
В связи с чем возникает подозрение, что все эти линии-точки произвольного размера эмулируются в драйвере через треугольники. Да и обычные, однопиксельные линии могут изрядно подтормаживать - попробуйте переключить ваш рендер в wireframe и увидите. Видимо, просто никому не нужно оптимизировать их рисование, т.к. игры используют почти исключительно треугольники.

Вопрос: насколько замедляет систему переключение режимов?
В D3D это сделало использование разных типов треугольников не применимым в нашем случае.

Что такое конкретно "переключение режимов" и "разные типы треугольников"? Если quad/strip, то дело здесь не столько в смене режима, сколько в увеличении числа вызовов DrawPrimitive (лучше - меньше).

В OpenGL, как пишут знающие люди ( http://sim0nsays.livejournal.com/9502.html ), "цена вызова" ниже. Но это, видимо, относится к VBO, a с glBegin/glEnd добавляется overhead от множественных вызовов процедур. В общем, затыков хватает и там, и там.

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

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

> сколько в увеличении числа вызовов DrawPrimitive (лучше
> - меньше).

Вы статью не поняли.

OpenGL рализованна как машина состояний. И есть возможность быстро переключать эти состояния в отличии от DX. За счет этого можно сыкономить процессорное время.


> поскольку сейчас все рисуется треугольниками. А вот стоит
> ли игра свеч?

Рассчеты упростяться. Насчет вывода.

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

Тут не столько дело в драйвере, а сколько в видеокарте.

OpenGL рализованна как машина состояний. И есть возможность быстро переключать эти состояния в отличии от DX.

D3D практически такая же машина. Даже по синтаксису видно: SetRenderState, SetTextureStageState.
И вряд ли смена состояний через OpenGL принципиально быстрее. Т.е. на аппаратном уровне оно не может быть быстрее, это та же самая видеокарта. И на программном все трюки для уменьшения накладных расходов примерно одинаковы: кэширование команд (в OpenGL есть команды управления кэшированием glFlush/glFinish, про D3D написано в статье), средства для создания больших блоков команд (дисплейные списки - теоретически они более продвинуты чем D3D-шные state blocks, т.к. могут включать команды рисования; практически же именно ролью state blocks они и ограничены, а рисование, в конечном итоге, сведено к D3D-стилю - VBO).
В общем же, цитируя последний комментарий к статье, в OpenGL "DIP cost [и, видимо, переключения состояний тоже] действительно меньше, но проблема балансировки рендера никуда не уходит". Точнее, проблему можно решить, если использовать вместо общепринятого у геймдевелоперов VBO старые добрые glBegin/glEnd - с ними можно не думать о количестве реальных обращений к видеокарте, драйвер сам разделит данные на блоки оптимального размера и отправит по мере необходимости. При этом следует помнить, что производительность glBegin/glEnd далеко не дотягивает до теоретического максимума видеокарт, другой вопрос, понадобится ли этот максимум для рисования чертежа. Если (что вполне вероятно) не понадобится - OpenGL действительно будет более простым решением.
Впрочем, при наличии готового D3D-кода никаких преимуществ переписывание на OGL не даст, кроме разве что "отвязывания" от DX runtime.

В общем сделали и D3D и OpenGL (для совместимости с не-виндоус). Итог:
1. D3D чуть быстрее, вывод текстур (картинки и TrueType шрифты) проще.
Из недостатков сложнее реализация и долго отлаживать (много скрытых недочетов типа зависания после хранителя экрана, попеременная работа не на всех картах, и т.п., которые то появляются, то исчезают - пришлось поиграться с инициализациями/деинициализациями, параметрами).
2. OpenGL - рисует в нашей реализации чуть медленнее (встроили в ту же модель треугольников). Сложность с реализацией текстур (программист долго разбирался и говорит что сделано через...). Также очень заметно падает скорость при появлении текстур на некоторых видеокартах. Возможно не до конца использовали возможности OpenGL (матриц нет, например), поскольку встраивали в ту же модель которая изначально писалась под Direct3D и долго с ней не возились.

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

> Сложность с реализацией текстур (программист долго разбирался
> и говорит что сделано через...).

Свяжись со мной по почте(BasovAV@gmail.com). Возможно вы что-то не так делаете с текстурами, ибо никаких проблем не обнаружено.

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

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