User talk:Wendy

From K-3D

Fantastic project writeup! Some minor nits:

Any object that needs to save state is a "document" plugin by-definition. The simulation-control plugin will undoubtedly have user-modifiable state (Global ERP, Global CFM, Gravity magnitude and direction, etc), so it will be a document plugin.

As you correctly identify, a "physics-enabled" node is really a transform node - one that produces a transformation matrix as output. However, rather than creating multiple "physics-enabled" nodes for different types of mesh, you should simply make the mesh an input to the node. With this in mind, a "physically accurate" pipeline (one where the same mesh is used for rendering and collision-detection) might look like:

This way, you only have to create one "physics-enabled" node, and it can be used with all mesh sources. Of course, to get started you would simply ignore the mesh input and hard-code something, then move to handling specific types of input (cubes, spheres), then move to a completely general solution that converts the mesh input to triangles.

A second advantage to this approach is that you introduce a new degree of flexibility - users don't have to use the same mesh for collision-detection that they use for rendering:

In this scenario, users could provide a low-poly-count mesh to speed collision detection, or an out-and-out different mesh for special-effects: using a scaled-up mesh to represent a "force field" surrounding the original mesh comes to mind.

Tshead 19:45, 2 April 2008 (MDT)