Object-Oriented Shader Framework for OpenGL API Abstraction

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Developers face difficulties in manipulating shaders within low-level, non-object-oriented APIs like OpenGL due to the need for a deep understanding of these APIs, limiting their ability to fully utilize 3D graphic potential without extensive knowledge of intricate coding.

Innovation Solution

An object-oriented framework allows developers to manipulate shaders using object-oriented code, mapping it to non-object-oriented APIs, enabling access to powerful tools without needing to learn the intricacies of the low-level API, such as using Objective-C to interact with the OpenGL API.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If developers use low-level non-object-oriented APIs like OpenGL to manipulate shaders, then they can access powerful graphics tools, but they need deep understanding of the API intricacies

Engineering Contradiction:
Improveaccess to graphics toolsVSAvoidlearning curve
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent introduces an object-oriented framework that acts as an intermediary layer between developers and low-level OpenGL APIs. This framework provides high-level abstractions such as shader programs, vertex buffers, and texture objects that automatically translate object-oriented operations into corresponding OpenGL function calls, eliminating the need for developers to learn complex API intricacies while maintaining access to powerful graphics tools

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the complex OpenGL API into manageable object-oriented components. By dividing the graphics programming task into distinct objects (shader programs, buffer objects, texture objects) with specific responsibilities, the framework simplifies the overall complexity and makes graphics programming more accessible to developers without requiring deep knowledge of the underlying low-level API

Inventive Principle:
Principle #1Segmentation

2Productivity

If developers use non-object-oriented code to manipulate shaders, then they can control shader functionality, but the code manipulation becomes difficult

Engineering Contradiction:
Improveshader manipulation capabilityVSAvoidcode manipulation difficulty
Core Design Contradiction:
ProductivityVSEase of operation

Solution Approach 1:

The patent replaces the mechanical, function-call-based OpenGL API with an object-oriented system that uses intuitive method calls and property assignments. Instead of manually managing shader compilation and linking through multiple OpenGL functions, developers can manipulate shaders through object methods such as setting uniform variables, binding textures, and configuring buffer data, which are automatically translated into the necessary low-level operations

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Solution Approach 2:

The object-oriented framework serves as a mediator that handles the complexity of shader manipulation internally. When developers interact with shader objects through simple method calls, the framework automatically manages the underlying OpenGL operations including shader compilation, program linking, and uniform variable binding, making code manipulation easier while maintaining full shader control capability

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS9804900B2Manipulating shaders with object-oriented programming
Publication Date: 2017.10.31 APPLE INC
  • US9804900B2 patent drawing
  • US9804900B2 patent drawing
  • US9804900B2 patent drawing

AI summary

Shader manipulation via object-oriented instructions is disclosed. In various embodiments, a processor may receive object-oriented instructions. Upon receiving the object-oriented instructions, the processor may match the object-oriented instructions to uniforms of a non-object-oriented application programming interface (API) that may interface with a graphics processing unit (GPU). Further, the processor may modify the uniforms based at least in part on the received object-oriented instructions. Additionally, the processor may implements the uniforms after modification at a determined time.