Język Python w 3ds Max

[adek]

Najwidoczniej dla programistów ze studia Blur język skryptowy MaxScript był niewystarczający do wykonania pewnych projektów. Zespół Blur-dev stworzył bibliotekę, która integruje 3ds Max z Pythonem oraz frameworkiem PyQt. Bilbiotekę oczywiście możecie pobrać za darmo.

 

Projekt Py3dsMax: code.google.com/p/blur-dev/wiki/Py3dsMax

[SYmek]

Znów ktoś inny wykonał robotę za Autodesk. Brawo Blur.

[Skoti]

@chyziryzisusipiesi: Python nie jest taki znowu fajny - niezbyt przyjemnie się pisze, sprzyja robieniu błędów i jest powolny... ale ma zalety jak to, że może skorzystać z zewnętrznych bibliotek (i rozszerzać praktycznie nieograniczenie swoje możliwości) i tak tu skrypty będą tworzyć okienka w QT, jak ktoś będzie chciał to może robić obliczenia na GPU to użyje PyCUDA/PyOpenCL...

Co do "konsolidacji" to sama nauka nowego języka skryptowego można liczyć w godzinach, a największym problemem jest poznanie API (a tu wszędzie jest inaczej) w danym programie, więc ten czy inny język nie robi wielkiej różnicy.

[SYmek]

@chyziryzisusipiesi: Python nie jest taki znowu fajny - niezbyt przyjemnie się pisze, sprzyja robieniu błędów i jest powolny...

 

Hmm, w czym przyjemniej się pisze?

[the_fgdf]

Odpowiedź jest jedna MELu ;)

[Skoti]

Hmm, w czym przyjemniej się pisze?

Szczerze to w prawie każdym ;p - ja zamieniłem pythona ze swojego silnika na AngelCode.

 

 

Kwestia przyjemności z pisania jest bardzo względna. Ja mam dobry edytor, więc mi się w każdym języku przyjemnie pisze. :)

 

API jest najważniejsze, to nie ulega wątpliwości. Ale nie zgodzę się z Tobą co do czasu nauki. Samą składnię faktycznie można przyswoić i w godzinę, i w takim czasie napisać jakiś tam skrypt, na potrzeby doraźne. Ale żeby korzystać na poziomie z dobrodziejstwa danego języka, to już trzeba się wgryźć głębiej. A jeśli np. piszesz pluginy, albo skrypty dla kilku różnych softów, to już nie jest tak wesoło. Albo jeśli łączysz narzędzia ze sobą. Ja więc osobiście wolę, aby była jakaś "baza", jeden wystarczająco elastyczny język, a za taki, wedle mojej wiedzy, uchodzi Python.

Kwestia przyjemności nie jest w tym wypadku względna (jeśli pominiemy masochistów) - jest to język bez kontroli typów, więc jeśli przypiszesz przypadkiem do zmiennej inną wartość niż powinieneś, żadnego błędu Ci nie wyświetli i szukaj później godzinami błahego błędu... to samo z blokami danych - zrobisz spację za mało/za dużo i skrypt zupełnie inaczej działa, ale dla interpretera wszystko jest ok więc Ci nie pokaże błędu.... takich wad pythona jest bardzo wiele które skutecznie przeszkadzają pisać coś większego w nim, bez rozstroju nerwowego.

 

Samej składni nowego języka jeśli znasz inny to żaden problem - znając język C znasz praktycznie cały python czy inne języki - różnice są naprawdę niewielkie. Nie musisz się wgryzać za głęboko bo rozpoczynając naukę znasz go już bardzo dobrze - a jest tylko kilka małych różnic o których przeczytasz w kilka pierwszych godzin i już cała nauka.

Dlaczego nie jest wesoło? Dla programistów to tak naprawdę żadna różnica - ba programiści wolą się nauczyć nowego języka niż mieć język który tworzy problemy.

 

BTW Jeśli firma chce sprzedać swój produkt to nie pisze skryptów, bo one mają otwarty kod źródłowy (taka natura skryptów), co nie jest pożądane i pisze się pluginy w C/C++. Języki skryptowe w programach graficznych nie są dla programistów i firm tworzących pluginy do softu, tylko dla grafików, żeby była prosta składnia i można było łatwo, szybko zautomatyzować niektóre rzeczy - do większych rzeczy się nie nadają - dlatego wybiera się pythona, bo grafik może znać już ten język, a olewa się problemy przy szukaniu później błędów w dużym kodzie... bo duży kod z założenia ma nie powstać.

[SYmek]

