Tylko, że na td nie raz generowałem twoimi exekami i było ok. Spróbuję wygenerowac raz jeszcze ale tym razem na podstawie inców. Może lights we wpisie ma jakieś znaczenie. Wszystkie fx zostawiłem w tga by im jakości nie rżnąć.
---
Jednak na paczce repowskiej, wczytywane z t3d, jest taki sam efekt. Czyli to nie moja wina. Teraz dlaczego?
---
Ogarnięte. Problem jest z przezroczystą płaszczyzną, robiącą za opcjonalne flary w modelu. Wszyscy wiemy jak działają dwie półprzezroczystości przesłaniające się przy złym sortowaniu. Będę potrzebował toola do naprawy t3d. Śmietnik w pliku jednak to znacznie komplikuje.
Semafor ma strukturę:
głowica
|
|-flara
|
|-soczewka
|-freespot
Trzeba zmienić na:
głowica
|
|-soczewka
|
|-freespot
Flara ma niezerowego transforma, więc program w pierwszej kolejności musi wymnożyć transform obiektu soczewka przez transform obiektu flara. Potem zmienić parenta soczewki na głowicę. Usunąć obiekt flara. Posortować obiekty zgodnie z hierarchią, by freespot nie wylądował nad soczewką, swoim nowym rodzicem.
Nie jestem pewien co z freespotem, bo przez zbieżność nazw ma on nieokreśloną hierarchię. Nie wiem czy wymaga mnożenia transforma czy nie.
Flara to obiekty o nazwach light_onXX o mapowaniu sem/[kolor]. Soczewka to obiekt o takiej samej nazwie o mapowaniu sem/#pkplight_lenses. Freespot to obiekt o takiej samej nazwie typu freespotlight.
W załączniku przykładowy semafor A z TD w wersji oryginalnej i poprawiony jednak bez wymnożenia transformów (potem zauważyłem, wiec tylko po Y przesunąłem, ale widać, że zgubił Z). Dodatkowo zmieniłem nazwy freespotów by każdy obiekt miał unikalną. Nie wiem czy ma to znaczenie, ale zwiększa czytelność pliku.
