How to use rootnode in another thread?

I want to check collision between character vision bounding box and rootNode in another Thread to prevent freezing main JME thread.

the problem is using rootNode in other thread to check collision.
and cloning rootNode is so heavy that freeze the main thread and slow down the game…

how can I do It?

You can’t.

If you really really really really really need this (and I doubt it) then you need to keep a whole complete copy just for the other thread. Maybe it’s worth it… probably not.

I suspect your issue is really elsewhere.

1 Like

Some questions you should ask yourself:
Why does doing a bounds intersection take so long?
Do I really need to intersect “every single detail of the scene down to the fingernails of the cats”?
…probably not.

Also, people don’t see in “bounding boxes” and there are more efficient intersection shapes.

how must do it?
I mean how can I check bounding box collision without effect on fps?

Revisit all of your assumptions.

Doing such collisions against the “whole visual scene graph” is like hitting the problem with a giant building-sized sledge hammer.

Edit: put another way: What is it that you are ACTUALLY trying to do? Why do you need this?

1 Like

I want to scan environment every second to find enemies and shoot at them…

is there a better way?
or in path finding I need multi Threading and reading rootNode in other threads…

“I need pathfinding and hit detection to be able to see every tiny little detail even the 1000 spark particles that are falling from the particle emitter.”


Are you trying to do a top-level bounding box check like in your picture? Why is it taking more than 1/60th of a second.

There is a simpler way to do everything you want to do and it involves using your game objects and not your visual representations of game objects. Unless they are the same thing and then you need to revisit your whole game design, I guess… because you’ve done the equivalent of strapping a text field right to the Oracle table’s field and now you are wondering how to handle reindexing properly.

Edit: anyway, at this point we’d need to know a LOT more about your setup to help. Else we can only provide general advice on what not to do.

1 Like

Question: is this actually a problem right now? Like is it taking a long time now… or are you just trying to optimize something before you’ve even tried it?

yes it a big problem and now it is so slow:

1- checking collision with rootnode in update method lowering the fps from 60 to 10.
2- checking collision with rootNode in other thread throws exception some times.

and also I need it to optimize my pathfinding algorithm.

I think that checking distance between spatial and other NPC characther is a better way .


You should just loop through a list of all current enemies. Checking the entire rootnode is way overkill. If you have 50 enemies, you should only need to check 50 collisions. Checking the entire root node means that you are likely colliding with every rock and every patch of grass to see if it is an enemy - which you could already determine if you store a reference to all enemies in a list when they are spawned.



1 Like

And you can reduce that even further. I presume you want a sphere, not a box because it’s more natural. You can check if something is inside a circle quite trivially, and disregard those that aren’t in it. If you limited the angle (not 360 degrees, maybe 90 degrees instead) then you have a field of view - so even less of an area to check.


I feel there is one problem:
JMEs built in collideWith is based on Scenegraph,
That way you can only run it in the MainThread and it also operates on the whole SceneGraph by default / there are no ways to supply lower res versions / make it use Bullets Shapes.

Especially when it comes to hybrids like for my shooting I have hitboxes which are actual geometries and the scene which might be represented by Bullet Shapes, you don’t have something easy to call. You CAN exclude particles by setting a collisionHint iirc, but still you can’t say Spatial A, B and X.

On the good side of things jME uses a BIH Tree, so usually the slowdown is only happening once and after that for me it’s pretty fast even though I cast in my 10M+ vertices Scene multiple rays per frame as of now.

1 Like

Simple, override the collideWith method on the geometries you want to have special collisions with and then implement the checks yourself for each of the bounding volumes you’ll be using.

I’ve implemented a handful of mathematical collision methods for the ships in lightspeed. AABBs, spheres and elipsoids I think, since the ships have so many modules it’s too slow to do mesh checks for each. I only really needed boundingspheres and rays though. The performance boost was rather insane for large battles with lots of ray projectiles.

It’s also worth noting that as far as I could tell there are no real broadphase distance checks before jumping straight into mesh (I think it was technically there, but all commented out and some notes by pspeed) triangle buffer checking, so simply adding that helps too.

For bullet shapes, just do actual bullet ray casts.

1 Like

not sure why you even use collision… as i see from first your screenshot, you need to know when enemy or character is in vision range. Why you cant just calculate distance from player <-> enemy?

to even optimize it, you can from time to time (for example for each 10 seconds) calculate what enemies are below some distance, to not compare ALL world enemies each second, but only part of them.

myself i even mapped map to HashMap grid like, so i know in what part of map are enemies, so i can compare close enemies or know what enemies should see on “visible map - not fog of war”

about pathfinding, depends what you want to achieve. If this gonna be a big world, i would suggest doing something like “road points” to calculate small pathfinding to closest road point first, then go road, and when near target, again small pathfinding from road to target place.
if small world, then you can simply do pathfinding using library.

Please note i got for example 10000 NPC in world and it even dont take 0.01 second to manage them all. ofc depends on processor/ram imo, but it should not take much.

myself i would have other question to JME community. How to do best optimized way to calculate when character is on ground(terrain or object like house, not just terrain) and calculate what position is “on ground”(again not just terrain) having x/z pos?

1 Like

Off the top of my head, shoot a ray from their feet into your collision shapes.

Or detect when the feet have contacts.

Like in my SiO2 bullet integration (and even MPhys) the control driver object collects collision events for the body so you can keep track of when you have vertical collisions and know that the character must be standing on something.

So a lot depends on the other parts of how your game is setup.

1 Like

Hi @pspeed

Off the top of my head, shoot a ray from their feet into your collision shapes.

I already do this, but dont seem too optimal.

Using just terrain height would be best, but problem is when character is on object like rock or other thing.

i mean it work well, but maybe my problem is that i check this also for “near npc” to also know when they stand on ground. But i belive i should do different logic for NPC. when there are a lot of npc near, then it affect fps visually. maybe its not about raycast itself, because dont check it fully, but imo its about it.

Or detect when the feet have contacts.

via standard physics or what? i think it might take more worktime than raycast?

anyway i would prefer decide some “elipse” so when there is small slope in ground it would not take character as flying one ;p currently i just take raycast and check distance from some point above feets.

also how to best know how to rotate npc based on slope. i understand i could use raycast i belive to know it, but what about extreme situations like one of triangle having much different rotation. so should i check and calculate average roration of all points or how :slight_smile: would like to know best solution for all of this.

When you walk down a hill do you lean forward? (no)

If you are using bullet, it is constantly telling you about the collision events (if you listen). A dot product between the contact point normal and the up vector will tell you if it’s a point that is keeping them from sinking into something… ergo: on the “ground”.

1 Like