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 ტექნიკით იყო მგონი გადაღებული, გარეგნულად თითქოს ეგრეა. მაგალითად ბომბორა, კომბლე, საზამთრო… არა?

 

რატომ PHP?

threads

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

მოდი ცოტა შორიდან დავიწყებ.
ერთხელაც, .net რომ ვითარდებოდა ვებში, შემოვიდა asp ვებ ფორმები და პოპულარული გახდა. რამდენჯერ ვცადე შიგნით გარკვევა, რა წიგნები არ წავიკითხე, მაგრამ არ მიმივიდა გული არცერთხელ, თუმცა მიზეზს ვერ ვასახელებდი მაშინ. ეგ მიზეზი იყო თავსმოხვეული ხელოვნურობა. გეუბნებოდა ფრეიმვორკი, რომ მე ვიცი რასაც ვაკეთებ, შენ მარტო ეს ღილაკი დასვი და იმას დააჭირე. მერე მიდიოდა და ზურგს უკან რას აკეთებდა?! 😀 ამხელა სტეიტს დაათრევდა აქეთ იქით რიქვესთებს შორის. მე მგონი პლატფორმა კი არა, ერთი დიდი workaround იყო ვებისთვის.

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

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

Java EE-ში რიქვესთების საპასუხოდ პროგრამისტები ვწერთ სერვლეტ კლასებს, იქ კი instance ცვლადების გაკეთება არ არის კარგი. იცით რატომ? იმიტომ რომ თითო სერვლეტის ერთი ობიექტი გამოიყენება ყველა რიქვესთის საპასუხოდ (მთლად მაგაზე დაყრდნობაც არ შეიძლება, რადგან კონტეინერი აკონტროლებს როდის მოკლას ან ჩაანაცვლოს ის ინსტანსი). სტატიკური რაღაცები, სინგლტონ კლასები – ყველაფერი ჩვეულებრივ არსებობს აპლიკაციაში და shared არის მომხმარებლებს შორის. სპეციალურადაც კი არის ობიექტი – ‘აპლიკაციის კონტექსტი’ რომელიც სერვლეტებს შორის shared მონაცემებს დაატარებს და არაერთ best practice-ში გამოიყენება, თუნდაც რაღაც ობიექტების კეშირებისთვის. ამ ყველაფერს კი სჭირდება სინქრონიზაცია. უნდა იცოდეს პროგრამისტმა რა ბიბლიოთეკები და კლასებია thread-safe, იცოდეს კოდის რა ნაწილი მოხვდება ცალკე ნაკადში და რა ნაწილი იქნება გაზიარებული. მერე შესაბამისად lock-ებით და სინქრონიზაციის სხვადასხვა მექანიზმებით უნდა აკონტროლოს ეს ყველაფერი.

იყო რაღაც ფრეიმვორკები, ახლაც არის. ახლების ნახვის სურვილი აღარც გამჩენია მათ შემდეგ, იმიტომ რომ მე მგონი იმ ვებ ფორმებზე უარესად აფარებდნენ ფარდებს ყველაფერს. მახსოვს Struts რომ მიშრობდა სისხლს. xml-ში აკონფიგურირებდი და მერე ჯადოსნურად უნდა ემუშავა ბევრ რამეს. მაგრამ უმეტეს გაშვებაზე ერთი შეცდომა გამოდიოდა ხოლმე, რაც ჭირივით მეზიზღებოდა 😀 ფაილს ვერ ვპოულობო. ვერ გაიგებდი რა უნდოდა, xml-ში გამოგრჩა წერტილი თუ გადატვირთვა დააკლდა სერვერს. Spring-ზე არც დავიწყებ…

asp.net-ზე როცა იწერება ვებ აპლიკაცია, იქაც ერთი პროგრამა ეშვება. იქაც თუ შექმნით სტატიკურ კლასს, საერთო იქნება და რაღაც საერთო კონტექსტის ობიექტიც ჰქონდათ თუ სწორად მახსოვს. მერე asp MVC ფრეიმვორკი რომ შექმნეს, იქ კარგად ცდილობდნენ ყველა რიქვესთი stateless ყოფილიყო და როცა მომიწია მაგით წერა, ერთი სიამოვნება იყო ჩემთვის რადგან ფაქტიურად ზუსტად ისე ვწერდი როგორც php-ში.

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

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

მეორე გახდა node.js, რომელზეც ქვევით ვიტყვი უფრო დეტალურად.

