Войти
ПроектыФорумСобираю команду

iEngine2 DX9/10/11 + PhysX/Havok + PC/XBox (Киев) (5 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#60
23:17, 8 фев 2009

Добавил оптимизацию геометрии под кеш видео карточки с генерацией стрипов и получил дополнительно +30 FPS ! :)

#61
20:07, 22 фев 2009

Рендеринг ландшафта 8к х 8к (пока без красивых текстурок :) )

#62
1:22, 16 мар 2009

Сделал механизм постраничного чтения и записи в файл.

#63
17:50, 6 мая 2009

Assassin
Красивая калька с Огре, имхо Огр далеко не пример для подражания...в некоторых аспектах да, но в целом не не..ни разу


Продолжая тему ^_^

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
  // создаем ядро
  // когда создается ядро, автоматически инициализируются
  // основные модули движка, такие как фабрика плагинов
  // и менеджер лога
  Atlantis::ICore* core = Atlantis::createCore();

  // получаем указатель на фабрику плагинов
  Atlantis::IPluginFactory* pluginFactory = core->getPluginFactory();


  // плагины можно загружать как вручную, так и с помощью конфиг
  // файла (xml)
#  ifdef ATLANTIS_DEBUG
    pluginFactory->loadFromConfig("configs/plugins_d.aconfig");
#  else
    pluginFactory->loadFromConfig("configs/plugins.aconfig");
#  endif

  // инициализируем плагины (можно инициализировать вручную)
  /*
  core->initialize(
    "window1",  // заголовок окна
    640,    // ширина окна
    480,    // высота окна
    0,      // позиция по оси x
    0,      // по оси y
    true,    // запустить в полноэкранном режиме?
    false,    // вертикальная синхронизация
    32);    // bpp
  */
  core->initializeFromConfig("configs/start.aconfig");


  // получаем указатель на файловую систему
  Atlantis::IFileSystem* fileSystem = core->getFileSystem();

  // создаем новый источник файлов
  Atlantis::IFileSource* fileSource = fileSystem->createFileSource("main_source");

  // загружаем пути для него из конфига
  fileSource->addPathsFromConfig("configs/paths.aconfig");

  
  // получаем указатель на менеджер логов
  // с помощью менеджера логов у нас есть возможность создать
  // любое количество логов и писать в них нужную информацию
  // например создать индивидуальный лог для нашего плагина
  Atlantis::ILogManager* logManager = core->getLogManager();

  // пока воспользуемся логом движка, сюда добавляются все сообщения
  // движка
  Atlantis::ILog* log = core->getLog();


  // получаем указатель на окно, окно создается в методе initialize, но можно создать и вручную
  //
  // Atlantis::IWindow* window = (Atlantis::IWindow*)pluginManager->createType("window");
  // window->create(...parameters...);
  //
  Atlantis::IWindow* window = core->getWindow();


  // получаем указатель на рендер
  Atlantis::IRender* render = core->getRender();



  // получаем указатель на систему ввода
  Atlantis::IInputSystem* inputSystem = core->getInputSystem();

  // создаем устройства ввода
  Atlantis::IKeyboard* keyboard = (Atlantis::IKeyboard*)inputSystem->createInputObject(Atlantis::IOT_KEYBOARD);



  // пока окно открыто
  while (window->isActive())
  {
    // обрабатываем ввод
    if (keyboard->keyDown(DIK_ESCAPE))
    {
      break;
    }

    // обновляем ввод
    inputSystem->update();


    // очищаем буффер кадра выбранным цветом
    render->clearFrameBuffer(Atlantis::Color(64, 150, 255), true, true);

    // начинаем рендеринг
    render->beginFrame();
    {
      // !!! рендерим !!!
    }
    // заканчиваем рендеринг
    render->endFrame();

    // копируем содержимое заднего буффера в передний
    render->swapBuffers();
  }

  // деинициализируем ядро и освобождаем из под него память
  core->shutdown();
  ATLANTIS_DELETE(core);

  return 0;
}
Прошло более 8 месяцев
#64
2:33, 2 янв 2010

Реализовал:
1. Перенёс рендер в собственный поток. Взаимодействие с потоком ренедеринга производится через систему thread safe очередей.
2. Многопоточный стримминг (картинок пока нет);
3. Мегатекстурирование (картинки на первой странице);
4. Генерация ландшафта на шейдерах 3.0 по карте высот (картинки на первой странице);

