无标题
Chúng ta cần một mô-đun hoạt hình như thế nào?
Chúng ta cần một mô-đun hoạt hình như thế nào?
Chúng ta cần một module hoạt hình như thế nào?
Trong dự án gần đây, chúng ta gặp phải hàng loạt yêu cầu về hoạt hình cơ khí: máy đào mỏ, bơm hút nước, máy phát điện, máy lắp ráp, cánh tay robot… Tôi nhận ra module hoạt hình tự phát triển của chúng ta hiện không đủ sức đáp ứng yêu cầu này.
Ban đầu, khi thiết kế module hoạt hình cho engine, chúng ta dựa trên nhu cầu từ các game MMORPG từng làm, tập trung vào kiểm soát chuyển động của Avatar: đi bộ, nhảy, chạy, tấn công… Sau khi nhập dữ liệu hoạt hình từ phần mềm dựng, engine chủ yếu xử lý việc chuyển tiếp giữa các động tác - ví dụ như chuyển từ bước đi sang chạy bộ, đồng thời thêm các điều khiển runtime như xoay đầu nhìn theo vật thể, điều chỉnh bàn chân bám sát mặt đất thông qua module IK (Inverse Kinematics).
Tuy nhiên trong dự án này, đặc điểm hoạt hình hoàn toàn khác biệt. Các thiết bị cơ khí với hàng loạt bộ phận chuyển động độc lập đòi hỏi giải pháp khác biệt. Dù vẫn có thể dùng module xương hiện tại, nhưng cách dùng truyền thống lại gây lãng phí dữ liệu nghiêm trọng.
Lấy ví dụ một thiết bị cơ khí: bánh răng quay liên tục, piston di chuyển qua lại. Khi dựng xong tổng thể trong phần mềm chuyên dụng, chu kỳ hoạt hình toàn bộ thiết bị có thể lên đến hàng chục giây. Nhưng thực tế mỗi chi tiết chỉ có chu kỳ lặp lại cực ngắn - bánh răng quay 1 vòng trong 2 giây, piston qua lại trong 1 giây. Nếu xuất toàn bộ xương như thông thường, dữ liệu sẽ phình to do lặp lại vô số lần các chuyển động đơn giản.
Nếu theo phương pháp truyền thống, dung lượng dữ liệu sẽ phình to không kiểm soát khi số lượng máy móc tăng lên. Giải pháp chia nhỏ thiết bị thành từng bộ phận dựng riêng rồi ghép lại trong engine cũng không khả thi vì gây khó khăn cho nghệ sĩ dựng phim. Điều này đòi hỏi chúng ta phải nâng cấp module hoạt hình và editor engine để hỗ trợ đặc thù này.
Dù không đủ nguồn lực phát triển một editor xương chuyên sâu như Spine (ngay cả khi làm được cũng khó sánh với phần mềm chuyên dụng 3D), chúng ta nên hướng đến giải pháp “tối giản thông minh” - một editor tổ hợp hoạt hình với chức năng giới hạn nhưng đủ dùng.
Tôi hình dung nghệ sĩ có thể tạo hoạt hình từng bộ phận riêng biệt trong phần mềm dựng, đặt chúng lên bộ xương tổng thể, sau đó import từng hoạt hình cụ thể vào engine. Khi biên tập, mỗi đối tượng sẽ có nhiều track hoạt hình, mỗi track chứa hoạt hình một chi tiết. Trên từng track, có thể thêm nhiều đoạn lặp với thời điểm bắt đầu và tốc độ phát khác nhau. Runtime, engine sẽ tính tổng các track để tạo thành hoạt hình hoàn chỉnh.
Áp dụng logic này cho nhân vật, các động tác cục bộ như lắc đầu, chớp mắt, vẫy tay đều có thể xuất riêng. Mỗi hoạt hình cục bộ được dựng trên bộ xương đầy đủ nhưng hầu hết khớp không hoạt động. Vì tất cả đều dùng chung bộ xương nền, kết quả tổng hợp chỉ cần cộng dồn đơn giản.
Đối với cơ cấu máy móc, đa số chuyển động là cơ bản: quay đều, dao động điều hòa… Các chuyển động này chỉ tác động lên khớp đơn. Thay vì dựng thủ công trong phần mềm bên ngoài, chúng ta có thể tạo tự động trong editor. Với nền tảng IK đã có, chỉ cần thêm tính năng liên kết tương tác trong editor là có thể tự động phát sinh chuyển động phối hợp. Chẳng hạn khi điều chỉnh piston, hệ thống tự tính toán chuyển động lan truyền lên các bộ phận liên kết. Các quỹ đạo tính toán trước này sẽ được lưu lại khi dựng, thay vì xử lý runtime, giúp giảm tải hiệu năng.
Dù editor tự phát triển không linh hoạt bằng phần mềm chuyên dụng, nhưng lại giúp tối ưu luồng dữ liệu, tránh được phức tạp trong xuất nhập định dạng. Biết rằng dữ liệu 3D vốn khó chuẩn hóa hơn 2D, và trước đây chúng ta đã tiêu tốn nhiều công sức cho việc tương tác giữa engine và phần mềm dựng. Giải pháp mới sẽ giúp tập trung vào sáng tạo mà không vướng vào “chiến tranh định dạng”.