Those controls should run automatically when the height of the terrain is modified. Calling setHeight() on those quads will trigger the controls to update those areas. So, maybe those controls aren’t there to begin with or were removed? It’s a bit odd really.
I can see and interact with them in the sceneExplorer node list, I tried removing and re-adding the controls that didnt work and still no joy, but I do get this error sometimes when I save the scene; I’m not sure what it means exactly but it is in the general area of lighting, so thought I’d bring it up. I guess this @nehon might be able to tell us if it’s a dead end:
[java]
SEVERE [com.jme3.gde.core.scene.SceneApplication]: NullPointerException: null
java.lang.NullPointerException
at com.jme3.renderer.lwjgl.LwjglRenderer.renderMesh(LwjglRenderer.java:2458)
at com.jme3.material.Material.renderMultipassLighting(Material.java:853)
at com.jme3.material.Material.render(Material.java:1122)
at com.jme3.renderer.RenderManager.renderGeometry(RenderManager.java:523)
at com.jme3.renderer.queue.RenderQueue.renderGeometryList(RenderQueue.java:322)
at com.jme3.renderer.queue.RenderQueue.renderQueue(RenderQueue.java:374)
at com.jme3.renderer.RenderManager.renderViewPortQueues(RenderManager.java:763)
at com.jme3.renderer.RenderManager.flushQueue(RenderManager.java:719)
at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:983)
at com.jme3.renderer.RenderManager.render(RenderManager.java:1029)
at com.jme3.gde.core.scene.SceneApplication.update(SceneApplication.java:334)
at com.jme3.system.awt.AwtPanelsContext.updateInThread(AwtPanelsContext.java:188)
at com.jme3.system.awt.AwtPanelsContext.access$100(AwtPanelsContext.java:44)
at com.jme3.system.awt.AwtPanelsContext$AwtPanelsListener.update(AwtPanelsContext.java:68)
at com.jme3.system.lwjgl.LwjglOffscreenBuffer.runLoop(LwjglOffscreenBuffer.java:125)
at com.jme3.system.lwjgl.LwjglOffscreenBuffer.run(LwjglOffscreenBuffer.java:151)
at java.lang.Thread.run(Thread.java:722)
[/java]
EDIT: Ugh. seems to point back to the LOD control not working. I’m stumped.
@Sploreg I ignored the LOD/NormalRecalc control issues for now, and carried on to finish the modification tools, all of which are now working. Each terrainquad and its associated alpha-maps now have a rough numbering convention as to make them unique to each other.
So the situation now is how to best display which terrainquad we’re dealing with whilst painting/setting textures. The most obvious way for me since you already subscribe to node selection changes would be to hook into that and display the assigned textures based on which is selected.
Sound like a plan to you, or did you have a different approach in mind?
Also, how do I go about committing this when I’m done?
@jayfella said: @Sploreg I ignored the LOD/NormalRecalc control issues for now, and carried on to finish the modification tools, all of which are now working. Each terrainquad and its associated alpha-maps now have a rough numbering convention as to make them unique to each other.Maybe number them with the grid coordinates. Something like: long id = x<<32 | z to combine the x and z coordinate values into a number. Or even just a string id for x,z.
@jayfella said: So the situation now is how to best display which terrainquad we're dealing with whilst painting/setting textures. The most obvious way for me since you already subscribe to node selection changes would be to hook into that and display the assigned textures based on which is selected.Sound like a plan to you, or did you have a different approach in mind?
The paint/modify tools will have to select that node they are interacting with when clicked and when moved. Are you using the NeighbourFinder interface in the terrain classes and your grid? If you make an object that implements Terrain, and NieghbourFinder, then you can tile as many quads under it as you need and the tools will just work without any changes or listening to node selection.
As for displaying which textures on the UI for the terrain being painted on, you could have up to 4 terrain’s textures showing. When to show the 4 and when to just show 1 or 2, I’m unsure how to best do that. The controls for this might have to pop out into a separate window to show 4 of those texture tables. There’s got to be a better way but I’m not sure what it would look like, I’m not really a UI guy =)
I can review the code with a patch file and then give you commit access barring that it is backwards compatible with older terrains and scenes.
One thing to keep in mind is the editor should not be cluttered with multiple extra controls/buttons for handling many quads if those quads aren’t there.
At the moment I’m using nothing other than raw TerainQuad objects laid next to each other. Any implementation (TerrainGrid, TerrainPaging, etc…) should work exactly the same provided the terrain uses the supported lighting material.
I use the ray you cast for the controls to determine which terrain to modify, and subtract the location of the terrainquad from the cursor position to centre it back to zero. And thus its as simple as that to make it work over any terrainquad. This way works with any possible situation you can throw at it.
I’m quite well versed in the art of creating an effective GUI, so with your permission I’ll create it in a way that is more intuitive. I think personally it just needs tweaks from its existing layout. Displaying the textures for the current active terrain and all neighbours would be information overload. I personally think it should only display the textures for the terrain being worked on: Displaying on Mouse-Over selection would provide at-a-glance information and Node selection would provide absolute configuration.
Once we have resolved that consideration, and I have implemented it, I’m happy to throw the patch file your way - but we still remain with the last outstanding issue of the LOD and NormalRecalc controls not working as they should. I should also note that I still have no idea how to overcome that problem. No matter how I add the terrain to the scene (via Terrain Editor using the button or right-click a node - or just using the regular composer) the problem persists. It does, however update when I save, close and re-open the scene, but any changes after opening result in the same situation - only the first found instance of the controls update - all others do not.
1 Like
Okay I think I know the issue with the terrain controls. The scene composer and terrain editor are just looking for one TerrainLODControl so they can add the camera to them. So if they don’t know about the other terrains there they won’t look for the controls. Without the camera, they won’t update. I will fix that on monday when I am back from a conference.
Go ahead with the UI layout changes. Just make sure the seams of the terrain are understandable when painting so you can paint across them without having to match up each side. It could be as simple as painting that texture on the other terrain, adding the texture layer if it is not there yet. Then the user can change the layer order after the fact.
1 Like
Ok. I’ll have this done by time you’re back.
@sploreg I’m just doing the “display material based on node selection” part and I’m done. I’ll push the patch to you once that’s done as promised, but I would really like to re-write this properly if you would be willing to consider letting me do it. I do feel that it’s inefficient in some key areas as a result of changing it to work with multiple terrain objects and rewriting it will reduce the memory footprint and performance in certain areas.
@sploreg Here is the patch: Google Drive or Mediafire
There are two known issues thus far, though I wanted to give you the patch regardless because I don’t see them as large enough to cry about.
- The slope control does not work as intended. I couldn’t find a reasonable way to get it to work over multiple terrains, and so remains untouched.
- It doesn’t appear to save more than two textures in a terrainquad upon save/close. It is more than likely just a missed call on a method somewhere.
There may be other small issues, I haven’t had time to test it to death because I literally just finished it, but throughout the journey I repaired any exceptions raised and I’m confident it’s fairly solid.
As you move around over the terrain (with a tool enabled) the material table will change to reflect the materials that paticular terrainquad is using. It remembers which texture was selected per-terrainquad instead of going back to the first texture in the list every time. You can select a terrainquad from the scenecomposer node list and it will display the textures of that terrainquad - which will be typically used to add and remove textures, or select one to paint. This should give both the ability to view textures per-terrainquad at a glance using mouse-over and also the ability for a more direct configuration using scenecomposer node selection.
1 Like
What memory and performance issues are you running into? Just in the editor? How the textures are displayed in the UI can be changed, and it will no doubt have to be re-written to support multiple terrains.
Thanks for the patch, I will look at it today. For now I will apply it to a branch I have locally here.
How are things going on this, is this still planned to go into the main editor?
this would be a really nice addition!
the video is quite impressive, especially the slope part looks interesting!
I hope you don’t give up on this. 
I got kinda side-tracked on another jme project to help push plugins to github. Can’t say much about that since it isnt finished yet, but once I’ve done that I’ll be continuing with this.
1 Like
Plan is to run with it, it all looks goos and has the changes we want.
1 Like