Pause and resume the GLCanvas animator; zoom and adjust clipping with mouse wheel

[cm8]

With the current state of the code the render loop generates frames as long as the window is open, even when there is no user input and no changes in the 3d models. If the scene has lots of objects this wastes lots of cpu / gpu time. The patches in the pull request pause the GLCanvas animator after update events to the scene have settled, this means after all user input and data changes have been processed. The animator is resumed as soon as new events are detected / processed.

On normal workflows this will give cpu / gpu chance to cool down and thus prevent possible frequency down-scaling in response to overheat conditions, so this is not strictly an energy-saving measure but an aid to ensure persistent performance.

Unrelated to these performance related changes, the following noteworthy functional changes, bound to and controlled by mouse wheel movements, have been introduced:

• zooming by modifying the camera's field of view (on y-coord) setting
• adjust zFar (i.e. distant clipping of render objects) if CTRL is pressed and held while wheel is used

For both actions the rate of change is higher if SHIFT is pressed in addition. A middle mouse button click will reset zoom, if CTRL is held zFar, to default value.

---

Unrelated to this pull request, interested readers might also consider the (work intensive!) feasability of exchanging the current backend (JOGL) by the alternatives:

• https://www.lwjgl.org/ (github)
• https://threejs.org/ (github)
• https://www.mapbox.com/mapbox-gl-js/api/ (github) (claimed to be BSD licensed, but advertised with tight integration into the mapbox ecosystem, if unusable without that ecosystem, an access-token needs to be applied for, unless that's for technical reasons, it sounds unfree)

LWJGL seems more like a drop-in-replacement to JOGL. The latter two are browser based and suggest opening a viewport in a browser window, that communicates with JOSM acting as an object server on localhost (similar to the remote control plugin). It is doubtful if much of the event flow currently coded may remain untouched if this is to be realized, but it may be appealing in some respect (i.e. less code to setup the canvas, less driver worries, immediate support for geojson, etc., but bound to a working html5+webgl browser). On a second thought, since much of the client code may need to be rewritten (javascript), it might make more sense to start a new project for such endeavour all together (not saying I will!).

[cm8]

Please take your time to carefully review this set of changes. There might be some glitches in need of fixing, like last pull request. Known already:

• commits do not yet use formatter setting + save actions you recently uploaded to doc/
• at least one additional menu action needs to implement Resumer (like MoveCameraAction does)

I'll push another commit to solve the formatting issues (concerns 25 files) in the next couple of days. Hence, if you review before, please neglect formatting issues.

[cm8]

Should be in shape now, I issued the pull request a little too early...

Commits 11df9a5 through 82bde53 used PERSP_VIEW_ANGLE in updateViewport(Camera camera) without the getter, which led to a regression in kendzi3d-plugin for these three commits.

Commit e6f35b9 and onward fixed this and use getFovy() in updateViewport, which means if getFovy() is overriden in subclasses and updateViewport is not, then the latter is ok for all classes.

TODO: The last commit fixed size of ArrowEditor when the viewport uses a non-default view angle (when zoomed), but

• the sphere used for intersection (mouse hover/click detection)
• the distance between small box editor (roof) and arrow editor (height)

need fovy ratio correction applied as well. done, see 86baefa

[kendzi]

I didn't start review yet. So first some comment on your post to give you some background. I'm aware jogl is "little" out of date nowadays anyway, it is still working. The more concerning issue is that my application is using old outdated opengl2 and now we have modern opengl with shaders. Whole model stuf is basing on some example classes found in some very old tutorial for opengl so we have that Model class with arrays, but its build by builders in code. The screen composer is ugly, basically allow only to set location in X-Z and no support to any transformation. And most likely some other thing which I completely forgot. So long time ago I start to think how to clean up it all that. My summary was to use some ready engine to fix all or at least most of problems. I even choose Ardor3D as the best fitting as it had out of box support for large scale ground model. I even do some initial work and... then I found that Ardor3D is dead. I think that demotivated me and any migrations stopped completely. I still think it is worth to migrate to some engine like jMonkey. Otherwise, switch to lwjgl but then composer, model definition, need to be improved. Engines usually gives nice set of onscreen components and allows selections out of box. About webgl it is nice feature but main goal for Kendzi3d app is helping with adding 3d related feature to openstreetmap. Actually few of user would like to have it even more integrated with josm and display 3d preview inside josm window not in separate one. In past I had idea to use webgl as some form of preview for users whose use js online editor. The ida was to add some wizzart which appears when user select building. That wizzart show parameters which can be changed like color shape of row similarly as it has been done in presets in josm. In parallel that single building will be send to backend service which generate mesh model and send it back to frontend. There could be preview. I even make simple demo app [1], it use raw webgl and downloads data from overpass-api. I show that concept long time ago but there was no response from community :(

[1] - http://openstreetmap.pl:8080/quad.html?lat=52.239403463102796&lon=21.045641899108887&size=200

[cm8]

You're right. WebGL is not an option, it would be a topic for a whole different project as it would change the kendzi3d plugin that users are familiar with too much.

I think we should only take very small steps and not pull in new dependencies (except for LWJGL maybe, but this is not a priority). In my mind we need to focus on continuity, i.e. do not introduce regressions and improve stability / code readability when changing the code.

The most important priorities (imho) are

• make the render loop more efficient (partly addressed by this pull request, but ideally only objects should be calculated that are actually seen in the viewport)
• address interoperability issues (see work in progress bits in rework_UpdateDataEvent_handling branch) - it is problematic, that every NodeMove triggers a full re-render in the 3d window, this degrades performance to the point that the 2d map editing becomes unusable, esp. for larger datasets

I was not aware of Ardor3d, but I think it is less important to add new editing functions to the 3d window. More important use case is to be able to see the impact of tag and geometry changes made in the 2d map window -> this is why the 3d window should not block (degrade) the workflow going on in the main josm window (maybe we should only render the selected model as long as the mouse is dragged in josm 2d map window, as long as the render loop is too inefficient for larger datasets).

As long as the plugin does not address this issue, the workflow is rather: Close 3d window, edit 2d map, open 3d window, check 3d model, close 3d window, edit 2d map, .. and so on.