Szczerze to w prawie każdym ;p - ja zamieniłem pythona ze swojego silnika na AngelCode.

 

Należysz to tego specjalnego typu ludzi, którzy silne strony Pythona uważają za słabości. Można też tak, ale z opinii, która jawnie przeczy doświadczeniu milionów, nie zrobisz wiarygodnego stanowiska. Ot, po prostu dziwactwo, choć trzeba przyznać, że pojawiając się od czasu do czasu na forach.

 

Wszystko o czym piszesz to specyfika większości języków dynamicznych, które albo komuś podchodzą albo nie i nie bardzo jest o czym rozmawiać. To że słabe typowanie zachęca do błędów jest obiegową opinią ludzi wychowanych na na językach statycznych. Opinią równie znaczącą jak to, że wcięcia są trudniejsze do opanowania od nawiasów... Zresztą, w tej kategorii wskaźniki biją wszelką konkurencję i jakoś nikt się tym nie przejmuje.

 

Oczywiście, siłą Pythona jest jego prostota, ale nie dlatego zyskał pozycję w branży. Zyskał, bo dzięki cechom, które Ty uważasz za wady, stał się językiem bardzo popularnym, co w konsekwencji doprowadziło do powstania masy modułów, na czym z kolei zależy ludziom decydującym się na Pythona jako język skryptowy w ich aplikacji. Bo z definicji ma działać jako klej do łączenia jej z innymi technologiami.

 

Python ma oczywiście swoje wady, jest wolny, ciężki, i ma problemy z wątkami. Luę znacznie łatwiej jest osadzić w aplikacji. Najwyraźniej jednak zalety (te, które uważasz za wady), przesądzają sprawę. Ja się ciszę, choć przyznam, że ustawicznie kombinuję jakby tu podrasować Pythona ironem, albo ctypem ;)

 

pozdr.,

skk.

[lejacypies]

Ja tam wiem że Python to mapa w SC :):P

[Skoti]

Należysz to tego specjalnego typu ludzi, którzy silne strony Pythona uważają za słabości. Można też tak, ale z opinii, która jawnie przeczy doświadczeniu milionów, nie zrobisz wiarygodnego stanowiska. Ot, po prostu dziwactwo, choć trzeba przyznać, że pojawiając się od czasu do czasu na forach.

Nie należę do żadnego specjalnego typu ludzi - chyba, że tak nazywasz wszystkich niepoczątkujących programistów. Pythona praktycznie nikt z osób doświadczonych nie lubi (lubią w nim pracować początkujący, zanim przekonają się, że jego zalety na początku przeradzają się w olbrzymie wady przy czymś większym niż paręnaście linijek),

 

Wszystko o czym piszesz to specyfika większości języków dynamicznych, które albo komuś podchodzą albo nie i nie bardzo jest o czym rozmawiać. To że słabe typowanie zachęca do błędów jest obiegową opinią ludzi wychowanych na na językach statycznych.

Dynamiczne typowanie jest w wielu językach dynamicznych, ale zdecydowanie nie w większości, wcięcia znakami białymi jest charakterystyczny tylko dla pythona. To, że dynamiczne typowanie powoduje błędy jest opinią osób wychowanych na językach o ścisłym typowaniu, bo są to przeważnie doświadczeni programiści również z językami z dynamicznym typowaniem, ale nie tylko - to po prostu fakt, a co najwyżej początkujący jeszcze się na własnej się nie przekonał dlaczego doświadczeni nie lubią dynamicznego typowania.

 

Opinią równie znaczącą jak to, że wcięcia są trudniejsze do opanowania od nawiasów... Zresztą, w tej kategorii wskaźniki biją wszelką konkurencję i jakoś nikt się tym nie przejmuje.

Trudniejsze do opanowania z pewnością nie są - jednak przy braku wcięcia nie zasygnalizuje Ci błędu, tylko zmieni się sposób działania całego kodu - a potem szukaj wiatru w polu (a dodatkowo mało czytelne jest takie rozwiązanie gdy monitora zaczyna brakować w szerz na wcięcia ;p). Co do wskaźników to widać, że nigdy nie programowałeś czegoś wymagającego wydajności - fakt jeśli nie wiesz jak wskaźniki działają lepiej nie używać, ale jeśli wiesz to zdajesz sobie sprawę, że nic lepszego nie ma (kolejna rozbieżność początkujący vs doświadczony).

 

