Binary Asset Workspaces for Version Storage and Cross-Platform Rendering
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Collaboration in computer graphics is hindered by the inefficiency of storing multiple versions of large binary assets and inconsistencies due to the use of different tools and platforms, leading to excessive storage use and confusion among artists.
Innovation Solution
A system with separate workspaces for asset creation and modification, linked to a central repository, uses central build automation to render assets consistently across platforms, reducing storage inefficiencies and improving collaboration by ensuring assets are complete before being stored in the repository.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of information
If multiple versions of large binary assets are stored during collaboration, then asset versions can be preserved for review and comparison, but storage space is excessively consumed
Solution Approach 1:
The system segments the storage of binary assets by separating work-in-progress files in workspaces from completed assets in the central repository. Only completed assets are permanently stored in the repository, while incomplete versions are discarded after transfer, reducing storage requirements while preserving version history for review.
Solution Approach 2:
The system performs preliminary validation and rendering of assets in workspaces before transferring them to the central repository. This ensures only complete and functional assets are permanently stored, avoiding unnecessary storage of incomplete versions while maintaining the ability to review historical versions.
2Adaptability or versatility
If assets are rendered on multiple platforms using different tools, then versatility and adaptability are improved, but inconsistencies and rendering differences occur
Solution Approach 1:
The system introduces a central build automation system as an intermediary that standardizes the rendering process. This intermediary component ensures consistent rendering across different platforms by using a unified rendering pipeline, while still supporting multiple target platforms through configuration rather than requiring different tools.
Solution Approach 2:
The system manages platform-specific rendering by changing configuration parameters rather than fundamental rendering processes. The central build automation system adjusts rendering parameters to match different platform requirements while maintaining a consistent base rendering pipeline, ensuring both versatility and consistency.
3Adaptability or versatility
If artists use various tools for asset creation, then creative flexibility and tool specialization are improved, but collaboration efficiency decreases due to inconsistencies
Solution Approach 1:
The system segments the workflow into creation phase (using various specialized tools) and review phase (using standardized rendering). Artists can use their preferred tools during creation, but all assets must pass through the standardized central build automation for consistent rendering and review, improving collaboration efficiency.
Solution Approach 2:
The central build automation system acts as an intermediary between different creation tools and the final rendering output. This intermediary standardizes the workflow by accepting assets from various tools and producing consistent renders across all platforms, eliminating collaboration inefficiencies while preserving tool flexibility.
Data Source
AI summary
A method of creating, modifying, and rendering a binary asset is disclosed. A first workspace for a first binary asset can be generated. A first version of the first binary asset can be saved on the first workspace. A modification to the first binary asset can be received. A second version of the first binary asset with the modification can be saved on the first workspace. The first version of the first binary asset and the second version of the first binary asset can be rendered based on a selected platform. The second version of the first binary asset can be saved to a repository. The first workspace can be deleted.