Quest3D - Русскоязычное сообщество

Здравствуйте. Работаю я в Максе, программу Quest3d впервые, я открыл минут 5 назад. У меня сразу возник вопрос, Quest3d у меня версии 3.0d каким образом я могу её обновить до версии 3.6? ???

Скачать версию 3.6 и установить, можешь оставить и старую версию, будешь сразу в двух делать ;)

Всем привет! У меня такой вопрос:
  Если я правильно понял, рекомендуется использовать текстуры в формате dds в  stage 1 и лайт мэп в stage 2. Но например если размер Лайт Мэп 1024*1024 и размер
Комплит Мэп 1024*1024 то в чем будет разница если в stage 1 ложить Комплит Мэп, а в stage 2 - ничего? Всмысле почему это будет хуже?

Текстуры квест сам конвертит в dds после загрузки.

Посчитай скока раз повторяется текстура на объекте...

При мультитекстуринге в память видеокарты грузятся только текстура и лайтмэп.
Если использовать одну текстуру(текстура+лайтмэп) то чтобы сохранить тоже качество текстуры, те понадобится подгрузить текстуру больше на колво повторений которое ты насчитал.
Если колво до 3 то не очень страшно... А если 100 ?

YoZJ, с чего ты взял что "Квест" конвертит в *.dds, где такое написано?

Ты как-то мутно написал о "мультитекстуринге"  :o я то не сразу понял, что ты имеешь ввиду  :D
Мой перевод:
Если объекте покрыт плиткой, а объект большой - то что бы получить качественный "комплит" придется
просчитывать бооольшую текстуру(например - 4096х4096). В такой ситуации проще использовать раздельно
"диффуз" и "лайтмап", можно взять текстуру плитки (например - 64х64) и "растайлить" в Stage1,
а в Stage2 поместить "лайтмап" (например - 512х512).
В итоге получится лучшее качество с меньшей загрузкой памяти видеокарты.

vik, не обязательно использовать Stage2, все зависит от твоих потребностей,
иногда хватает "комплита", а иногда нужна "лайтмап". Можно просто использовать цвет
и ИС "Квеста", разные проекты, разный подход. Не надо зацикливаться на том, что написано
в уроках, они показывают, что можно сделать в конкретной ситуации, но ситуации бывают разные  :D

1. текстуры не кратные степени двойки маштабируются в кратные (требование dds формата)
2. В DirectX приложениях, использующих мипмапинг, текстуры в dds формате.
3. В диалоге можно указать колво мипмэпов
4. Знаете другой формат поддержимающий мипмэпы?

Вообщем на 99% уверен.

Спасибо! Очень информативненько!

Тогда будем искать 1%  ;D
0,3% - Если бы в "Квест" был встроен полноценный конвертер в *.dds, то почему в видео-уроках от "АКТ-3Д"
используются в основном текстуры в формате *.dds? Если нет разницы в формате, тогда зачем в уроке №03
"лайтмап" в *.dds, ведь можно было при "запекании" сохранить в *.tga и потом сразу запихнуть в "Квест".
0,5% - Идем в "хелп" и пытаемся прочитать описание канала "Texture":
"This texture channel can load a picture from your hard disk and use it as a texture.
When you save the channel group the picture is saved within the CGR in the original format.
This means that a *.JPG keeps its small size."
Пытаемся перевести программой-переводчиком:  :o
"Этот канал структуры может загрузить картину от вашего жесткого диска и использовать
это как структура. Когда Вы спасаете группу канала, картина спасена в пределах CGR в оригинальном формате.
Это означает, что *.JPG держит его небольшой размер."
Теперь пытаемся перевести программный перевод:  :D
"Этот текстурный канал может загрузить изображение с вашего жесткого диска и использовать как текстуру.
Когда вы сохраняете группу каналов, изображение записывается в CGR в оригинальном формате. Это означает,
что если брать формат *.jpg, то в проекте (*.cgr) изображение будет занимать такой же малый размер."
0,2% - Разработчики - советуют, на офф. форуме - советуют, все кому не лень - советуют, использовать *.dds 