Oczywiście, siłą Pythona jest jego prostota, ale nie dlatego zyskał pozycję w branży. Zyskał, bo dzięki cechom, które Ty uważasz za wady, stał się językiem bardzo popularnym, co w konsekwencji doprowadziło do powstania masy modułów, na czym z kolei zależy ludziom decydującym się na Pythona jako język skryptowy w ich aplikacji. Bo z definicji ma działać jako klej do łączenia jej z innymi technologiami.

Tak zyskał dzięki temu, że początkujący się w nim dobrze czują, a nie dlatego, że można w nim napisać coś większego - to się zgadza. To co jest zaletą dla laika jest wadą dla programisty.

 

Python ma oczywiście swoje wady, jest wolny, ciężki, i ma problemy z wątkami. Luę znacznie łatwiej jest osadzić w aplikacji. Najwyraźniej jednak zalety (te, które uważasz za wady), przesądzają sprawę. Ja się ciszę, choć przyznam, że ustawicznie kombinuję jakby tu podrasować Pythona ironem, albo ctypem ;)

Wcale nie łatwiej - mniej więcej tak samo łatwo się integruje i jest to banalnie proste (sam kiedyś w swoim silniku dopóki nie zaczął sprawiać problemów programistą skryptów).

 

Skoti, no nie powiem, część argumentów do mnie trafia. Ja też lubię silne typowanie i rozwiązania skalowalne, ale wynika to, jak pisze Symek, z "wychowania". Poza tym, co wobec tego, że można się szybko nauczyć każdego języka, uważałbyś za lepszą sytuację? Każdy soft z innym językiem skryptowym? Bo troszkę się pogubiłem.

Nie lepiej, każdy soft z innym tylko z takim który można zastosować zarówno w małych jak i dużych skryptach, bez utraty pigmentu włosów. Jednak jeśli mam do wyboru python lub inny język, bez wad pythona to wolę się nauczyć takiego niż użyć pythona.

 

A jeśli z jednym konkretnym, to jakim? Ja np. nie zamierzam pisać w Pythonie rzeczy, które mogę sobie napisać w C++ czy w Javie. Uważam po prostu, że nie bez powodu Python zdobywa coraz większą popularność i to mimo wszystko lepiej, niż żeby każdy sobie dodawał język skryptowy wedle uznania. To że np. twórcy Nuke'a (The Foundry), ludzie z ogromnym doświadczeniem w pisaniu plugów na najróżniejsze platformy, wybrali Python, to też o czymś świadczy. Pewnie, że jest to kompromis, ale chyba lepszy niż np. AppleScript na Macu --- język z dialektem quasi-naturalnym, który wykańcza programistów, a laicy i tak w nim nie piszą, bo nie wiedzą o co chodzi. :)

Niczego konkretnie nie sugeruje - sam zmieniłem pythona na angelcode i ja jak i współpracownicy jesteśmy zadowoleni - ale to wszystko zależy od tego dla kogo jest kierowany język. Jeśli dla laików jak w przypadku Nuke (dla użytkowników) to python może nie być takim złym wyborem, jeśli dodadzą możliwość pisania pluginów w C/C++. Jeśli programiści wybierają język dla siebie/innych programistów (jak w moim wypadku - przy tworzeniu gier) to nie wybierają pythona tylko języki ze statycznym typowaniem i bez udziwnień mogących tworzyć błędy (no wyjątkiem jest język LUA który miał swoje 5 minut (tu ze względu na niezłą wydajność), ale też się od niego odchodzi).

[mamoulian]

Skoti możesz napisać jaki jest Twój silnik? Coś w deseń Crysis, czy zwykłe 2d?

Co to za gra? jakaś niekomercyjna, indie, mmo czy dla większego wydawcy?

I na jakim etapie jesteście, tzn ile % jest skończone i od ilu lat.

 

I jak się odniesiesz do szybkości pisania w AngelCode vs Python.

 

Co do szybkości Pythona to zależy(jak wszystko w programowaniu). Z NumPy potrafi być szybszy niż C++.

[Skoti]

@mamoulian: Silnik 3d. Nie mówię o grze tylko o silniku - gry to wiele na przestrzeni ~8lat, grupa Indie. Teraz realizujemy 2 projekty z czego jeden zbliża się ku końcowi.

 

Szybkość pisania jest porównywalna, szybkość wykonywania na korzyść AC.

 

Tak - w sztucznych testach Java też przegoni znacznie C++ - z tym, że praktyka jest inna niż testy. Co do NumPy to on jest pisany w C/C++ + wrapper pythona, a wykonywany z poziomu pythona jest zawsze wolniejszy, bo jest dodatkowy narzut - jeśli wyprzedzał w jakimś teście C++ to po prostu ktoś użył gorszego algorytmu, bo sam python czy NumPy z pewnością nie dały przewagi ;p

