Результаты поиска

Плохо понимаешь. Я проблемы не вижу. Тяжело отлаживать в уме особенно, когда не знаешь, чего ты ожидаешь и что рендерится на самом деле. Я бы на твоем месте сделал бы с нуля и поэтапно. Во-первых, после каждого этапа проверял бы, что ничего не сломалось (все, что после этапа должно рендерится...

Какой кусок все портит?

Только тут исправил? А в других местах что?

1. Да. 2. Ивент майнкравта тут не причем. Но раз уж заговорил, то в идеале весь постпроцессинг должен быть между RenderWorldLastEvent и рендером hud и gui. Для того, чтобы все моды успели отрендерить мир, но на hud ничего не влияло. А ещё лучше сделать себе postprocessing pass между...

Ты матрицу проекции испортил потому что. Сделал её единичной, а обратно не вернул. Push-pop всегда делаешь только для modelview. Еще я не очень понимаю, зачем ты там делаешь всякие drawSun в мировом пространстве. God rays же screen space техника.

Если рендерить в ванильный фбо, проблемы нет? Показывай код. Как и что рендеришь, и всю работу с фбо. И ещё несколько скринов хотелось бы. По одной лишь матрице проекции позицию солнца не узнать. Оптифайн задаёт юниформу sunAngle (точное название не помню) для этого.

Нет. Нужен TypeAdapter.

Этот вершинный формат без нормалей. Вот у тебя их и нету в результате. А если не работало с POSITION_TEX_NORMAL, то возможно, в "запечёной" модели нет нормалей.

Эх.. А мог бы написать что-то вроде и все. Type type = new TypeToken<HashMap<String, Case>>() {}.getType(); HashMap<String, Case> map = gson.fromJson(json, type);

Хз, не нужен был ванильный парсер. Раз уж очень хочется его поддерживать, то можно внутри TypeAdapter использовать ванильный алгоритм. Т.е. просто обертка алгоритма. А можно просто сделать три TypeAdapter и ни о чем не думать.

Потому что он говняный. Критерии говняности уже не помню, но точно помню, что выход мне не нравился. Потому что это просто и удобно. И подозреваю, что у тебя при создании происходит ненужный парсинг строки в нбт, поиск айтема по строке и т.п..

Gson не сможет распарсить нбт в приемлемый вид. Нужно писать свой TypeAdapter (кмк, он проще, чем сериализатор/десериализатор). А заодно для Item и ItemStack, так как там есть поля, которые не нужно сериализовать. А вот с CaseDrop gson прекрасно справится сам.

Разве там сделано не на коллизии? (я не видел кода)

А с чего вы вообще взяли, что через тайл решить эту задачу - лучше? Что насчёт сложности алгоритмов в обоих случаях? Об этом нужно думать изначально, а не после того, как все реализовано.

Я уже плохо помню, но мне кажется, что в 1.12 сущности рендерятся только в видимых чанках. И получается так, что маунт уже перенесен в чанк, который не проходит frustum culling.

Ключ размером в один байт.. Такое себе.

Цитата с другого форума, но почему-то вспомнилась..

Надо было ставить котлин

Смотря для какого. Для школьника-студента очень даже неплохая подработка. Поэтому он не обязан фанатеть или вообще быть заинтересованным в проекте. Просто выполнил работу, получил 5 копеек, и счастлив. Плюс, получил опыт. Ну а когда есть основная работа, то тут да, встаёт вопрос: хочешь ли ты...

Для начала проверь, рендерится ли любая другая текстура вместо ClientProxy.renderedTextureId. Пoдставь handle как-нибудь майновской или своей текстуры (но не из фбо)