#65
13:12, 2 янв 2010

Liberty Prime
> Взаимодействие с потоком ренедеринга производится через систему thread safe
> очередей.
Очереди самопальные или брали откуда-то реализацию? И ещё они lock-free/wait-free?

#66
14:11, 2 янв 2010

Всё самопальное, а за основу взята концепция примера cтримминга из DirectX SDK. 
Поток рендеринга - wait-free. Все остальные (основной поток приложения, потоки стримминга) - синхронизируются.
Вообще - перевести всё по максимуму на lock-less принципы - было бы очень круто ! ) Но это со временем...

К стати - может кто-то посоветовать, как лучше организовать очередь рендеринга!? Дело в том - что сейчас у меня их несколько - пока одна заполняется основным потоком - поток рендеринга рисует из другой. И всё бы хорошо, но - приходится копировать объекты в очередь, а это лишнее время, да и не всегда правильно - потому что, копировать кости меша - например, может занимать много времени. Хотя - в какой-то степени - это позволяет уберечься от лишней синхронизации с каждым объектом. У меня есть идея - сразу создавать несколько копий объекта - и обрабатывать ту - которая не в очереди рендеринга - но это приводит к усложнению архитектуры, и требует много памяти. Так что - буду благодарен за дельные советы ! :)

#67
16:06, 2 янв 2010

А Зачем копировать? Общую очередь между потоками сделай и синхронизируй ее . Или я не так понял?

#68
16:28, 2 янв 2010

Ну смотри - например - у нас есть меш с костями, и тут можно несколькими способами организовать рендеринг такой структуры:
1. Можно трансформировать кость (или группу) и тут же их рисовать.
2. Можно в начале трансформировать - полностью обходя скелет, а потом рендерить - полностью обходя скелет.
3. Можно трансформировать группу мешей, а потом всю эту группу - отправить на рендеринг. Этот способ имеет ряд технических преимуществ:
  3.1 Трансформировать каждый меш - можно в отдельном потоке - причём коэффициент ускорения практически равен количеству процессоров.
  3.2 Рендерить группы мешей можно с использованием инстансига.

В способе 3 есть проблема: потоки трансформирования мешей - могут проводить трансформацию во время ренеринга - потому что данные - общие. Так вот - для того чтобы данные не были общими можно:
1. Синхронизировать доступ к данным костей
2. Сделать копию (потоки трансформирования будут готовить новые данные, а рендер - рисовать старые, взятые из копии в очереди рендеринга).

П.С. Я только что понял - что в случае распараллеливания и инстансига - издержки на копирование будут минимальны (тем более если мешей будет много)... Но всё же сложность архитектуры неумолимо возрастает...

В общем - интересно Ваше мнение по поводу изложенного выше.. Есть ли альтернативы ?

#69
16:58, 2 янв 2010

Liberty Prime
Хм, тоже не врубаюсь в чем проблема. На рендер можно ведь посылать матрицы (кватернионы) трансформирования костей и меш в начальной позе, а в шейдере уже трансформировать.

#70
17:25, 2 янв 2010

Jet Hadron

А Intel Thread Blocks - удобная штука ? В общем - тоже думал писать свой планировщик задачь - но потом, передумал - ведь в винде свой есть ))) Его просто надо немного подтянуть чтобы таски быстрее крутил - и всё. )

#71
17:26, 2 янв 2010

К стати - а у Intel - есть что-то вроде STL только оптимизированного для многопоточного использования (ну типа vector, list... конетейнеры) ?

#72
17:28, 2 янв 2010

Liberty Prime
> А Intel Thread Blocks - удобная штука
Удобная. )  Посмотри демку Smoke с исходниками. Эпики использовали в последнем АнрилЭнжин.

#73
17:29, 2 янв 2010

Liberty Prime
> К стати - а у Intel - есть что-то вроде STL только оптимизированного для
> многопоточного использования (ну типа vector, list... конетейнеры)
Угу, они в TBB входят + scalable allocator'ы.

#74
17:48, 2 янв 2010

Jet Hadron

Да - эту демку - уже давно скачал ))) Надо бы глянуть.. )

Страницы: 1 2 3 4 5 6 7 Следующая »
ПроектыФорумСобираю команду

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