Вполне возможно - 1) что при компиляции в *.ЕХЕ, "Квест" все текстуры загоняет в *.dds, а возможно 2) он это
делает уже при запуске откомпилированного *.EXE. Тогда при втором варианте, получается - чем больше текстур,
тем дольше будет загружаться, ведь на перегонку изображений из других форматов в формат *.dds нужно время.
Я не утверждаю, я пытаюсь узнать ;)  Может я заблуждаюсь и готов выслушать опровержение моим домыслам.

P.S.
Еще, всем кто не в курсе, советую почитать замечания (Remarks) в "хелпе" по каналу "Texture"

YoZJ писал:точнее было бы "Текстуры квест сам конвертит в dds при компиляции"

Опять же 100% уверености нет.

Похоже в проекте они хранятся в оригинале(Чтобы удобно было изменить в другой программе и сделать релод), но параметры dds задаются в свойствах текстур при загрузке.

Логичнее 1 вариант. По 2 варианту. Зачем в ехе встроенный конвертр? Конвертация при запуске жрет время...

Вообщем, я заметил, что квест работает с любым форматом без проблемм. Так что смысла конвертить в dds не вижу... Разве что, осознано использовать возможности dds, такие как нормалмап в альфа канале. Хотя в диалоге текстур надо подгружать альфаканал отдельно... А вот этот абзац, застсвляет сомневаться в возможности использования нормалмэппинга...

Мип-меппинг поддерживается аппаратно практически всеми современными видео, за посредством графф двига. Квест не конвертит текстуры в DDS. Использование DDS имеет
смысл в плане оптимизации. DDS — это формат графических файлов специально разработанный для приложений и текстур DirectX.

Большой выбор DDS "форматов" позволяет "платить" производительностью ТОЛЬКО! за то что мы используем.DDS предоставляет широкий выбор "форматов", практически на "все случаи жизни". Парива конечно больше, но я четко понимаю сколько видеопамяти(для текстур) я использую.

С Нормалмаппингом, Бампмаппиногом и разновидностями Квест "дружит" за посредством шейдеров.               

Непонятно, зачем тогда:
1. текстуры не кратные степени двойки маштабируются в кратные
2. В диалоге можно указать колво мипмэпов
если мы грузим jpg?
Он мипмэпы в формате jpg чтоль считает, или не считает вообще?

Вообщем, декомпильнуть надо ехе и посмотреть...

1 Это делается для совместимости с ранними моделями видео где большинство не разрешают использовать текстуры, размеры которых не являются степенями двойки.
В еще более "древних" видео еще были ограничения на текстуры у которых высота отличается от ширины (то есть, размером 128 × 64 или 32 × 256).

2 Использование мипмапинга повышает быстродействие, так как более эффективно используеться текстурная кеш-память видеокарты, и меньше данных приходиться передавать по шине.

Генерацию мип-уровней можно сделать несколькими способами:

1)Это указать видеокарте сгенерировать мип-уровни. То что вы сделаете, указав в диалоге текстуре количество мип-мепов. Формат тут не при чем!!!

2)Другой вариант - генерировать мипмапы самому, воспользовавшись пакетами для редактирования изображений, которые уже имеют нужную функциональность. Вот тут на сцену "выходит" DDS.

Вариант второй дает значительно лучший результат, как по производительности так и по качеству изображения.

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

Хочу окончательно рассеять сомнения в полезности использования DDS. Прелесть DDS не токо в мип мапах. Контроль текстурной видеопамяти.

Например вот такой формат - A8R8G8B8 говорит о том, что для хранения значения одного пикселя текстуры будет использовано 32бита(8 бит на Альфу, и по 8 на каждую цветовую компоненту). Причем, без значения используем мы ту самую альфу, или нет:))). А теперь представте сколько в видеопамяти будет занимать текстура 256x256?.

Припустим нужно хранить Grayscale текстуру. Большинство знакомых мне художников
используют для этих целей R8G8B8 расходуя 24бита на пиксель, в то время когда вполне сойдет A8(8 бит на пиксель). Есть индивидумы сохраняющие карты нормалей в R8G8B8(24 бита) а следует в X4Y4(8 бит), или U8V8(16 бит), или когда нужна высокая точность U16V16(32 бита). А может нам от текстуры надо только 16 цветов? или 256? Примеров можно привести массу. Идея в том, что бы платить только за то, что мы используем.

Фотожоп DDS плюгин, можно на шару скачать с NVIDIA.           