[SYmek]

Nie należę do żadnego specjalnego typu ludzi - chyba, że tak nazywasz wszystkich niepoczątkujących programistów. Pythona praktycznie nikt z osób doświadczonych nie lubi (lubią w nim pracować początkujący, zanim przekonają się, że jego zalety na początku przeradzają się w olbrzymie wady przy czymś większym niż paręnaście linijek) (...)

 

Nie zrozumielismy sie. Wskazniki byly przykladem na to, ze funkcje jezykow generujace trudnosci albo nawet zawile, bywaja niezastapione. Podobnie sprawa ma sie z elestycznoscia Pythona. Jest bardzo pomocna. Ludzie, ktorzy tworzyli Pythona slusznie zauwazyli, ze w wiekszosci przypadkow to wlasciwie od Ciebie zalezy czy uzywsz typow dynamicznych. I w praktyce tak wlasnie jest. Doswiadczony programista nie zmienia typow zmiennych nawet jesli jezyk mu na to pozwala. To samo mozna powiedziec o funkcjach chronionych i wielu innych magicznych cechach jezykow dla "prawdziwych programistow".

 

Python - czyli jezyk skryptowy - powinien byc elastyczny i latwy w pisaniu, wiec czynienie mu z tego zarzutu jest conajmniej nietrafione. Slabe, dynamiczne typowanie i wciecia, spelniaja swoja role: pisze sie w nim szybko i przyjemnie. A ze nie nadaje sie do pisania obslugi promow kosmicznych... coz.

 

Do argumentu z ignorancji, ktorego naduzywasz, nie bede sie odnosil, szkoda slow. Z latwoscia mozesz sobie sam wymienic dziesiatki powaznych projektow, stworzonych dla programistow i naukowcow (nie grafikow), przez doswiadczonych programistow, liczacych wiele milionow linii kodu, w ktorych z powodzeniem uzywa sie Pythona, zaczynajac od platformy Google, przez pipeliny duzych studiow czy chocby Numpy, Cortex, Zope, Django etc etc etc.

 

A ze jego cechy predystynuja go raczej do tworzenia uzytecznych skryptow niz ciezkich aplikacji rozumiemy z zalozenia. Dlatego uzywa sie go do skrytowania aplikacji 3d, a nie ich pisania.

 

Kazdy jezyk ma swoje "udziwnienia mogace tworzyc bledy". Jednym z nich jest szalony wymog, zeby kod napisal czlowiek, ktory jak wiadomo jest omylny.

[Skoti]

Ludzie, ktorzy tworzyli Pythona slusznie zauwazyli, ze w wiekszosci przypadkow to wlasciwie od Ciebie zalezy czy uzywsz typow dynamicznych. I w praktyce tak wlasnie jest. Doswiadczony programista nie zmienia typow zmiennych nawet jesli jezyk mu na to pozwala.

Ja nie pisałem o tym, że umyślnie zmieni typ, ale właśnie jeśli nieumyślnie zmieni to wtedy szukać może problemu godzinami, a język w znalezieniu problemu nie pomoże (w wypadku statycznych typów rozwiązanie problemu to kilka sekund, bo powie dokładnie co się stało i w której lini).

 

Python - czyli jezyk skryptowy - powinien byc elastyczny i latwy w pisaniu, wiec czynienie mu z tego zarzutu jest conajmniej nietrafione. Slabe, dynamiczne typowanie i wciecia, spelniaja swoja role: pisze sie w nim szybko i przyjemnie. A ze nie nadaje sie do pisania obslugi promow kosmicznych... coz.

Język skryptowy powinien być językiem skryptowym - nie ma wymogu elastyczności i łatwości, a jedynie żeby był interpretowany w trakcie uruchomienia. A to, że typy są statyczne/dynamiczne nie robią wcale język łatwiejszym czy trudniejszym, a wcięcia jako bloki danych to właśnie bardzo nieelastyczne rozwiązanie ;p.

 

Z latwoscia mozesz sobie sam wymienic dziesiatki powaznych projektow, stworzonych dla programistow i naukowcow (nie grafikow), przez doswiadczonych programistow, liczacych wiele milionow linii kodu, w ktorych z powodzeniem uzywa sie Pythona, zaczynajac od platformy Google, przez pipeliny duzych studiow czy chocby Numpy, Cortex, Zope, Django etc etc etc.