როცა PHP-ის ვებ სერვერზე ვიყენებთ, უმეტეს შემთხვევაში ისე ვაკონფიგურირებთ რომ ის არ ინახავს არანაირ state-ს. თუ CGI-ის, FastCGI-ის ან Apache-ს Prefork რეჟიმს გამოვიყენებთ, სერვერთან მოსული თითოეული რიქვესთისთვის ახალი პროცესი გაეშვება და მარტო ერთ ნაკადში შესრულდება php-ის კოდი. მაშინაც კი თუ php-ის კომპილირებული ფაილების კეშირებას ვაკეთებთ, სკრიპტის თითოეული ინსტანსი მაინც ცალკე შეიქმნება და ფიზიკური მეხსიერებაც ცალკე გამოეყოფა.
თურმე სახელიც ჰქონია ასეთ მიდგომას – Shared nothing architecture.

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

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

ჰოდა node.js-ს რაც შეეხება, მანდ საერთოდ მარტო ერთი ნაკადი გვაქვს. მერე უკან, ჩვენს გარეშე კი აქვს რაღაცები გაპარალელებული, მაგრამ პროგრამისტები რასაც ვწერთ, იქ ერთისთვის ვწერთ და სრულიად არ გვანაღვლებს race condition-ები. მაგის მოდელზე ჯობია ცალკე პოსტს დავწერ.
node-ში წერასაც ექნება თავისი ნაკლები და ბევრჯერ წავიმტვრევ ალბათ ცხვირსაც, მაგრამ ნაკადებზე რომ არ ვფიქრობ, ძალიან მომწონს.

ისიც მესმის, რომ ნელ-ნელა გარდაუვალი გახდება წარმადობაზე ფიქრი და წინსვლისთვის მაინც მოგვიწევს ისეთი პროგრამების შექმნა, რომლებიც ბევრი პროცესორისთვის და ბევრი ნაკადისთვის იმუშავებს, მაგრამ რაღაცნაირად იმედი მაქვს რომ იქნება რაღაც იდეები (მაგალითად როგორც node.js ან როგორც nosql ბაზები) და ნაწილობრივ მაინც მოგვაცილებენ shared state-ის თავისტკივილს.

მეტყვით ალბათ, რომ სიზარმაცის და Thread-ების აზრზე არ ყოფნის გამოა ეს ყველაფერი გამოწვეული. მაგის უარყოფას არ დავიწყებ 🙂

ჯავასკრიპტის ხრიკები

ფოტო jstips-დან

jstips-header-blog

ადრე ჯავასკრიპტის ერთი ბიბლიოთეკის გარჩევა მომიწია, რომელიც მინიმიზატორში იყო გატარებული და მაგის აღდგენის პროცესში ის გზები შემხვდა რითიც მინიმიზატორები კოდის მოცულობას ამცირებენ. ყველაზე მეტად ცხადია ცვლადების სახელების ერთ-ორ ასომდე დაყვანა ამცირებს. მაგის გარდა კიდევ იყო რაღაცები, რასაც საღ გონებაზე პროგრამისტი არასდროს გააკეთებს, მაგრამ just for fun 😀 გთავაზობთ რამდენიმეს გამოსაცნობად:
(მერე ისეთებსაც, რასაც აზრი აქვს)

1. როგორ ჩაწერდით false-ს ორი სიმბოლოთი? true-ს?

!1 false, !0 true

2. როგორ შეამცირებდით ამ კოდს?

if (a) b();

ამათ?

if (!a) b();

if (a) {
b = 1;
c = 2;
}

&& და || ჯავასკრიპტშიც short-circuit ოპერატორებია, ანუ გამოსახულების შესრულებისას როგორც კი ცხადი გახდება შედეგი, შემდეგ აღარ გრძელდება დანარჩენი ნაწილების ევალუაცია, ფუნქციების გამოძახება, ა.შ. ამიტო if-ის მაგივრად შეგვიძლია დავწეროთ a&&b().
მეორე შემთხვევაში იქნება a||b().
მესამე შემთხვევაში დიდი არაფერი ხდება, უბრალოდ მინიმიზატორები ხშრად ერთ ბრძანებად აერთიანებენ ყველაფერს და მძიმით გამოყოფენ. მერე ბლოკების გაკეთება აღარ უწევთ.
if (a) b=1, c=2

3. ყველაზე მოკლედ როგორ შეამოწმებთ ასეთ რამეს ცვლადისთვის: თუ ცვლადი არის undefined, 0, false, “”, null ან NaN – ყველა ამ შემთხვევაში დააბრუნოს false, წინააღმდეგ შემთხვევაში true.
(ეს მინიმიზატორში არ იყო, უბრალოდ კოდში ხშირად კარგად გამომდგომია).

bool ტიპად გადაქცევით: result = !!a

4. როგორ შეამცირებდით ამ ნაწილს? ვთქვათ რაღაც arg-ის ვალიდაციას აკეთებთ და თუ არაა განსაზღვრული, default მნიშვნელობას ანიჭებთ. ესეც არ არის მინიმიზატორში.

var options = (arg) ? arg : [];

