Jump to content
  • Advertisement
Sign in to follow this  
lucky6969b

Can the IK subsystem be described as a "Mover"?

This topic is 655 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In my design, every mover will carry at least one thread.
And also, every game object carries at least one thread too.

If the IK is *NOT* a mover, unlike other stuff like the pathfinder and physics,
which each of them has a least one thread, then IK will be handled by the game object thread.

when the game object is updating the IK, it will deal with the IK there.
Other stuff like pathfinding, when looping the game object, it will issue requests to pathfinder,
and the pathfinder thread will work on it and tell the game object it has finished the job and you can interpolate on the waypoints?
Thanks
Jack

Share this post


Link to post
Share on other sites
Advertisement
I'm not familiar with this "mover" vs "not mover" idea. Does anything stop working right if you arbitrarily put the IK in the "mover" category or the "not mover" category? If so, then that's the answer. Otherwise, pick either one.

What I'm worried about: Each thread has a separate thread stack in RAM. Start too many threads and you'll waste a LOT of RAM.

If you plan on using threads heavily, consider using a fixed number of threads (a thread pool) which poll for tasks (independent batches of data that need to be processed). Then you can make the tasks be anything you want.

Share this post


Link to post
Share on other sites

If I had 9 objects in the scene, 2 pathfinders, 1 physics, 1 collision avoider

should I open 14-15 threads including one main thread?

 

But I am still having doubts abou the one thread per object approach.

9 threads in game objects is a resource hog and also the main thread

has nothing to do at all!!

 

If not otherwise, should I throw the game objects into a loop, or should

I submit requests on regular basis?

Edited by lucky6969b

Share this post


Link to post
Share on other sites
Wherever you have a system which may use a lot of threads, consider creating a thread pool.

A thread pool basically manages allocation of and recycling of threads so that the load is split evenly between a set number of threads e.g. 8 or 16 (just an example) based upon what is optimal for the hardware rather than just letting the thread allocation run out of control.

This might solve a few problems if you really must thread pathfinders etc.

Personally I'd have one pathfinding thread, and queue requests in that thread, passing back responses to the requestor on completion. Only if the queue is getting unreasonably long during play might I consider multiple path finding queue threads but this would be set at compile time rather than runtime.

Just my own 3 cents (2 cents adjusted for inflation)...

Share this post


Link to post
Share on other sites

One thread per object is a terrible idea. One thread per system (or mover, or whatever you want to call them) is also a terrible idea.

The number of threads should match the capabilities of the hardware.

 

As Nypyren says, you should have a fixed number of threads in a thread pool, and then your objects and systems should generate tasks for that thread pool to execute.

This way you can keep the CPU as busy as possible, without wasting resources.

 

Having too many threads just means a bunch of them are sleeping and do nothing but waste resources and will make your program execute slower.

Share this post


Link to post
Share on other sites

There is not much point in having many more ready-to-run threads than you have CPU-cores.

 

Mostly a single CPU-core can work on one thread. This is not entirely true, eg hyperthreading does 2 threads, but at a reduced speed.

If you start 15 threads on a dual core machine, about 12 of the 15 threads are just blocked on not having a CPU-core to run on.

 

Edit: Ninja'd by Olaf Hedman

Edit2: Add "-core" to the CPU, to clarify.

Edited by Alberth

Share this post


Link to post
Share on other sites

I had 9 objects in the scene, 2 pathfinders, 1 physics, 1 collision avoider should I open 14-15 threads including one main thread?
No no no. No thread pools. No thread anything. You stop using threads right now. No idea where you got this "one thread per object" idea from.

 

Do a single game loop in the main thread for now.

Share this post


Link to post
Share on other sites

No idea where you got this "one thread per object" idea from.
 


Sounds like java code smell to me, the usual java way is to assume resources are unlimited and let the jvm deal with it.

However, I see where you're going with your recommendation to avoid threads. Threads are a nightmare for even an experienced developer and should be used with extreme caution.

If there really is no other way, this is when you use threads, for example pathfinding several thousand actors across a gigantic navmesh in realtime whilst doing other AI and physics etc. Most of the big game engines have separate threads for things like physics and pathfinding, but they are much more complex systems, perhaps the adage applies: Keep It Simple.

Share this post


Link to post
Share on other sites

Sounds like java code smell to me, the usual java way is to assume resources are unlimited and let the jvm deal with it.
I'm going to blame every little single thing any C++ programmer does on the language. Every single one of them.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!