Здравствуйте, всем доброго дня.

Я хочу модернизировать интерфейс одной своей разработки. Суть следующая: на рабочей области нужно размещать примитивы — многоугольники, эллипсы, параболики — и мне хотелось бы делать это именно так, как это реализовано в AutoCAD'е. То есть, чтобы все примитивы можно было бы легко редактировать мышкой, прибегая к помощи диалогов только в крайнем случае. Очевидно, что это стандартная задача из вектороной графики и наверняка существует вполне устоявшийся способ её решения. С какой стороны подступиться — написать какие-то компоненты (какие и как?), которые бы помещались в контейнер, служащий рабочей областью или просто на ООП реализовать классы с кучей методов?

Здравствуйте, Михаил Дюмин, Вы писали:

МД>Здравствуйте, всем доброго дня.

МД>Я хочу модернизировать интерфейс одной своей разработки.
Ага..

МД>Суть следующая: на рабочей области нужно размещать примитивы — многоугольники, эллипсы, параболики — и мне хотелось бы делать это именно так, как это реализовано в AutoCAD'е. То есть, чтобы все примитивы можно было бы легко редактировать мышкой, прибегая к помощи диалогов только в крайнем случае.
Круто.

МД>Очевидно, что это стандартная задача из вектороной графики и наверняка существует вполне устоявшийся способ её решения.
Ничего не устоялось. И при чем тут "задача векторной графики"?

МД>С какой стороны подступиться — написать какие-то компоненты (какие и как?), которые бы помещались в контейнер, служащий рабочей областью или просто на ООП реализовать классы с кучей методов?
А как же. Написать компоненты. Потом в контейнер. Ну и уж никуда не деться от классов с кучей методов.

А если серьезно, то можно свободно пользовать подход студии.
Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе. Кроме того нужны дизайнеры : классы, которые будут отображать на рабочем поле "фишечки", добавлять контролы-"прямоугольнички", контролы-"стрелочки" и т.д., модифицируя внутреннее представление классов примитивов. По правой клавише — GetDesignVerbs и т.д.

Здравствуйте, Михаил Дюмин, Вы писали:

МД>Я хочу модернизировать интерфейс одной своей разработки. Суть следующая: на рабочей области нужно размещать примитивы — многоугольники, эллипсы, параболики — и мне хотелось бы делать это именно так, как это реализовано в AutoCAD'е. То есть, чтобы все примитивы можно было бы легко редактировать мышкой, прибегая к помощи диалогов только в крайнем случае. Очевидно, что это стандартная задача из вектороной графики и наверняка существует вполне устоявшийся способ её решения. С какой стороны подступиться — написать какие-то компоненты (какие и как?), которые бы помещались в контейнер, служащий рабочей областью или просто на ООП реализовать классы с кучей методов?

В последних версиях AutoCAD'а (Начиная с 2000) встроен VBA, и открыта архитектура(Описания классов и методов в хелпе имеются) и подробно изучив ее можно получить представление о том, как это реализуется. У меня где-то до сих пор иерархия классов в dwg формате лежит.

У меня есть простенький векторный редактор (взят из книги "Программирование графики в Windows"). Он позволяет рисовать простенькие примитивы (линии, окружности, элликсы, полилинии, полигоны...), масштабировать их и перемещать. также позволяет выставлять свойства линий. Там есть пара ошибок, но для изучения это не существенно. Написан на VC++6 и чистом API. Если интересно — могу скинуть на майл.

Здравствуйте, Poudy, Вы писали:

МД>>Суть следующая: на рабочей области нужно размещать примитивы, как в AutoCAD'е.
P>Круто.
Ещё бы.

МД>>Очевидно, что это стандартная задача из вектороной графики и наверняка существует вполне устоявшийся способ её решения.
P>И при чем тут "задача векторной графики"?
Видимо при том, что AutoCAD по сути — граф.редактор, пусть и специализированный. А подобный интерфейс — вещь для векторной графики, вроде бы, стандартная...
Ну да ладно, не в этом суть.

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

P>А если серьезно, то можно свободно пользовать подход студии.
P>Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе.

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

