Updated some docs to reflect current status.

Author: RossNordby

Documentation/PerformanceTips.md

@@ -20,4 +20,4 @@
 ## Solver Optimization
 -Try using the minimum number of iterations sufficient to retain stability. The cost of the solver stage is linear with the number of iterations, and some simulations can get by with very few.
 
--Watch out when there are a large number of constraints associated with a single body. The solver cannot solve multiple constraints affecting the same body at the same time, potentially limiting both SIMD and multicore parallelism. 300 characters on a spaceship represented as a single body may cause a sequentialization bottleneck. If this appears to be a dominant cost, consider splitting the offending body into multiple pieces. (If this becomes a frequently encountered issue, I may need to add in a fallback solver to handle this kind of corner case.)
+-Watch out when there are a large number of constraints associated with a single body. The solver cannot solve multiple constraints affecting the same body at the same time, potentially limiting both SIMD and multicore parallelism. 300 characters on a spaceship represented as a single body may cause a sequentialization bottleneck. If this appears to be a dominant cost, consider splitting the offending body into multiple pieces. (This tip should become unnecessary once the jacobi fallback solver is available.)

Documentation/StabilityTips.md

@@ -18,7 +18,7 @@
 
 -When trying to build rope-like constraint systems, it's likely that the solver will suffer from both mass ratios and the difficulty of propagating impulses through a long chain of bodies. In this situation, you can give the solver a little help by adding 'skip' constraints. That is, rather than creating distance limits only between adjacent bodies in a rope, try also connecting the first body to the last body (with an appropriately increased distance limit). In extreme cases, you could also create more skip constraints- connecting every other body or every third body, for example.
 
--When tuning the natural frequency of constraints, prefer values smaller than PI * 0.5 / timeStepDuration. Higher values risk oscillation that the time step can't represent, potentially leading to explosions.
+-When tuning the SpringSettings.Frequency of constraints, prefer values smaller than 0.5 / timeStepDuration. Higher values increase the risk of instability.
 
 -Once bugs and misconfiguration are ruled out and things are still behaving poorly, try decreasing the time step duration and updating the simulation more frequently to compensate. This is the single most powerful way to stabilize simulations, but also one of the most expensive.
 

Documentation/roadmap.md

@@ -2,7 +2,7 @@
 
 This is a high level plan for future development. All dates and features are goals, not guarantees. For a detailed breakdown of tasks in progress, check the [issues](https://github.com/bepu/bepuphysics2/issues) page.
 
-## Near future (Q1-Q2 2018)
+## Near future (Q2-Q3 2018)
 
 The big goals for the initial version are:
 - Performance should generally be an order of magnitude better than v1.
@@ -13,14 +13,7 @@ Note that this release will lack many of v1's built in features, like:
 - Full featured character controller (though I will likely provide a simple example version in the demos, just without the full upstepping/downstepping/stance shifting feature set).
 - Dedicated vehicle type.
 
-The initial version will be split into incremental stages: alpha, beta, and release.
-
-### Alpha (March 2018)
-This will be the first version that is likely to be useful to anyone, but far from everyone.
-- Spheres, capsules, and boxes.
-- List-based compound shape type. Primarily useful for small groups of shapes.
-- Basic non-contact constraints. Should be able to simulate a ragdoll.
-- Some extra convenience types for accessing body data.
+The initial version will be split into incremental stages: alpha, beta, and release. The alpha was released on March 31, 2018.
 
 ### Beta (April-May 2018)
 The beta will still be missing some important pieces, but should be able to support most games.

README.md

@@ -2,14 +2,32 @@
 
 This is the repo for the bepuphysics v2 library, a complete rewrite of the C# 3d rigid body physics engine [BEPUphysics v1](https://github.com/bepu/bepuphysics1).
 
-*The library is still early in development. Many important features are missing, and many bugs likely remain. Nothing is guaranteed to build or be usable.*
+The library is still in alpha. Many important features are missing, and many bugs likely remain.
+
+The alpha contains a basic featureset:
+- Spheres, capsules, boxes
+- Simple compounds of the above, mainly for use in smaller shapes where acceleration structures wouldn't be helpful
+- Highly nonidiomatic APIs
+- Automatic sleeping/waking management
+- Ball socket, hinge, swivel hinge, and swing limit
+- Speediness
+
+It notably does *not* yet include:
+- Convex hulls, cylinders, cones, or other complex shapes 
+- Efficient compounds supporting many children
+- Meshes
+- Bounciness, other than the frequency/damping ratio tuning
+- Continuous collision detection, other than the speculative margin
+- Scene-wide queries like ray casts or volume queries
+- Shape casts
+- Many useful constraint types
+
+If you are one of the brave early adopters, you can report bugs [here on github](../../issues). 
 
-You can keep an eye on incremental progress in the [issues](../../issues). 
+Visit the [forums](https://forum.bepuentertainment.com) for discussion and questions.
 
 Check the [roadmap](Documentation/roadmap.md) for a high level look at where things are going.
 
-Visit the [forums](https://forum.bepuentertainment.com) for discussion and questions.
-
 There exists some sparse proto-documentation:
 
 [Q&A](Documentation/QuestionsAndAnswers.md)