AI რეჟისურა და ხარისხი

წყაროდან სცენამდე: რატომ სჭირდება გენერირებულ ვიზუალურ ნოველას რეჟისორი

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

ლიტერატურული ადაპტაციისას ვნახე, როგორ იცვლიდნენ პერსონაჟები ზომას, ეკიდნენ ჰაერში, იცვლებოდა იგივე სანაპირო მეზობელ კადრში, იწყებოდა მუსიკა თავიდან და მნიშვნელოვანი ბეჭედი ხელს, თითს ან რაოდენობას იცვლიდა. ამიტომ შევქმენი ტექსტის ანალიტიკოსის, მხატვრის, კომპოზიტორის, MCP აგენტის, ტექნიკური ვალიდაციისა და AI რეჟისორის pipeline.

![Romergo-ს flow წყაროდან, სიუჟეტის სტრუქტურიდან და უწყვეტობის ბიბლიებიდან assets, MCP assembly და director review-მდე](direction-flow)

1. წყარო სურათზე წინ დგას

შესავალი შეიძლება იყოს ტექსტი, HTML, Markdown ან ტექსტური PDF. ჯერ ფიქსირდება ენა, გამოცემა, თავების რიგი და უფლებები ორიგინალზე, თარგმანსა და ილუსტრაციებზე. romergo_inspect_story_source და romergo_plan_story_source project-ის ჩაწერის გარეშე ქმნის inventory-სა და preview-ს. ხაზოვან წყაროს გამოგონილი განშტოებები არ ემატება.

სცენა იყოფა ადგილის, დროის, მონაწილეების ან მოქმედების რეალური ცვლილებით. თითოეული ინახავს ზუსტ sourceExcerpt-ს და visual contract-ს: ვინ არის, ვინ ლაპარაკობს ან უსმენს, რას აკეთებს, სად იყურება, რას ეყრდნობა, რომელი სახე უნდა დარჩეს mobile crop-ში და რომელი დეტალი აკავშირებს მეზობელ კადრებს.

2. პერსონაჟებს, ადგილებსა და props-ს მეხსიერება აქვთ

დამოუკიდებელი text auditor ნაწყვეტს ხელახლა კითხულობს და ურთიერთქმედების ყველა ნივთს იღებს. თითოეულ prop-ს აქვს canonical description, უცვლელი ნიშნები, მფლობელი, მდგომარეობა, ხილვადობა და რაოდენობა. ოქროს ბეჭედი გადაცემამდე, გადაცემისას და შემდეგ იგივე ერთი ბეჭედი უნდა იყოს.

Scene map, character და location bibles, prop ledger, asset manifest, generation jobs და audit reports სტაბილური ID-ებითა და source hash-ებითაა დაკავშირებული. ისინი ნაწარმოებს არ ცვლის; აგენტებს შორის გადაწყვეტილებების დაკარგვას უშლის ხელს.

3. კომპოზიციის ორი რეჟიმი

baked_narrative პირდაპირი დიალოგის გარეშე პერსონაჟებს ფონში აერთიანებს, რათა მიწა, საწოლი, ქვა ან სკამი ბუნებრივ საყრდენად დარჩეს. layered_dialogue საუბრისთვის ფონსა და speaking/listening sprites-ს აცალკევებს და სწორ სახელსა და portrait-ს ინარჩუნებს. Hybrid mode შესაძლებელია, მაგრამ მხოლოდ როგორც მკაფიო გადაწყვეტილება.

გენერაცია ზუსტ ნაწყვეტს, location bible-სა და prop-ის მიმდინარე მდგომარეობას ეყრდნობა. File QA ამოწმებს ანატომიას, transparency halo-ს, მოჭრილ სილუეტს, შემთხვევით ტექსტსა და განმეორებად მცენარეულობას. ცალკე PNG მაინც ვერ აფასებს საბოლოო დადგმას.

4. MCP აწყობს რედაქტირებად project-ს