P>Кроме того нужны дизайнеры : классы, которые будут отображать на рабочем поле "фишечки", добавлять контролы-"прямоугольнички", контролы-"стрелочки" и т.д., модифицируя внутреннее представление классов примитивов. По правой клавише — GetDesignVerbs и т.д.

Интересная идея. Надо будет надо всем этим подумать.
А вообще, придётся поизучать идеологию конторолов. Создавать их мне ни разу не приходилось.

Спасибо за ответ.

Здравствуйте, Михаил Дюмин, Вы писали:


МД>Пока ждал хоть какого-нибудь ответа, пришёл к выводу, что всё можно сделать без каких-либо контролов. Всё вполне укладывается стандартное ООП без APIшных наворотов.
При желании почти все можно уложить в ООП без наворотов. Это не самоцель.

P>>А если серьезно, то можно свободно пользовать подход студии.
P>>Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе.

МД>Хмм... А смысл? Ведь в моём случае, если я правильно понимаю, экземпляров контролов будет столько же, столько и экземпляров примитивов, и наличие у контрола нескольких дополнительных полей ничего не изменит. Какой смысл выделять поля, отвечающие за сам примитив, в отдельный класс?

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

Один контрол изображает внешний вид, другие позволяют редактировать свойства. Дизайнер знает обо всех них, принимает сообщения, обрабатывает клавиши, а также:
• перекачивает данные из контролов в классы примитивов, чтобы при последующем вызове у экземпляра класса примитива метода
вроде CalculateBodyAngle или свойства NormalLine, все обсчитывалось правильно.
• предоставляет дизайнеру сцены (или там... чертежа).. получать данные о snappoint's.
• Сам, или созданные им тулзы, кладут транзакции (команды) о выполняемых операциях в стек отмены текущего дизайнера сцены
(или специального DesignService).

Здравствуйте, Nata1111, Вы писали:

N>В последних версиях AutoCAD'а (Начиная с 2000) встроен VBA, и открыта архитектура(Описания классов и методов в хелпе имеются) и подробно изучив ее можно получить представление о том, как это реализуется. У меня где-то до сих пор иерархия классов в dwg формате лежит.
То есть, надо полагать, что и в Mechanical Desktop 6 это тоже есть. Гляну...

N>У меня есть простенький векторный редактор (взят из книги "Программирование графики в Windows"). Он позволяет рисовать простенькие примитивы (линии, окружности, элликсы, полилинии, полигоны...), масштабировать их и перемещать. также позволяет выставлять свойства линий. Там есть пара ошибок, но для изучения это не существенно. Написан на VC++6 и чистом API. Если интересно — могу скинуть на майл.

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

(Собственно, прога написана два года назад на VC++ 6.0. Работает вполне нормально и впечатление производит. Но интерфейс никуда не годится и исходник там местами страшный настолько, что умным людям его показывать опасно для собсвенной репутации. Вот и взялся переписать кое-что от нехрен делать)

Здравствуйте, Михаил Дюмин, Вы писали:

Можно микрософтовскйи примерdrawcli за основу взять и под себя заточить.

Можно поиском по сайту найти Rogue Wave Stingray Studio и разобратся с ихней Objective Views.

Здравствуйте, Михаил Дюмин, Вы писали:

МД>Пока ждал хоть какого-нибудь ответа, пришёл к выводу, что всё можно сделать без каких-либо контролов. Всё вполне укладывается стандартное ООП без APIшных наворотов.

P>>А если серьезно, то можно свободно пользовать подход студии.
P>>Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе.

МД>Хмм... А смысл? Ведь в моём случае, если я правильно понимаю, экземпляров контролов будет столько же, столько и экземпляров примитивов, и наличие у контрола нескольких дополнительных полей ничего не изменит. Какой смысл выделять поля, отвечающие за сам примитив, в отдельный класс?

P>>Кроме того нужны дизайнеры : классы, которые будут отображать на рабочем поле "фишечки", добавлять контролы-"прямоугольнички", контролы-"стрелочки" и т.д., модифицируя внутреннее представление классов примитивов. По правой клавише — GetDesignVerbs и т.д.

