首先，现在甚至不用担心平台独立性。等到你对你的架构有了更好的想法。
执行大量的绘制调用/状态更改是缓慢的。在引擎中这样做的方式是，你通常希望有一个可以绘制自己的可渲染类。此可渲染将关联到它所需要的任何缓冲区（例如，例如，顶点缓冲器）和其他信息（如顶点格式、拓扑、索引缓冲器等）。着色器输入布局可以与顶点格式相关联。
您可能希望有一些基本的geo类，但将任何复杂的内容推迟到处理索引tris的某种类型的网格类。对于高性能应用，您可能希望在着色管道中对类似输入类型进行批量调用（以及可能的数据），以最大限度地减少不必要的状态更改和管道刷新。
着色器的参数和纹理通常通过与渲染对象相关联的某种材质类来控制。
场景中的每个可渲染对象本身通常是分层场景图中节点的组件，其中每个节点通常通过某种机制继承其祖先的变换。您可能需要一个使用空间分区方案的场景剔除器来进行快速可见性确定，并避免视图外事物的绘制调用开销。
大多数交互式3D应用程序的脚本/行为部分紧密连接或挂钩到其场景图节点框架和事件/消息传递系统中。
这一切都适合在一个高层次的循环，你更新每个子系统的基础上的时间和绘制场景在当前帧。
显然，有大量的小细节被遗漏了，但它可能会变得非常复杂，这取决于你想要的概括和性能以及你的目标是什么样的视觉复杂性。
你的问题draw(renderable)，vs renderable.draw()或多或少是无关紧要的，直到你确定所有的部分如何组合在一起。

**[更新]***在这个空间工作了一段时间后，一些人增加了见解 *：

话虽如此，在商业引擎中，它通常更像draw(renderBatch)，其中每个渲染批次是以某种有意义的方式对GPU同构的对象的聚合，因为迭代异构对象（通过多态性在“纯”OOP场景图中）并逐个调用obj.draw()具有可怕的缓存局部性，并且通常是GPU资源的低效使用。采用面向数据的方法来设计引擎如何以最有效的方式与其底层图形API进行对话是非常有用的，尽可能多地批量处理，而不会对代码结构/可读性产生负面影响。
一个实用的建议是使用一种朴素的/“纯粹的”方法来编写第一个引擎，以真正熟悉域空间。然后在第二遍（或可能重写）中，关注硬件：比如内存表示、缓存局部性、流水线状态、带宽、批处理和并行性。一旦你真正开始考虑这些事情，你会意识到你最初的设计大部分都已经脱离了窗口。很有趣。

我认为OpenSceneGraph是一种答案。看看它的implementation。它应该为您提供一些关于如何使用OpenGL，C++和OOP的有趣见解。

下面是我为物理模拟实现的，它工作得很好，并且在很好的抽象级别上。首先，我会将功能划分为类，例如：

• 对象-保存所有必要对象信息的容器
• AssetManager -加载模型和纹理，拥有它们（unique_ptr），返回指向对象资源的原始指针
• 渲染器-处理所有OpenGL调用等。，在GPU上分配缓冲区并将资源的渲染句柄返回给对象（当希望渲染器绘制对象时，我调用渲染器，给它模型渲染句柄，纹理句柄和模型矩阵），渲染器应该聚合这些信息以便能够批量绘制它们
• 物理-使用对象沿着资源（尤其是顶点）的计算
• 场景-连接所有上述内容，也可以保存一些场景图，这取决于应用程序的性质（可以有多个图，用于碰撞的BVH，用于绘制优化的其他表示等）。）

问题是GPU现在是GPGPU（通用GPU），因此OpenGL或Vulkan不再只是一个渲染框架。例如，在GPU上执行物理计算。因此，renderer 现在可能会转换为类似 GPUManager 和它上面的其他抽象。此外，最佳的绘制方式是一次调用。换句话说，整个场景的一个大缓冲区也可以通过计算着色器进行编辑，以防止过多的CPU<->GPU通信。