Войти
ФлеймФорумРазработка игр

Ещё один глупый вопрос по рендеру - густой лес. (2 стр)

Страницы: 1 2 3 Следующая »
#15
15:22, 24 июня 2016

равен
Да-да-да! И чтобы домики набигали!
(а если серьёзно, то где-то оттуда меня и зацепила эта идея и первые "мысли" по решению тоже оттуда (когда дерево вдалеке заменять картинкой :) - увы, не вспомню дословно))

Madware
> но в тех местах куда игрок не доберется вполне можно нарисовать круговые пререндеренные "участки" леса. По сути просто кольцо из поликов с панорамной текстурой. Можно таких колец несколько слоев сделать.
Да, пока я именно на таком варианте и остановился, только не круги, а скайбоксы. Но там есть один жёсткий баг с этим всем. И я пока не знаю как его порешать:
Итого, у меня есть, допустим, 10 динамически генерируемых скайбоксов на разных расстояниях.
НО ландшафт (из леса иногда можно взглянуть на горы, например), не будет стыковаться для скайбоксов, что приведёт к крайне заметному артефакту.
Тогда убираем ландшафт и рендерим его отдельно. НО тогда надо не рендерить участки леса, перекрытые ландшафтом (т.е. чтобы ландшафт рендерился в маску, но при этом не отображался на рендере), а как это сделать в Castle Game Engine (и вообще) я себе пока не представляю.
Вторая проблема - деревья должны бы шевелиться. Я понимаю, что скорее у меня будут стандартные анимации, а не сложно зависящие от силы ветра, но всё равно легко будет отличить статичный скайбокс/билборд от анимированного дерева - их тоже надо хоть как-то анимировать...

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


Прошло более 6 месяцев
#16
10:25, 13 янв. 2017

И эльфу раз лесные то сделать так что там густой лес... А движок можно поставить так что вдали деревья картинкой, когда подходиш они преобразовываются в 3-хмерные деревья.
Пока только "верхний ярус" :) Влез в проблемы с памятью...
Изображение

#17
14:46, 13 янв. 2017

eugeneloza
> Пока только "верхний ярус" :) Влез в проблемы с памятью...
> Изображение
Лоды есть?

#18
15:30, 13 янв. 2017

1 frag / 2 deaths
В прямом смысле этого слова - нет.
Есть "авторендер" (и авто-ре-рендер) в спрайт (ну, типа лод) и автонарезка мира на чанки. Ну, и автоматическое переключение между отображением модели и спрайта.
П.С. эта картинка не совсем честная, т.к. спрайты ещё не прозрачные получаются пока и жрут нереально много памяти :) Она пока "авансом" :)  Но это я поисправляю, главное, что есть ФПС 100 почти независимо от сложности сцены.

Что ещё сделать:
1. Сделать спрайты прозрачные.
2. Сделать, чтобы на спрайтах не было лишнего пространства.
3. Сделать спрайты правильно повёрнутые.
4. Сделать управление в треде (сейчас в одном потоке, можно эффективнее).
5. Сделать кэширование на диск для особо огромных миров.
6. Сделать террейн (хейтмап) и его автонарезку на чанки.

#19
16:32, 13 янв. 2017

eugeneloza
У тебя по спрайту на дерево, что-ли?
Деревья одинаковые или разные?

В общем, мои предложения:
а) Квантизация направления: если ориентации двух деревьев относительно взгляда близки, то использовать один спрайт.
б) Для любых расстояний (видимых масштабов) использовать один спрайт с мипмапами.

Под пунктом 3 ты имеешь в виду ориентацию спрайта на камеру, а не параллельно экрану, что ли?
Все билборды должны смотреть на камеру — это единственный правильный способ.

#20
13:29, 14 янв. 2017

А движок какой?

#21
15:37, 14 янв. 2017

}:+()___ [Smile]
> Все билборды должны смотреть на камеру — это единственный правильный способ.
Нихрена. Есть как минимум два базовых варианта + как минимум два варианта их суперпозиции, Мистер Категоричность.

#22
18:58, 14 янв. 2017

-Eugene-
> Нихрена. Есть как минимум два базовых варианта + как минимум два варианта их суперпозиции, Мистер Категоричность.
Физически верными являются те, которые смотрят на камеру (если, конечно, не делать извращенных проекций).
Стоимость реализации параллельных экрану и смотрящих на камеру практически одинаковая.
Следовательно, параллельные экрану билборды являются обычным говнокодом.

Или ты про линейные и сферические билборды? Так и те и другие должны смотреть на камеру с учетом допустимых вращений.
#23
19:17, 14 янв. 2017

}:+()___ [Smile]
> Физически верными являются те, которые смотрят на камеру
Прошу прощения, а физически верный билборд это как?

#24
20:10, 14 янв. 2017

-Eugene-
> Прошу прощения, а физически верный билборд это как?

+ Показать
#25
20:37, 14 янв. 2017

}:+()___ [Smile]
> Представим сферически симметричный объект с таким же симметричным освещением, в
> общем, одинаково выглядящий с разных сторон.
Этому определению удовлетворяет разве что однородная сфера.
Применительно к реальности, билборд должен выглядеть наиболее приятно глазу наблюдателя, а не то что ты сейчас написал.

#26
10:56, 16 янв. 2017

Да, каждый объект - уникальный спрайт.
За идеи благодарю, попробую, как раз этим занимаюсь.

#27
11:46, 17 янв. 2017

Есть чуть больше времени отписать...

Движок: Castle Game Engine

Вопрос по Billboard-ам: Зачем??? Вижу, что все так делают, значит, наверное, правильно. Но сколько их изучаю - так и не понял, для чего ещё одну операцию (ориентацию на игрока) на каждый спрайт вешать? Если спрайт не динамический а пре-рендер, понятно. Но, если спрайт рендерится раз в 1-2 секунды из 3d объекта и выставляется перпендикулярно вектору зрения, то какой смысл ещё его и ориентировать каждый кадр на игрока?

Нашёл и (частично) решил проблему с памятью.

#28
12:07, 17 янв. 2017

eugeneloza
> Но, если спрайт рендерится раз в 1-2 секунды из 3d объекта и выставляется
> перпендикулярно вектору зрения, то какой смысл ещё его и ориентировать каждый
> кадр на игрока?
Это где ты такие спрайты нашел??? Тебе никакой памяти и производительности не хватит пре-рендерить каждое из статыщ деревьев.

#29
12:20, 17 янв. 2017

-Eugene-
Статыщ пока нету, по этому хватает :)
А вообще, очень туго представляю как "это" без ре-рендера можно сделать. Тупо пре-рендер 1 штука на объект? Ну, в среднем, да. Но на дерево ведь можно смотреть не только сбоку, но и сверху, снизу (Одна из визуальных фишек, которых хотелось бы добиться - посмотреть на всю локацию с горы в начале игры)... Дальше допуски, группировка, и готово (ага, написать просто, сделать сложно :), но прорвёмся :)).

Если быть конкретнее, то request на rerender выдаётся в зависимости от "отклонения" спрайта от точного положения и выполняется в зависимости от текущего FPS. Т.е. таким образом дальние объекты будут выдавать request раз в час, а ближние - раз в секунду. В любом случае - реже, чем 30-60 раз в секунду :)

Страницы: 1 2 3 Следующая »
ФлеймФорумРазработка игр

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