Войти
ПрограммированиеФорумГрафика

Чтение значений из буфера глубины [OpenGL]

Страницы: 1 2 Следующая »
#0
23:53, 2 сен. 2011

Для определения жизни под мышкой решил использовать изменение значений в буфере глубины, но  glGetPixels уронил мне фпс на 300, и это один вызов финальной проверки, а что будет когда объекты проверятся начнут подумать страшно.
Неужели все так плохо ???
Юзаю GL33

inline float _read_zbuf(int x, int y){
  float v;
  glReadPixels(x,screen.height-y+1,1,1,GL_DEPTH_COMPONENT,GL_FLOAT,&v);
  return v;
}

#1
1:33, 3 сен. 2011

VDragon
> определения жизни под мышкой
Это как?

VDragon
> Неужели все так плохо ???
Конечно!

#2
9:12, 3 сен. 2011

Поднял свою мышку, разумную жизнь под ней не обнаружил. :(

#3
10:10, 3 сен. 2011

Все просто
Если по координатам мыши в буфере глубины изменилось значение, значит последний нарисованный объект под мышкой, чего непонятного.
После очистки значение буфера глубины обычно 1, хотя для верности можно и прочитать его.
Затем, если объект помечен как определяемый после его вывода проверяем наши координаты в Z буфере, и ели значение изменилось то там нарисовался последний посланный меш.
И так далее, запоминая гдето метки попавших под координаты объектов
Последняя проверка после рисования, дабы узнать не перекрыло ли что-то последний определенный меш.

Так вот, уже одна последняя проверка уронила мне фпс с 1400 до 1030
Мне грустно от этого...

Код чтения буфера я привел выше.

#4
10:57, 3 сен. 2011

Нарисуй кубик, он опустит твой ФПС ещё на 600. Видеокарты - гавно.

#5
11:16, 3 сен. 2011

haper
Причем тут кубик и чтение 4 байт из буфера глубины ???

#6
11:26, 3 сен. 2011

VDragon

glReadPixels синхронно читает, хоть 4 байтика хоть 1024 - будет задержка
если сильно хочется можно асинхронно с arb_pixel_buffer, но сама идея мне не нравится :) тут нужно другое

#7
15:38, 3 сен. 2011

haper
> Нарисуй кубик, он опустит твой ФПС ещё на 600. Видеокарты - гавно.
Да да, поддерживаю.

VDragon
> уронил мне фпс на 300
То есть у тебя было 2500 а стало 2200 или было 315 а стало 15?

#8
17:14, 3 сен. 2011

Sergio
было 1400 фпс
1 вызов чтения из буфера глубины уронил фпс до 1030
2 вызова до 800
сейчас я забил на чтение из буфера и пишу класс ge_boundary_box =)

#9
17:32, 3 сен. 2011

>сейчас я забил на чтение из буфера
Наконец одумался...

#10
21:37, 3 сен. 2011

VDragon
> glReadPixels
да чувак, рид пикселс реально меееедлеееееенннннннооооооо работает. ничего не поделать.
можеш разве что к подмышке обращаться не на каждом кадре а через 2-3 кадра или по клику.

в любом случае выполнение его ты быстрее не сделаеш.

#11
22:53, 3 сен. 2011

VDragon
>>Если по координатам мыши в буфере глубины изменилось значение, значит последний нарисованный объект под мышкой, чего непонятного.
>>После очистки значение буфера глубины обычно 1, хотя для верности можно и прочитать его.
>>Затем, если объект помечен как определяемый после его вывода проверяем наши координаты в Z буфере, и ели значение изменилось то там нарисовался последний посланный меш.
>>И так далее, запоминая гдето метки попавших под координаты объектов
>>Последняя проверка после рисования, дабы узнать не перекрыло ли что-то последний определенный меш.
 
Ты либо что-то не договариваешь, либо порешь ахинею, либо я чего-то не понял. Я склоняюсь к первому.
CPU и GPU работают асинхронно, и всё, что ты послал на рендер - попадет на экран одновременно. И совсем не сразу после glFlush.
Но я думаю, что ты знаешь об этом, поэтому после фразы "Если по координатам мыши в буфере глубины изменилось значение, значит последний нарисованный объект под мышкой" у меня возникает когнитивный диссонанс.
 
Обьясни, о чем ты говоришь, что ты делаешь и что ты хочешь сделать?
 

  • правка цитаты
  • #12
    23:14, 3 сен. 2011

    0xdeadc0de

    Чтото какаято нервная реакция на пост X_x
    Черт ты вывел меня на чистую воду, да да, я недоговариваю.
    В главном посте под фразой "поиск жизни под мышкой" я зашифровал мои попытки определения попадает ли отрисованный объект под заданные координаты в окне, обычно это используется для определения по чему кликнуто мышкой. Для этих целей я хотел использовать изменения в буфере глубины, но судя по всему из за того что cpu и gpu работают асинхронно большого успеха мои попытки не дали.
    Так что твой гневным пост немного не своевремен, хотя ты полностью прав, поздравляю =)


    Lamer007
    Рана радуешься, у меня начинается раунд 2, упрощенный рендер в текстуру малого размера сцены, и далее определение объекта по полученной маске=D.

    #13
    23:25, 3 сен. 2011

    VDragon
    Я разочарован. Надеялся, что это будет какая-то новая система определения видимости перекрытых обьектов...
     
    >>обычно это используется для определения по чему кликнуто мышкой
    >>у меня начинается раунд 2
    Фигней ты занимаешься. Обычно это делают через рейкастинг. Пускают луч в точку на экране через octree/твоё_дерево, находят первый встретившийся обьект, у него - поиск пересечения луча с треугольниками. Если не попали (вошли в баундинг-бокс обьекта но не прошли сквозь меш) - ищем дальше вглубь дерева.
    Метод прост, как топор. Скорость работы адекватная. Проверено на Ogre. Там же можешь посмотреть исходный код.

    #14
    23:45, 3 сен. 2011

    0xdeadc0de
    > Фигней ты занимаешься. Обычно это делают через рейкастинг. Пускают луч в точку
    > на экране через octree/твоё_дерево, находят первый встретившийся обьект, у него
    > - поиск пересечения луча с треугольниками. Если не попали (вошли в
    > баундинг-бокс обьекта но не прошли сквозь меш) - ищем дальше вглубь дерева.
    > Метод прост, как топор. Скорость работы адекватная. Проверено на Ogre. Там же
    > можешь посмотреть исходный код.

    1. Это требует хранения копии геометрии в памяти
    2. Это требует хранения и создания дополнительной геометрии в памяти
    3. Это требует полюбому перелопатить всю эту геометрию
    4. Все это потребует внесение больших изменений в мой проект
    5. Я в данный момент незнаю как проверить треугольник на пересечение с лучом

    Страницы: 1 2 Следующая »
    ПрограммированиеФорумГрафика

    Тема в архиве.