Wpis z mikrobloga

@ewolucja_myszowatych: Z punktu widzenia performance'u, to zrobiona w shaderze na sztywno zamiana texCoords.uv na texCoords.vu powinna mieć impact równy lub bliski 0. Jedynie jakaś lokalność mogłaby tu ewentualnie mieć wpływ, ale jeśli wszystkie atrybuty vertexa leżą obok siebie to nie sądzę aby to miało znaczenie. Natomiast musisz się zastanowić, czy z punktu widzenia logiki działania całej gry nie byłoby lepiej wpychać do pamięci już wcześniej zamienionych współrzędnych.
@RadzieckiKonstruktor: @selenita66: często potrzebuję na szybko poodbijać teksturę np. na podłodze/budynku żeby kafle szły raz tak a raz inaczej. I fajnie byłoby mieć skrypt który to poodwraca i poskaluje zamiast robić to w modelu, model miałby tylko podstawowe UV np. na całą podłogę a skrypt miałby suwaki do różnych wariantów tilingu

wydawało mi się że jakby edytor zrobił to raz na starcie to shader potem nic nie robi w runtime
@ewolucja_myszowatych: Shader i tak "coś robi", bo jakoś użyć tych UV musi. A czy zrobi to w takiej kolejności, czy w odwrotnej, to ma małe znaczenie. Bardziej bym się martwił czy pisanie shadera pod jedno, konkretne użycie na jednym obiekcie ma sens. Bo podmiana shaderów pomiędzy obiektami ma już realny koszt performance'owy.
@selenita66: nie, widziałbym to tak: jest jeden shader dla wszystkich podłóg ale zmienna jest np. tekstura kafla i sposób tilingu. I jest gdzieś w scenie skrypt który zmienia wartości wektorów w tym shaderze, ale robi to raz na starcie i potem shader wałkuje to już zmienione cały czas.

Druga opcja to shader bez modyfikacji UV, UV byłoby przerobione skryptem c# przez nadanie nowych koordynat wszystkim wierzchołkom na starcie - i shader