Потому что это потенциальное прерывание и уход в ядро на неизвестно сколько миллисекунд. Высвобождение памяти тоже может быть очень не бесплатным.
Если и предрассчитывать таблицы, то где-то заранее и (квази-)статичного размера. При этом надо иметь в виду размер кэшей, промах по которым может нарушать «Доступ к переменной дешевле чем вычисление».
Не на гпу такие штуки делать просто бессмысленно. Это дороже-дольше и в прототипировании, и в исполнении.
Современные гпушечи трассируют лучи через синтезируемого в реальном же времени Вороного в 3D на пофиг, если говорить про производительность.
Крутяк!
Однако, отмечу, что то, что вы называете шумом Перлина, таковым не является. На самом деле у вас фрактальный value noise, а оригинальный шум Перлина несколько сложнее.
Кроме того, у вас довольно странные места в коде, много их.
Например, вот это
delete[] interpolateTable;
interpolateTable = new float[f];
значительно и непредсказуемо дороже, чем просто при надобности делать
Пытался пользоваться этой штукой года три-четыре, а потом еще раз ~два, назад, и она была так себе стабильна — при сильной нагрузке можно было схлопотать странное. Уж не знаю, правда, почему — не доходили руки разбираться.
Из интересных вариантов расположения свопа есть еще видеопамять.
Окей, я правда не разбираюсь, на какие подсистемы и с какими легальными закавыками там всё рассыпается в точности, поэтому я больше не буду пытаться выглядеть умным и попробую проще сформулировать то, что хочу узнать:
Будет ли под вашу плату доступен «официальный» дистрибутив линукса, установив который можно просто начинать писать на OpenGL ES 2.0 и бед не знать?
Будет ли набор доступных OpenGL-расширений сопоставим, например, с доступным на iPhone 4 с iOS 6 (там из той же серии ядро видео, насколько я знаю)? В частности интересует GL_OES_texture_float.
Насколько я знаю, как правило, в embedded нельзя просто взять и скачать OpenGL-драйвера. И если сам чип можно купить в каждом втором ларьке/подвале, то документацию, SDK и драйвера (если они вообще есть под нужную ось) для него нужно покупать за отдельные большие (>1e4$, а то и 1e5-1e6) деньги, попутно подписывая толстые неприятные NDK, запрещающие, среди всего прочего, передавать это дальше — например, конечным покупателям самой борды.
Легально победить это и довести систему до состояния «накатил debian на sd-карту и полетел в неизведанные дали растеризации треугольников» удалось только двум известным мне проектам: OpenMoko и Raspberry Pi. Может, есть ещё кто, но мне о них неизвестно.
Я сейчас быстрым гуглежом обнаружил, что PoverVR-таки раздаёт SDK для Linux и бесплатно, но в этом пакете я не нашел поддержки (а) выбранного вами чипа, (б) WindowsCE.
Да, мои знания здесь очень поверхностны, поэтому буду очень рад специалистам, способным поправить/дополнить вышесказанное, расширив нам тут всем в этом чяте кругозор.
Разодрать PNG/ARGB на PNG/RGB + PNG/A можно с помощью imagemagick, bash и получаса времени. Для PVR и прочих вариантов компрессии тоже есть консольные утилиты, тривиально встраиваемые в скрипты сборки ассетов.
Проблемы с двумя текстурами в шейдерах я тоже не вижу — два раза написать sampler2D и texture2D вместо одного. Ну, и переставлять две (четыре, восемьдесят три) текстуры в материале должно быть не принципиально сложнее, чем одну. По крайней мере в голом OpenGL, не знаю, как там с этим в юнити.
Не находил ответ на этот вопрос нигде, поэтому задам сам: с чем связано решение выпуститься под Android, а не под iOS (или по крайней мере в таком порядке)? Популярность платформы, отсутствие серьёзных конкурентов (в плане графики, например), заказ от гугла/производителя железа :D, или что-либо ещё?
Как разработчик под обе нахожу это решение болезненным с точки зрения процесса и времени разработки — iOS куда более дружелюбна к разработчку (графики), и тот же OpenGL на ней себя ведёт куда более предсказуемо, по крайней мере из моего опыта.
Не понимаю, почему результат будет зависеть от видеокарты. Он может быть не bit-perfect (с точностью до того, как производители-драйвера оптимизируют свой fp-ливер), но должен быть в итоге визуально идентичным, если делать всё по стандартам.
Кроме того, свое ускоренное node-based решение можно сделать на коленке за неделю, I can tell from making quite a few node-based shader-processors in my time. С учетом того, что вы лапочки, я вас обожаю, и у вас в движке есть скриптуемое всё и UI, это может быть и того быстрее.
С sin вообще забавно получается — если не выпендриваться, gcc на место sin (когда я в последний раз смотрел году в 2009) вместо того, чтобы православно заинлайнить fsin, генерирует вызов в libm, который там у себя внутри считает синус самостоятельно (емнип, оно даже в этот самый fsin не упирается в итоге, но не буду утверждать).
Если и предрассчитывать таблицы, то где-то заранее и (квази-)статичного размера. При этом надо иметь в виду размер кэшей, промах по которым может нарушать «Доступ к переменной дешевле чем вычисление».
Современные гпушечи трассируют лучи через синтезируемого в реальном же времени Вороного в 3D на пофиг, если говорить про производительность.
Разное получается, если выпендриваться.
Однако, отмечу, что то, что вы называете шумом Перлина, таковым не является. На самом деле у вас фрактальный value noise, а оригинальный шум Перлина несколько сложнее.
Кроме того, у вас довольно странные места в коде, много их.
Например, вот это
значительно и непредсказуемо дороже, чем просто при надобности делать
Из интересных вариантов расположения свопа есть еще видеопамять.
Легально победить это и довести систему до состояния «накатил debian на sd-карту и полетел в неизведанные дали растеризации треугольников» удалось только двум известным мне проектам: OpenMoko и Raspberry Pi. Может, есть ещё кто, но мне о них неизвестно.
Я сейчас быстрым гуглежом обнаружил, что PoverVR-таки раздаёт SDK для Linux и бесплатно, но в этом пакете я не нашел поддержки (а) выбранного вами чипа, (б) WindowsCE.
Да, мои знания здесь очень поверхностны, поэтому буду очень рад специалистам, способным поправить/дополнить вышесказанное, расширив нам тут всем в этом чяте кругозор.
Проблемы с двумя текстурами в шейдерах я тоже не вижу — два раза написать sampler2D и texture2D вместо одного. Ну, и переставлять две (четыре, восемьдесят три) текстуры в материале должно быть не принципиально сложнее, чем одну. По крайней мере в голом OpenGL, не знаю, как там с этим в юнити.
Как разработчик под обе нахожу это решение болезненным с точки зрения процесса и времени разработки — iOS куда более дружелюбна к разработчку (графики), и тот же OpenGL на ней себя ведёт куда более предсказуемо, по крайней мере из моего опыта.
Кроме того, свое ускоренное node-based решение можно сделать на коленке за неделю, I can tell from making quite a few node-based shader-processors in my time. С учетом того, что вы лапочки, я вас обожаю, и у вас в движке есть скриптуемое всё и UI, это может быть и того быстрее.