MrShoor
Именно что нет. Там лишь храниться цвет а потом мы делаем так texturVolumeColor = (N*textureVolumeColor + color) / (N+1). То есть хранится среднее по факту
IBets
> Там лишь храниться цвет а потом мы делаем так texturVolumeColor =
> (N*textureVolumeColor + color) / (N+1). То есть хранится среднее по факту
Хм, тогда даже не знаю. А если сделать RGBA8 текстуру?
А, тю, так у тебя же это float текстура. Это вполне может быть проблема округления. Ты сделал + color, но значение не поменялось из-за погрешности флоата.
MrShoor
Да вполне возможно мы складываем очень маленькое и очень большое. Соотвественно теряем. Как лечить такое?
MrShoor
Но почему это не проявлялось при стандартном флоате ведь GPU полноценными float-ами оперировать должен, то есть сначала он декодит из R11G10B10 => в float3 => производим наш рассчет=> записываем в float3 => GPU енкодит в R11G10B10. Разве нет? Или к примеру проблема из-за того что когда мы конвертим из f32 -> f16 при все большим количестве итераций мы теряем маленькую часть, а потом при делении на (N+1) у нас происходит потеря?
IBets
> записываем в float3 => GPU енкодит в R11G10B10. Разве нет?
Да, только после записи в R11G11D10 ты получаешь такие же значения, какие были там до твоего + color, ибо точности 11ти битного флоата не хватает.
IBets
> Соотвественно теряем. Как лечить такое?
Возьми целочисленный формат текстуры, у него будет константная абсолютная погрешность.
MrShoor
Благодарю работает.
Тема в архиве.