Да причём тут декомпозиция
Чтобы создать портал, достаточно и треугольника. Сколько миллионов их нагенерится и толку от них?
Для эффективного рассчёта видимости нужна лоуполи аксиальная геометрия, которую никаким прогрессив-мешем нормально не сделаешь.
Потому что даже с ручной геометрией, с порталами иногда случаются забавные вещи. ну вы в курсе.
Цитата:
Ku2zoff писал: Дядь Миш, как у тебя в целом продвинулась работа над новым движком?
Работаю. Читай тему сначала.
Добавлено 12-01-2020 в 18:45:
Цитата:
Crystallize писал: Ставить точечную энтитю, от неё создавать горизонтальную поверхность и рекурсивно смотреть какой объём эта вода зальёт?
хорошые у вас сегодня шышки
Добавлено 12-01-2020 в 20:07:
Халфовский CSG, кроме того что вычитает брашы друг из друга, пытается их объеденить. И вот здесь, судя по всему и начинаются проблемы на сложной геометрии. Собственно, каждый маппер знаком с этим явлением. Пол, на полу кубик. Кубик разобъет пол на несколько частей, даже при условии что он его не пересекает. Такое уж требование к халфовскому BSP, чтобы правильно уложить сурфейсы на ноду. Но вообще CSG эту ситуацию обрабатывать никак не должен. Вот ежели бы кубик немножко залез внутрь браша, тогда да, он бы спровоцировал появление новых.
В моём новом компиляторе CSG только вычитает брашы. Можно добавить и объединение конечно, но сперва надо подумать как часто возникают подобные ситуации. Навскидку, это актуально только для воды.
Чо-т я не понимаю. Для эффективного виза нужна лоуполи аксиальная геометрия, поэтому браши. Но тут приходит CSG и нарезает браши на каломассу с кучей лишних треугольников и корявостей от недостатка точности.
Цитата:
Дядя Миша писал: вода не всегда простой формы. Иногда её приходится делать из составных брашей. Например изгибающееся русло реки.
возможно, проще хранить эти составные браши и считать пересечения с ними индивидуально, нежели нарезать и собирать деревья?
ncuxonaT писал: Для эффективного виза нужна лоуполи аксиальная геометрия, поэтому браши. Но тут приходит CSG и нарезает браши на каломассу с кучей лишних треугольников и корявостей от недостатка точности.
ну вот на таких взаимоисключащих требованиях и построен халфовский формат уровней, да.
Цитата:
ncuxonaT писал: возможно, проще хранить эти составные браши и считать пересечения с ними индивидуально, нежели нарезать и собирать деревья?
с водой коллизия не считается. Там бинарное состояние - в воде\не в воде.
nemyax я напоминаю, что геометрия должна быть замкнутая, иначе портал флоу вытечет наружу, за пределы уровня. Аппроксимация не даст замкнутой геометрии. Хотя конечно, если её надуть как клипноды, может из этого что-нибудь и получится.
Ну чтожы, настала пора самого интересного - собирать халфовские карты моим компилятором. Тут ведь идея в чём? Карта она так и остаётся прежней, со своими путями к текстурам. Но компилятор, вооружонный мощной системой материалов спокойно находит всё что ему нужно, причём пути указывает юзер.
Добавлено 12-01-2020 в 23:02:
ЧТобы было понятнее о чём речь, пусть вам Thambs расскажет, как он однажды попытался скомпилить свои карты под ку3 и писал всякие шейдеры.
Вообще говоря с кутришным форматом работать на порядок приятнее, точнее говоря не с самим форматом конечно, а подобной организацией дерева. Халфовский компилятор из-за озвученного выше противоречия работаешь на пределе точности двойного вещественного. А кутришному и флоата за глаза хватает. Нет ощущения, что вот сейчас один эпсилон подкрутишьи всё полетит к чертям, взорвется дырками, ликами и битыми полигонами.
пусть вам Thambs расскажет, как он однажды попытался скомпилить свои карты под ку3 и писал всякие шейдеры.
Ну там, собственно, три проблемы было. Первая -- это собственно, эти замороченные шойдеры, которые писать замаялся, там сотни ненужных опций, причём на каждый чих и всё равно их прописывать приходилось, типа тут лайтмэпу такую, тут секую, никакой автоматизации или адекватных дефолтов. И от неба небыло _spread для солнца. Вторая -- это брашевые горы, так и не удалось найти оптимальные параметры, что бы он целиком их в единое полигоновое месево превратил, а без этого швы получались. Впрочем, я по всей видимости буду от брашевых гор отказываться и переводить их в модели, тк иначе не получится сделать несколько уровней песка, да и вообще ландшафты в блендере удобнее делать. Третья -- это там какие-то проблемы с путями были, я их решил, но с ..дцатого раза. А так, геометрия там, конечно лучше получалась, тоннели полигон-в-полигон, а гротто2 -- в фанк_статик (но его тожа в модель надо будет, брашами его делал скорее от безисходности).
На самом деле, у меня основная проблема это текстуринг в блендере, очень уж неудобно для мировой геометрии сочинять все эти развёртки, там бы режим наложения как в джеке -- цены б ему не было.