ჯავასკრიპტში && და || ცოტა არასტანდარტულად იქცევიან – boolean-ს კი არ აბრუნებენ შედეგად, არამედ იმ ოპერანდს, რომელიც გამოსახულების ბედს გადაწყვეტს.
მაგალითად 1 && 0 && false დააბრუნებს 0-ს.

შესაბამისად ის გამოსახულება უფრო ლამაზად შეგვიძლია ასე ჩავწეროთ

var options = arg || [];

4. ამას მინიმიზატორი არ აკეთებს, მაგრამ, ვთქვათ რიცხვის ქვემოთ დამრგვალება გვინდა (ნოლისკენ). როგორი იქნებოდა მაგის ყველაზე მოკლე და სწრაფი ვარიანტი?

მოდი ჯერ პირდაპირ დავწერ. ქვემოთ დამრგვალებისთვის არსებობს ფუნქცია Math.floor(), თუმცა ეს სტანდარტულად ამრგვალებს negative infinity-ისკენ. ანუ 12.6 გადავა 12-ში, მაგრამ -12.6 გადავა -13-ში. ამ კითხვის პასუხში ეგ შემთხვევა არ გაითვალისწინება (და ისედაც მე პირადად უფრო ხშრად ნოლისკენ დამრგვალება უფრო მჭირდება, რომ -12.6 გახდეს -12, რადგან ნიშანი სხვა დატვირთვით მაქვს ხოლმე).
ჰოდა გამოვიდა შემდეგი:

foo > 0 ? Math.floor(foo) : Math.ceil(foo)

თუ არ ვართ დარწუნებული რომ foo რიცხვი იქნება და NaN-ის მიღება არ გვინდა, მაშინ შემოწმებების დამატება მოგვიწევს:

typeof foo === 'number' && !isNaN(foo) && foo !== Infinity
? foo > 0 ? Math.floor(foo) : Math.ceil(foo) : 0;

ჰოდა ახლა ეს ყველაფერი ჩავწეროთ ორი სიმბოლოთი 🙂 foo-ს გარდა ცხადია

ბინარული ოპერაციები დაგვიჭრდება აქ, ორი ვარიანტი გვაქვს – ორმაგი ბინარული უარყოფა ან ბინარული ‘ან’ ნულთან.
~~foo
foo|0

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

5. 1000000, 0.0000023 და სხვა ბევრ ნულიანი რიცხვების დაპატარავება

1e6, 23e-7 – ნულების თვლა ცუდია 😀

ხატვა ვექტორებით და ყველაზე მოსახერხებელი პროგრამა

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

cupcake

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

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

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

pen_tool

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

vector_raster

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

რასაც ეგ აკეთებს ვიდეოში ჩრდილებისთვის ოვალური გრადაციებით (წრიული არა, ოვალური) და ლეველებით, ფოტოშოპში და ილუსტრატორში იყო შეუძლებელი. ახლა მგონი დაამატეს ილუსტრატორში, მაგრამ ჩემთვის ძველებურად მოუხერხებელია მაგის გამოყენება მოკლე დროში. კაი ხანი ვეძებე პროგრამა რაც ვიდეოშია – როგორც ჩანს იყო ეგეთი – Xara Xtreme ლინუქსისთვის. ვინდოუსისთვის არსებობს Xara Photo and Graphic designer

მას შემდეგ შემიყვარდა მისი სიმარტივე და მოსახერხებელი UI. აქაც არის ფენების ცნება.
ასე ვექტორებით ხატვის დროს მაუსიც საკმარისია ჩემი აზრით და დაფა არ არის აუცილებელი.

pearl

მერე იყო კიდევ რამდენიმე ნახატი, მაგრამ ბევრი დრო ვეღარ გამოვნახე მაგ სქილების დასახვეწად:

chocolate

ტექსტურებისთვის და სხვა დამუშავებისთვის ზოგჯერ ბოლოს ისევ ფოტოშოპში გადმომქონდა ხოლმე, მაგალითად ეს დრაკონი…

dragon

ისე, მაგ პერიოდში წარმოდგენა არ მქონდა როგორ წერდნენ პროგრამისტები ასეთ პროგრამებს. მერე მაგისტრატურაზე გავიცანი ერთ-ერთი ძალიან ძალიან მაგარი ლექტორი – გოდერძი ფრუიძე, რომელიც ამ წიგნით გვიკითხავდა კურსს – Computer Graphics and Geometric Modelling: Implementation & Algorithms

მართალია, ჩემი სიზარმაცის და მოუცლელობის შედეგად მხოლოდ ბეზიეს წირები მახსოვს, მაგრამ ზუსტად ეგ ბეზიეს წირების ალგორითმია თურმე, რითიც ვხატავთ ამ ფორმებს.

bezier

რატომ (არ) შესტკივათ ადამიანებს გული ერთმანეთზე

პოსტი პროგრამირებას არ ეხება და ახალიც არაფერი წერია შიგნით : )

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

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

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

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

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

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