МД>Интересная идея. Надо будет надо всем этим подумать.
МД>А вообще, придётся поизучать идеологию конторолов. Создавать их мне ни разу не приходилось.

В ACAD-е есть графические (entity) и не графические объекты (просто object). Для графических объектов ACAD сам вызывает функции отрисовки в конкретном контексте рисования. Так что как надо рисоваться знает только сам объект. За сериализацию объектов отвечают тоже сами же объекты. И скажите еще, что у ACAD-а плохой дизайн приложения.

Вообще-то можно и разделять объекты данных и объекты отображения. Смотря, какие задачи стоят. А делать это ради того чтобы сделать – “суета одна и томление духа”.

Здравствуйте, Poudy, Вы писали:

P>А если серьезно, то можно свободно пользовать подход студии.
P>Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе. Кроме того нужны дизайнеры : классы, которые будут отображать на рабочем поле "фишечки", добавлять контролы-"прямоугольнички", контролы-"стрелочки" и т.д., модифицируя внутреннее представление классов примитивов. По правой клавише — GetDesignVerbs и т.д.

Не надо делать классы примитивов.

Класс, который реализует редактирование примитива ("дизайнеры") еще куда ни шло, но
класс для самого примитива — не стоит. Достаточно контейнера.

Здесь уже начинает работать правило больших объемов — накладные расходы на создание-удаление
объекта класса будут очень велики.

Павел

Здравствуйте, bizhan, Вы писали:

B>Не надо делать классы примитивов.

B>Класс, который реализует редактирование примитива ("дизайнеры") еще куда ни шло, но
B>класс для самого примитива — не стоит. Достаточно контейнера.

А куда тогда запихнуть геометрические расчеты? И как иначе сделать легким расширение библиотеки примитивов?
Я почти уверен, что поверхность не стоит хранить как множество отрезков, только в таком контексте поверхность — тоже
примитив. А не примитивы — только составные объекты.

B>Здесь уже начинает работать правило больших объемов — накладные расходы на создание-удаление
B>объекта класса будут очень велики.

• 100 000 никого не запарят;
• совсем необязательно инстанциировать все объекты;
• сериализовывать можно и в контейнеры;


B>Павел

Здравствуйте, bizhan, Вы писали:

P>>А если серьезно, то можно свободно пользовать подход студии.
P>>Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе. Кроме того нужны дизайнеры : классы, которые будут отображать на рабочем поле "фишечки", добавлять контролы-"прямоугольнички", контролы-"стрелочки" и т.д., модифицируя внутреннее представление классов примитивов. По правой клавише — GetDesignVerbs и т.д.

B>Не надо делать классы примитивов.

B>Класс, который реализует редактирование примитива ("дизайнеры") еще куда ни шло, но
B>класс для самого примитива — не стоит. Достаточно контейнера.

B>Здесь уже начинает работать правило больших объемов — накладные расходы на создание-удаление
B>объекта класса будут очень велики.

А вот скажи, пожалуйста, ты САМ (в команде) что-то разрабатывал достаточно большое? Или просто умных книжек почитал?

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

Кроме того, при достаточно сильной связи между объектами (составные объекты, ownership, etc) будет достаточно сложно реализовать управление объектами в принципе. Ведь по классической схеме объект данных (контейнер) ничего не знает о своем accessor-е. Поэтому все управление должно быть централизованно.

Так что предлагаю посмотреть, для начала, как это сделано у людей.

Здравствуйте, Poudy, Вы писали:

P>Здравствуйте, bizhan, Вы писали:


P>А куда тогда запихнуть геометрические расчеты? И как иначе сделать легким расширение библиотеки примитивов?

Пример расчетов. Таких, что их надо реализовывать на уровен одного примитива.
Легко расширение библиотеки примитивов — это хороший вопрос. Я не знаю универсального решения.
Хорошие — известны, но часто зависят от конкретной предметной области.

P>Я почти уверен, что поверхность не стоит хранить как множество отрезков, только в таком контексте поверхность — тоже
P>примитив. А не примитивы — только составные объекты.

