Collision System Rewrite: below the surface (expected in Alpha 13)

[Greenleaf]

This video is essentially meant to show that behind the pretty surface (and, damn it is pretty!) is a lot of code, math and physics. Other point was that I wanted to show that stuff is not just flying about. It actually obeys the physical laws.... well... as many as we reasonably can care about :-)

[Dan Dixon]

This is a really exciting update... Thanks for all your work on this Thomas.

If things go well, we expect this collision rewrite will be in the next release, Alpha 13.

[smjjames]

Ooh, so Roche Limit will be in Alpha 13? cool. That's going to be fun to play with, especially flinging stuff at Jupiter.

Also, what do you mean by semi-large moons? Like what mass? And does that mean that if you fling Earth close enough to Jupiter, it won't suffer fragmentation at this time?

Also, could you guys implement a roche limit indicator?

[Gordon Freeman]

These are really awesome first steps into SPH development. Great work, Thomas!

Also, could you guys implement a roche limit indicator?

What would that do?

[Greenleaf]

...what do you mean by semi-large moons? Like what mass?
...could you guys implement a roche limit indicator?

As I stated, it was limited for testing. Just added it yesterday and needed to make sure I didnt end up with a gazillion fragments right away when things fragmented and refragmented. In that test it was only for radius above 1000km. In the more polished version it will be handled differently, so it feels nice and gradual.


Several factors are added as options for Roche limits. The test had it set the distance to 1/9th sensitivity, meaning that a read limit of 100.000 km would become 11.111 km, so a moon has to come closer than reality before crossing over. That can be controlled by the user. That it only fragments (in the test) that much closer than it should, is also the reason the fragments, when formed, pulls apart that quickly. It would otherwise be a more "gentle" process.

[Greenleaf]

These are really awesome first steps into SPH development. Great work, Thomas!

Thanks :-)
Have to, in the spirit of being accurate, point out that this has exactly nothing to do with SPH. It is still the high performance fallback method, which describes bodies as spheres and only calculate gravity. Accretion/coalescing has no sense of pressure or viscosity. All collisions are essentially gradual inelastic merges... clumps of clay slowly sticking together.


But that said, it does aim to provide much of the same look and feel as proper fluid calculations will eventually, just for a fraction of the computational cost.


Getting there... ever so slowly.

[Camacha]

This is looking very convincing. My gripe with most cinematic animations is that breakups and such always look overly contrived. Here it already looks pretty natural. Which is, of course, the point of this software, but still.

I must say I also like the very schematic graphics style. It tickles my inner science nerd. Maybe an idea for another render mode?

Can I ask what hardware is used in the video (and thus the development of US²)?

[Greenleaf]

This is looking very convincing. My gripe with most cinematic animations is that breakups and such always look overly contrived. Here it already looks pretty natural. Which is, of course, the point of this software, but still.

I must say I also like the very schematic graphics style. It tickles my inner science nerd. Maybe an idea for another render mode?

Can I ask what hardware is used in the video (and thus the development of US²)?

Thanks for the positive comment. Yes, sometimes the real physics does look a bit less exciting than the movies. Same goes for small scale explosions as well, it seems... or perhaps physics guys just claim that it is so, because we suck at making nice graphics ;-)


The schematic view (which is in an entirely different application written for testing this) is something I wouldn't mind seeing in US² as well. Seems like a good overview and suitable for teaching.


As to hardware. Personally running win 8.1 on an i7 5820K 3.3GHz and a radeon hd 7900. I am sure some of you have much better systems than that. Others develop/test on slower systems like laptops. Essentially the program should run ok'ish on most non antique hardware, so it would be counter productive if we all had the latest and greatest.

[Plutonium]

Looks impressive!
A few questions:
If the distance where it starts to break up will be user defined, then how will it behave and look like if the number is set too high??
If two equal size and mass bodies are involved will they both break apart?

...I must say I also like the very schematic graphics style. It tickles my inner science nerd. Maybe an idea for another render mode?..

I liked it too...

[Greenleaf]

If the distance where it starts to break up will be user defined, then how will it behave and look like if the number is set too high??
If two equal size and mass bodies are involved will they both break apart?

If you look at the definition for the Roche limit
http://en.wikipedia.org/wiki/Roche_limit


distance=1.26*moonRadius*cubeRoot(planetMass/moonMass)


if we assume planet and moon are identical, then this reduces to


distance=1.26*radius

So, in this form, for a planet with a radius of 6371km, the center distance when there  is breakup is essentially after they collided, since at distance=2*radius, they are just starting to touch.

Obviously the Roche limit is a simplified ideal description, but the point is that if you use a sensitivity of one, then equal bodies need to collide to enter the limiting distance.... setting a higher sensitivity... well... yes, then you could see planets break apart before touching, but I might consider limiting the sensitivity to realistic or lower sensitivity, to be able to handle all the fragmentation.

nb. The distance is not user defined. That is calculated. This distance can then be scaled by the user.

[Camacha]

Yes, sometimes the real physics does look a bit less exciting than the movies. Same goes for small scale explosions as well, it seems... or perhaps physics guys just claim that it is so, because we suck at making nice graphics ;-)

