C или ObjC для Raytracer в реальном времени на iOS?

Question

Я начинаю строить raytracer в реальном времени для iOS.Я новичок в этой трассировке лучей, все, что я до сих пор делал, это писал элементарный в ObjC.Мне кажется, что raytracer на основе C будет быстрее, чем написанный в ObjC, но ObjC будет намного проще, поскольку иерархии объектов очень удобны.Скорость очень важна, хотя, я хочу, чтобы она была в реальном времени, скажем, 30 кадров в секунду.

Как вы оцениваете, стоит ли ускорение C дополнительной сложности?Я могу предвидеть, что код C занимает намного больше времени и вызывает у меня головную боль с большим количеством ошибок (хотя я не новичок в C), но поначалу стремление к большей скорости изначально соблазнительно.raytracers написано на С?Мой поиск в Google по таким вещам загрязнен множеством результатов для C ++ и C #.

Answer 1

Если вам нужна быстрая трассировка лучей, вы можете забыть об использовании или C или Objective C. Вы почти наверняка захотите использовать OpenCL. Этого все еще не хватит, чтобы получить (даже очень близко) 30 кадров в секунду, но, вероятно, он будет как минимум вдвое быстрее, чем все, что работает на процессоре (и в 5-10 раз быстрее, не будет настоящим сюрпризом). ).

Answer 2

Посмотрите на http://ofps.oreilly.com/titles/9780596804824/, который настолько близок, насколько вы получите.

Это не трассировка лучей, я написал трассировщик лучей, и это огромный объем работы,GL использует другую технику для графики, поэтому он не сможет, например, отобразить способность алмаза захватывать свет.эта ссылка содержит пример кода, вы можете скачать и запустить его.Вы поймете, что даже некоторые из довольно сложных примеров действительно пыхтят на реальном устройстве ... мы говорим <1 кадр / с. </p>

Answer 3

Написание "Raytracer в реальном времени" без использования Hand-Optimized Assembly (или с использованием "дешевого" компилятора Intel;), но это невозможно для этой платформы), невозможно, потому что вам нужна скорость.

Более того, вам нужно много вычислительной мощности, но я думаю, что даже путь OpenCL недостаточно силен (на мой взгляд, это относится даже к реальным настольным компьютерам, причина этого - отсутствие * 1003).* очень большой кэш на графическом процессоре).

Answer 4

, как сказал zneak, c ++ - лучшая комбинация скорости и полиморфизма.

однако, вы можете сделать что-то близкое, уменьшив количество вызовов objc (читай: уменьшите полиморфный интерфейс до минимально необходимого набора, затем просто поместите части, которые должны быть быстрыми, в простой c или c ++).

Отправка сообщений objc довольно быстрая, и вы обычно можете удалить большую часть виртуальных / динамических методов из ваших интерфейсов (предположим, что каждый метод экземпляра objc является виртуальным). c-код в методах objc все еще c-код ... оттуда определите, где находятся ваши узкие места - это не помешает профилировать перед изменением рабочего кода;)