მაღლიველი სტუდენტი და NASA-ს ჯავას სტანდარტი


წინა პოსტისთვის მასალების გადამოწმებას რომ ვცდილობდი, ნასას საიტზე სხვა საინტერესო რამეებსაც გადავაწყდი და პატარა პოსტს მივუძღვნი ბარემ 🙂

ერთი იყო ჭკუის სასწავლებელი შეცდომები არქივი, რომელსაც ჰქვია Lessons learned. და პრობლემები, სადაც ცხვირი წაიტეხეს, თავისი გადაჭრის გზებით არის აღწერილი.

მეორე იყო JPL ლაბორატორიის სტანდარტი, რომლითაც მათი ჯავა პროგრამისტები ხელმძღვანელობენ. იქ ჩამოთვლილი საკითხების უმრავლესობის წყაროდ ორი წიგნი მოეყვანათ – ჯავას ერთ-ერთი შემქმნელის – ჯოშუა ბლოხის Effective Java და იგივე ავტორის Java Puzzlers: Traps, Pitfalls, and Corner Cases.

ჩემი და ჯავას სიყვარულის ისტორია მეორე კურსიდან იწყება, როცა ორი ძალიან მაგარი ლექტორის, მიშა კაპანაძის და იოსებ ძმანაშვილის წყალობით საფუძვლიანი ჯავას და საერთოდ OOP-ის კურსი შემოგვემატა თსუ-ში (სხვა ლექტორები სხვა ჯგუფებში იყვნენ). დაახლოებით იმ პერიოდში ვკითხულობდი ჯოშუა ბლოხსაც დიდი აღფრთოვანებით, ზუსტად იმ ორ წიგნს. ჰოდა დიდი კი არაფერი, უბრალოდ აღნიშნვა მინდოდა, რომ რა მაგარ დროში ვცხოვრობთ და როგორ წაშლილია საზღვრები ინტერნეტის გამოისობით, რომ 17 წლის სტუდენტი სადღაც საქართველოში, სახლში იგივე წიგნებით “ხელმძღვანელობს” რითიც ნასას ინჟინერი. არ სჭირდება გამომცემლებისთვის ხელებში ყურება. აქვე უნდა გავიხსენო ერთი კარგი საქველმოქმედო პროექტი – “ჩართე” charte.ge , რომელიც ინტერნეტს ურთავს სოციალურად დაუცველ უფროსკლასელებს, იმიტომ რომ ჩემი აზრით ინტერნეტი ყველაზე კარგი რამ არის ადამიანის ცხოვრების შესაცვლელად. ახლა ნასაც არ არის იდეალური კომპანია (რომ გადავეკიდე), მაგრამ რაღაცებში ჩვენ კი გვისწრებენ ჯერჯერობით.

თვითონ სტანდარტს რაც შეეხება, რამდენიმე შედარებით საინტერესო შემთხვევა ამოვკრიბე (პასუხები იქვე დავმალე), დამწყებ ჯავას ხალხს შეიძლება მოეწონოს:

1. რას დაბეჭდავს მეორე ხაზი?

int i = 0; 
System.out.print(true ? 'x' : 0); // prints "x"
System.out.print(true ? 'x' : i); // prints ?

“120”
ეს იმიტომ რომ char დაყავს int-ზე. ამიტო ასეთ შემოკლებულ if ჩანაწერებში ჯობია ორივე მხარეს ერთი ტიპის ცვლადი იყოს.

2. როგორ შევადაროთ სწორად float ტიპის რიცხვები?

0.1 + 0.2 == 0.3

false
0.1 + 0.2 დაბეჭდავს 0.30000000000000004
მცოცავმძიმიან რიცხვებზე ოპერაციები ყოველთვის პრობლემაა და დიდი ისტორია აქვს, ახლა არ ჩავუღრმავდები (განსხვავებულად ინახება მეხსიერებაში). ენების უმრავლესობაში ჯობია, რომ სიზუსტე სადაც გვჭირდება long ტიპი ან შესაფერისი ბიბლიოთეკა გამოვიყენოთ. მაგალითად, ფული იყოს არა 1.43 ლარი არამედ 143 თეთრი.

თუ float ტიპის მნიშვნელობების შედარება გვჭირდება, გამოვიყენოთ პატარა ცდომილება. მაგალითად:

final double EPSILON = 0.001;
System.out.println(Math.abs((0.1 + 0.2) - 0.3) < EPSILON); // დაბეჭდავს true;

