Posts made by Kuroyume0161

@s_bach

Aha! That helps! I will see how this works this weekend.

@s_bach

For this plugin, I am just updating it to work 'natively' in C4D R20 so that users are no longer required to use Insydium's bridge plugin to use the R13 plugin build. There is already a next version (2.0) in the works so I don't care so much about making use of the latest and greatest in this particular situation. Nonetheless, the thing that really annoys me the most is that there is not one example (in the docs, examples, or here) on how to use 'threads' with 'parallelfor'. The simplistic idea of using C4DThreads with ParallelFor, if possible, would probably be enough to achieve my goals. If I must use JobInterface with ParallelFor, then so be it. But my inquiry remains the same: how does this work? Without any examples, I cannot proceed without some trial-and-error guesswork and hope - I have been studying and searching for the past many days to no avail.

It would be great to see an example (even if skeletal) on how to 'pool' threads with ParallelFor using either C4DThread or JobInterface to initialize, launch, and finalize the process.

Thank you very much!

@s_bach

Still a bit (sarcasm) confused. So, there is no longer a need for a 'Control thread' since ParallelFor handles the initialization, parallel running, finalization of the concurrent threads, right?

I also see that there are 2 choices: Dynamic and Static which appear to control the division of labor between the concurrent threads. For static, do I state the division numbers? The criteria in my case is the division of a polygon object by polygons to be processed by the concurrent threads.

Finally, for now, my Control thread initialized, launched, then, once all of the concurrent threads completed, then did assembly of the pieces from each thread into a single new polygon object. This is passed back to GetVirtualObjects() in my ObjectData plugin. Not sure where this assembly would be done exactly for this new paradigm.

Thanks, again!

My original code was written for C4D R13 and uses a control thread (C4DThread derived) and a set of 'child' threads (C4DThread derived and based on number of CPUs), using an MPThreadPool. There is no need for locks/semaphores as the child threads are independent of each other.

Okay. C4DThread exists in R20. MPThreadPool appears to be either undocumented or deprecated (?). What's up?

I am in the process of migrating my code and everything else is completed but the threading. Although MPThreadPool is added to C4DThread as a friend class, there is no definition of it. I also see that everything in C4DThread is '/// @markDeprecated'. So, does this mean that I have to convert over to a maxon::ThreadInterface? Is there some migration information on how to achieve this?

Thanks!

Sebastian,

Added tags. Not really a question but a request. I thought that I had read about people adding a TreeView to the AM using GetDDescription() but maybe it wasn't as well fleshed out as they (or I) suspected.

I will look into the custom data type and GUI for it.

Please mark as Solved.

Thanks!
Robert

Maybe I am missing it in my searches, but I'd like to add a CUSTOMGUI_TREEVIEW to my Object plugin using GetDDescription() and set it up properly for use like in a GeDialog. I have some code to do the basic creation in GetDDescription() but then you need to have the TreeViewCustomGui* for the TreeViewFunctions and other setup. Yes, this can all be found by arduous searching and piecing together but if someone has an already working basic example that would be much appreciated.

The GeColliderEngine is a more finer grained approach (Narrow Phase). It is recommended to use it still, but it should be combined with some Broad Phase spatial partitioning hierarchy (KD Tree, Half-Spaces) or bounding hierarchies (AABB Tree, OBB Tree, etc.) which can quickly and easily weed out large swaths of objects that have no collisions by using either bounding boxes (thus, BB) of the objects or blocks of space between them.

At first this may seem contradictory: more code work to do this faster? Yes. This is classic Divide and Conquer. Instead of checking EVERY object against EVERY other object EVERY time no matter what, the faster you can remove objects from consideration by checking a simple overlap/locality, the faster the collision detection algorithm gets.

So, first do a Broad Phase to find only objects that are or may be colliding (even overlapping bounding boxes incur many false positives). Then move to a Narrow Phase to determine the type of collision (if any) and get the details of it. Personally, I found AABB hierarchies to be real-time fast if designed well.

Is this possible or should I simply maintain my own class double-links?