What’s a good way to keep the camera from going through terrain
I need advice and help
What’s a good way to keep the camera from going through terrain
I need advice and help
make camera use physics or ray in physics to determine where is “max distance from character”
Good advice
any suggestions for what method to use (on a spatial or node) to then prevent the movement when you detect the collision with a ray?
I’ve seen setWalkDirection()–I’m not sure how to set that up on a model without the model being a charactercontrol or without it being physics enabled
Any other suggestions for what method to use to stop the model from moving?
but setWalkDirection is for Character physics, not Camera. It just move RigidBody per frame based on this direction, thats all it do.
Idea1:
Camera could use for example GhostControl/RigidBody for itself (to setup some margin from elements)
while Ray in physics should teleport GhostControl/RigidBody to “maximum distance” detected.
Idea2:
Can also use just Ray (its not accurate so much then, but its fast) to determine distance of camera to not cross terrain/etc. Its fine for terrain but if there would be objects with crazy mesh, it might cause little issues.
Idea3:
Can only just use GhostControl/RigidBody with Cone Collision Body.(and restrict its movement to some axis line) So when it contast with terrain/etc, it will just move closer to character
There are a lot of solutions.
Yeah I didn’t mean for camera, specifically – didn’t mean to hijack you were just discussing rays so I saw an opportunity. I am trying to go after Idea2 hehe
I’ll mess around more and then make a separate topic on it if needed. Thanks for the reply
Sometimes you can use a long capsule ghost aligned with one end at the head-pivot and the other end at the maximum camera distance… then use any intersection with the ghost to decide how close/far to render the camera. (Or to temporarily go back to first person.) It’s like the Ray idea but a little better because you can give it some thickness (doesn’t take much).
I did something similar with the unreleased second Mythruna engine and I will end up doing similar for this recent third one.
Best to add some interpolation from camera location to desired location. Really fast interpolation for getting out of the way of a contact and slower interpolation for zooming back out again.
Ok I will add this to my list of ideas to monkey around with … Thank you!
ray.setLimit (10f)
I set the length to 10F and collision detection can detect distances greater than 10F
碰撞结果(collision results):2
射线(Ray):null
序号(serial number):0, 距离(distance):12.60, 物体名称(Collision object name):floor, 交点(collision point):(6.2831354, -1.9000006, -1.4240495), 交点法线:(0.0, -1.0, 0.0)
序号(serial number):1, 距离(distance):12.95, 物体名称(Collision object name):floor, 交点(collision point):(5.9899693, -1.7000003, -1.4513258), 交点法线:(-0.0, 1.0, 0.0)
最近点(Near point):(6.2831354, -1.9000006, -1.4240495), 最远点(Far point):(5.9899693, -1.7000003, -1.4513258)
Why is a distance greater than 10 detected?
Using a physics ghost object is a neat idea. Thanks for mentioning it!
For avoiding line-of-sight obstructions, I’ve found that rapid changes to the camera distance are disorienting; I prefer to change the camera’s near clipping plane instead.
This can sometimes create its own artifacts… like clipping things strangely that just happen to be nearby. It’s a neat trick, though.
I guess I’m used to the 90% of third-person behind-head/over-shoulder games that slide the camera around to keep the player in view. As long as the tweening is nice, it doesn’t even make me sick.
I find zooming in quickly to be less jarring than zooming out quickly. (Even for sniper-scope style stuff I find this to be the case.) Which is fortunate in this case because zooming in to move out of the way is where being quick is useful. For zooming out again, I do it pretty slow (walking speed)… which also helps keep from jittering around a lot for bump walls.
The limit is an optimization so that the collision routines can eliminate objects that are too far to matter. However, there is the chance that an object is close enough (bounding shape) that it is within the distance but then the actual collision is still farther than the limit. Since jMonkeyEngine did the calculation is does not throw this information away.
If you strictly want to limit the results based on distance then add an if statement.
if( distance > 10 ) skip it
If the terrain is represented as a physics rigid body, you can prevent cameras from penetrating it by attaching each camera to a physics object.
For instance, some of the terrain examples in jme3-examples attach the camera to a capsule-shaped CharacterControl
… including TerrainGridTileLoaderTest and TerrainGridSerializationTest.
Since Bullet’s character dynamics are … peculiar, I prefer to attach each camera to a sphere-shaped dynamic rigid body. I recently published DynamicCamera
, which is a reusable AppState
using this approach. It’s included in version 0.5.0 of the Garrett Library.
This is a very good suggestion and hint.
警告: Failed to set root path http://jmonkeyengine.googlecode.com/files/TerrainGridTestData.zip
java.net.ConnectException: Connection timed out: connect
at java.base/sun.nio.ch.Net.connect0(Native Method)
at java.base/sun.nio.ch.Net.connect(Net.java:579)
at java.base/sun.nio.ch.Net.connect(Net.java:568)
at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:588)
at java.base/java.net.Socket.connect(Socket.java:633)
at java.base/java.net.Socket.connect(Socket.java:583)
at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:183)
at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:498)
at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:603)
at java.base/sun.net.www.http.HttpClient.<init>(HttpClient.java:246)
at java.base/sun.net.www.http.HttpClient.New(HttpClient.java:351)
at java.base/sun.net.www.http.HttpClient.New(HttpClient.java:373)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1309)
at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242)
at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128)
at java.base/sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:1057)
at com.jme3.asset.plugins.HttpZipLocator.readData(HttpZipLocator.java:190)
at com.jme3.asset.plugins.HttpZipLocator.readEndHeader(HttpZipLocator.java:295)
at com.jme3.asset.plugins.HttpZipLocator.load(HttpZipLocator.java:322)
at com.jme3.asset.plugins.HttpZipLocator.setRootPath(HttpZipLocator.java:347)
at com.jme3.asset.ImplHandler$ImplThreadLocal.initialValue(ImplHandler.java:120)
at java.base/java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:195)
at java.base/java.lang.ThreadLocal.get(ThreadLocal.java:172)
at com.jme3.asset.ImplHandler.tryLocate(ImplHandler.java:173)
at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:374)
at com.jme3.asset.DesktopAssetManager.loadModel(DesktopAssetManager.java:439)
at com.jme3.asset.DesktopAssetManager.loadModel(DesktopAssetManager.java:444)
at com.jme3.terrain.geomipmap.grid.AssetTileLoader.getTerrainQuadAt(AssetTileLoader.java:73)
at com.jme3.terrain.geomipmap.TerrainGrid$UpdateQuadCache.run(TerrainGrid.java:152)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
I can’t seem to access this file properly
hi~
I used the second option you mentioned
My screen flickered
https://youtu.be/xUA9bkkyepk
I don’t know what the problem is
But I found a word “interpolation”
I don’t know what interpolation is
What method is used to implement interpolation in JME?
Found on Github
Google mothballed “googlecode.com” many years ago. You must be running a very old version of jme3-examples, because that URL was removed from the JMonkeyEngine codebase in 2016.
Thank you for your reply.
I found the file on GitHub.
The Discord group Ali-rs gave me a hint
Looks like TerrainGridSerializationTest and TerrainGridTileLoaderTest still points to old URL:
However TerrainGridAlphaMapTest points to a valid one: