I think the color range for the Velocity and Acceleration color mode should be flipped.
As far I know violet-blue colours are mostly used to indicate when something is high, while red-yellow colours indicate when something is low.
I think of red as fast and blue as slow... But I can imagine that this is not the standard. Can anyone find examples where color is used to show speed?
Here's an example where red is high:
http://mappery.com/map-name/Printable-World-Map-Elevation-Wik
Here's an example where blue is high:
http://mappery.com/map-name/Digital-Elevation-Map-of-Lunar-South-Pole
I think the first map might be based upon height data created by radiographic measurement of the earth. This would means that the surface parts who are close to the satellite (mountains) are coloured red and the rather distant parts blue. The second map looks rather demonstrational since it has a 0 point colour defined.
However I'm not entirely sure about the colour controversy. I think I've seen a lot of maps based upon radio data which used blue / violet as colour to indicate maxima. But it might be that researchers just choose the way the color range goes after their personal preference.
Timed Screenshots
Universe Sandbox does this already, but it's not at all clear. If you right click, next to the movie button is a text box, this number is how frequently (in frames) to take a screenshot. If you set it to 1 then movie mode takes a screenshot every frame. Would you prefer that this was not frames, but simulation time?
But this only describes how much frames should be saved as screenshots per second, right?
What I'm rather thinking of is letting US take one screenshot after every 60 or 30 seconds, or any user wanted time intervall.
If you decide to make trails multicolored according to the velocity and acceleration changes, it would be pretty easy to show these data in the chart mode. Maybe this way:
http://i278.photobucket.com/albums/kk114/FGFG-23/GraficoUniverseSandbox.jpg
Wow I love your idea. However Dan, if you consider adding any time based stats tracking similiar to this also add an option to disable. I do suspect that I might cost a lot of performance in large system.
And some feature suggestions again:
The Event Log:I suggest to introduce a simple event log, which simply logs objects collisions and mergings, as well as the time of the events. This would especailly help the user of keeping track of the events happening in large scaled systems.
Gravity Mapping:The very interesting thing about the 2D grid is that it shows in acceleration mode during the first seconds a gravity map of all massy objects. You can even see the low gravity zones in which some of the lagrange points are situated It might be really interesting to introduce some sort of fixed and improved version of that 2D grid for gravity mapping.
The little yellow dot between the Earth and Moon is actually where L1 is situated.
Thinking about including it, I think the first and simplest way would be simple to introduce a slice of very dense ordered but fixed particles. Like the current 2D grid. However it could be selected and simply moved around the dimension. Or rotated.
A bit like the slicing function in this demonstration of the magnetic force:
http://www.falstad.com/vector3dm/