Hi!
I know two sources can not access the same data at the same time.
Thus I get the errors when I tried to multi task before.
Now I dont do that anymore because I run it all in the main update loop.
But Im getting prittie sick of the system I’v made and I want to go back to threading.
So my question is: What can I safely access in jme and what can not?
I know that asking for the body.getWorldTranslation() is bad and will give errors prittie frequently.
So other than that, what am I not suppose to touch?
For all variables I will do, I will have a copy of them avalible to my thread, and for all variables I want set, I just
modd the copy and then in the main update, it will set the new one to be the copy.
But as for my question, I can not touch the following:
rootNode and physicsNode. The rest is ok right?
Anything workign with something under the rootNode is no go.
However you can savely work with Nodes that are not attached to the rootNode, also the assetManager is threadsave, so for example you can load models in the background and then attach them in the mainupdate via Callables. For debugging I suggest to make yourself a check if you do everything alright,
Thread openglThread = Thread.currentThread();
in the simpleInit / initialize so you know the thread doing the update, for everything sensible you now can easily debug/check if the right thread is calling it by comparing this to Thread.currentThread.
With much more effort a more advanced solution is possible(like the physic does). You synchronzie yourself with the update and your woker thread, then both threads do one tick simultaniously and after that it starts from the beginning. (So when using this you see physic one tick delayed, but calculated while rendering but at the end of each update both threads wait for each other, copy the needed data over and only after that they work independent from the other again untill next updateloop end.
In my project, I do a lots of calculs and Mesh preparation in separate Threads, using an Executor. Then when the data is ready, I send a “custom Action object” to my “Update controler”.
The Update can treat the Action quickly since all the big work has been done in background.
Im getting prittie sick of the system I’v made
I can guarantee you that you wont need multithreading for your game. Whatever you can do with multithreading, you can do with a single thread much easier. Maybe you have an omega super duper zomg omg wtf leet idea of using multithreading to gain +0.001 fps, you are welcome to tell us.
This article outlines how you can do threading without having “detached” threads and while maintaining one logic loop:
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:multithreading
As I understand from that tutorial, even tho I’v read it several times, is that for each value that I want
to get using my threads. I must write 3 separate files with atleast 30 lines of code in each.
Sounds extremly frustrating to me.
@tralala, I’v already tried updating all in my main update loop. I can have 4 zombies on my map, then it will start lagging as heck. Its not an option.
Also what I do not understand about the builtin multi thread support is how can you guarantee its working?
I meen, if my thread starts running when the jme is not updating, then how can it be sure its finished before next update?
I really think that I must use this builtin support but I just do not understand the concept of it.
you are doing something wrong, normally you should be able to rander/update 1000 zombies at the same time.
- how much fps you have. screenshot or it didn’t happen. I guess you have 2000 fps ? i think 50-60 fps is fine.
- show us your update zombie code that takes zomg time
- you can use net bean’s profiler to let it tell you what takes long time.
- 15-25 at normal. 30 at the best.
My pixel acceleration card got burned and now Im just running on vga cable
But the zombies have 36 faces each, about 100 vertexes so it cant be the rendering.
- The logic is not so complicated either.
They do a raycast to see if theres an obstacle between you and them. If it is then they create a path around it.
That doesnt take long either.
Next time they update, they check to see if theres a path, if not, check for obstacles.
- Using eclipse
Read the document again, you did not understand it.
Okej, I might understand now 
(I think anyways)
I want to keep my concept of create a brain and attaching it to the zombie to control it (even tho zombies usually lack brains :P)
So would you suggest that I create a controller for the zombie like: AIcontrol
Then do zombie.geometry.setControl(AIcontrol)
and then when creating the brain, I would extend a AppState, and inside of that I do:
Path = MainClass.pathFinder.getPath();
and then let the brain loop freely until path is found or is not canceld?
MainClass.pathFinder would then be an instance of a object implementing callable whos call method is the path finding.
Am I correct in my thinking now?
I want to make sure before I start cleaning and removing tons of code…
Yes, the thing is that your control should handle starting the thread and integrating the data it supplies into the game so that the point in time that happens is defined by the control and does not happen at some time in the update loop. This way you can consider your control like being sequentially called code and have your normal update loop logic. Additionally it scales to a theoretically unlimited amount of threads / cores.
Humm… Than for a final question:
Can I freeze my controller so it waits until it gets the path and then continue with the script?
Like:
Path = MainClass.pathFinder.getPath();
while(!Path.isCancled() && Path != null){
wait(100);
}
Or something simular?
That causes a freeze frame… Read the stuff again and again and meditate a bit about what multithreading really means… Also what the update loop is.
aaaa you want to use multithreading to speed up your ai. Lets say you use 1 thread per zombie.
Note: how i havent seen how jme does multithreading but here is how i would do in java.
- what are the objects that are used, and shared by all threads but are not modified : stage, player location.
- what are the objects that are modified but only 1 thread should know : zombie position.
for 1,2 there is no need to copy them / or make them synchronized.
Pseudocode:
[java]
create N threads();
Thread
{
Vector3f resultPosition;
run()
{
Do pathfinding for zombie;
resultPosition = x;
}
}
For (every thread) run();
For (every thread) wait until all finish
//since now only one thread is running ours, you can do this.
for (everyThread) myArray = thread.resultPosition;[/java]
Guys, you don’t need to setup your own update/check logic, just do it like I posted. The controls themselves give off the “capsule” for each entity and the update loop is the logic loop that combines that info again… No need to go out of that logic and having threads to manage and acknowledge each other. Pathfinding even is the exact example :roll:
Okej, thanks. Thats all I need to know.
One of the main problems with my system was that it had no option to wait(time) except for skipping x amounts of updates.
But I guess I’ll have to bypass this in order to use this builtin support…
Ohwell, thanks alot everyone 
I read the discussion extremely interested in the ending that I eventually haven’t found. I experience similar problem with bots - drastic frame rate drop after adding 4 or 5 of them (using oto model). It seems to me as if it was the matter of physics. (well, pausing the bullet system helps) However adding every oto into a separate physicSpace sounds like a bad idea to me. Would like to multithread, because sooner or later i will have to, but even more i am curious about the performance I should achieve. I tried multithreading using the default physics multithreading approach, but it offered very litlle help (as a matter of fact, detached thread did the best job).
So far I haven’t introduced any LOD concerning those bots, bots all use characterControl with cylinder collision shapes. Sorry if I didn’t write it clear - it’s late and I can hardly think clear here.
However, I have a side-question: is there a huge performance gap between the RigidBodyControl adn CharacterControl? I remember from some tutorials with rolling balls that they rolled quite easily, despite coming in some numbers.
Thanks in advance for any help.
Best regards,
Tomek
Forget about multithreading single objects in the physics space yourself. Use the parallel mode in the BulletAppState, that runs the physics update in parallel. Native bullet supports multithreading inside the physics space but its complicated, the results look a bit odd and not really such a huge performance gain, so even the pro’s have their issues in getting this to work. The only thing that you could try (what I intend to do some time) is having a “grid” of physicsSpaces. The complicated thing is having the borders share their objects properly so that balls can roll from one grid to the other. These would automatically be multithreaded when run in parallel mode and using the current app state.
Thanks, in fact I was wondering about trying to detach/attach spatials into PhysicSpaces based on GhostControls for example. I wonder however whether to divide the terrain as well or perhaps add the same terrain to each PhysicSpace and later just swap the other spatials around.
On one hand it could alleviate the pain of n^2 checks for collision, but on another detecting all the space-trasnfers might minimize that gain.
I also noticed, or at least it seemed to me, that increasing slightly the accuracy (i mean higher value of the parameter, i suspect it works like tolerance margin) seemed to produce better results in terms of frame rate, with a slight decrease in smoothness. Are there other parameters like this to meddle with in hope for further improvements?
And my very final question: how many characterControls is it considered safe to attach to one physicalSpace without experiencing quality drop?
Best regards,
Tomek
The resolution is the internal framerate of the physics and should best be left at 60 fps (1/60) to allow accurate physics. All the other things should be easy to find out in a proper context and depend largely on what you actually do. Detecting the overlapping should be as easy as using a ghost object to check for overlapping objects.