Interesting lib design

[attilaz]

This is not an issue, I just didn't manage to add a comment on your article with a twitter account...

I really like this lean and mean API design. Probably needs a higher level interface for adding removing bodies/colliders etc but it is very easy to add on top of this. And I think an interface like this is way better than traditional OO interfaces like bullet3d with a hundred .h files and tons of classes with public functions and of course ( with private/protected stuffz that a user didn't really care about)

About the multithreading, how about an interface like this?

generateJobs(JobsData* j);
bool doJob(JobsData* j, int processJobCount);
void waitForJobs(JobsData* j)

threads could call doJob so JobsData needs to be thread-safe, I think an atomic int could be enough for stepping.
JobsData could also store number of finished jobs with atomic int for waiting, or could implementing with some higher level multithreading primitive to avoid spinning.

or instead of the two fuction ( doJob, waitForJobs) maybe
bool doJob(JobsData* j, int processJobCount, bool waitForFinish);

[rasmusbarr]

Thanks for the comment! I'm glad you like it.

I haven't given multithreading a lot o thought yet but I will definitely come back to your comment again when I get to it.

The way I see it now, I won't be able to generate a fixed number of jobs up front. There will be multiple passes of going wide over multiple threads ending with a barrier that joins all threads again.

Sketching the flow of collide as an example:

# Setup.
Compute bounding boxes and Morton codes in parallel.
Barrier.
Sort Morton codes in parallel.
Barrier.
# Broadphase.
Test coarse pairs in parallel.
Barrier.
Test fine pairs in parallel.
Barrier.
Sort pairs in parallel.
Barrier.
Determine coarse islands and filter out resting pairs.
Barrier.
# Narrow phase.
Compute detailed collisions in parallel.
Barrier.
Determine fine islands and filter out resting pairs.

If the job system would allow a task to spawn more tasks, a coarse pair task could immediately launch fine pair tasks, but it's unclear if that complication would improve performance because of worse cache locality.

If the library would be allowed to have its own synchronized job management, it would be enough to simply configure the number of thread slots the user wants and she could then call a worker function on each slot, which would block for the duration of work. This seems similar to, but not exactly like, what you are suggesting.

WorkSlots* begin_work(unsigned slot_count);
void do_work(WorkSlots* work_slots, unsigned slot_index);
void end_work(WorkSlots* work_slots);

Usage would be something like:

WorkSlots* work_slots = begin_work(8);
// Launch 8 threads or jobs that call do_work.
collide(..., work_slots);
simulate(..., work_slots);
end_work(work_slots); // Unblocks the do_work tasks.

While I haven't decided yet, I don't really like the idea of implementing job management within the physics library. I would rather have it leverage the users own system and come up with a simple/generic interface for that. Perhaps something like this:

struct Job {
	void (*perform)(void* data);
	void* data;
};

struct JobManager {
	void (*spawn)(void* data, Job* jobs, unsigned count);
	void (*barrier)(void* data);
	void* data;
};

In this interface, spawn would always be followed by barrier and they would only be called from the main physics thread, which could simplify the implementation of the job manager. If the user already have a sophisticated job manager, it should be quite easy to integrate that interface with it.

Usage would be:

JobManager* job_manager = ...;
collide(..., job_manager);
simulate(..., job_manager);

[attilaz]

Sorry to disturb/nudge you again.

I am trying use this library for a hobby project, maybe extend with ray and other colliders. And I have some questions, I don't know where to ask them. Other projects use gitter but I haven't found you there. If you don't have time to deal with this and I am on my own, it is perfectly fine for me too. I have seen you involved in RTX/DXR, so I guess you are pretty busy.

• What should be the way to remove colliders/bodies? For me it seems that I should do an unordered array remove ( colliders[to_remove] = colliders[--count]), but that changes the index of the body/collider. So a higher level API should add another indirection with handles?

• Adding other colliders seems straightforward. But rays seems to be a special case (no need for general collision response). For performance reasons(broadphase data generated here) I think ray collision should be handled inside nudge::collide but no need to add hit points to the contacts list. It could be best to store first hits inside ray collider data.
  Any thoughts on that?