następny »

[HAV]

Pytanie natury technicznej - czy R3 ma jakiś limit wielkości wyświetlanych blueprintów?

Mam blueprinta high res (~9000x6300 px) pozwalającego na duże zoom'y bez efektu pikselozy, ale Rhino już taki wyrozumiały nie jest... Wprawdzie blueprinta ładuje bez zająknięcia, ale przy nawet niewielkim zoom'ie robi się już pikseloza i wszystkie szczegóły szlag trafia :/

Stąd pytanie jak wyżej - czy jest jakiś limit, do którego blueprinty wyglądają tak jak powinny, ewentualnie - czy R3 ma jakąś opcję pozwalająca na właściwe wyświetlanie blueprintów?

[Odyniec]

Hmmm...

1. Zależy jakich komend używasz do umieszczania blueprintów

Jeśli poprzez View -> Backround Bitmap -> Place to ja nie zauważyłem większych różnic od sytuacji, gdy wrzucam np. bitmapy (Rhino 3, czy 4 nie ma tu znaczenia) 6000x4500 do programu edycji grafiki. Jeśli jest za duża pikseloza przy powiększeniu to można zawsze użyć polecenia Filter, które jest częścią komendy Bitmap place.

Obrazek 6000x4500 wrzucony do Rhino



Zbliżenie - pikseloza (ale to normalne przy takim zbliżeniu !)



Użycie filtra - jest lepiej



Ta sama bitmapa w programie do obróbki grafiki



2. (Rhino 3, 4) Jeśli blueprinty wrzucamy sposobem znanym z aplikacji typowo 3d (np. 3ds max), czyli teksturujesz prostą powierzchnię kwadratową albo prostokątną - to w zależności od firmy, sterowników, wersji OpenGl i Direct X, wersji Pixel Shadera - słabsze karty wyświetlają obrazki max 2048x2048,  nowsze max 4096x4096, a te nowe, obsługujące DirectX 10 i profesjonalne typu Nvidia Quadro, czy Fire GL 8192x8192.
Z tego co wiem niestety drivera DirectX 10 pod Rhino jeszcze nie ma (jest DX9).

W Rhino 4 jest dokładna informacja o karcie i o tym, co będzie potrafić, (niestety nie pamiętam już czy podobnie jest w Rhino 3, a tu nie mam zainstalowanego) np:



Blueprint jako tekstura na zwykłej powierzchni:



I limity te to nie jest sprawa tylko Rhino, ale dokładnie tak samo skalować duże obrazki będzie np. 3ds max.

[HAV]

Nic już z tego nie rozumiem...

Jeśli załaduję Rhino zdjęcie high res jako blueprinta wyświetla się tak jak powinien - pikseloza robi się dopiero przy dużych zbliżeniach - i tak wiem Odyniec, że to jest normalne ;-)
Co innego gdy załaduję blueprinta z rzutami...

blueprint w R3:


ten sam blueprint w zbliżeniu w standardowej przeglądarce zdjęć windows'a:



Sprawdziłem przed chwilą inne blueprinty domyślnie zapisane jako .jpg i nie ma z nimi żadnego problemu.

Więc w czym problem? Próbowałem już różnych rozszerzeń, ustawień etc. - bez rezultatu. Blueprint był łączony w photoshopie z kilku blueprintów .tif - może to jest przyczyną, bo jeśli załadować pierwotny plik .tif do R3 robi się taka sama pikseloza, mimo że w przeglądarkach graficznych zoom działa bez problemów (pikseloza widoczna przy zoomie 200-300%).


Jakby ktoś mógł na to zerknąć i sprawdzić co jest nie tak z tym blueprintem

[Odyniec]

Sprawdzę jeszcze w domu (na lepszej karcie graficznej), ale sprawa wygląda bardzo ciekawie.

W Rhino 3:



W Rhino 4 wygląda to tak:

[HAV]

Przy okazji bo zapomniałem wcześniej dopisać - w R3 wygląda na to, że nie ma filtra do Backround Bitmap; przynajmniej ja go tam nigdzie w opcjach nie widzę

[Odyniec]

Tak, niestety nie ma  w Rhino 3. Wszystko przez to, że ja już Rhino 3 dawno nie widziałem i wielu rzeczy już w nim nie pamiętam, dziś specjalnie zainstalowałem triala z powodu sprawy tej bitmapy.
Co do oficjalnego stanowiska McNeela - to jest ono tutaj, ale wszelkie próby spełnienia tych wymagań nic nie dają, Rhino 3 i tak rozmywa duże blueprinty. Dziś jeszcze powalczę (:-)

[Odyniec]

