Unified Solver Framework for Graphical Simulations
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing graphical dynamics simulators are inflexible and require modification of internal logic to accommodate new objects and interactions, making it difficult for third parties to expand or modify them, especially in the special effects film industry where no solver meets production expectations, and current solvers introduce biases when handling multiple interactions.
Innovation Solution
A general and flexible solver system that treats simulation as an ordered sequence of steps involving objects and their relationships, allowing animators to directly control and modify the logic by querying each object and relationship for tasks and merging them into a sorted list for execution.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a solver is hard coded for a fixed number of objects and their possible interactions, then the solver structure is simple and manageable, but it becomes difficult to expand or modify the solver to accommodate new objects and interactions
Solution Approach 1:
The patent implements a universal solver framework that can handle multiple types of objects (rigid bodies, soft bodies, particles, fluids, cloth, hair) and their interactions through a unified architecture. The solver uses a scene graph data structure and a task-based execution model that allows different object types to be processed through the same solver infrastructure, eliminating the need for separate hard-coded solvers for each object type while maintaining structural simplicity.
2Adaptability or versatility
If the internal logic of the solver is modified directly to add new objects and interactions, then the solver can be expanded, but third parties without source code access cannot modify the solver
Solution Approach 1:
The patent implements a self-service modification mechanism where animators and users can add custom objects and interactions through a scripting interface without needing to access or modify the source code. The solver automatically integrates user-defined objects into the scene graph and executes their tasks through the standard task-based framework, allowing third parties to extend solver functionality while the core solver logic remains intact and protected.
3Reliability
If multiple solvers are used for different effects (rigid body motion, hair movement, pouring liquids, cloth modeling), then each effect can be simulated with specialized logic, but one solver always takes precedence over others introducing unwanted biases
Solution Approach 1:
The patent merges multiple specialized solvers into a single unified solver that processes all object types through a common task-based framework. The scene graph organizes all objects and their relationships in a unified data structure, and the solver executes tasks from all object types in an interleaved manner, ensuring that rigid body, soft body, particle, fluid, cloth, and hair simulations all contribute equally to the final result without any single solver type taking precedence or introducing bias.
4Adaptability or versatility
If a single general solver is used to allow many different objects to interact, then proper interactions between different object types can be achieved, but the solver becomes more complex to manage
Solution Approach 1:
The patent segments the solver functionality into discrete, manageable tasks that can be independently defined and executed. Each object type (rigid body, soft body, particle, etc.) contributes its own tasks to the scene graph, and the solver executes these tasks in a systematic interleaved sequence. This task-based segmentation allows the complex interactions between different object types to be managed through modular, independent task units rather than complex monolithic logic.
Data Source
AI summary
A system is described that treats a solver as an ordered sequence of steps involving the different objects that have to be simulated and relationships between them. Tasks and the order of the tasks are obtained from each object and relationship. The tasks are merged into a sorted list. The solver traverses the list and passing each task to a corresponding object and relationship where the objects are interleaved during processing. The object or relationship then executes the task.