Smalltalk Three Dee

ST3D is a ThreeDeeEngine? I've been playing with for the past few months.

I'm getting really sick and tired of ST3D. It's not enough that it's weak (low frame rates, no particle engine, no text) and cryptic (requiring voodoo coding). No, the biggest problem by far is the framework itself which makes it impossible to organize things the way I want. The framework is built on the mindset that the scenegraph is static and that the objects within the scene are only coupled to each other in a way that a render "manager" can understand.

It's based on the incorrect assumption that all information about the scene can be and should be conveyed to the renderer. The correct way to do things is to convey all the necessary information about the renderer (camera, lights, etc) to the scene's components and let them render themselves. That way, objects can choose for themselves the level of detail they will be rendered at instead of having the scene graph be "adjusted" all the time. They can also choose their level of translucence in response to the user's level of interest (as indicated by the camera and mouse pointer). They can even have more complex behaviours like figuring out their own names, visibly destroying themselves when what they represent gets destroyed, et cetera.

One of the most obvious (but not the worst) consequences of ST3D's mindset is that CcSwitchNode isn't a subclass of CcPart, so it's impossible to build a complex object with many representations (all children of a SwitchNode) and then rotate that object by rotating the SwitchNode. In fact, it's impossible to make a SwitchNode a child of a CcPart and then rotate the part (it causes a DNU when the part rotates). This is completely wrong.

And it's only the most superficial example. A much, much bigger problem is that instead of objects (eg, balls in CoolPool) choosing the level of detail they will be rendered at themselves based on information which the renderer provides, instead you've got some voodoo mumbo-jumbo with an #adjustBallQuality method buried in PgPoolGameShell >> onViewOpened. This is NOT object-oriented, this is imperative!

In more general terms, the idea that information should flow from the user to the manufacturer (in this case, the objects being rendered to the renderer) is contradicted by massive amounts of research led by EricVonHippel and 3M corporation. The direct consequence of this requirement is less innovation by the users. And since programming, as opposed to cut-and-paste, is all about innovation (creating new objects to do new things) it follows that this requirement inhibits programming.

-- RichardKulisz

CategoryThreeDee CategorySoftwareTool CategorySmalltalk