Hello all. I’m not sure if this is the right topic for this, but I’'m lacking some critical information and kind of came to a road block. I’m trying to get the distance between two meshes (or geometries, there the same in my case as I have both in the same parent object). I thought of raycasting, but ran into self collision bugs and decided to drop that idea.
Edit I’m trying to get the distance between the surfaces of the two meshes, not the distance from their centers
Does anyone have some pointers to nudge me to the right side of the hill? I appreciate the help
…because what you are ACTUALLY asking for is hard to do and will not perform well.
In the general case, there may be no more correct way than iterating over all triangles of mesh A and checking the distance of those against all triangles of mesh B. A.triangleCount * B.triangleCount distance calculations.
Ah, that’s what I figured. I had a couple plans for this function, namely for altimeter and spawning things a set amount of units form the surface. The spawning situation is what made me think of this, as the mesh is created from noise, I couldn’t figure out spawn points when the generator got to that (generator = mesh/lod creation → texture creation → terrain object placement → building placement → spawn points → pass to director object, which handles states like spawns and missions). I have been just spawning test players at a safe height, but now that I’m in to implement fall damage I realized that fall would kill (planet with 500 unit radius, safe spawning height with all terrain features is 100 units higher than radius, leaving a possible 100 unit fall for a 1 unit player)
so, with looping the mesh triangles, the mesh can have a resolution anywhere from 131072 to 18 triangles. I feel like the performance hit there would hurt pretty bad for lod 0 meshes, just say two players, I would need to do about 262144 iterations, not counting the triangles on the player meshes
Probably ray casting against the terrain is what you want to do. But I don’t know why exactly this information isn’t already easy to figure out from the terrain… so can’t really answer any better than that.
Edit: because note that you are not really trying to solve the general “mesh to mesh” distance problem. You are trying to find a suitable distance for a relatively small mesh to sit on a relatively big mesh… and that’s a much easier problem to solve.
But for example, in this use case you could cast a ray from the position you would have safe-spawned the player to the planet’s center. The nearest point will be the ground.
Gotcha, I appreciate the help! And sorry, this is my first time trying planets instead of flat terrain. Thanks for your help, and for your work on this engine!
Sorry, one more question before I stop bugging you (lol), is there a preferred raycast method in jme3? the best I can find is this but it’s two years old. Is that the best way to raycast in jme3?
For example, for spawning, you should use some physics based plotter 2d or 3d based, depend what you need. You can base it on Spatial bounding or just some custom plotter colliders.
About terrain, you can just use “getHeight” to know Y position after spawn.
If this is 3D planet, the plotter might first check overall sphere collision, and later if collide, do just single raycast to center of planet to see exact space that need to be adjusted.(so the spawned object is on surface)
for 2d, see for example:
(but what i understand you would need 3d version of it)
Gotcha, you gave me an idea, in the mesh generator, I could compare the terrain details (which I would mostly have at that time, and the generator is repeatable so I can always just run it again with all of the terrain details) to spawn rules and just set the spawn points in an array on the planet object. Any thoughts?
LIKE MENTIONED ABOVE FOR PLOTTER USE PHYSICS (image 2)
(you can also just use bounding boxes, but it will not be precise)
For example for planet( if you dont use planet, but flat terrain, you can skip first step and just use getHeight instead of RayCast):
I just mean you should use Math:
over sphere (you can calculate sphere points using just math) spawn your objects.
(add some margin so sphere is bigger than planet)
ofc use some physics based plotter so this objects do not overlap
when all objects will be placed on math calculated sphere spawning
then each of them Raycast(use ray in physics or just on mesh) from spawn point of object to center of planet and then you will know exact point and normal direction, so you can fix each object position to be exactly on planet. Normal direction you can use for rotations if you need.
After objects are placed on terrain surface, you can AGAIN use physics to fix positions
(or if your objects gonna have origin point as “terrain contact point” then you dont even need, you would only need it if your objects(models) origin point is center of mass, then physics need calculate how offset them from planet surface)
Physics-related queries should use physics meshes to aid physics-related calculations. Physics meshes aren’t always the same as scene meshes, though. Most of the time they are simplified to reduce the complexity of calculations. If you want to place things in the scene then use the scene or its underlying data that was used to construct it or you might not get the result you are expecting.
The argument that “its faster” is most likely because the physics engine internally uses trees to reduce calculations (hint: the scenegraph - or scene tree - does the same thing if used correctly), and the underlying data is simplifed intentionally (simplified meshes) to make it faster. If your scene was managed properly your code would be doing the same thing by only casting the ray on the appropriate node/spatial instead of the rootNode itself.
hey, sorry ive been out a while. i havent yet found a solution. i ran into a problem trying to make jbullet do what i want. so currently, id like to use the planets mesh as a physics object (to simplify everything, and avoid say translating a low resolution sphere to the high resolution mesh or having things “float” because of the lower resolution), but everything stopped rendering when i refactored everything. i currently have a very efficient entity graph that manages the scene graph and (well its supposed to) the physics space, but again, i spawned a bug somewhere in there, so ill be back tomorrow after i apply some good pesticides to my code (and sober up a bit)
at the same time though, im debating if i want to keep going forward with a planet based system and fulfill my goal of being able to fly from planet to planet (or just fly around a planet) or keeping it simple. Any thoughts? if i do planets, i would really like gravity implemented ( eg eject something from your craft and watch it fall to the planet), but im also aware of the double loop issue, and given my projected size of the “universe”, that would result in a hell of a potato. but i also really want to be able to, say, allow the players to wander empty space and have random encounters in open space. plus the idea of hitting the upper strato at a higher speed to navigate faster really calls to me. I dont know, im trying to balance “ideal” with “practical”. Any ideas on what direction i should go? i already implemented a random planet generator that hijacks the Sphere class, but it came with its own bugs (cant make a planet with a resolution higher than 256, meaning no more than 256 x 256 points on a planet, regardless of size, looks very… poor when generating a planet the literal size of earth, which would be “ideal”). i might just be taking on a task for greater than one man can achieve, but ive been working on the idea behind this game for about 7 years and have made too many excuses on it (technology, time, money, etc) and i really just want to get moving on it.
sorry for the eyesore of a post, maybe i need to get a team together behind this. if anyone is interested, contact me. I have some funds set aside for this project so I might even be able to compensate, but no promises .but really, if anyone wants to work on a fairly large project, im open to having people on board with this, and also open to having contributers have a degree of design freedom.
.but really, if anyone wants to work on a fairly large project, im open to having people on board with this, and also open to having contributers have a degree of design freedom.