Я про другое. Я про то, что класс для каждого типа примитива — это не самое удачное решение.
Например,

class Line {}
class Rectangle {}
class PolyLine {}
class Ellipse {}
class Surface {}

+ к ним контейнеры

Line Lines[];
...

и так далее.

B>>Здесь уже начинает работать правило больших объемов — накладные расходы на создание-удаление
B>>объекта класса будут очень велики.

P>• 100 000 никого не запарят;
P>• совсем необязательно инстанциировать все объекты;
P>• сериализовывать можно и в контейнеры;

О том и речь.
То, что тебя не запарят 100 000 объектов — это вопрос.
Вот алгоритм (условно) для отрисовки только тех, кого надо.
Есть rectangle окна.

foreach(Line *pLine in Lines){
 if(pLine->Intersect(rectangle)) {
   pLine->Draw();
}
}

Я про то, что этот вариант — не самый удачный.

Причины, например такие:
1. индексы
2. свопинг
3. если хранение в БД, то инициализировать объекты придется

Мой поинт таков — правило больших объемов.
Основная работа, это:
1. отрисовать _много_ примитивов (а не один)
2. редактировать один или несколько.

То есть, упор именно на работу с многими объектами.

Павел

Здравствуйте, Exhumer, Вы писали:


E>А вот скажи, пожалуйста, ты САМ (в команде) что-то разрабатывал достаточно большое? Или просто умных книжек почитал?

Да, разрабатывал. Система для кабельных сетей. Подстанции, кабели и так далее.
Система разработана и успешно внедрена например на Шереметьево и в 7 районе Московской кабельной сети. И еще десятке организаций Москововской области.

И книжки умные я тоже почитал.

E>Я тут выше писал, как это сделано в ACAD-е. Все графические объекты имеют единообразный алгоритм взаимодействия с пользователем. Поэтому все стандартные команды могут работать с custom объектами, т.е. расширениями стандартных классов. Также можно реализовать расширения протоколов (ACAD-овских) для каждого из классов.

А как это противоречит тому, что написал я?-)

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

А вот уже редактирование — это конкретика. Общее в редактировании тоже есть, это само собой,
но конкретики больше. Сравни — редактирование полигона и редактирование эллипса.

E>Кроме того, при достаточно сильной связи между объектами (составные объекты, ownership, etc) будет достаточно сложно реализовать управление объектами в принципе. Ведь по классической схеме объект данных (контейнер) ничего не знает о своем accessor-е. Поэтому все управление должно быть централизованно.

Это правда. Ты сам пишешь, что объектом данных выступает не объект типа примитива (конкретного),
а весь контейнер. А вся работа с ним — внешняя. Я об этом и говорю.

Павел

p.s а сам-то что-нить сделал или книжек почитал?-))

Здравствуйте, Nata1111, Вы писали:

N>Здравствуйте, Михаил Дюмин, Вы писали:

МД>>Я хочу модернизировать интерфейс одной своей разработки. Суть следующая: на рабочей области нужно размещать примитивы — многоугольники, эллипсы, параболики — и мне хотелось бы делать это именно так, как это реализовано в AutoCAD'е. То есть, чтобы все примитивы можно было бы легко редактировать мышкой, прибегая к помощи диалогов только в крайнем случае. Очевидно, что это стандартная задача из вектороной графики и наверняка существует вполне устоявшийся способ её решения. С какой стороны подступиться — написать какие-то компоненты (какие и как?), которые бы помещались в контейнер, служащий рабочей областью или просто на ООП реализовать классы с кучей методов?

N>В последних версиях AutoCAD'а (Начиная с 2000) встроен VBA, и открыта архитектура(Описания классов и методов в хелпе имеются) и подробно изучив ее можно получить представление о том, как это реализуется. У меня где-то до сих пор иерархия классов в dwg формате лежит.

N>У меня есть простенький векторный редактор (взят из книги "Программирование графики в Windows"). Он позволяет рисовать простенькие примитивы (линии, окружности, элликсы, полилинии, полигоны...), масштабировать их и перемещать. также позволяет выставлять свойства линий. Там есть пара ошибок, но для изучения это не существенно. Написан на VC++6 и чистом API. Если интересно — могу скинуть на майл.

