sami
Местный
Я вообще про задачи, которые имеют смысл в отображении на монитор. Большого смысла в множестве линий с похожими Bounding-box-ами я не вижу (пока не увидел). Гриф так гриф, с ним лучше не шутить!Вот привести реальную постановку задачи гриф не позволяет. Но поверьте наслово - это очень большой пласт задач :huh:
И я! Ходить по растру не быстро, не надежно, и виляно.И я о том же: это не быстро, не надёжно и писями по воде виляно
Вполне. В серьезных приложениях программной 3D графики и не такое хранится для каждого пикселя! Списки примитивов, которые в них попали, субпиксельные маски на каждый примитив, нормали к поверхности и прочее, прочее, прочее.... Это не говоря об эффектах с прозрачными объектами.Для каждого пикселя хранить списки? "расшаривать списки линий для разных пикселей"? Вы - серьёзно?
Если вспомнить тему ГИС-ов, то там не редкость полигональные объекты с границей из десятков тысяч линий. И объектов может быть миллионы. Не все такие сложные, но все-таки. Некоторые объекты записываются как результат теоретико-множественных операций над полигонами.Походу, вообще о разных вещах говорим B) Из разных категорий применения. У меня - чертежи в десятки тысяч линий с коэффициентом разномасштабности - 1:100, а у Вас?
И ничего, с движением мышки не только пересечения с линиями вычислялись, но и решались задачи определения принадлежности точки многоугольнику, вычислялись кратчайшие пути! (правда, тсссс!!! Эллипсов там не было. Но эллипсы можно с хорошей точностью аппроксимировать отрезками)
Нужен только дружественный индекс (например, триангуляция с ограничениями).
А сегодня за пространственные запросы может отвечать даже РСУБД. Кажись эта фича уже внесена в стандарты. Так что имея хорошую абстракцию от устройства вывода, можно скидывать линии прямо в БД и получать пересечения SELECT-ом.