-
Уважаемый посетитель!!!
Если Вы уже являетесь зарегистрированным участником проекта "миХей.ру - дискусcионный клуб",
пожалуйста, восстановите свой пароль самостоятельно, либо свяжитесь с администратором через Телеграм.
Обсуждение игровых движков
- Автор темы klever
- Дата начала
N
NeyRom
Гость
Fractal
В Age of Empires самые настоящие спрайты и только они. 256 цветов каждого спрайта - и никакого мошенничества
А то, что много позиций и углов - это называется трудолюбие и большой бюджет И в "Казаки" тоже самое.
В Age of Empires самые настоящие спрайты и только они. 256 цветов каждого спрайта - и никакого мошенничества
А то, что много позиций и углов - это называется трудолюбие и большой бюджет И в "Казаки" тоже самое.
Fractal
Почетный участник
NeyRom
В эпохе империй каждый объект имеет 32 положения по повороту, умножить на хрен знает сколько, но точно не меньше 20-30 позиций движения/атаки/смерти...Итого порядка 750 спрайтов. Юнитов порядка 100. 75000 спрайтов.
Каждый минимум 64*64*24бит, те 12кб. Получается более гб одних спрайтов для юнитов... А еще ведь строения есть, деревья, прочее....Да не только ведь спрайты место на диске занимают... Имхо во время игры там спрайты, но они не хранятся на диске, а просчитываются при запуске игры, или что-то в этом роде.
В эпохе империй каждый объект имеет 32 положения по повороту, умножить на хрен знает сколько, но точно не меньше 20-30 позиций движения/атаки/смерти...Итого порядка 750 спрайтов. Юнитов порядка 100. 75000 спрайтов.
Каждый минимум 64*64*24бит, те 12кб. Получается более гб одних спрайтов для юнитов... А еще ведь строения есть, деревья, прочее....Да не только ведь спрайты место на диске занимают... Имхо во время игры там спрайты, но они не хранятся на диске, а просчитываются при запуске игры, или что-то в этом роде.
N
NeyRom
Гость
Fractal
Нету никаких 24-х битов, всего 8, выделен прозрачный цвет! То есть не 12 Кбайт, а всего 4.
По-твоему, проще _рендерить_ все фазы анимации юнитов _заранее_, чем просто хранить их запакованными PNG, скажем, и распаковывать в RAM?? А модели-то для рендеринга - высокополигональные, они, хоть и маленькие, а долго рендерятся, да и места занимают гораздо больше картинки 64*64. И кратный степени 2 размер картинки не нужен - это не 3D графика, вывод через поверхности DirectDraw в лучшем случае, значит, еще меньше картинка.
Нету никаких 24-х битов, всего 8, выделен прозрачный цвет! То есть не 12 Кбайт, а всего 4.
По-твоему, проще _рендерить_ все фазы анимации юнитов _заранее_, чем просто хранить их запакованными PNG, скажем, и распаковывать в RAM?? А модели-то для рендеринга - высокополигональные, они, хоть и маленькие, а долго рендерятся, да и места занимают гораздо больше картинки 64*64. И кратный степени 2 размер картинки не нужен - это не 3D графика, вывод через поверхности DirectDraw в лучшем случае, значит, еще меньше картинка.
Fractal
Почетный участник
NeyRom
Тогда создай новую тему и скопируй сообщения, ты же модер..
Я не уверен насчет 8бит, имхо на скрин там точно больше 256 цветов приходится... А одна модель займет точно меньше места, чем 750*12кб, те 5-6мб. Кроме того, я же говорил, что они "кастрировано" рендерятся, те кое-что просчитано заранее, а кое-что (то, что легко меняется при повороте итп)
просчитывается. Возможно там еще и комбинируются различные элементы, например руки/ноги итп просчитаны во всех положениях по отдельности, а потом склеиваются. Из-за этого картинка становится не 64*64, а 20*20, например(я не говорил, что она должна быть степени 2, просто навскидку сказал)...
Возможно ты прав, тридешного предпросчета там нет, но как-то они модифицируются перед запуском (а может в процессе инсталляции?)
Тогда создай новую тему и скопируй сообщения, ты же модер..
Я не уверен насчет 8бит, имхо на скрин там точно больше 256 цветов приходится... А одна модель займет точно меньше места, чем 750*12кб, те 5-6мб. Кроме того, я же говорил, что они "кастрировано" рендерятся, те кое-что просчитано заранее, а кое-что (то, что легко меняется при повороте итп)
просчитывается. Возможно там еще и комбинируются различные элементы, например руки/ноги итп просчитаны во всех положениях по отдельности, а потом склеиваются. Из-за этого картинка становится не 64*64, а 20*20, например(я не говорил, что она должна быть степени 2, просто навскидку сказал)...
Возможно ты прав, тридешного предпросчета там нет, но как-то они модифицируются перед запуском (а может в процессе инсталляции?)
N
NeyRom
Гость
Fractal
Фреймбувер, ясен перец, 16 или 32 бита, у каждой модели своя, адаптивная палитра в 256 цветов.
Далее, AoE2 - на 2-х CD. Кроме графики, объемны еще мультики и карты, все остальное весит копейки. У Мелкософта есть шикарный архиватор CAB, так что даже при том раскладе, что ты насчитал 64*64*3, все влезает легко. Но на самом деле объем спрайтов меньше, и я объяснил почему.
Пожалуйста
Фреймбувер, ясен перец, 16 или 32 бита, у каждой модели своя, адаптивная палитра в 256 цветов.
Далее, AoE2 - на 2-х CD. Кроме графики, объемны еще мультики и карты, все остальное весит копейки. У Мелкософта есть шикарный архиватор CAB, так что даже при том раскладе, что ты насчитал 64*64*3, все влезает легко. Но на самом деле объем спрайтов меньше, и я объяснил почему.
Слишком сложно, зачем все это, если можно просто хранить просчитанные спрайты? Они это и не делают, а хранят как раз спрайты, в файлах .SLP, а отдельно хранят палитры в файла .PAL, поэтому вот это
справедливо, в зависимости от выбранного цвета юнитов для SLP, которая хранит только индексы, подставляется нужная палитра и готовый спрайт загружается в оперативку. Все!
Fractal
Почетный участник
NeyRom
Вероятно ты прав, не буду спорить...Правда aoe2 на одном диске, по крайней мере я так покупал....
И CAB-ом изображения, тем более в индексированном цвете не сожмешь особо...
То, что они не хранят отдельно спрайты для каждого цвета юнитов, это понятно, так даже в warcraft (первом) было...
Вероятно ты прав, не буду спорить...Правда aoe2 на одном диске, по крайней мере я так покупал....
И CAB-ом изображения, тем более в индексированном цвете не сожмешь особо...
То, что они не хранят отдельно спрайты для каждого цвета юнитов, это понятно, так даже в warcraft (первом) было...
N
NeyRom
Гость
Fractal
Ок, пока отложим эту дискуссию, постараюсь найти AoE2 и представить доказательства
Предлагаю в развитие темы делать обудить развитие игровых движкок применительно к разным жанрам, допустим, что дает 3D для RTS и нужно ли оно вообще, или, когда будет рей-трейсинг в шутерах
Ок, пока отложим эту дискуссию, постараюсь найти AoE2 и представить доказательства
Предлагаю в развитие темы делать обудить развитие игровых движкок применительно к разным жанрам, допустим, что дает 3D для RTS и нужно ли оно вообще, или, когда будет рей-трейсинг в шутерах
Fractal
Почетный участник
NeyRom
Рей-трейсинг в шутерах будет очень нескоро, это я тебе гарантирую... Для этого нужно на несколько порядков увеличить скорость процов...И все равно проблем много будет.
Кроме того, необходимо различать рейтрейсинг(прямую трассировку лучей, те трассировку из источников света), и рейкастинг (обратную трассировку, те трассировку из камеры)
Также можно их комбинировать, иногда это единственный выход, например, когда скорость просчета важна (когда ждать 1 сутки сильно легче, чем 1 год
), но и качество световых эффектов (таких, как солнечные зайчики, световые пятна за преломляющими объектами итп)... Правда и этот способ далеко не всегда можно применить...
Единственное "но" - оба эти принципа идеально разпараллеливаются, те их можно разделить на много
процессоров, и прирост производительности будет почти в n раз... Так что теоретически даже сейчас можно добится скорости 50fps на рейтрейсинге (всего лишь 10000-20000 процов ).......
Рей-трейсинг в шутерах будет очень нескоро, это я тебе гарантирую... Для этого нужно на несколько порядков увеличить скорость процов...И все равно проблем много будет.
Кроме того, необходимо различать рейтрейсинг(прямую трассировку лучей, те трассировку из источников света), и рейкастинг (обратную трассировку, те трассировку из камеры)
Также можно их комбинировать, иногда это единственный выход, например, когда скорость просчета важна (когда ждать 1 сутки сильно легче, чем 1 год
), но и качество световых эффектов (таких, как солнечные зайчики, световые пятна за преломляющими объектами итп)... Правда и этот способ далеко не всегда можно применить...Единственное "но" - оба эти принципа идеально разпараллеливаются, те их можно разделить на много
процессоров, и прирост производительности будет почти в n раз... Так что теоретически даже сейчас можно добится скорости 50fps на рейтрейсинге (всего лишь 10000-20000 процов ).......
N
NeyRom
Гость
Fractal
На самом деле, рей-трейсинг я упомянул постольку-поскольку, потому что мейнстрим графики ближайший год-два не за ним. Пакет RenderMan обходится _совсем_ без рей-трейсинга, одним высокоуровневым языком шейдеров, и ничего, Toy Story 2 и еще прорву чего еще рендерили в нем Pixar и останавливаться не собираются... И такой подход есть к фотореализму 3D-графики.
Золотые слова!!! Вот разработчики графических чипов тоже это знают и делают к этому семимильные шаги. В чипе Radeon 9700 - 4 независимых процессора примитивов и 8 процессоров закраски (это уже не текстурные конвееры). Все они программируются (циклы, ветвления) и умеют накапливать результат (есть правда ограничения). У GFFX процессоры, хоть их и меньше, но еще гибче. Так что я убежден, рей-трейсинг (или рей-кастинг) можно сделать уже сейчас. Посмотри демку SevenHeaven - там уже рей-трейсинг, и шустро идет на 500-х пеньках. Посмотри тест CPU RightMark - это тоже рей-трейсинг! Рей-трейсинг, пусть и не в полном объеме, будет скороЕдинственное "но" - оба эти принципа идеально разпараллеливаются, те их можно разделить на много
На самом деле, рей-трейсинг я упомянул постольку-поскольку, потому что мейнстрим графики ближайший год-два не за ним. Пакет RenderMan обходится _совсем_ без рей-трейсинга, одним высокоуровневым языком шейдеров, и ничего, Toy Story 2 и еще прорву чего еще рендерили в нем Pixar и останавливаться не собираются... И такой подход есть к фотореализму 3D-графики.
Fractal
Почетный участник
На самом деле, это все не рейтрейсинг
Точнее не совсем...
Хотя SevenHeaven я вообще не нашел, не знаю, напиши адресок, но CPU RightMark я заценил.. Сделано качественно, но:
1) как ты думаешь, почему там все из сфер сделано?
Ты видел грани в этих сферах? Вот именно, нет, тк они сделаны не из граней, они являются кривыми поверхностями..
Это намного увеличивает скорость, тк вместо 100-1000-10000 плоских граней нужно просчитывать одну кривую поверхность, которая конечно сложнее, но не в сто раз. Это правильно и хорошо, но о скорости просчета реальных граней здесь судить очень сложно, а из сфер, конусов и циллиндров нормальной сцены не построишь. А кривые поверхности более высокого порядка, а также сплайн-апроксимированные (NURBS итп) считаются чудовищно медленно.
2) Сколько их там, этих сфер? На порядки меньше, чем граней в современных моделях...
3) Не заметил, угол визира камеры МАЛ, те нет искажений "рыбьего глаза".. Чем это выгодно? А вот чем: так-как все сделано только из сфер, то можно для каждой сферы в каждый кадр хранить центр её проекции на экран (из-за отсутствия рыбьего глаза это будет круг), и радиус этой проекции (вычисляется элементарно и очень быстро, тк один раз для всего кадра, а не для каждой точки. После этого для каждой экранной точки мы знаем, какие сферы проецируются на неё, их получается немного (1-2, а в большинстве случаев - ни одной, те отображается фон), так что отсев ближайшей поверхности делается элементарно...Отражения на самом деле занимают не так уж и много процессорного времени, тк площадь отражающих поверхностей на экране мала, и чаще всего луч отразившись, уходит за границы сцены.
В реальной сцене, понятное дело всё будет намного сложнее, и эти оптимизации работать не будут, или будут малоэффективны.
3)1-2 фпс на 1024*600 - не слишком много Надо понимать, что этот метод (трассировка лучей) зависит по скорости от количества граней сцены КВАДРАТИЧНО, в то время как классический - ЛИНЕЙНО, а это значит, что при увеличении сложности сцены в 100 раз фпс будет 1-2*10-4, что не слишком круто, а сцена все равно будет проще, чем в современных играх. И из шариков маленьких
4) Не понятно, зачем вообще это сейчас нужно? Когда-нибудь видел, какая скорость просчета на пакетах вроде 3d studio max или maya со включеной трассировкой лучей? Средненькая сценка с одним стаканчиком, преломляющим свет по более-менее реалистичному принципу просчитывается на 640*480 на p3 733мгц около 4 часов, притом стаканчик довольно мал (150*100), все остальное занимают простые для просчета объекты...Зато в этом случае действительно налицо преимущества такого просчета, выглядит очень неплохо, просчитываются отражения и преломления... Да и то, из-за того, что там обратная трассировка, блик от стакана отсутствует....
Конечно, отдельные элементы трассировки лучей могут применяться, но с бешенными ограничениями, и в очень частных случаях.
Да, еще забыл сказать, при трассировке лучей скорость очень сильно (практически линейно) зависит от количества источников света, а в данной сцене нормальных (точечных) источников света вообще нет, есть два вектора освещения, что вообще очень быстро для просчета, тк не нужно просчитывать путь от источника до цели....
Точнее не совсем...
Хотя SevenHeaven я вообще не нашел, не знаю, напиши адресок, но CPU RightMark я заценил.. Сделано качественно, но:
1) как ты думаешь, почему там все из сфер сделано?
Ты видел грани в этих сферах? Вот именно, нет, тк они сделаны не из граней, они являются кривыми поверхностями..
Это намного увеличивает скорость, тк вместо 100-1000-10000 плоских граней нужно просчитывать одну кривую поверхность, которая конечно сложнее, но не в сто раз. Это правильно и хорошо, но о скорости просчета реальных граней здесь судить очень сложно, а из сфер, конусов и циллиндров нормальной сцены не построишь. А кривые поверхности более высокого порядка, а также сплайн-апроксимированные (NURBS итп) считаются чудовищно медленно.
2) Сколько их там, этих сфер? На порядки меньше, чем граней в современных моделях...
3) Не заметил, угол визира камеры МАЛ, те нет искажений "рыбьего глаза".. Чем это выгодно? А вот чем: так-как все сделано только из сфер, то можно для каждой сферы в каждый кадр хранить центр её проекции на экран (из-за отсутствия рыбьего глаза это будет круг), и радиус этой проекции (вычисляется элементарно и очень быстро, тк один раз для всего кадра, а не для каждой точки. После этого для каждой экранной точки мы знаем, какие сферы проецируются на неё, их получается немного (1-2, а в большинстве случаев - ни одной, те отображается фон), так что отсев ближайшей поверхности делается элементарно...Отражения на самом деле занимают не так уж и много процессорного времени, тк площадь отражающих поверхностей на экране мала, и чаще всего луч отразившись, уходит за границы сцены.
В реальной сцене, понятное дело всё будет намного сложнее, и эти оптимизации работать не будут, или будут малоэффективны.
3)1-2 фпс на 1024*600 - не слишком много
Надо понимать, что этот метод (трассировка лучей) зависит по скорости от количества граней сцены КВАДРАТИЧНО, в то время как классический - ЛИНЕЙНО, а это значит, что при увеличении сложности сцены в 100 раз фпс будет 1-2*10-4, что не слишком круто, а сцена все равно будет проще, чем в современных играх. И из шариков маленьких 4) Не понятно, зачем вообще это сейчас нужно? Когда-нибудь видел, какая скорость просчета на пакетах вроде 3d studio max или maya со включеной трассировкой лучей? Средненькая сценка с одним стаканчиком, преломляющим свет по более-менее реалистичному принципу просчитывается на 640*480 на p3 733мгц около 4 часов, притом стаканчик довольно мал (150*100), все остальное занимают простые для просчета объекты...Зато в этом случае действительно налицо преимущества такого просчета, выглядит очень неплохо, просчитываются отражения и преломления... Да и то, из-за того, что там обратная трассировка, блик от стакана отсутствует....
Конечно, отдельные элементы трассировки лучей могут применяться, но с бешенными ограничениями, и в очень частных случаях.
Да, еще забыл сказать, при трассировке лучей скорость очень сильно (практически линейно) зависит от количества источников света, а в данной сцене нормальных (точечных) источников света вообще нет, есть два вектора освещения, что вообще очень быстро для просчета, тк не нужно просчитывать путь от источника до цели....
N
NeyRom
Гость
Fractal
Сорри, ошибся, на самом деле Heaven Seven Вот прямой линк http://www.demoscene.hu/~picard/h7/h7-final.zip
1. Из сфер сделано исключительно по тем причинам, что ты назвал, для оптимизации. Кстати, я где-то в конфе iXBT для разработчиков видел линк на сплайновый движок, на моей машиннке, скажем, не сильно тормозил Только я не знаю принципа, там в реал-тайм тесселируются сплайны или заранее, при загрузке. Что не редактором уровней - это точно.
2. Но зато они сферы
3. Там, IMHO, камера вообще без перспективы, просто как View в 3DMax.
4. Ну не знаю, у мемня было намного больше Правда, там зверская оптимизация SSE2, а у меня четырепень.
5. Видел, видел Стаканчик я не рендерил правда, но процедурные деревья из 3DViz с рей-трейсинговыми тенями рендерились в три раза дольше, чем scan-line'ом с генерацией shadowmap'ов. Причем последний результат мне понравился гораздо больше - в жизни тени не такие резкие, как дает Максовый трейсер. Вообще, я уверен, что что-то не докрутил просто
В игровых движках вообще не обойтись без оптимизаций. Для этого и придумали BSP-деревья и порталы. Ессно, я не имел в виду, что в играх прямо скоро будет честный рейтрейсинг всего и вся, конечно выборочно, конечно где-то имитированно. Главное, что EyeCandy будет достигаться.
Сорри, ошибся, на самом деле Heaven Seven
Вот прямой линк http://www.demoscene.hu/~picard/h7/h7-final.zip 1. Из сфер сделано исключительно по тем причинам, что ты назвал, для оптимизации. Кстати, я где-то в конфе iXBT для разработчиков видел линк на сплайновый движок, на моей машиннке, скажем, не сильно тормозил
Только я не знаю принципа, там в реал-тайм тесселируются сплайны или заранее, при загрузке. Что не редактором уровней - это точно.2. Но зато они сферы
3. Там, IMHO, камера вообще без перспективы, просто как View в 3DMax.
4. Ну не знаю, у мемня было намного больше
Правда, там зверская оптимизация SSE2, а у меня четырепень.5. Видел, видел
Стаканчик я не рендерил правда, но процедурные деревья из 3DViz с рей-трейсинговыми тенями рендерились в три раза дольше, чем scan-line'ом с генерацией shadowmap'ов. Причем последний результат мне понравился гораздо больше - в жизни тени не такие резкие, как дает Максовый трейсер. Вообще, я уверен, что что-то не докрутил простоВ игровых движках вообще не обойтись без оптимизаций. Для этого и придумали BSP-деревья и порталы. Ессно, я не имел в виду, что в играх прямо скоро будет честный рейтрейсинг всего и вся, конечно выборочно, конечно где-то имитированно. Главное, что EyeCandy будет достигаться.
N
NeyRom
Гость
Игровые движки
Здесь собраны все известные мне игровые движки и игры, под капотом которых они работают. Список точно не полный, надеюсь, будет пополнятся.
Quake I: Quake, Hexen 2;
Quake 2: Quake 2, Sin, Half-Life, Soldier of Fortune;
Quake III: Quake III, Star Treck Voyager: Elite Force, Medal of Honour: Allied Assault, Return to Castle Wolfenstain, Star Wars Jedi Knight: Jedi Outcast, Soldier of Fortune 2, Star Treck: Elite Force 2, Star Wars: Jedi Academy, Call of Duty, Medal of Honour: Pacific Assault;
Serious Engine: Serious Sam: First Encounter, Serious Sam: Second Encounter, Nitro Family;
LS3D: Mafia, Hidden&Dangerous 2;
Doom III: Doom III, Quake 4;
Source Engine: Half-Life 2;
Renderware: GTA3, GTA: Vice City, Axel Rage;
Gamebryo: The Elder Scroll III: Morrowind, Dragon Empires, Dark Age of Camelot, Star Trek: Bridge Commander, Freedom Force
Krass Engine: Aquanox, Aquanox:Revelation, Spell Force: Order of Dawn;
Unreal Engine: Unreal, Unreal Tournament, Rune;
Unreal 2 Engine: Unreal Tournament 2003, Unreal 2: The Awakening, Raven Shield 3, Splinter Cell, Postal 2, Devastation, Duke Nukem Forever;
LithTech Jupiter: No One Live Forever 1&2, Contract J.A.C.K, TRON 2.0;
Max FX: Max Payne, Max Payne 2: Fall of Max Payne;
Vital Engine: Venom, Xenus;
X-Ray: S.T.A.L.K.E.R: Oblivion Lost;
Storm Engine: Корсары, Пираты Карибского Моря, Морской Охотник;
Sage: Command&Conquer: Generals, The Lord of the Rings: Battle for Middle Earth;
CryENGINE: Far Cry;
Aurora: Neverwinter Nights, Star Wars: Knights of the Old Republic
Здесь собраны все известные мне игровые движки и игры, под капотом которых они работают. Список точно не полный, надеюсь, будет пополнятся.
Quake I: Quake, Hexen 2;
Quake 2: Quake 2, Sin, Half-Life, Soldier of Fortune;
Quake III: Quake III, Star Treck Voyager: Elite Force, Medal of Honour: Allied Assault, Return to Castle Wolfenstain, Star Wars Jedi Knight: Jedi Outcast, Soldier of Fortune 2, Star Treck: Elite Force 2, Star Wars: Jedi Academy, Call of Duty, Medal of Honour: Pacific Assault;
Serious Engine: Serious Sam: First Encounter, Serious Sam: Second Encounter, Nitro Family;
LS3D: Mafia, Hidden&Dangerous 2;
Doom III: Doom III, Quake 4;
Source Engine: Half-Life 2;
Renderware: GTA3, GTA: Vice City, Axel Rage;
Gamebryo: The Elder Scroll III: Morrowind, Dragon Empires, Dark Age of Camelot, Star Trek: Bridge Commander, Freedom Force
Krass Engine: Aquanox, Aquanox:Revelation, Spell Force: Order of Dawn;
Unreal Engine: Unreal, Unreal Tournament, Rune;
Unreal 2 Engine: Unreal Tournament 2003, Unreal 2: The Awakening, Raven Shield 3, Splinter Cell, Postal 2, Devastation, Duke Nukem Forever;
LithTech Jupiter: No One Live Forever 1&2, Contract J.A.C.K, TRON 2.0;
Max FX: Max Payne, Max Payne 2: Fall of Max Payne;
Vital Engine: Venom, Xenus;
X-Ray: S.T.A.L.K.E.R: Oblivion Lost;
Storm Engine: Корсары, Пираты Карибского Моря, Морской Охотник;
Sage: Command&Conquer: Generals, The Lord of the Rings: Battle for Middle Earth;
CryENGINE: Far Cry;
Aurora: Neverwinter Nights, Star Wars: Knights of the Old Republic
Похожие темы
- Закреплено
