ok I will rewrite that
but because I would like to learn. why is that a bad idea?
Much of what you have in there is not directly related to TerrainQuad such as the material and the physics. Sure you can use them with terrain, but they are not related to it directly. You are also tying your class to the Application. Serializing (save/load) the class will become impossible.
Also if the Terrain API changes at all, then you have to update your class to match.
Everything that you put in there you can place in to a Factory class, or just outside of the terrain as the test cases are doing.
In short, you are tightly coupling the application and other utilities to your terrain object, which restricts what you can do and doesnât buy you the easy of use and convenience that you are trying to obtain by placing it in that single class.
to be clear: I really appreciate the explanation and the advice. thank you very much for that.
but I donât see why I donât get the correct behavior. I am no longer extending the TerrainQuad, instead I have the Battlefield objects, which has the TerrainQuad as a private variable. I made the necessary adaptations to the code and it still doesnât work.
even after this change, terrainQuad.getWorldBound() is still null.
back to debugging 
All I can suggest it match it as closely to one of the test cases (TerrainTestModifyHeight for example, it uses ray collision) and see what is different and where it might be going wrong. Also upgrade to the latest version. An old version of terrain had the issue with rays not colliding if the terrain was flat but that has been fixed for a few months now, and is in the Beta version.
didnât fix it yet, but it will happen.
until then I replaced movement with arrow keys. here is a small video of what I have until now
1 Like
I was using ray collision with straight downwards rays as well as other directions in stable and nightly and both worked splendidly and performed great even with lots of units.
Cool video, I like the name too.
I had a similar problem and found the answer in this thread (after 2 hours of searching and testing -.- )
try normalizing the ray-vectors instead of localNormalizing.
i hope that helps
@mess said: I have a terrain. I click with the mouse and I create a ray. I check the collision with the terrain. Nothing :(<br /> <br /> This is how I create my Ray<br /> [java]<br /> private Ray getMouseRay() {<br /> Vector2f mouseCoords = new Vector2f(inputManager.getCursorPosition());<br /> Vector3f origin = cam.getWorldCoordinates(mouseCoords, 0).normalizeLocal();<br /> Ray mouseRay = new Ray(origin, cam.getWorldCoordinates(mouseCoords, 1).subtractLocal(origin).normalizeLocal());<br /> return mouseRay;<br /> }<br /> [/java]<br />
I know this post is old. But the there seems to be an easy mistake with the origin. Replacing [java]Vector3f origin = cam.getWorldCoordinates(mouseCoords, 0).normalizeLocal();[/java] with [java]Vector3f origin = cam.getWorldCoordinates(new Vector2f(settings.getWidth() / 2, settings.getHeight() / 2), 0.0f);[/java] solved the problem for me (Tracing from the middle of the screen instead).
Strange that works because you should get NaN from a zero depth, all rays from the screen surface cross zero (cam position) so you cannot compute one 3D position.
After rereading my previous post, after using jme a bit more and having refreshed my math skills a bit, Iâve realized that it was a bit strange. Instead I use the following solution with good results (found among the jme test files):
[java]
Vector3f origin = cam.getWorldCoordinates(inputManager.getCursorPosition(), 0.0f);
Vector3f direction = cam.getWorldCoordinates(inputManager.getCursorPosition(), 0.3f);
direction.subtractLocal(origin).normalizeLocal();
Ray ray = new Ray(origin, direction);
[/java]
I donât know which is common practice on this site yet, to remove the old post, or just reply with a new post. Either way I thought it be good to let future googlers and searchers to have a proper way of creating a mouse ray.
1 Like