Symulator EU07 (i nie tylko) > Na warsztacie
Exe - konwersja na C++
tmj:
--- Cytat: Krzysiek626 w 30 Czerwca 2017, 07:46:49 ---Dodatkowy stres wprowadzają linijki:
--- Kod: ---Bad model: transformation matrix for sub-model "Fspot02" imposes geometry scaling (factor: 3.63)
Bad model: transformation matrix for sub-model "mocowanie2" imposes geometry scaling (factor: 0.93)
Bad model: transformation matrix for sub-model "mocowanie1" imposes geometry scaling (factor: 0.93)
Bad model: transformation matrix for sub-model "mocowanie2" imposes geometry scaling (factor: 0.90)
Bad model: transformation matrix for sub-model "mocowanie1" imposes geometry scaling (factor: 0.90)
Bad model: transformation matrix for sub-model "mocowanie2" imposes geometry scaling (factor: 0.90)
Bad model: transformation matrix for sub-model "mocowanie1" imposes geometry scaling (factor: 0.90)
--- Koniec kodu ---
--- Koniec cytatu ---
Te komunikaty wystepuja rowniez na "zwyklym" exe, jest to informacja ze dany model 3d ma w swoich transformacjach skalowanie elementow, ktore moze negatywnie wplynac na kalkulacje oswietlenia specular. W zalozeniu powinny wywolywac stress tylko u autorow modeli, zachecajac ich do wprowadzenia poprawek ;>
Natomiast "Bad geometry (shape estimation failed)" wystepujace w duzych ilosciach to juz roznica w zachowaniu, i raczej nie powinny wystepowac. Cos tam moze byc nie tak przy procedurze dzielenia krzywych na segmenty, lub pobocznych.
Milek7:
--- Cytat: tmj w 30 Czerwca 2017, 13:34:25 ---Te komunikaty wystepuja rowniez na "zwyklym" exe, jest to informacja ze dany model 3d ma w swoich transformacjach skalowanie elementow, ktore moze negatywnie wplynac na kalkulacje oswietlenia specular. W zalozeniu powinny wywolywac stress tylko u autorow modeli, zachecajac ich do wprowadzenia poprawek ;>
--- Koniec cytatu ---
Co jest chyba zbędnym ostrzeżeniem w shaderowym exe, bo normalne mnożą sie przez glm::mat3(glm::transpose(glm::inverse(modelview)))
Wywalę to przy następnym buildzie
tmj:
Mnozenie przez inverse nie pomoze niestety przy wszystkich przypadkach, bo czesc submodeli uzywa niejednolitego skalowania (inverse ma poprawny efekt tylko gdy wektor jest skalowany tak samo wzdluz wszystkich osi) Trzeba robic pelne normalize() a to niestety kosztuje :<
Milek7:
hmm, czyli ten opis jest błędny? http://www.lighthouse3d.com/tutorials/glsl-12-tutorial/the-normal-matrix/
To się robi tylko raz na submodel więc myślę że wydajność nie powinna być bardzo zła, ale później porównam.
Krzysiek626:
Tymczasem na windows 7 mam odwrotną sytuację. Exe C++NG 64bity uruchamia Bałtyk! Za to nie chce uruchomić Kaliskiej, całość się wczytuje do końca, ale niestety po kilku sekundach następuje wysyp. Tutaj mam niejaki sukces, bo w tym przypadku zapisuje się crashdump (w załączniku 2 takie pliki, do porównania czy przyczyna jest ta sama). Także w wersji 64 bitowej na Drawinowie mam niezidentyfikowaną kulę co pokazałem kilka postów wcześniej w załączniku.
Tak jak w przypadku x86 i tu nie musiałem instalować vc 2017, exe dało się uruchomić i przejechałem cały Bałtyk. Instalacja VC 2017 jednak przeprowadziłem, mimo to wysyp z kaliską. Zostało na x64 systemie, przetestować paczkę testowaną na x86. Chętnie poznam co ciekawego jest w załącznikach.
Nawigacja
[#] Następna strona
Idź do wersji pełnej