Хорошо тогда

Всё грузится) И работает в VR) Просто оптимизировал парсер и кастомные шейдеры) Суть в том, что модель грузится за 8 минут, что как бы адекватно)

Быстрее, чем даже редактор, да ещё и асинхронно и многопоточно) Красота) Ну и собственно через итератор выше. Вообще в шарпе очень много прикольных заготовленных итераторов)

Думаю можно свести до 4-5 минут, но это надо пару недель с парсером копаться, чтобы как раз-таки загрузить модель вообще без единой лишней аллокации)

Там как раз читать байты, то так как obj - это у нас строковый формат, а не байтовый, то основной гемор - это восстановление чисел без аллокаций. Так как нужно высчитывать флот значения

Но в целом это тоже делается за линию в один проход алгоритмически. Просто вот это уже дрочево)

Нужен условный буффер длинной в число значимых символов или точности и при движении каретки, натыкаясь на команду - запоминать её, натыкаясь на пробел обнулять буферы и т.п. Плюс запоминать положение точки. И по сути дальше в цикле по буфферу восстанавливать число, где будет формула типа buf[i] * pow(10, k), где k равно будет положению точки в числе минус индекс массива. И вот по сути полный парсер, через некоторый конечный автомат без лишних аллокаций (ну только буффер по размеру значимых символов в числе)

Но со строками тоже нормально работает)

Чем тебе не нравится float.parse?

строку тебе в него подать надо

Для этого её надо аллоцировать

Убедил

Хотя

Просто с чтением файла через стрим байт без аллокаций особо (чисто через пару буфферов) нужно долго думать) Поэтому нафиг)

Ну смотри) Стандартный парсер допустим csv) readline (аллокация большой строки) + split - аллокации кучи мелких строк)

И вот ты читая файл в 1 гб срёшь в память на все бабки (точнее на всю оперативку)

Чекни ReadOnlySpan

Так, ты попробуй через стэк делать

Ну это тот же буффер только на стеке. Float.parse ты по нему по идее не сделаешь)

Ну, есть ReadOnlySpan