И мне, и мне ... vva@udm.ru

Здравствуйте, bizhan, Вы писали:

E>>А вот скажи, пожалуйста, ты САМ (в команде) что-то разрабатывал достаточно большое? Или просто умных книжек почитал?

B>Да, разрабатывал. Система для кабельных сетей. Подстанции, кабели и так далее.
B>Система разработана и успешно внедрена например на Шереметьево и в 7 районе Московской кабельной сети. И еще десятке организаций Москововской области.

А вы под конкретный заказ писали или так вообще? Просто интересно.

B>И книжки умные я тоже почитал.

Извини, что вышло как наезд. Вообще-то, неправильно получилось. Я должен был описать это Poudy. То ли Opera глюкнула, то ли я :)

E>>Я тут выше писал, как это сделано в ACAD-е. Все графические объекты имеют единообразный алгоритм взаимодействия с пользователем. Поэтому все стандартные команды могут работать с custom объектами, т.е. расширениями стандартных классов. Также можно реализовать расширения протоколов (ACAD-овских) для каждого из классов.

B>А как это противоречит тому, что написал я?-)

Никак!

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

B>А вот уже редактирование — это конкретика. Общее в редактировании тоже есть, это само собой,
B>но конкретики больше. Сравни — редактирование полигона и редактирование эллипса.

Ну да. Тут уж каждый (примитив) сам все про себя знает.

E>>Кроме того, при достаточно сильной связи между объектами (составные объекты, ownership, etc) будет достаточно сложно реализовать управление объектами в принципе. Ведь по классической схеме объект данных (контейнер) ничего не знает о своем accessor-е. Поэтому все управление должно быть централизованно.

B>Это правда. Ты сам пишешь, что объектом данных выступает не объект типа примитива (конкретного),
B>а весь контейнер. А вся работа с ним — внешняя. Я об этом и говорю.

Консенсус.

B>p.s а сам-то что-нить сделал или книжек почитал?-))

RCAD Steel — гражданское строительство. Проект развивается уже три года. Ну и книжки само собой :).

Здравствуйте, Exhumer, Вы писали:

E>А вот скажи, пожалуйста, ты САМ (в команде) что-то разрабатывал достаточно большое? Или просто умных книжек почитал?
Сейчас разрабатываю ERP, а в составе нее дизайнер форм.

E>Я тут выше писал, как это сделано в ACAD-е. Все графические объекты имеют единообразный алгоритм взаимодействия с пользователем. Поэтому все стандартные команды могут работать с custom объектами, т.е. расширениями стандартных классов. Также можно реализовать расширения протоколов (ACAD-овских) для каждого из классов.

Довольно нетривиально понять, что ты тут написал.

E>Все графические объекты имеют единообразный алгоритм взаимодействия с пользователем.
Это чем-то отличается от базового класса?

E>Поэтому все стандартные команды могут работать с custom объектами, т.е. расширениями стандартных классов.
"Стандартных классов" не примитивов? А чего тогда?

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



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

E>Ведь по классической схеме объект данных (контейнер) ничего не знает о своем accessor-е. Поэтому все управление должно быть централизованно.
Ну да, в дизайнере оно и будет централизовано. Только зачем в дизайнер запихивать метод нахождения касательной? А если нет класса примитива, то куда это поместить?

E>Так что предлагаю посмотреть, для начала, как это сделано у людей.
Не имею ничего против.

Здравствуйте, bizhan, Вы писали:

B>Пример расчетов. Таких, что их надо реализовывать на уровен одного примитива.
B>Легко расширение библиотеки примитивов — это хороший вопрос. Я не знаю универсального решения.
B>Хорошие — известны, но часто зависят от конкретной предметной области.
Примитив — просто универсальный доступ к объекту. Базовый класс. То, у чего есть отдельный дизайнер.
Соотв. поверхности, пересечения, геометрические преобразования, типа размножения с поворотом, вытягивания — примитивы.


