sezna / bigbang Goto Github PK

In an x/y visualization, it appears things are more likely to be pulled down/left than up/right. why?

There's a test right now that is failing which describes five entities in very close proximity which are colliding. One of the entities is only reporting one collision, while the rest are reporting four.

Currently, we don't scan for collisions. It would be a good addition, and should be opt-in either as a separate export or an additional flag to the tree.

I'm having trouble understanding what boundaries the viewport for the websocket example exist. Perhaps @Ameobea has some time to spell it out for me?

I want to remove the rng() for the largest entity that gets spawned in the middle's location, so it always starts roughly in the middle of the viewport. However, even with extensive trial and error, I cannot figure out what the appropriate x, y and z values are for this. This may be worth a new issue instead of this PR, though.

It'd be nice to integrate serde and allow for saving to bincode or json in addition to the data file method currently provided. It could include the time_step as well.

entity.rs needs a refactor. The branching on the right and the left is no bueno. Some alternatives:

• Keep the node structure but make a function do the stuff that's duplicated. Thread-spawn it (bench this) on big recursive calls and do both sides at once.
• Change left, right to [Node; 2]
• Node could be an enum of leaf or internal, getting rid of some options
• The tree should be an iter so we don't have to process the entire vec beforehand
• There might be better (unsafe?) ways to represent the tree in memory...maybe.

Adding custom derive macros for AsEntity and maybe the response function wouldn’t be too hard and would have high payoff.

Benchmarking the benefits of a fundamentally immutable structure would be great to have in the docs.

The ability to turn off collisions and set theta, time_step, and max_pts should be in some sort of tree_builder. additionally, I think that AsEntity shouldn't be implemented for Entity by default, that is the job of an example.

I'm pretty sure pub root: Node<T> in gravtree doesn't need to be public. Also my syntax of [[linking to other things]] appears to be invalid.

They really should be properties on the tree. Adding them to entities is not optimal. How can they be configurable?

All that we need is Mass.

When running the 2d_js example, the soft body collisions don't seem to be behaving properly.

The benchmarks using Criterion have highlighted that there is actually no performance benefit using a higher theta value, at least not in the situation of the benchmarks. This shouldn’t be the case. Some research on the frequency of theta being exceeded and how many nodes are actually in the trees should be conducted.

Look into, and maybe implement, offloading computation to the GPU.

Currently apply_acceleration() returns a new Entity, and there are a few clones when new nodes are made. Would it be possible to make apply_acceleration() mutate self and make the entire simulation zero-copy?

If using async/await improves benchmarks beyond what is currently done with Rayon, it should be used. However, it may need to be behind a feature flag or perhaps an additional synchronous entry point, because I don't know how well FFI will play with async/await.

• Total mass is sometimes zero. As a temporary workaround, i set it to f64::MIN if it is zero, but really it should never be zero.
• I need to refactor apply_velocity((f64,f64,f64), bool)) to a simulation_results struct and allow the implementor to do with the simulation what they want.
• Docs need to reflect all of this.
• Replace my own write data file functions with serde stuff.
• More particles = way more gravity...
• average of all accel forces instead of adding?
• use nalgebra for points and point math, perhaps. or just abstract into my own matrix math/simd thing

criterion

Some research and benchmarking is needed here. The nodes are defined as an Option<Box> which may or may not have perf impacts.