Вы затронули очень "болезнинную" тему для квеста.
Да действительно использование .ддс повышает скорость обработки текстур.
Но тут есть одно очень важное НО. Что это буквально никаких результатов
в квесте не даст т.к. сист. шина очень главное слабое место квеста -
эти каналы не на прямую обращаются к видеокарте и по очень понятной причине
(квест НЕ компилируется в удобный для компьютера код)

Я утверждать не буду, но у меня по этому поводу другая теория. Если мне подскажут где я не прав, буду благодарен.

Дело в том, что даже "чистое" DirectX приложение не общается с видео напрямую. Есть уровень абстракции HAL - Hardware Abstraction Layer.

Приблизительно это выглядит так

Графдвиг -> DirectX -> HAL -> Видео.

Цель HAL это избавить программиста от титанического труда прямого общения с видео. Учитывая количество разных видео и производителей, со своими заморочками + те модели
которые еще в разработке и когда нибуть да появятся. Как гарантировать, что приложение написанное сегодня, будет работать на различных видео? или на тех, которые появятся скажем через пять лет? Это задача HAL.

В момент, когда наши текстуры "рисуются" значения для текстур читаются из видеопамяти. В кеш памяти видеокарты содержатся ссылки, на тот участок памяти видео,
где содержатся значения наших текстур.

А теперь представим себе что мы "попросили" Quest3D генерировать за нас мип-уровни.
Quest3D-> DirectX -> HAL -> Видео.

На уровне абстракции HAL -> Видео это происходит где-то так - возможно :)))
1Читаем участок видео памяти(текстура).
2Проcчитываем GPU мип уровень из полученной текстуры(мипмап уровень №1)
3Записываем полученный результат в память видео.
4Записываем указатель на участок памяти выделенный для хранения миплевела в кеш     
и так дальше... в зависимости от количества нужных нам мип-левелов.

Пусть у нас получилось 5 мип-мап уровней. Причем самый верхний(основная текстура)
занимает больше всего видеопамяти, а последняя меньше всего. Теперь, рисуя такую текстуру мы способны контролировать нагрузку на ВИДЕО - шину, поскольку рисуем(читать - (читаем и считаем)) ту текстуру(участок видео памяти(мипмапуровень)) которая нам нужна в зависимости от детализации. Ни системная шина, ни квест не имеют
к этому процессу прямого отношения.

Я не это имел в виду.
А в виду я имел следующее:
Что этот метод "освобождает сист. шину от нагрузок. Но
при использовании квеста в среде DirectX квест именно нагружает
системную шину в связи с использованием частых лишних обработок
каналов процессором. :(

Я не имел ввиду системную шину. А то что квест грузит проц и не только, это чистая правда. Особенно вам, как человеку выступающему по физике это особенно понятно. Ведь физику считаете СPU. Думаю использование SDK может решить массу проблем. С графикой несколько другая ситуация. Фактически графика от Q3D архитектуры страдает только от части. С одной стороны графика проблема GPU, с другой - архитектура Квеста иногда просто выводит из себя. Каждый канал Q3D считает уникальным, то есть, если я буду использовать 10 каналов с одинаковой текстурой, то получу десятикратное увеличение использования видеопамяти! Но с другой стороны, мне ничего не мешает использовать
один канал текстуры, и накопипастить 10 ссылок ;). Есть и другие заморочки, например
для HLSL - канала такой фокус не пройдет. Короче - оптимизируем как получается.       

В теме обсуждаются просто таки ЧАЙНИЦКИЕ вропросы ))))
Простите за оффтоп  ::)

У меня следующий вопрос:
А что в Квесте нет такой функции как Undo/Отменить??? Вренутся назад, Ctrl+Z !?!?

Неужели разработчики думают, что ее можно изучить без ошибок и работать в ней без ошибок... видемо, где-то я не досмотрел - подскажите, где?

Вот эта ерить меня тоже бесит.

Но есть такая вещь см. скрин.
Restore - нынешний
Last Save - вернуться к последнему сохранению

Агааа! Понятненько! я счас пока мануал прохожу, так из-за ошибки приходилось всю сцену заново подгружать и все заново повторять. Счас то оно хорошо - все впервой, запоманается лучше, а если это будет свой проект, глобальных масштабов... Мелочь, вроде бы, но ценная-то какая ))
Спасибо за подсказку,Denil-Tornado :)