დამტკიცებული assets draft-ში შედის. MCP tools ქმნის თავებს, სცენებს, ტექსტს, გადასვლებს, timeline-ს, მუსიკასა და placement-ს. შემდეგ agent კითხულობს მდგომარეობას romergo_get_chapter-ით, უშვებს romergo_validate_project-ს და ასრულებს romergo_verify_quest_change-ით. Tool-ის წარმატებული პასუხი persisted runtime-ის მტკიცებულება არ არის.

5. AI რეჟისორი ტექსტსაც კითხულობს და Player-საც უყურებს

Final review მთელ თავს desktop-ზე და 390 × 844-ზე თამაშობს. Scene entry-ის 0, 100 და 500 ms კადრები პოულობს შავ ეკრანს, თეთრ ფონსა და ძველ sprite-ს transition-ში. რეჟისორი screenshot-თან ერთად იღებს ზუსტ ტექსტს, contract-ს, მეზობელ სცენებსა და prop history-ს.

თუ ფონი სწორია, მაგრამ sprite ჰაერშია, MCP-ით position, scale, layer ან crop იცვლება — recompose. თუ არასწორი პოზა ფონშია ჩახატული, საჭიროა regenerate. ახალი render დამოუკიდებელ review-ს თავიდან გადის.

შეცდომა 1. გმირი გმირზე დაჯდა

Mobile crop-ში Gray-ს layer მძინარე Assol-ს დაემთხვა. „ორივე ჩანს“ მართალი იყო, მაგრამ არასაკმარისი. ახლა ყოველი viewport ამოწმებს საყრდენს, სიღრმესა და სხეულების გადაკვეთას.

![Mobile კადრი, სადაც Gray მძინარე Assol-ს ეფარება](direction-failure-overlap)

შეცდომა 2. ერთი ბეჭედი რამდენიმე გახდა

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

![ბეჭდის არასწორი მდებარეობის ცხრა ამონაჭერი: თითს აცდენილი, გვერდით ჰაერში ან სხვა თითზე](direction-failure-ring)

შეცდომა 3. პერსონაჟები ფანჯარაში იყურებოდნენ ტექსტის საწინააღმდეგოდ

ტავერნის კადრი ლამაზი იყო, მაგრამ წყარო ამბობდა, რომ კაცები ფანჯარას ზურგით ისხდნენ. არასწორი მიმართულება სურათში იყო baked და placement-ით ვერ გამოსწორდებოდა — regeneration სჭირდებოდა.

![ტავერნის სცენა, სადაც პერსონაჟები ტექსტის საწინააღმდეგოდ ფანჯარას უყურებენ](direction-failure-window)

სურათების კრებულიდან განმეორებად რეჟისურამდე

პირველი tests მხოლოდ file, alpha, bounds და graph-ს ამოწმებდა. საიმედოობა გაჩნდა, როცა მოთხოვნები ზუსტი ტექსტიდან გამოვიდა, Player controlling surface გახდა, review-მ მეზობელი სცენები და ნივთების ისტორია მიიღო, ხოლო ყოველ failure-ს repair-ის არჩევა და დამოუკიდებელი rerun დაევალა.

ეს ყველაფერი ჯერ კიდევ შორსაა სრულად ავტომატური generation-ისგან. ადამიანის ვიზუალური გამოცდილება, პროფესიული ცოდნა და გრძნობა წარმატების მთავარ კრიტერიუმად რჩება; არ მგონია, მალე შევძლო generation-ს სრულიად autonomous ვუწოდო.

მიუხედავად ამისა, არსებული pipeline უკვე ბევრ საათს მიზოგავს და იმედი მაქვს, სხვა ავტორებსაც დაუზოგავს დროს. დრო შემოქმედებისთვის დავიტოვოთ, რთული ტექნიკური რუტინა კი scripts-სა და AI-ს ვანდოთ. ასე იქცევა ტექსტი, HTML ან PDF ერთიან ნაწარმოებად და არა სურათების კრებულად.

დაბრუნება dev-ბლოგში