3. ვთქვათ გვაქვს ცვლადი, რომელსაც ციკლი უყურებს თავის პირობაში. ხოლო ამ ცვლადში სხვადასხვა ნაკადი წერს მნიშვნელობებს.

class Spin {
    public boolean done = false;
    public void spin() {
        while(!done){ 
	    // რაიმე ლოგიკა
        }
    }
}

რა პრობლემა აქვს ამ კოდს?

როდესაც ცვლადს რამდენიმე ნაკადი იყენებს და კოდში ის არ გვაქვს მონიშნული volatile keyword-ით, შეიძლება კომპილატორის სხვადასხვა ოპტიმიზაციების შედეგად მისი განახლება ვეღარ შეამჩნიონ ნაკადებმა. შეიძლება თითოეულმა მათგანმა ეს ცვლადი თავისთან ქეშში შეინახოს და იქიდან ჩატვირთოს ხოლმე. შედეგად უსასრულო ციკლს მივიღებთ.
სანაცვლოდ ან volatile უნდა გამოვიყენოთ ან უსასრულო ციკლის გარეშე დავწეროთ იგივე ლოგიკა ჯავას concurrent ბიბლიოთეკით.

4. ვთქვათ რიცხვის კენტობაზე შემოწმება გვსურს. რა პრობლემა აქვთ ამ პირობებს?

x % 2 == 1
x % 2 > 0

უარყოფითი რიცხვები.
ეს სწორად არ მუშაობს თუ x უარყოფითია. მაგალითად -5 % 2 არის -1.
ამიტომ ჯობია შევამოწმოთ ხოლმე ამ პირობით: x % 2 != 0 კენტობა, x % 2 == 0 ლუწობა.

როგორ გავხდეთ უკეთესი პროგრამისტი ეფექტურად

ამ 10-11 წლის განმავლობაში, რაც პროგრამირება ჩემს პროფესიად იქცა, მრავალფეროვანი უკან დახევის და წინსვლის პერიოდები მქონდა, ხან რუტინები, ხან ნახტომები – როგორც ყველას მოკლედ 🙂

მომინდა სტატიაში მომეყარა თავი. თქვენც ხომ არ დამიმატებთ რჩევებს კომენტარებში?

 

დიდი სურათი

V8 ძრავი

ერთი და იმავე საკითხის სასწავლად რამდენიმე გზაა. ერთს შეიძლება ხუთი წელი დასჭირდეს, როცა მეორეთი იგივე შედეგს ერთ წელში მივიღებთ. პროგრამისტები პრაქტიკული ხალხი ვართ, მალევე გვინდა მკლავები ავიკეცოთ, დავჯდეთ, დავწეროთ, გავუშვათ. სავარაუდოდ ამიტომ ჩვენი სწავლის ყველაზე გავრცელებული მეთოდი როლიკებზე დადგომას ჰგავს. უამრავჯერ ვეცემით, უამრავი დალურჯება გვაქვს. ბოლოს შეიძლება მაგის მომგონიც გავლანძღოთ და თავიც დავანებოთ. ამის ნაცვლად შეგვეძლო წინასწარ გვეყურებინა / წაგვეკითხა – როგორ უნდა იყოს შეკრული ფეხსაცმელი, როგორ არ უნდა ავწიოთ ხელი, როგორ დავეცეთ, როგორ მოვტრიალდეთ, ეს ყველაფერი ფიზიკაა და წინასწარ ცნობილია. მაინც ბევრჯერ დავეცემით, მაგრამ შედარებით ნაკლები ტრამვით.

მოდით ექსპერიმენტი ჩავატაროთ: გაიხსენეთ ენა, რაზეც ბოლო ერთი-ორი წელი წერთ. გარანტიას გაძლევთ, რომ თუ ამ ენაზე ერთ კარგ წიგნს (ან უბრალოდ მის დოკუმენტაციას) წაიკითხავთ თავიდან ბოლომდე, ნახევარი თუ არა დიდი ნაწილი მნიშვნელოვანი სიახლე იქნება. არ ვგულისხმობ, რომ წიგნის ყველა მაგალითზე გავჩერდეთ და კოდი გავუშვათ, ან ყველა დეტალი ბოლომდე გავიგოთ / დავიმახსოვროთ. უბრალოდ, როცა წინასწარ ვკითხულობთ მთლიანად და ერთიანად, დიდ სურათს ვხედავთ. ყოველთვის შეგვიძლია დეტალები დავგუგლოთ, თუ ვიცით რომ ეგეთი რამ საერთოდ არსებობს. თუ არ გვეცოდინება საფუძვლები ან თუნდაც, მაგალითად, როგორ იყენებს მეხსიერებას, გვექნება memory leaks პროგრამაში და ვერც მივხვდებით.
ამის შემდეგ შეგვიძლია წავიკითხოთ კიდევ ერთი წიგნი – შესაბამისი Best practices, ანუ ამ ენის გამოყენების საუკეთესო პრაქტიკა, რაც კიდევ უფრო მეტი ‘ტრამვისგან’ დაგვიხსნის. თუ სწავლის პროცესში უამისოდ პროექტს გადაწერთ ხუთჯერ, ამის წაკითხვის შემდეგ სავაურაუდოდ გადაწერთ ერთხელ.