Tak jak pisałem, w przypadku Rhino 4 miałem rację - to jest kwestia karty graficznej i jej możliwości . Jak widać na obrazku - ta karta potrafi sporo, pełna obsługa OpenGL 2.0.3, a nie 1.3, 4096x4096 max tekstury.
Rhino 4 w pełni obsługuje OpenGL 2, więc poszło jak po maśle.
W Rhino 4 - w zasadzie jest full - no może minimalnie gorzej, ale to minimalnie

Rhino 3 - nie obsługuje zaawansowanych sposobów wyświetlania i nie potrafi skorzystać w pełni z możliwości współczesnych kart graficznych 

[Odyniec]

Oczywiście zapomniałem dodać, że w przypadku tej bitmapy  , w innych może być zupełnie różnie.

[HAV]

Problem w tym marku, że to raczej wina tego konkretnego blueprinta, tyle że pojęcia nie mam co mu dolega. Przerobiłem go na krotność 2, przeskalowałem do 4096x4096, zmieniałem też rozdzielczość px/cal - efektów nie widać żadnych.
Co do Twojej rady odnośnie skanowania - wprawdzie refkami w postaci drukowanej nie dysponuję, ale zawsze można wydrukować te co są i zeskanować jeszcze raz - tyle, że to jest tylko ominięcie problemu ;-) Choć chyba nic innego mi nie zostanie :/

Podejrzewam, że problem tkwi u źródła, czyli blueprintów .tiff - tu jeden na pokaz
A tu inny blueprint w .jpg, z którym problem z pikselozą nie jest tak uciążliwy i pozwala na znacznie większe zoomy, mimo iż ma mniejszą rozdzielczość px/cal =>


Odyniec - trochę się to kupy nie trzyma, bo wychodzi na to, że R3 jedne blueprinty potrafi wyświetlić w miarę poprawnie, a z innymi zupełnie sobie nie radzi - przykład w/w blueprint w .jpg - rewelacji wprawdzie nie ma, ale jest znacznie lepiej.
Jedno co mogę śmiało wykluczyć to niewydolność mojego hardwaru...

[Odyniec]

HAVOC - ja już się domyśliłem, że ty na 486 i na Riva 128 nie pracujesz 
Sprawdź proszę na swoim sprzęcie - jak to wygląda u Ciebie na Rhino 4 w wersji próbnej, podeślij też screeny.
Przypominam, że Rhino 3 i 4 pracują całkowicie niezależnie i mogą być naraz zainstalowane i mogą nawet naraz pracować!

Problem tej konkretnej bitmapy pod rhino 3 jest wątpliwy, ale możliwy, np ten png, który udostępniłeś na z-hare, za nic nie chciał wczytać się do rhino - unsupported file type. Dopiero jak go otworzyłem i zapisałem (też jako png w darmowym) IrfanView - zadziałało.

Mniejsza rozdzielczość obrazka - zawsze będzie oznaczać mniejsze rozmycie w rhino 3. Im większa rozdzielczość, tym rozmycie większe.

A jednak coś jest na rzeczy z tym Rhino 3 - bo nawet na tym pliku 54 - różnice widać i to sporą...

[Odyniec]

Hehe, no robi się coraz ciekawiej....

Oto tiff ten co dałeś....

Rhino 4 - zero błędów i jakość - żyletka - zero rozmycia - dokładnie kopia 1:1

[HAV]

Problem tej konkretnej bitmapy pod rhino 3 jest wątpliwy, ale możliwy, np ten png, który udostępniłeś na z-hare, za nic nie chciał wczytać się do rhino - unsupported file type. Dopiero jak go otworzyłem i zapisałem (też jako png w darmowym) IrfanView - zadziałało.

A to dziwne - u mnie R3 wczytuje ją bez zająknięcia (czyt. nie zgłasza error'ów) - oczywiście mowa o tej z z-share'a.

Co do R4 - zassam i potestuję.
 
Na chwilę obecną wychodzi na to, że R3 nie radzi sobie z plikami .tif i ich pochodnymi, nawet z innym rozszerzeniem - przynajmniej nic innego nie przychodzi mi na myśl

[Odyniec]

Na to chyba wygląda, ale dzięki Havoc, bo odkryłeś bardzo ważny problem się okazuje w Rhino 3, ale zawsze możesz tego tiffa zapisać jako Targę (TGA)

[HAV]

Przy okazji - takie same kwiatki wychodzą, jeśli zapisać ten domyślny .tif z innym rozszerzeniem obsługiwanym przez R3

[Odyniec]

Z moich testów wynika, że Targa (TGA) w Rhino 3 czuje się jak ryba w wodzie, łyka wszystkie TGA Rhino 3.