Allow camera derivement

Contribution Depot
1

Problem: std camera cant be a camera-extension. if there isn’t any reason for that (cant see one) it is better to let actual creation of objects become overridable by subclasses.

please change:

in Application.java

private void initCamera(){
cam = new Camera(settings.getWidth(), settings.getHeight()); …

­­­­­­‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
into

protected Camera doCreateCamera (int width, int height)
{return new Camera(width, height); }
private void initCamera(){
cam = doCreateCamera(settings.getWidth(), settings.getHeight()); …

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

2

There is no reason to extend Camera. You’d probably have to explain why you want to even do this.

3
@pspeed said: There is no reason to extend Camera.

Err… simply because i want to have more control and everything inside the object responsible? From my perspective, there is no reason to not allow an extension. As long as it derives from camera, no code on JME-side is affected. I need multiple cameras with some special features that i already implemented into a Camera extending class, but i cant figure out how i can my QCamera extends Camera setup as Application.camera. I neither can overload initCamera() nor can i simply redefine the field.

So perhaps it is you that should explain why Camera shouldnt be extended, because if there is no reason to not do it, there is no justification to forbid it, it’s – finally – an engine and not a top-security-secret-blackbox…

4

At the risk of making you even madder (not a great way to get help by the way):

JME relies on Camera to behave a certain way and it already incorporates the functionality needed to do that. It’s one of the more core classes which is why it’s in renderer. Modifying it’s behavior could have severe or disastrous effects.

…and if you are not modifying it’s behavior then there is little reason to extend it. Adding a few data fields or non-Camera related behavior doesn’t count. That implies a “has a” relationship not an “is a” relationship.

In general, composition should be preferred over inheritance and JME tries to push that wherever possible. Since there has never been a need to compose anything into a Camera then it doesn’t have the same AppState or Control features as the other more user-level classes.

5

"

@pspeed said: At the risk of making you even madder

You didnt. But it’s perhaps a language-thing, i aint no native speaker.

Of course, i can work-around with a has-a relationship, but its rather complicated and would involve setting up a map connecting every camera i use with a dedicated controller, so it’s a classical is-a relation that i could press into a has-a relation. I just wanted to suggest an improvement for free.

And if someone changes behavior of Camera, it’s his responsibillity, isnt it? My complete setup is – fasten seat belt – 5D and i have a couple of InsaneToReal()-functions dealing with translation into 3D-space. Having a Camera understanding Hyperspace vectors directly without a controller like FlyCam would simply be the correct approach from a modern oo-perspective, because i would have to keep track of my camera-to-extension mapping but let java simply do its job, because keeping track of class-relationsships is its job and not mine.

BTW: you’ll never know what people do with your tech once you publicated it, so you should implement useful defaults (Camera FlyCam, root/gui-node etc…) but NEVER restrict anything without serious reasons.

Computer histroy if full of today ridiculous sounding claims that have been meant quite serious at their time…

@pspeed said: composition over inheritance

Ok, thats a different story, there are some jme3-classes that dont even split object-access and generic functionality into reusable public static and protected/private object modifications. (Awtloader, Abstractbox,…) That would make COI possible…

Disclaimer: Please dont interpret any emotions into this text. I dont use them in coding.

6
@rhavin said: you'll never know what people do with your tech once you publicated it, so you should implement useful defaults (Camera FlyCam, root/gui-node etc…) but NEVER restrict anything without serious reasons.
That exactly is the serious reason ^^ The jMonkeyEngine project has been around long enough (10 years) for us to know there simply is no good reason to extend some classes. You can just as well extend your own class that wraps the object in question or change the source code. Lots of libraries that do things in lots of different ways "just because its possible" already has been identified as a problem, lets see if the restrictive class layout really will be, I strongly doubt so. The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there's emotes that hint otherwise or there's an increased use of exclamation marks and all-capital words.
7

The application code does not own the camera, it is owned by the renderer. Or put another way, the camera class is used as a shared memory between your code and the renderer.
So, controlling the camera is encoding some application specific behavior in a class and communicating that to the renderer (i.e. render from this point-of-view this frame). This communication is through the camera class exposed API. So think of it more as message passing than owning the state of the camera.
The abstraction you want to work with is encoding behavior - how to control the camera. More like a director than a camera-man (or an actual camera). In that context a control-class seems the good OO-way, call it has-a relation of you want. Switching behavior is switching the active control-class, not switching the camera instance or even encoding a lot of if-statements into the camera (or chain of commands or whatever).
Hope that makes sense.

2 Likes