წიგნს ორი-სამი დღე სჭირდება, იგივე შეცდომებზე სწავლას კი თვეები.

 

შეჯიბრებები და ალგორითმები

ჩემი აზრით არის ერთი ეტაპი, რომელიც ყველა თავმოყვარე პროგრამისტმა უნდა გაიაროს. ბევრ დროს ითხოვს და ამიტომ ხშირად ამას სკოლის ან სტუდენტობის პერიოდში გადიან, მაგრამ გვიან სჯობს, ვიდრე არასდროს. თუ ვინმეს დაეზარება, მას უბრალოდ ერთი დიდი ნაბიჯით გაუსწრებენ კონკურენტები.

პროგრამირების შეჯიბრებებზე და ამოცანების ამოხსნაზე მაქვს საუბარი. ამ ვარჯიშის პროცესიდან გამომდინარე მნიშნველოვნად შეიცვლება თქვენი ფიქრის სტილი, აზროვნების სისწრაფე, თავში ბევრი კომპონენტის ერთდროულად დალაგება. კოდიდან თითქმის გაქრება გავრცელებული შეცდომები, როგორიცაა მაგალითად მასივის არასწორ ან არარსებულ ინდექსებზე მიმართვა, ციკლისთვის არასწორი საზღვრების დაწესება, ზედმეტი მეხსიერების გამოყოფა და memory leaks, არაოპტიმალური კოდის წერა, არასწორი მონაცემთა სტრუქტურების გამოყენება. აღარ გეხსომებათ ბოლოს როდის გამოიყენეთ დებაგერი. შეგეძლებათ ყველა ფუნქციის შემდეგ კი არა, მთელი კოდის დაწერის შემდეგ გაუშვათ პროგრამა და ექნება ძალიან ცოტა შეცდომები. ჩვეულებრივი პროექტისგან განსხვავებით შეჯიბრების დროს თქვენს ყველა შეცდომას იჭერენ.

შეიძლება არ დაგჭირდეთ ნასწავლი ალგორითმები და არ შეგხვდეთ ისეთი ამოცანები რეალურ პროექტებში, მაგრამ აუცილებლად დაგჭირდებათ სწრაფი გონება და კარგი კოდის წერის / ტესტირების უნარები. არა უშავს, თუ ვერ მოვიგებთ, თუ ასეულში ვერ მოვხვდებით, თუნდაც ვერც მსოფლიო ათასეულში – ეს სპორტია. არიან ბუნებრივი ნიჭით დაბადებულები, არიან ძალიან ნამეცადინები ადამიანები. ცოტა მიისწრაფის ოლიმპიური მედლისკენ, მაგრამ ჯანრთელობისთვის ყველა ვარჯიშობს, ხომ ასეა?

ჩემთვის ასეთი ეტაპი იყო, როდესაც ჯეოლიმპზე ვმუშაობდით. იქ ამოცანებს მაგ სფეროში გამოცდილი ხალხი იგონებდა, მე უბრალოდ სხვა საქმეს ვაკეთებდი და თან ამოხსნას ვცდილობდი შეჯიბრის მსვლელობისას (სხვათაშორის ახლაც დევს იქ არქივი, ონლაინ მატესტირებელი სისტემა და ვიდეო/ტექსტური გარჩევები). დღესაც ვგრძნობ ხოლმე, როგორ ვვარდები ფორმიდან ვარჯიშის გარეშე, იმის მიუხედავად რომ რაღაც კოდს მუდმივად ვწერ. მერე მრცხვენია, როცა უაზრო შეცდომები მომდის.

კარგი სია, სადაც ვარჯიში შეიძლება: The 10 Best Coding Challenge Websites for 2018

 

ასწავლე სხვას

ეს ცნობილი მეთოდია 🙂 როდესაც სხვას უხსნი, სულ სხვა დეტალებს ამჩნევ. ზოგადად, ასე მგონია, რაღაცის სიტყვიერად ჩამოყალიბება გასაკეთებელი საქმის ნახევარია. როცა შეცდომას ეძებთ, ან არ იცით როგორ გააკეთოთ რამე, ჯერ პირობის დაწერა და აღწერა ცადეთ. რეზინის იხვთან ლაპარაკი ამიტომ არის ეფექტური :))

 

სტრესი გვანადგურებს

Gravity Glue | Stone Balance by Michael Grab

პროგრამირება ერთ-ერთი ძალიან სტრესული პროფესიაა. გეტყვით რატომ – პროგრამისტი ყოველ დღე იმას აკეთებს, რაც აქამდე არასდროს გაუკეთებია. თუ ერთსა და იმავეს გააკეთებს (თუნდაც სხვისას გაიმეორებს) და უკვე გაკეთებულს არ გამოიყენებს სანაცვლოდ, ეს დიდ შეცდომად ითვლება და თვითონვე იჩენს დამატებით პრობლემებს. ამას ემატება, რომ წინასწარ სთხოვენ სამუშაო დროის შეფასებას. ცხადია, ყველა შეფასება მიახლოებითია. გზაზე შეიძლება ათასნაირი გაუთვალისწინებელი პრობლემა შეხვდეს, რაც ძვირფას დღეებს ან კვირებს დააკარგინებს. ზოგჯერ პროგრამისტი თავისივე მიცემული შეფასების დასაცავად დღეში 10 საათს ან მეტს მუშაობს.

ყველა მათგანს თავისი მეთოდი აქვს ამ სტრესთან გასამკლავებლად. გონების გადაღლიდან გაცილებით უფრო ძნელია აღდგენა, ვიდრე ფიზიკური დაღლილობიდან, რომელსაც შეიძლება ერთი გამოძინებით უშველო.
რამდენიმე პრაქტიკული რჩევა:

  • გააკეთეთ ავტომატიზაციები. ჩვენი სფეროს ყველაზე სტრესული პროცესები ავტომატიზირებადია. ეს ძალიან ბევრ ნერვებს და დროს დაგიზოგავთ.
  • როცა ერთ პრობლემაზე გაიჭედებით, გადაერთეთ ან დაისვენეთ. არსებობს გამოთქმა – sleep on a problem. თუ ძილის წინ კარგად ჩამოაყალიბებთ გადასაჭრელ პრობლემას, ღამე ტვინი იფიქრებს და დილით პასუხსაც დაგახვედრებთ. ეს ნამდვილად მუშაობს.
  • ფიზიკური ჯანმრთელობა, ბუნებაში გასეირნება, მედიტაცია, ძილი. შეიძლება ჩათვალოთ, რომ ვარჯიშში დასაკარგი დრო არაა, მაგრამ გონებრივი სამუშაოც პირიქით უფრო მეტი ესწრება, როცა პარალელურად ფიზიკური დატვირთვაა. ხოლო უძინარმა და დაღლილმა მთელი ღამე რომც წეროთ კოდი, მეორე დღეს თვითონ გადააგდებთ იმ კოდს ან შეცდომებით იქნება სავსე. ენერგეტიკული სასმელები და უზარმაზარი რაოდენობით კოფეინი ალბათ მხოლოდ გამოუვალ მდგომარეობაში შეიძლება, თუ შეიძლება საერთოდ.
  • მხოლოდ თქვენ შეგიძლიათ საკუთარ თავზე ზრუნვა. სტრესი მშვენიერი მამოტივირებელია, მაგრამ მუდმივის შემთხვევაში ტვინსაც და ორგანიზმსაც ძალიან ცუდი რამეები მოსდის.

 

სხვისი კოდების კითხვა და open-source პროექტებში მონაწილეობა

წიგნების მსგავსად, კოდების კითხვა განვითარების ძალიან კარგი წყაროა. დღეს ყველაზე საინტერესო პროექტები ღია სახით დევს ინტერნეტში და კონტრიბუციაც კი შესაძლებელია. აირჩეთ თქვენი საყვარელი ენა, პროექტი და შეგიძლიათ სახლიდან გაუსვლელადვე გახდეთ მისი მონაწილე. ეს თქვენს CV-ზეც კარგად აისახება სხვათაშორის.

