Как проверить принадлежность точки кругу?..

← →
Delperec (2008-09-24 14:59) [0]

Допустим, есть несколько кругов и несколько точек - как можно определить что точки №1 и №2 принадлежат какому-то кругу, а не находятся за ним?

Рисунок (пример):
http://s2.ipicture.ru/uploads/080924/17097/lTTdxjyB32.jpg

← →
Сергей М. © (2008-09-24 15:13) [1]

> Delperec (24.09.08 14:59)

Уравнение окружности тебе знакомо ?

← →
anonims (2008-09-24 15:23) [2]

сравнить расстояние от точки до центра круга и радиус круга

← →
Anatoly Podgoretsky © (2008-09-24 18:10) [3]

> Delperec (24.09.2008 14:59:00) [0]

За ним это уже 3d характеристика и тогда надо вести речь о плоскостях.

← →
@!!ex © (2008-09-24 19:14) [4]

OutSide:=sqrt(sqr(x-circle.x)+sqr(y-circle.y))>circle.radius;

← →
Правильный$Вася (2008-09-25 18:51) [5]

немного через зад, но почти не нужно знать математики
createellipticrgn + ptinregion

← →
jack128_ (2008-09-26 09:23) [6]

> почти не нужно знать математики

теорема пифагора классе в пятом проходится.. Определение окружности - тогда же..

← →
Правильный$Вася (2008-09-26 11:11) [7]

> jack128_ (26.09.08 09:23) [6]

ну, правильно, почти

← →
Рамиль © (2008-09-26 11:20) [8]

Перевести в полярные с началом в центре окружности. И просто сравнивать с радиусом;)

> @!!ex © (24.09.08 19:14) [4]
>
> OutSide:=sqrt(sqr(x-circle.x)+sqr(y-circle.y))>circle.radius;
>

Думаешь догадается перенести координаты?

← →
@!!ex © (2008-09-26 11:49) [9]

> [8] Рамиль © (26.09.08 11:20)

в смысле? кого и куда перенести?

← →
Alex Konshin © (2008-09-27 10:12) [10]

> @!!ex © (24.09.08 19:14) [4]
> OutSide:=sqrt(sqr(x-circle.x)+sqr(y-circle.y))>circle.radius;

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

← →
antonn © (2008-09-27 12:28) [11]

> Alex Konshin © (27.09.08 10:12) [10]

код?

ЗЫ тут есть темка, про "игроделов". так вот, будь эта тема создана в "Играх", там бы уже дали сразу код (@!!ex все испортил, да :) ) и в навесок посоветовали сначала trect"ом ограничивать проверку, поинтересовались другими деталями и прочее. В этом различие "игроделов" и "мастеров с других конференций", первые просто подскажут и часто покажут, вторые намекнут (плюс, как видно из первых постов, еще и постебуться :) ).

← →
jack128_ (2008-09-27 13:41) [12]

> код?

мдя. ну тогда понятно, почему игры всё тормознее и тормознее...
обе части неравенства в квадрат возведи.

> jack128_ (27.09.08 13:41) [12]

дело принципа :)

> ну тогда понятно, почему игры всё тормознее и тормознее.
> ..

расскажите? :)

> [13] antonn © (27.09.08 13:44)
> > ну тогда понятно, почему игры всё тормознее и тормознее.
> > ..
>
> расскажите? :)

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

> [12] jack128_ (27.09.08 13:41)

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

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

думаю ты и сам понимаешь, что "игры тормознее" от этого не становятся :)

> Действительно имеет место упровщение оптимизаций, никто
> не борется за микросекунды, как это было раньше...

не совсем так, сейчас модно внедрять всякие скриптовые движки (а так же всякие навороченные "менеджеры диалогов/симуляций жизни"), которые позволяют очень быстро наворачивать "контент" игры (от миссий до смены логики), однако сами эти скрипты не очень то и быстры (вспомнить хотя бы тот же UFO:E, графика никакущая, наполнение сцены околонулевое, но благодаря внедренному скриптовому движку можно поменять почти все в игре (что в общем не спасло ее от провала :))). И отчасти даже само ООП и виновато в навороченности переходящей в тормоза, зачастую "процедурный" код работает быстрее.
Ну и не стоит забывать, что "раньше" игры имели не ту "детализацию" (в смысле наполненость сцен - от кол-ва полигонов, до "активных" элементов (физика и проч.)).
Но вообще да, кривые руки встречаются часто (например недавний Сталкер, гыгыгы :) ).

Очень многое сейчас в видуху упирается...
Часто менеджеры не понимают и не хотят понимать, что количество полигонов играет роль и не маловажную...
Вплоть до того, что на меня накинулись совсем недавно: "Нужен в игре дисплейсмент и точка."
Я недели две убил, втолковывая что введение этой технологии в нашем случае преимуществ не даст никаких... а производительность убьет...
Убедил все таки.. вагонами споров...
Сейчас загорелись использовать систему симуляции погоды от Симулы... круто смотрится, облока объемные и проч... но нафиг, если вся игра проходит строга над землей?? Я согласился внедрить систему. но с условием, что обязательно можно будет в настройках отключить этот погодный двиг и влючить обычный скайбокс, в котором полигонов 4 штуки.... проЭкт и так уже в видуху уперся, из за жуткой полигональности....

> Очень многое сейчас в видуху упирается...

ну эт смотря какие игры, я писал "точки" у меня "стек оферфлоу", пришлось немножко по другому организовать анализ поля. а потом уже после переработки на поле 128*128 получался нефиговый объем занимаемой памяти при почти полной заполнености точками и тормоза появлялись при анализе все этого :)

> проЭкт и так уже в видуху уперся, из за жуткой полигональности.
> ...

оглядываясь на GF8800, которые стали вполне себе по карману в мейнстриме как то не верится, там же нефиговая мощь :) по идее лоды, зедбуферы должны поскоростить сцену... или у тебя там текстуры 1024*1024 на каждом полигоне, с паралакс маппингом и еще тучей шедеров? :)

> ну эт смотря какие игры, я писал "точки" у меня "стек оферфлоу",
> пришлось немножко по другому организовать анализ поля.
> а потом уже после переработки на поле 128*128 получался
> нефиговый объем занимаемой памяти при почти полной заполнености
> точками и тормоза появлялись при анализе все этого :)

Ну это скорее частный случай, чем общеизвестная практика. :)

> оглядываясь на GF8800, которые стали вполне себе по карману
> в мейнстриме как то не верится, там же нефиговая мощь :)
> по идее лоды, зедбуферы должны поскоростить сцену... или
> у тебя там текстуры 1024*1024 на каждом полигоне, с паралакс
> маппингом и еще тучей шедеров? :)

На самом деле я немного лукавлю... Просто мы еще вообще не занимались оптимизацией, даже Frustum Culling"a нету. Не время еще.
Вот текстуры 1024х1024 - это минимум.... номер на машине текстурой 512х512, нафиг - непонятно. Пока решили, что порезать всегда успеем. :)

Как проверить принадлежность точки кругу?.. Найти похожие ветки