Thoughts on the following changes to Controller usage

Create “Controllable” interface and make Spatial/render state implement it. Give Controllable


Add to “Controller” functions setParent(Controllable) and removeParent(Controllable)

Put a setParent and removeParent call inside setController and removeController

Remove null checking in main loop for Spatial public void updateWorldData(float time), and place null checking inside setController(Controller). Check isActive() before calling update(time) on a controller.

Change RenderState’s Controller from an array of controllers to an ArrayList.

Controllable interface goes along with oop design, because both basicly do the same thing with controllers. It also sets up a system where someone could easily for instance mark their own class to take a Controller ( like extend Vector3f and use a Controller on it)

setParent and removeParent remove redundant user created code where people have to both tell their controller what to control and also attach it to the same thing. I see this a lot in most of jME’s built in controllers. It seems more intuitive that you define the “verb” and attach it to the “noun” and the engine knows the “grammer”.

isActive checking is basicly a redundant huge if statement for most controllers. This removes the need for that, and may save overhead of an unneeded function call to Controller.update(float). It also supports the generic contract of isActive() in Controller and simplifies/genericizes the creation and use of Controller objects.

And I can’t see any reason why RenderState uses an Controller[] instead of an ArrayList considering most RenderStates have 0 and at -most- 1 controller.

Just ideas. Any thoughts?

Any input on this? The current system of controlling things doesn’t seem very right, I’ve noticed making my file loader. For example, to correctly animate full Quake3 models I will need to load multiple md3 files. Each of these files will be animated by a KeyframeController, -and- each of these vertex-animating objects will need to be spun/translated together to make correct animations. So basicly I will have 2-3 KeyframeControllers and 1 SpatialController all that need to be working in sync with each other.

To do this, I will create a ControllerController. It’s a controller that will Control the controllers. This lets a person change -one- controller for the Quake3 file and in effect change them all.

The problem with this is that I need these changes to make a generic ControllerController savable in a file, without giving 3 if statements for every single controller in the file. Right now, each controller would need 3 if statements.

  1. Is my parent a spatial, if so call this function
  2. Is my parent a renderstate, if so call this function
  3. Is my parent a ControllerController, if so call this function

    Very repeditive.

    A Controllable interface would solve this problem, and would still be backwards compadable. I’ld be able to make the changes myself if given the go-ahead. IMHO, it would make jME make more sense :slight_smile:

I like the idea but I think that the parent Controllers should know about the children Controllers.

I think your changes have a lot of merit. I don’t directly use this part of jME yet, so I can’t input much. Also, Badmi, could you expand more on your comment?

Well, parent "Controllable"s will know about Children "Controller"s just like we do now with Spatial

After reading the comment 3 times, then having Renanse explain it to me, I now understand. :slight_smile: Give me a break, I haven’t work on jME in a couple months.

I think it shows a good solution to a loose end that needed to be tied. I say run with it, see how it works (keep it local for awhile until you are sure it’s in good shape).

"renanse" wrote:
Also, Badmi, could you expand more on your comment?

I wanted to check that the folowing is the case.
"Cep21" wrote:
Well, parent "Controllable"s will know about Children "Controller"s just like we do now with Spatial