DevFest 2017 გამოსვლა: Continuous Integration-Delivery-Deployment

დეველოპერების ფესტივალის გამოსვლების გამოქვეყნება დაიწყო ^_^
ჩემს გამოსვლას აქ გავაზიარებ, რომ ბლოგზე მქონდეს. მიყვარს ეს ფესტივალი და მართალია დღეების ნაცვლად ერთი თვე მოვუნდი პრეზენტაციის მომზადებას პატარას ხელში :))) მაგრამ ძალიან მინდოდა მონაწილეობის მიღება.

ესეც დემოს ლინკი გიტჰაბზე:
https://github.com/elatsoshvili/DevFestDemo2017

ქართული ვები მათთვის, ვინც უსმენს

10 წელზე მეტია, რაც ქართული ვებ სივრცე არსებობს და ყოველ დღე ვქმნით მას, ის კი ჩვენი ცხოვრების მნიშვნელოვან დეტალებს ქმნის. სამწუხაროდ, საქართველოში არის ათეულობით ათასი ადამიანი, ვისთვისაც მისი სიკეთეები ჯერ კიდევ არ არის ხელმისაწვდომი.

თუ გსურთ შეიტყოთ:
– როგორ იყენებენ უსინათლო ადამიანები კომპიუტერს, ინტერნეტს, ელექტრონულ ფოსტას, სოციალურ ქსელს…
– რა ტექნოლოგიები და პრობლემები არსებობს საქართველოში ამ კუთხით
– რა მინიმალური რესურსით შეგვიძლია გავხადოთ ქართული ვებ სივრცე ხელმისაწვდომი

ან გაგვიზიაროთ მოსაზრებები, მაშინ შემოგვიერთდით 14 მაისს, 14:30 საათზე.
ა/ო ინფორმაციული ტექნოლოგიების განვითარების ინსტიტუტთან (IDIT) ერთად, საქართველოს ინოვაციებისა და ტექნოლოგიების სააგენტოს მხარდაჭერით, ვატარებთ კონფერენციას – “შეუზღუდავი შესაძლებლობები ონლაინსივრცეში”.

გეგმა ასეთია:

202-ე უსინათლო ბავშვთა სკოლის პედაგოგი, ინკლუზიური განათლების სპეციალისტი – კახა ცხოვრებაშვილი გაგვაცნობს ეკრანის წამკითხველებს და ოპტიმიზაციის პერსპექტივებს.

გიორგი გვასალია, ინფორმაციული ტექნოლოგიების განვითარების ინსტიტუტის აღმასრულებელი დირექტორი – წარადგენს ხმოვან ვებგვერდს, ინტერნეტის ხელმისაწვდომობის სტანდარტებს და მიმოიხილავს ქართულ ონლაინსივრცეს.

ბექა ცხოვრებაშვილი, მუნიციპალური სერვისების განვითარების სააგენტოს პროგრამისტი, მოგვიყვება მეტყველების სინთეზის შესახებ: რა არის ხმოვანი სინთეზატორი და როგორ შეგვიძლია მისი შექმნა. ბექა თავად არის უსინათლო, თუმცა აქტიურად იყენებს ინტერნეტს და წერს პროგრამებს სხვადასხვა პროგრამირების ენაზე. მას ძალიან დიდი წვლილი აქვს შეტანილი ეკრანის მკითხველის გაქართულებასა და ქართული ხმოვანი სინთეზატორის შექმნაში.

ალექსანდრე ხუციშვილი, კომპანია Circle-ის უფროსი დეველოპერი, ისაუბრებს ოპერაციული სისტემის ერთ-ერთ აუდიო ინტერფეისზე, რითიც მეტი შესაძლებლობები ეძლევათ უსინათლო დეველოპერებს.

მე კი შემოგთავაზებთ პატარა ექსპერიმენტულ პროექტს – ბლოგების ადაპტირებულ სისტემას, სადაც მომხმარებელს შეუძლია შექმნას საკუთარი ბლოგი, წეროს სტატიები, გამოეხმაუროს სხვა ბლოგებს ან გამოიყენოს შეტყობინებების სისტემა. ასევე ვისაუბრებ, თუ რა შესაძლებლობა არსებობს ვებ სისტემების ადაპტირებისთვის, როგორ მუშაობს ეკრანის წამკითხველი ფარდის უკან, რა მნიშვნელობა აქვს საიტის სემანტიკურ სტრუქტურას და რა სირთულე შეიძლება შეგვხვდეს გზად.