Real physics look good enough, better even. I never understood why Hollywood explosions are those yellow gas filled blobs when real and proper ones are so very impressive. The same goes for these collisions - cinematic clips typically tend to look animated (which they are) and spectacular in all the wrong places, but this looks a lot more natural and, I would say, dramatic. I mean, it is a planet breaking up, what more do you want?

Give me a scientific simulation with at most a thin layer of artistic interpretation and I am a happy camper. I am curious to see what you guys can come up with!

As to hardware. Personally running win 8.1 on an i7 5820K 3.3GHz and a radeon hd 7900. I am sure some of you have much better systems than that. Others develop/test on slower systems like laptops. Essentially the program should run ok'ish on most non antique hardware, so it would be counter productive if we all had the latest and greatest.

I would pretty much call that the latest and the greatest. CPU wise this is pretty much the pinnacle of consumer grade kit at the moment and the GPU has been surpassed, but can hardly be called outdated or slow. Colour me jelly, I could use those 12 threads for renders and all kinds of assorted mischief. Need? No. Want? For sure.

I agree with not needing to develop on the fastest hardware though, it makes for lazy programming, har.

[Greenleaf]

I agree with not needing to develop on the fastest hardware though, it makes for lazy programming, har.

Ya. I remember when I was coding assembler and explicitly always did xor ax,ax instead of mov ax,0 since both accomplished the same, but the first was a clock cycle faster...and that is the trivial example... or when packing multiple data parts into a single number to save memory space etc. etc. Now it is more important to just write easy to develop and maintain code. Though looking at the asymptotic cost of an algorithm never becomes irrelevant.


As to real vs graphics-sugar-coated. A real simulation will generally be very cool, but the sad thing is that we have a limited budget for computation, so that tends to limit the resolution. That in turn can require some of the higher resolution parts to be emulated via graphics without actual simulation.

[Lord DC]

Either way, I think this will definitely be a very good start to the things you guys hope to implement. I look forward to seeing what people make when it is released, seeing as a rough form of accretion is being implmented

Nice work Greenleaf 

[Bla]

Very nice work, the Roche limit feature looks very cool.

[Retsof]

How does the fragmentation work?  Does a body split into a pre-determined number of pieces, or are all the pieces a certain mass, giving you more fragments for a larger starting body?

[Greenleaf]

How does the fragmentation work?  Does a body split into a pre-determined number of pieces, or are all the pieces a certain mass, giving you more fragments for a larger starting body?

Fragmentation from collisions is based on calculating the released energy and the melt volume this will give. Then that volume is taken from the colliding objects and turned into fragments. The number of fragments depends on the current performance on the current hardware.


The current fragmentation for Roche, which is really just a quick test, fills a body with fragments positioned in a regular 3d grid inside the body in order to form a sphere or, if the body is colliding, a section of a sphere. Those positions are then slightly randomized and fragments form at them.

[gabriel.dac]

The number of fragments depends on the current performance on the current hardware.

That's nice to know.  As I watched the video, I was kinda worried, thinking that the fragmentation would cause too much lag on my poor computer.

[WitheHole18]

It's a good and cool new!
Good work

[Jim Jam Science Mans]

These are really awesome first steps into SPH development. Great work, Thomas!

Also, could you guys implement a roche limit indicator?

What would that do?

It'd help people avoid placing small bodies too close to their parents - or the opposite, if they specifically want tidal disruption of a body to create a debris ring, etc. It should also be fairly trivial to incorporate.

[Gordon Freeman]

Oh, like the Hill Spheres and Lagrange Points features in US1?

[Masterofworlds22]

This will be perfect for what I am planning.

[Greenleaf]

Ooh, so Roche Limit will be in Alpha 13? cool. That's going to be fun to play with, especially flinging stuff at Jupiter.

Perhaps it will. It is not a given, though, since it takes some time to go from initial testing to a version which is added to the product.

Also, could you guys implement a roche limit indicator?

I didnt really notice what you were asking before now, but, yes, we could. The limit is not a constant of the parent body, but depends on "moons" mass and size as well, so it would essentially be a per-body-placement indicator. It seems like a good idea still and with different scaling of the tidal effects, it might help a lot in setting up interesting scenarios.

[smjjames]

Ooh, so Roche Limit will be in Alpha 13? cool. That's going to be fun to play with, especially flinging stuff at Jupiter.

Perhaps it will. It is not a given, though, since it takes some time to go from initial testing to a version which is added to the product.

Also, could you guys implement a roche limit indicator?

I didnt really notice what you were asking before now, but, yes, we could. The limit is not a constant of the parent body, but depends on "moons" mass and size as well, so it would essentially be a per-body-placement indicator. It seems like a good idea still and with different scaling of the tidal effects, it might help a lot in setting up interesting scenarios.

Didn't Ubox 2 (the 2010 one) have a roche limit indicator? I forget exactly. If it did, it was definetly a fixed width, but you know, limitations of that iteration)

You're right though with it depending on the bodies involved, so it can be done with comparing the parent body with the one being edited. Although not sure how you would do it if you just wanted to look at the roche limit vs two different bodies without actually editing anything. I'm sure you guys can figure something out.

Perhaps put some kind of indicator on the predicted path when the roche limit visualization is active? Just ideas.