Изначально я использовал наивную версию создания мешей: просто создавал куб и отбрасывал вершины, не касающиеся пустого пространства. Однако такое решение было медленным, и при загрузке новых фрагментов создание мешей оказывалось даже более узким «бутылочным горлышком», чем доступ к файлу.
Основной проблемой было эффективное создание из фрагментов рендерящихся VBO, но мне удалось реализовать на C++ собственную версию «жадного создания мешей» (greedy meshing),
Когда решал, стоит ли заморачиваться и оптимизировать сетку для ренедринга, для проверки взял и продублировал всю геометрию. Вершин и треугольников стало в 2 раза больше, но fps не уменьшился. Я тогда сделал вывод, что если стану сетку упрощать, то генерировать её буду дольше, а fps нихрена в итоге не увеличится.
Если я когда-нибудь реализую многопоточное сохранение и загрузку фрагментов, то преобразование плоского массива в разреженное октодерево и обратно может быть вполне возможным вариантом для экономии памяти.
Забей. Все, кого я читал и кто на практике пытался прикрутить к воксельному движку октодерево, от него отказывались. Для сжатия чанков используй RLE ― примитивно и эффективно за счёт линейного доступа к памяти.
У меня даже была мысль, что можно данные чанков хранить в памяти в сжатом виде и распаковывать/запаковывать на лету когда надо. Попробовать не довелось, т.к. в моём движке блоки хранились не в отдельных чанках, а большом общем для всего видимого мира закольцованном 3д-массиве.
Ну да, порнотраффик опаснее терроризма, а отсутствие ключей шифрования — проблема серьёзнее, чем взрывы в метро и людей, мирно гуляющих с чьей-то головой в руках.
Не заметил, чтобы в интернете кончилось порно.
Гонять нариков и закрывать распространителей ― потенциально более полезное занятие, чем выискивать психопатов, которых один на миллион, и хрен ты его вычислишь, пока ему крышу не сорвёт. Бить по площадям эффективнее, чем бегать за каждым придурком. Потенциальных террористов тоже можно дрючить сильно заранее. Как минимум пусть помучаются в налаживании безопасного для них канала связи. Это ты, может быть, знаешь, как правильно организовать надёжную связь. А нормальный человек или накосячит, или плюнет ― авось пронесёт, или пойдёт спрашивать знакомых.
Вполне логично и экономически оправданно сначала разрабатывать те месторождения, которые богатые и неглубоко. Иначе просто деньги в трубу и обвинения от "общественности" в распиле.
Не знаю на счёт глючности первой версии 95, но работала она быстрее OSR2. На 486 мне это было принципиально. Как минимум у стандартных контролов было меньше спецэффектов и они были более отзывчивые. А поскольку они применялись почти всеми программами, всё было более отзывчивым.
Я знаю, что она делает, но мне не надо в Output. Если уж писать, то в отдельный файл. Чтобы в релизных версиях работало, чтобы логи сохранялись, чтобы можно было открыть посмотреть старые, чтобы дифы делать, чтобы с чужой машины было что получить...
Знаю, что Debug/Trace умеют направлять сообщения не только в Output, но и в другие места одновременно. Из этих других мест я их, скорее всего, и буду брать, когда понадобится.
Короче, вот это «все разработчики его используют в своей работе ежедневно» в первом абзаце явно зря было написано.
Ну что там реально полезного в рантайме? Логи у меня обычно выводятся в другое место и внутри VS не нужны. Необработанные исключения со стектрейсами видны и так; даже не в курсе, пишутся они в Output или нет. Что ещё?
Вы сами написали, что в Error List есть недостатки и Вы к ним приспособились так, что они уже не мешают
Я такого не писал. Написал, что в Output не смотрю вообще и просто закрываю, там в основном мусор, который никто не просил. Что есть полезного, есть в Error List, но он тоже большую часть времени автосвёрнут. В процессе набора ошибки и так видно в тексте. Если билд не сбилдится, в Error List будет написано почему. Не особо вчитываясь тыкаешь в строку с ошибкой, открывается исходник, а в нём всё подчёркнуто, подсвечено, при наведении мышки тултипы выскакивают ― уж куда удобнее? Если в списке присутствует какая-то лишняя сейчас информация, можно штатно отфильтровать/пересортировать/настроить так, как больше нравится.
Output ― это ж тупо лог всего подряд. Я допускаю, что он может быть иногда полезен. Когда случается какая-то непонятная фигня непонятно почему, тогда открываешь лог и смотришь, что происходит. Но чтобы постоянно туда смотреть...
В C# при редактировании все ошибки подсвечиваются на лету прямо в тексте. В Error List смотреть не надо, у меня он обычно свёрнут. Т.е. в C# для меня окно Output вообще бесполезно; а Error List полезен эпизодически, если билд вдруг не сбилдился или там ещё можно включить/выключить показ предупреждений/предложений от статических анализаторов.
Тогда понятно. В C# одна реальная ошибка обычно не приводит к каскаду фантомных ошибок компиляции, поэтому всё равно, в каком порядке ошибки представлены в списке. Если в списке их три, скорее всего, их реально три в разных местах. А если они ещё сортируются по типу или алфавиту, то так даже удобнее.
Поэтому я в окно Output не смотрю и сразу закрываю, если появилось.
С Unity так же. Пока делали игру, поняли, что движок под эту игру получается лучше, чем сама игра. Игру вроде даже выпустили, но всё внимание переключили на дальнейшую работу над движком.
Использую тёмные или скорее серые темы при работе с графикой, а код/текст предпочитаю чёрным по белому. Потому что когда читаешь, некоторое время задерживаешь взгляд на светлых строчках на тёмном фоне, они отпечатываются на сетчатке, и когда переводишь взгляд, в глазах рябит. Нафиг.
В 2д расчётах можно стерпеть ― ну, помнит человек школьную программу, уже хорошо. Но когда в коде видишь синусы/косинусы вместе с переменными x, y, z, бедного автора хочется пожалеть и чем-нибудь приласкать.
Вот у меня тоже слюноотделение по Zen 2, но чем больше я читаю обзоры и изучаю характеристики, тем меньше хочется менять свой разогнанный сэндик i7-2600K на новые процессоры. В игры поиграть люблю, и тесты показывают, что Intel почти всегда выходит лучше последних процессоров AMD.
Без разницы кто лучше вообще, Феррари или Ламборгини. Интереснее, кто лучше за ту сумму, которую не жалко на апгрейд. На момент двух предыдущих апгрейдов лучше был Intel, до них лучше был AMD, сейчас опять AMD. Через год, может, опять поменяется, а может, прилетит метеорит и мы все умрём.
3700X на дешёвой материнке с самой дешёвой 3200/CL16 памятью по моим тестам и впечатлениям получился в 1,5–2 раза быстрее i5-2500K @4.4 ГГц в однопотоке, плюс в два раза больше ядер, плюс SMT/HT (хотя у i7 оно тоже было). Вот бы ещё цена была как у 2500K, но я 8 лет ждал ― не дождался.
На всякий случай делал reality-check перед апгрейдом. i7-9700K без HT стоил дороже 3700X на цену материнки, а похожий i9-9900K на цену материнки вместе с памятью. Скорее всего, ещё нормальный кулер будет нужен, чтобы охлаждал и не визжал. Эти процессоры для игр просто не имеют смысла, потому что та же разница в цене, но потраченная на видеокарту, даст больший эффект. Если же смотреть, что у Интела есть дешевле, то оно заметно хуже и апгрейд 8-летнего сандика вообще теряет смысл.
Тут я не совсем понял, что именно в итоге получается. Вот картинка:
http://i.piccy.info/i9/3ed4fab4365bebb9fb194162e75f4b84/1573063991/63783/1346249/collider_mesh.jpg Голубыми линиями показана сетка, которая рендерится, а зелёными ― упрощённая модель для физического движка. У тебя в итоге получается какой вариант?
Когда решал, стоит ли заморачиваться и оптимизировать сетку для ренедринга, для проверки взял и продублировал всю геометрию. Вершин и треугольников стало в 2 раза больше, но fps не уменьшился. Я тогда сделал вывод, что если стану сетку упрощать, то генерировать её буду дольше, а fps нихрена в итоге не увеличится.
Забей. Все, кого я читал и кто на практике пытался прикрутить к воксельному движку октодерево, от него отказывались. Для сжатия чанков используй RLE ― примитивно и эффективно за счёт линейного доступа к памяти.
У меня даже была мысль, что можно данные чанков хранить в памяти в сжатом виде и распаковывать/запаковывать на лету когда надо. Попробовать не довелось, т.к. в моём движке блоки хранились не в отдельных чанках, а большом общем для всего видимого мира закольцованном 3д-массиве.
Если хочешь, читай как "террорист-любитель".
Не заметил, чтобы в интернете кончилось порно.
Гонять нариков и закрывать распространителей ― потенциально более полезное занятие, чем выискивать психопатов, которых один на миллион, и хрен ты его вычислишь, пока ему крышу не сорвёт. Бить по площадям эффективнее, чем бегать за каждым придурком. Потенциальных террористов тоже можно дрючить сильно заранее. Как минимум пусть помучаются в налаживании безопасного для них канала связи. Это ты, может быть, знаешь, как правильно организовать надёжную связь. А нормальный человек или накосячит, или плюнет ― авось пронесёт, или пойдёт спрашивать знакомых.
Вполне логично и экономически оправданно сначала разрабатывать те месторождения, которые богатые и неглубоко. Иначе просто деньги в трубу и обвинения от "общественности" в распиле.
В приличном обществе можно.
Edge, да и IE тоже — самые плавные браузеры на Windows. Но большинству плевать.
Не знаю на счёт глючности первой версии 95, но работала она быстрее OSR2. На 486 мне это было принципиально. Как минимум у стандартных контролов было меньше спецэффектов и они были более отзывчивые. А поскольку они применялись почти всеми программами, всё было более отзывчивым.
Я знаю, что она делает, но мне не надо в Output. Если уж писать, то в отдельный файл. Чтобы в релизных версиях работало, чтобы логи сохранялись, чтобы можно было открыть посмотреть старые, чтобы дифы делать, чтобы с чужой машины было что получить...
Знаю, что Debug/Trace умеют направлять сообщения не только в Output, но и в другие места одновременно. Из этих других мест я их, скорее всего, и буду брать, когда понадобится.
Короче, вот это «все разработчики его используют в своей работе ежедневно» в первом абзаце явно зря было написано.
Ну что там реально полезного в рантайме? Логи у меня обычно выводятся в другое место и внутри VS не нужны. Необработанные исключения со стектрейсами видны и так; даже не в курсе, пишутся они в Output или нет. Что ещё?
Я такого не писал. Написал, что в Output не смотрю вообще и просто закрываю, там в основном мусор, который никто не просил. Что есть полезного, есть в Error List, но он тоже большую часть времени автосвёрнут. В процессе набора ошибки и так видно в тексте. Если билд не сбилдится, в Error List будет написано почему. Не особо вчитываясь тыкаешь в строку с ошибкой, открывается исходник, а в нём всё подчёркнуто, подсвечено, при наведении мышки тултипы выскакивают ― уж куда удобнее? Если в списке присутствует какая-то лишняя сейчас информация, можно штатно отфильтровать/пересортировать/настроить так, как больше нравится.
Output ― это ж тупо лог всего подряд. Я допускаю, что он может быть иногда полезен. Когда случается какая-то непонятная фигня непонятно почему, тогда открываешь лог и смотришь, что происходит. Но чтобы постоянно туда смотреть...
В C# при редактировании все ошибки подсвечиваются на лету прямо в тексте. В Error List смотреть не надо, у меня он обычно свёрнут. Т.е. в C# для меня окно Output вообще бесполезно; а Error List полезен эпизодически, если билд вдруг не сбилдился или там ещё можно включить/выключить показ предупреждений/предложений от статических анализаторов.
А вот как всё происходит в C++, я не в курсе.
Тогда понятно. В C# одна реальная ошибка обычно не приводит к каскаду фантомных ошибок компиляции, поэтому всё равно, в каком порядке ошибки представлены в списке. Если в списке их три, скорее всего, их реально три в разных местах. А если они ещё сортируются по типу или алфавиту, то так даже удобнее.
Поэтому я в окно Output не смотрю и сразу закрываю, если появилось.
С Unity так же. Пока делали игру, поняли, что движок под эту игру получается лучше, чем сама игра. Игру вроде даже выпустили, но всё внимание переключили на дальнейшую работу над движком.
Есть же окошко Error List со списком ошибок и предупреждений и без постороннего мусора, типа Build started/Build failed/Loaded module...
Или оно только для дотнета есть, а для cpp нет?
Каждый абзац насыщен информацией, всё по делу, без воды, без лажи. Отличная статья, спасибо!
Использую тёмные или скорее серые темы при работе с графикой, а код/текст предпочитаю чёрным по белому. Потому что когда читаешь, некоторое время задерживаешь взгляд на светлых строчках на тёмном фоне, они отпечатываются на сетчатке, и когда переводишь взгляд, в глазах рябит. Нафиг.
Но в случае LCD это не тишина, а стон с кляпом во рту.
В 2д расчётах можно стерпеть ― ну, помнит человек школьную программу, уже хорошо. Но когда в коде видишь синусы/косинусы вместе с переменными x, y, z, бедного автора хочется пожалеть и чем-нибудь приласкать.
Без разницы кто лучше вообще, Феррари или Ламборгини. Интереснее, кто лучше за ту сумму, которую не жалко на апгрейд. На момент двух предыдущих апгрейдов лучше был Intel, до них лучше был AMD, сейчас опять AMD. Через год, может, опять поменяется, а может, прилетит метеорит и мы все умрём.
3700X на дешёвой материнке с самой дешёвой 3200/CL16 памятью по моим тестам и впечатлениям получился в 1,5–2 раза быстрее i5-2500K @4.4 ГГц в однопотоке, плюс в два раза больше ядер, плюс SMT/HT (хотя у i7 оно тоже было). Вот бы ещё цена была как у 2500K, но я 8 лет ждал ― не дождался.
На всякий случай делал reality-check перед апгрейдом. i7-9700K без HT стоил дороже 3700X на цену материнки, а похожий i9-9900K на цену материнки вместе с памятью. Скорее всего, ещё нормальный кулер будет нужен, чтобы охлаждал и не визжал. Эти процессоры для игр просто не имеют смысла, потому что та же разница в цене, но потраченная на видеокарту, даст больший эффект. Если же смотреть, что у Интела есть дешевле, то оно заметно хуже и апгрейд 8-летнего сандика вообще теряет смысл.