თუ თქვენი საიტი შექმნილია ზოგადი სტანდარტების დაცვით, ძალიან მარტივად, ზოგჯერ ერთ დღეშიც, შეიძლება მისი მინიმალური ოპტიმიზირება, რომ დიდი ნაწილი ხელმისაწვდომი გახდეს უსინათლო მომხმარებლისთვის.

მეტი ინფორმაციისთვის, კონფერენციის ორგანიზატორების და ჩატარების დეტალების შესახებ, ასევე რეგისტრაციისთვის, იხილეთ ღონისძიების გვერდი: https://www.facebook.com/events/1938015203106845

Boxtrolls და რევოლუცია stop-motion ანიმაციაში

სინამდვილეში ეს რევოლუცია 3 წლის წინ მოხდა :)) უბრალოდ ადრე როცა ტრეილერი ვნახე, ვერ დავიჯერე და ვერც წარმოვიდგინე რომ კომპიუტერი არ გამოიყენებოდა ანიმაციისთვის, რადგან ალტერნატივა სრული სიგიჟეა. თურმე ამ სიგიჟეს აკეთებენ და არაადამიანური გზით არის ფილმი შექმნილი. ვისაც ჩემსავით არ ეჯერა, მათთვის ვწერ ამ პოსტს 🙂

stop-motion არის ერთ-ერთი ტექნიკა კინემატოგრაფიაში, როდესაც ვიდეოს ნაცვლად ძალიან ბევრ კადრს იღებენ. მაგალითად 1 წამისთვის 12-24 კადრს და თითოეულ მათგანში ობიექტ(ებ)ის მდგომარეობა სულ ოოოდნავ არის შეცვლილი. შედეგად, კადრების გადაბმით ანიმაცია გამოდის.

Credit: Jason Ptaszek / LAIKA, Inc.
Credit: Jason Ptaszek / LAIKA, Inc.

ზუსტად ასეთი მეთოდის გამო, ბევრი რამე ძალიან რთული გასაკეთებელია, განსაკუთრებით სახის მოძრაობა, საუბარი, ემოციები. ანიმატორები ერთი კვირის განმავლობაში დაახლოებით 4-5 წამის ვიდეოს ქმნიდნენ.

ანიმაციური სტუდია Laika ამ 120-წლიანი ტექნიკით ქმნის ფილმებს და Boxtrolls მისი ერთ-ერთი ბოლო ნამუშევარია. რატომღაც ჩვენთან სიახლეებში მარტო იმ კუთხით გამოჩნდა, რომ მის ტრეილერში ერთსქესიანი ოჯახი იყო ნახსენები.

ინტერვიუებში კარგად ჩანს თუ რამდენად მრავალფეროვან პრობლემებზე მოუწია გუნდს მუშაობა. მაგალითად, როგორ ცხელდებოდა პატარა ნათურები და ობიექტებს აზიანებდა. როცა LED ნათურებით ჩაანაცვლეს ყველაფერი, განათების მეტი კონტროლი გაუჩნდათ. თვითონ პერსონაჟების თვალებშიც პატარა ნათურებია ჩადგმული, რადგან ტროლები ძირითადად მილებში და ჩაბნელებულ ადგილებში იყვნენ და სხვანაირად მბრწყინავ და ცოცხალ თვალებს ვერ აკეთებდნენ.

 

ცეცხლი, წყლის ათინათები, ტანსაცმლის დიზაინი, უამრავი წვრილმანი დეტალი…

 

ერთ-ერთი რევოლუციური ნაწილი მათ ნაშრომში 3D ბეჭდვის გამოყენებაა. თქვენი აზრით როგორ აკეთებენ სახის ანიმაციას? ყოველი კადრისთვის შესაბამის სახეს (ან თავს) ბეჭდავენ და მერე ობიექტს წამში 24-ჯერ უცვლიან სახეს :))

faces

მოკლედ, შემოქმედების ზეიმია ეს ფილმი 🙂

თუ არ გინახავთ ან ამ თვალით არ შეგიხედავთ, შეგიძლიათ ნახოთ და დატკბეთ დეტალებისადმი ამოდენა სიყვარულით და ზოგადად ძალიან საყვარელი პერსონაჟებით.

 

 

ისე, ძველი ქართული მულტფილმებიდანაც ბევრი stop-motion ტექნიკით იყო მგონი გადაღებული, გარეგნულად თითქოს ეგრეა. მაგალითად ბომბორა, კომბლე, საზამთრო… არა?