NumPy jest napisany w C, a w pythonie jest tylko wrapper na bibliotekę napisaną w C, Cortex podobnie jak NumPy z tym, że główna część była pisana w C++, a nie w C, Django w sumie nie ma dużego wyboru (aplikacja internetowa to do wyboru miała jeszcze gorszy php, a jsp nie każdemu odpowiada (ale i tak lepszym wyborem niż python byłby imo ruby... ale to już nie duża różnica i wybór pythona można uznać, za racjonalny wybór)). Zope nie znam i ciekawy jestem jak działa, ale wyjątek potwierdza regułę.

PS. możesz napisać o jakiej platformie Google mówisz, bo jest ich trochę i dużo eksperymentują z językami skryptowymi. Jeśli mówisz o ich głównych usługach to faktycznie wspierają się pythonem i odgrywa on podobno dosyć ważną rolę, obok C++ i Javy (JSP).

 

Kazdy jezyk ma swoje "udziwnienia mogace tworzyc bledy". Jednym z nich jest szalony wymog, zeby kod napisal czlowiek, ktory jak wiadomo jest omylny.

Próbujesz usprawiedliwiać pythona w sposób, "każdy ustrój ma swoje wady i nie każdy jest tak samo traktowany, więc dlaczego nie faszyzm?" - tak każdy język jest podatny na błędy, ale nie każdy je prowokuje.

[mamoulian]

Skoti nie mogę znaleźć tego testu. Chyba chodziło o funkcję sortowania i tu podobne algorytmy wskazywały na przewagę NumPy.

Oczywiście można napisać szybszy, bardziej zoptymalizowany algorytm w C++, ale jakim kosztem czasu.

 

Ukończyłeś jakaś grę w życiu czy wszystkie to rpg(zgduję, bo prawie każdy indie tworzy rpg) "when its done" vapoware? :)

[Skoti]

Skoti nie mogę znaleźć tego testu. Chyba chodziło o funkcję sortowania i tu podobne algorytmy wskazywały na przewagę NumPy.

Oczywiście można napisać szybszy, bardziej zoptymalizowany algorytm w C++, ale jakim kosztem czasu.

Można też skorzystać z jednej z licznych bibliotek matematycznych.

 

Ukończyłeś jakaś grę w życiu czy wszystkie to rpg(zgduję, bo prawie każdy indie tworzy rpg) "when its done" vapoware? :)

Tak ukończyłem i nie nie tworze RPG. Grupy Indie nie tworzą RPG za często - robią to przeważnie amatorskie teamy które nie wiedzą na co się porywają (chyba nie mylisz amatorki z niezależnością?).

[mamoulian]

Nie wiem co to teraz niezależność, ale wiem, że najbardziej sukcesywna polska gra indie (93 tys $ income) została napisana w Dephi ;).

[Skoti]

@mamoulian: 93k$ to nie jest polska gra indie z największym sukcesem komercyjnym.

[mamoulian]

To która? Za indie mam na myśli zespół poniżej 5 osób i wydawanie na własną rękę.

[Skoti]

@mamoulian: Indie to jakakolwiek grupa (moja ma 20 osób razem z grafikami i muzykami), która jest niezależna od wydawcy - robi grę sama według swoich założeń, a potem szuka wydawcy gotowego produktu/wydaje sama.

[mamoulian]

Ok to Twoja definicja. Według mnie gry indie są tworzone dla niszowego odbiorcy.

 

Czy nie uważasz, że income powinno się dzielić przez liczbę osób tworzących?

 

o ile mi wiadomo 93ty$ wygenerował 1 człowiek. Więc jeśli dzielicie się po równo w swoim zespole, to musielibyście wygenerować na czysto zysku z 2 mln $ by mu dorównać, czego Wam życzę.

Jednak nie znam polskiej gry indie, która byłaby równie sukcesywna. Nawet nie wiem czy istnieje jakaś mainstreamowa.

[Skoti]

@mamoulian: To nie jest moja definicja tylko tak definiowane są zespoły indie. To co Ty nazywasz indie jest określane jako causal (one są często tworzone najczęściej przez małą grupę osób, dla niewymagającego gracza, są proste i są tworzone zarówno przez grupy indie, jak i przez zależne (w polsce takie gry powstają na zlecenie playa i często w jednoosobowych zespołach - jednak to nie indie)).

 

Podział przez ilość osób pracujących mógłbyś robić gdyby wszyscy mieli równy udział w zyskach, a nie pracowali za wynagrodzenie, za pracę, a ostateczny zysk nie przypadał jednej/małej grupie osób (ofc mówię o samym teamie, a nie o wydawcy i dalej).