Все это, разумеется, должно было работать стабильно. Однако, учитывая что для движка были запланированы такие библиотеки рендеринга как Direct3D 6, 7, 8, и даже Software, хотя основными должны были стать Direct3D 10 и 9, а в дальнейшем мог прибавиться мифический тогда Direct3D 11, то проблемой становилась разработка игр под данный движок. И не только для разработчика - даже у более-менее технически продвинутого обывателя в голове не укладывалось, как это так может быть столько разных рендереров у одного движка, и под каждым игра должна выглядеть не хуже чем под другими.

На самом деле, говоря о мультирендере, стоит вспомнить, что одни рендеры не поддерживали, скажем, разрешение текстур больше 256х256 пикселов, а о предельно возможной детализации полигональных моделей говорить и вовсе не приходится. Так, Direct3D 8 не смог бы отрисовать модель с наложенной на нее текстуру имеющую разрешение выше 1024х1024, таковы были технические ограничения данного графического API. Текстуру большего размера он автоматически ужал бы и только тогда она попала бы в видеопамять.

Рендер-библиотеки с Direct3D меньших версий или вообще Software явно имели проблемы с поддержкой шейдеров, коих там попросту не было. Да и размеры текстур и максимальное количество вершин на модель там были еще меньше. Из всего этого следовало выкручиваться, да так чтобы и там и там игра, разработанная на движке смотрелась, по крайней мере, достойно.

Тогда пришла такая идея - не использовать один и тот же игровой контент для всех рендереров, а разработать под каждый рендер свою сборку контента, и при смене библиотеки просто подгружать все ресурсы игры заново. Но тут могла возникнуть проблема иного толка - общий объем разработанной на PE игры должен был неплохо так разрастись ради поддержки различных графических API. Ради уменьшения объема игры на жестком диске и увеличения ее производительности придумывались многочисленные фейки - как автоматическая сборка текстур из отдельных элементов, так и множество других. Была и такая идея - заменять далеко расположенный от игрока элемент окружения, либо персонаж спрайт. Выглядеть такой персонаж или элемент окружения должен был подобно монстру из первого Doom - плоским и не особенно интересным.

Особенно полезными все эти техники оптимизации должны были быть в самом масштабном проекте IS - Расколе. Там предполагалось создать исполинские локации, представляющие собой города, леса, различную местность. Поначалу предполагалось, что все эти локации будут одним целым миром, но впоследствии от этой идеи решено было отказаться в пользу технологий потоковой подгрузки контента для создания иллюзии нескончаемого мира. Кроме того, Раскол должен был стать игрой с поддержкой технологии Realtime RayTracing, честно считающей освещение в игре в реальном времени.

Со временем, а именно - после прогона нескольких внутренних демок движка, впрочем, стало понятно, что данная игра не сможет работать с включенной технологией освещения RT на заявленном качестве (Direct3D 10 со включенной тесселяцией и прочими плюшками), а кроме того сказались определенные изменения в сюжетной линии игры, потребовавшие кардинально переделать весь созданный к тому моменту контент игры.