| охуенно девки пляшут |
[Nov. 22nd, 2022|04:43 pm] |
добавил импорт vxl из voxlap (это то же самое, что ace of spades, только с заголовком, и в два раза ширшее и длиннее, так что код тот же самый), и мрачно охуел по порядку.
во-первых, импортёр радостно маллокает кубик 512x512xn (а для вокслапа — 1024x1024xn), и распаковывает туда всё-всё. но хотя бы n вычисляет, охуеть оптимизация. зачем? да пошли вы нахуй, вот зачем! у нас же есть стуктуры данных и код, которые как раз предназначены для динамического построения воксельных моделек, поэтому мы не будем это всё использовать, а будем тупо сначала всё распаковывать, и потом точно тем же апи, что используется для построения на лету, строить из распакованого. отличная идея. естественно, переделал на распаковку по одной вертикальной линии.
не подозревая больше плохого (а зря!) схоронил такой импорт в родном формате, попробовал загрузить… и охуел совсем. то, выше — были цветочки. загрузка родного формата тормозит. нет, не так: АДОВО ПИЗДЕЦ КАК ТОРМОЗИТ. полез смотреть на МегаДизайн.
родной файл, в общем, записывается примерно так: сначала мы перебираем все-все кубики 16x16x16 (я их буду называть просто «кубики») и пишем, заодно присваивая им номера, тупо по порядку. потом мы пишем каждый слой (не картинки, а layer в терминах любого редактора), просто перечисляя координаты и индексы нужных кубиков. тащемта, нормально, ничего особо страшного.
а вот как мы читаем этот файл… вот это произведение искусства и виртузоное программирование во все поля. для начала мы читаем кубики, и суём их в хэш-табличку. ключ таблички — uid, который НЕ СОВПАДАЕТ с индексом. это важно, запомним это.
потом мы читаем слои, и чтобы найти кубик по индексу… кто сказал: «перебираем все элементы в хэше начиная с первого добавленого, пока не отсчитаем index из них, тупо юзая хэш как односвязный список»? кто это сказал — тот угадал. да, хэш тут нахуй не нужен, достаточно обычного массива.
но ладно, хуй с ним, это не самая прелестная прелесть. подтормаживает, конечно, но не так, чтобы это было видно глазами. а тормоза видно глазами. тут мы приходим ко второй чудесности, комплексной.
хотя мы знаем, что у нас всё состоит из кубиков, и что кубики уникальны (это гарантирует сохранялка), мы не можем просто создать внутреннюю стуктуру слоя, передав ей координаты кубиков и их данные, нет (это, если что, всё ещё можно было сделать через API, не трогая стуктуры за интимные части). мы будем блитать каждый кубик через апи блитанья распакованых данных произвольного размера.
«ну и ладно, — скажет много кто. — ну, памяти в два раза больше надо, чем можно было бы использовать. её всё равно жопой жуй, хуй с ним.» в принципе, Много Кто прав. но есть один маленький нюанс: универсальная блиталка после копирования вызывает функцию убирания пустых блоков. потому что они автоматически не собираются, и их таки надо собирать, чтобы они не тормозили рендер и всё остальное. а функция эта — тупоцикл по всем блокам модельки, и проверка всех 4096 вокселов каждого блока на предмет «а есть ли там непустой» (ну да, выходим на первом непустом вокселе; сильно легче от этого).
ура: каждый, сука, раз, когда мы блитаем ебучий кубик при загрузке — мы проверяем все добавленые до этого кубики на «непустой». и пока загрузятся тридцать-сорок тыщ кубиков, можно покурить.
короче, чем дальше — тем там всё хуёвей. из достоинств только то, что рендер уже написан; и то я уверен, что когда я в него посмотрю, то побегу просить котиков помочь мне сделать множественное рукалицо. |
|
|