Skocz do zawartości

danilo2

Members
  • Liczba zawartości

    646
  • Rejestracja

  • Ostatnia wizyta

Odpowiedzi dodane przez danilo2

  1. Nie zgadzam sie z Tobą Danilo2. 20 lat temu zacząłem od assemblera i bardzo tego żałuję. Dostałem blowminda i zostałem grafikiem. A mogłem coś w zyciu osiągnąć :)

    Assembler a C to inna bajka. Jeżeli chcesz zostać programistą assemblera możesz nawet nie dotykać, ale podstawy zarządzania pamiecią i koncepcje językowe (jak szablonowanie, smaczki threadingu czy ochrona pamięci) są ważne do nauczenia i zrozumienia :)

  2. zaczynając oczywiście od Pythona, jako dobry wstęp do OOP. Potem C/C++ wchodzi *znacznie* łatwiej.

     

    Pierwszy raz chyba sie z Symkiem nie zgodzę.

    Zaczynanie od Pythona jest bardzo złe. Język ten, jak każdy wysokiego poziomu, daje niezłe możliwosci i pozwala osiągnąć łatwo zadowalające efekty, obchodzac naokoło wsyzsktie problemy i zagadnienia związane z niskopoziomowym programowaniem.

    Mimo wszyskto polecam zaczać od C (nawet nie od C++), potem C++ a dopiero Java czy Python. W tej kolejności zdobędziesz wiedzę "poukładaną" i zrozumiesz dlaczego tak a nie inaczej to wsyzstko jest tak zaplanowane.

     

    Garbage collector, ducktyping, automatyczne wskaźniki i wszystkie inne mechanizmy dostepne w interpretowlanych jezykach ,jakim jest python, pomagają programiście, ale tlyko takiemu, który wie co dzieje się pod maską, bo później przejscie na C++ mzoe wydawać się męczarnią, w drugą stronę na pewno nie.

  3. trzeba ściągnąć mova i przerobić go na ramki, a volume bedzie wielkosci: rozdzielczosc obrazka: x,y; a ilosc obrazkow to z :)

    Dzięki - to z rozdielczoscią to jest oczywiste, natomiast nie iwem czemu ,ale moje kochanep rzeglądarki pod jedynym słusznym systemem odmawiają wyświetlenia tego filmu i dlatego myslalem ze mozna te skany inaczej stamtąd pobrać :)

  4. W przypadku gdybym coś robił i zakładam, że np. Clothy robiłbym na mayce to nie ma szans żeby dogadały się tak, że można byłoby renderować w jednym? Tak jak można np. z XSI zaimportować części od ICE i całość zrenderwać na mayce?

    Hmm nie rozumiem pytania do końca, ale clothy się zazwyczaj świetnie dogadują ;] Możesz przerzucać cloth anmowany z majki do hudego - i go tam renderować a nawet odczytywać pewne informacje o prędkościach i ich używać - ale nie wiem czy o to chodziło :)

  5. rewelacja - a da sie w drugą stronę ? mam na mysli zbudowanie siatki 3d z tak wygenerowanego obrazu

     

    No ale to własnie chyba było w tą stronę - bo rozumeim, że na tej stornie www można ściągnąc te obrazki przekrojów (czyli de facto dane volumetryczne).

    Co prawda jakoś nie mogę znaleźć opcji pobrania tych danych - da się je stamtąd pobrać jakoś? ;]

     

    Symku fajne masz te pdfy :D

  6. Ja pisałem post dla osób, które nie mają licencji majki ani nie kupiły 3dlighta ;]

    Zasada działania każdej implementacji specyfikacji rendermana z definicji jest podobna, wiec jak chodzi o zasadę działania to dużych róznic między prmanem, 3dlightem i mantrą nie ma :)

    Oczywiście każdy z tych rendererów różni się od siebie (jakby się nie różniły to nie byłoby sensu zeby istniały równolegle ;])

    W mantrze dla przykładu ostatnio bardzo mocno rozwijany jest silnik pbr (physically based rendering), czego chyba nie ma w pozostałych implementacjach. (ale tutaj proszę osoby, które bawią się 3dlightm/ prmanem o potwierdzenie/zaprzeczenie tej informacji :) )

  7. @legomir -> houdniego może ściągnąć każdy (legalnie), a rsla, czy vexa (w przypadku mantry) możesz uczyć się bez żadnego wkładu pieniężnego. RSL jest tak podobny do VEXa, że darmowa wersja houdiniego + trochę zapału da efekty.

     

    Ofc to odnosi się do osób, które chcą w przyszłości pisać shadery, bo do obsługi rendermanów nie jest potrzebna wiedza z zakresu ich programowania (analogicznie zresztą do innych - aby renderować w mentalu nie musisz bawić się millem :) )

     

    W przypadku nauki zasad działania rendermanów i sprawdzenia tego w praktyce - darmowa wersja hudego z mantrą są dobrą opcją :)

    • Like 1
  8. W ramach wyjaśnienia - nie planujemy i nie będizemy planowali przeprowadzać wykładów typu "tutoriale". Doszliśmy do wniosku że tutoriali na temat - jak wymodelować, oświetlić, ustawić, ... jest na tyle dużo, że nie ma sensu powtarzać tego po raz kolejny.

     

    Dlatego też staramy się skupić na rzeczach, do którch dostęp jest trudny, lub wogóle go nie ma.

    Podczas wykładu na temat "kreacji realistycznych postaci", prelengent skupił się na sposobie kreacji.

    Z założenia wykład ten nie miał być prezentacją programu krok po kroku i żaden wykład w tej edycji artbuzza równiez nie bedzie prezentacją programu krok po kroku.

     

    Prezentacja dot. L-systemów (oraz inne prezentacje) nie ksupiała się na zagadnieniach czysto programowych (opis houdiniego ograniczał się do minimum, aby słuchacze mogli zrozumieć przykłady) , zaś cały nacisk położony był na główny temat - języka l-systemów, który tak jak techniki kreacji postaci NIE jest związany z żadnym konkretnym programem.

     

    Tak wiec i tym razem tutoriali nie będzie :)

  9. Przy okazji miło mi poinformować, że na youtube dostępne są WSZYSTKIE wykłady z poprzedniej edycji artbuzza (wystarczy wyszukać po nazwie wykładu lub po słowie artbuzz).

     

    W imieniu wszystkich organizatorów chciałbym serdecznie przeprosić za to, że materiły te tak długo czekały na ujrzenie światła dziennego i obiecuję że już więcej tak nie będzie :)

×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Wykorzystujemy cookies. Przeczytaj więcej Polityka prywatności