B>Я про другое. Я про то, что класс для каждого типа примитива — это не самое удачное решение.
B>Например,

B>О том и речь.
B>То, что тебя не запарят 100 000 объектов — это вопрос.
B>Вот алгоритм (условно) для отрисовки только тех, кого надо.
B>Есть rectangle окна.

B>

B>foreach(Line *pLine in Lines){
B> if(pLine->Intersect(rectangle)) {
B>   pLine->Draw();
B>}
B>}

B>

B>Я про то, что этот вариант — не самый удачный.

Может быть. На мой взгляд — это проблема аглоритма. Если заранее поделить область редактирования на клетки (кубы),
т.е. самый большой контейнер реализовать как группу контейнеров поменьше, то необязательно обходить все объекты.

B>Причины, например такие:
B>1. индексы
B>2. свопинг
B>3. если хранение в БД, то инициализировать объекты придется

B>Мой поинт таков — правило больших объемов.
B>Основная работа, это:
B>1. отрисовать _много_ примитивов (а не один)
B>2. редактировать один или несколько.

Опять же — как реализовать. Инкапсуляция и все такое. Можно выделять память в пуле, отрисовывать много объектов сразу. Одно другому не мешает
и не делает объекты примитивов лишними.

B>Павел
Очень приятно.

Здравствуйте, Юнусов Булат, Вы писали:

ЮБ>Здравствуйте, Михаил Дюмин, Вы писали:

ЮБ>Можно микрософтовскйи примерdrawcli за основу взять и под себя заточить.

ЮБ>Можно поиском по сайту найти Rogue Wave Stingray Studio и разобратся с ихней Objective Views.

А Вы случаем не пробовали для каких-нибудь разработок (САПР или что-то того) Objective Views?
Если кто пробовал, поделитесь опытом, какие там минусы и плюсы?
Что там можно использовать, а что не стоит?
Ну короче, есть мнения какие-нибудь об вышеупомянутой приблуде?

Здравствуйте, Poudy, Вы писали:

P>Здравствуйте, bizhan, Вы писали:

B>>Пример расчетов. Таких, что их надо реализовывать на уровен одного примитива.
B>>Легко расширение библиотеки примитивов — это хороший вопрос. Я не знаю универсального решения.
B>>Хорошие — известны, но часто зависят от конкретной предметной области.
P>Примитив — просто универсальный доступ к объекту. Базовый класс. То, у чего есть отдельный дизайнер.
P>Соотв. поверхности, пересечения, геометрические преобразования, типа размножения с поворотом, вытягивания — примитивы.

Мне кажется, что у тебя каша из терминологии.
Примитив — это что?
Класс — это что?
Дизайнер — это что?
Почему преобразование (глагол) у тебя примитив (существительное)?

P>Может быть. На мой взгляд — это проблема аглоритма. Если заранее поделить область редактирования на клетки (кубы),
P>т.е. самый большой контейнер реализовать как группу контейнеров поменьше, то необязательно обходить все объекты.

Здесь ответ будет такой — сходи и наступи на эти грабли

P>Опять же — как реализовать. Инкапсуляция и все такое. Можно выделять память в пуле, отрисовывать много объектов сразу. Одно другому не мешает
P>и не делает объекты примитивов лишними.

Сходи и наступи. Сделай простой тест и посмотри в профайлере на что уходит время.

Павел

p.s я не настаиваю

Здравствуйте, Exhumer, Вы писали:

E>А вы под конкретный заказ писали или так вообще? Просто интересно.

Скорее вообще. Но был главный заказчик, который определял общее направление.
Как сейчас — не знаю, я там не работаю.

E>Ну да. Тут уж каждый (примитив) сам все про себя знает.

При редатировании да. Только скорее не примитив, а нечто, что этот примитив редактирует.

B>>p.s а сам-то что-нить сделал или книжек почитал?-))

E>RCAD Steel — гражданское строительство. Проект развивается уже три года. Ну и книжки само собой .

У вас ээ расширение RCAD или это полнотсью ваш продукт? Я по инету посмотрел и не понял.

Павел

p.s а до 3D я так и не дошел.