next »

[Juan Raigada]

That is a pretty significant limitation. He goes on to propose alternate solutions like having each component be its own rigidbody and attach with joints or something, but that is not good. I think KSP does something like that and they appear to have pretty significant performance problems with a huge number of parts. In Lift, there is a single rigidbody for a plane and the inertia tensor and center of gravity are calculated based on the components and their properties. I'm not an expert on the subject and my math is probably not entirely correct with the inertia tensor calculation, but it is giving the results I want for now. (comparing my calculations with what unity comes up with, the numbers are similar yet different enough to notice a difference)

I can think of a quick workaround. Use several overlapping colliders to give extra mass to a section. As long as your density differentials are not too crazy, you should be fine (taking into account the heavier/denser parts are definitely going to be fewer than the lighter ones on a plane, thus few parts will have "duplicate" colliders.

Performance wise, since there's space partitioning and colliders of a rigidbody don't collide with themselves (I think) you should be fine.

[forsy]

Just wanted to say how much I love this sandbox idea even just looking at the gifs The love that everyone puts into their creations is great to see Customisation is king!

Thanks for the comment. I am pretty blown away by what has been created already. I like to try to showcase some of the cool stuff as much as possible with the gifs and what not, but ultimately I would like to have systems in place for other people to showcase their own stuff in whatever creative ways they can come up with. And yes, there definitely needs to be more customization. I've already experimented with some simple color selection for parts which would help a lot, and that is just the tip of the iceberg.

I can think of a quick workaround. Use several overlapping colliders to give extra mass to a section. As long as your density differentials are not too crazy, you should be fine (taking into account the heavier/denser parts are definitely going to be fewer than the lighter ones on a plane, thus few parts will have "duplicate" colliders.

Performance wise, since there's space partitioning and colliders of a rigidbody don't collide with themselves (I think) you should be fine.

Very interesting idea. I'll have to do some tests to see just how effective that is.

Off the top of my head I have a feeling it will be quite cumbersome to figure out count, size, and placement of these sub colliders to get the proper mass distribution based on what the user selects for mass and center of gravity location.

(an hour later)

For example, let's say I have a plane and I strap a missile to it. The plane has a mass of 10000 and the missile has a mass of 1000. Separately, they would be two individual rigid bodies with their own mass and center of gravity. Once I attach the missile to the plane, that rigid body goes away and now I just have missiles colliders that get attached to the planes rigid body. Let's say the missile center of gravity was up near the nose. With using sub colliders, I would have to figure out how to not only get enough mass to match what the missile was but also figure out how to get the center of that mass to be in the same spot that it was when they were separate. The closer the center of gravity is to the nose, the less room there is to work with so you would probably end up with a ton of small sub colliders at the nose.

If the plane had a mass of 1000 and the missile had a mass of 1000, the whole thing changes and a completely different set of sub colliders would be needed to solve the problem.

Anyway, I'm still going to test this. I wonder if you set a collider to be a trigger, if that is included in mass calculation or not. That could help a lot.

[Juan Raigada]

Ok, you want dynamic attachments. Yeah, it's not going to work....

You have to calculate your own total mass, center of mass and inertia tensor (not that difficult) and then assign them to the rigidbody (there should be only one in each hierarchy) after you have modified the hierarchy. Those are automatically calculated by unity when assigning parent transforms, so assign the parents and then run your code to calculate those and assign them to the rigidbody.

Center of mass is trivial. Inertia tensors not that hard...

So you need custom Attach and Detach functions that recalculate those and delete/assign rigidbodies to the parentmost transforms...

[Pishtaco]

Yeah, my current project involves attaching and detaching things from rigidbodies and this is how I'm doing it. Except I'm fudging calculations for the inertia tensor rather than studying how to do it properly  .

[forsy]

Ok, you want dynamic attachments. Yeah, it's not going to work....

You have to calculate your own total mass, center of mass and inertia tensor (not that difficult) and then assign them to the rigidbody (there should be only one in each hierarchy) after you have modified the hierarchy. Those are automatically calculated by unity when assigning parent transforms, so assign the parents and then run your code to calculate those and assign them to the rigidbody.

Center of mass is trivial. Inertia tensors not that hard...

So you need custom Attach and Detach functions that recalculate those and delete/assign rigidbodies to the parentmost transforms...

Yeah that is essentially how it works now. I ran into some strangeness with Unity not maintaining my manual override of its center of gravity and inertia tensor, so at the moment those are calculated and applied every frame.

One performance issue that I've noticed is when planes with lots of parts get destroyed, creating and initializing the rigid bodies seems to cause a little hiccup in Unity. Not sure if creating a pool of kinematic rigid bodies on the side and grabbing them when needed would work. I have yet to look at any optimizations.

Yeah, my current project involves attaching and detaching things from rigidbodies and this is how I'm doing it. Except I'm fudging calculations for the inertia tensor rather than studying how to do it properly  .

This discussion is going to cause me to look into my inertia tensor math again because I know it can't be 100% correct.

my math is probably not entirely correct with the inertia tensor calculation

I'm fudging calculations for the inertia tensor

inertia tensor (not that difficult)

Inertia tensors not that hard...

So Juan, what are you not sharing with us?

I have a much better understanding of what it is and how it works than I did before, so I think another pass on it will do the trick. However, if you have any good reference material, please share

[Juan Raigada]

Yeah that is essentially how it works now. I ran into some strangeness with Unity not maintaining my manual override of its center of gravity and inertia tensor, so at the moment those are calculated and applied every frame.

One performance issue that I've noticed is when planes with lots of parts get destroyed, creating and initializing the rigid bodies seems to cause a little hiccup in Unity. Not sure if creating a pool of kinematic rigid bodies on the side and grabbing them when needed would work. I have yet to look at any optimizations.

Mmmm. Don't calculate your tensor every frame. I'm not 100% sure when Unity overrides those (I'm guessing when the hierarchy changes or a component is added, but I'll need to test). bUt if you know your structure has not changes, just store them in a variable instead of calculating them. That should save time... (maybe you are already doing this, it's just that your wording implied otherwise).

You could create the rigidbodies in a pool, but you will have to store them in their own objects, since they are components. I guess this will be very fast, but I wouldn't even make them kinematic (since you'll have to switch to non kinematic and that most likely involves a lot of physics calculations). Make them dynamic and disable them... I have noticed hiccups when creating a lot of physics objects before, specially if they are spatially close (I even crashed Physx in Heart&Slash when I generated the whole level as kinematic rigidbodies on top of each other (too many rigidbodies in the same space partitioning cell, I think).

[forsy]

Thanks for the tips, Juan. I'm not ready to go balls deep in optimizations yet, but I will definitely hit you up when I get to that point and pick your brain a bit. I'm sure by then Heart&Slash will be done and you will know all the tricks

---
And now back to fun progress type stuff... inertia tensors are so boring.

I was fiddling with some pause functionality tonight and just by pure random luck I managed to pause the game at the moment you see below in the gif. I was actually flying a different plane when I paused it and had a nice surprise waiting for me when I switched to this plane.



Game over for that dude. I think he was probably going 200m/s at the moment of impact.

[Juan Raigada]

Thanks for the tips, Juan. I'm not ready to go balls deep in optimizations yet, but I will definitely hit you up when I get to that point and pick your brain a bit. I'm sure by then Heart&Slash will be done and you will know all the tricks

---
And now back to fun progress type stuff... inertia tensors are so boring.

I was fiddling with some pause functionality tonight and just by pure random luck I managed to pause the game at the moment you see below in the gif. I was actually flying a different plane when I paused it and had a nice surprise waiting for me when I switched to this plane.



Game over for that dude. I think he was probably going 200m/s at the moment of impact.

I LOVE that gift!!!! I would play an aircraft crash simulator!

[forsy]

I LOVE that gift!!!! I would play an aircraft crash simulator!

Yeah, implementing this pause mechanic and capturing that beautiful moment in time has inspired me to add some additional sandbox features to the todo list. While these features aren't necessarily focused on building a crash simulator, they most certainly can and will be used for that purpose

[forsy]

And just for fun, slow motion.



I'm pleased with how easy this time manipulation stuff is going in, in regards to the physics. It is all just manipulation of Time.timeScale in Unity. Setting timeScale to 1 for a single frame and then the next setting it back to 0 seems to allow for accurate single frame stepping. I was afraid it would cause some strange inconsistent behavior, but it is looking good so far.

In the gif above, timeScale is at 0.1 for slow motion until the end when I set it back to 1 for real time.

[Juan Raigada]

You setting the timescale in FixedUpdate or in Update?

But yes, this could be epic! One cool thing that just came to my mind would be to predict hen a collision might be imminent and slow down, so you have either more reaction time to avoid it or to watch the mayhem.

[forsy]

You setting the timescale in FixedUpdate or in Update?

Update. FixedUpdate doesn't get called when timeScale is set to 0, and I set it based on key presses so I need to do that in Update. I might have to adjust the way it works because I think Update could be called twice in a row before FixedUpdate gets called and my single frame logic might not work. I haven't run into any problems yet though. Why do you ask?

But yes, this could be epic! One cool thing that just came to my mind would be to predict hen a collision might be imminent and slow down, so you have either more reaction time to avoid it or to watch the mayhem.

Good idea. I'm seeing the missile map currently in the game now and slowing time down as you see a missile flying at you to avoid collision. Things could get a little too crazy so I'll probably leave it as simple time manipulation for now and let it stew for a bit and explore some ideas down the road.

[forsy]

So I'm working on getting the challenges integrated into the main builds instead of being standalone things. And also setting them up so you can use any plane to do them, instead of a specific one that I choose. Much more fun to try this stuff with all the random stuff that is being built. And when I say challenges I mean challenge, I still only have the one that was released earlier. More to come though.

Anyway, a long time ago I built a glider and strapped it to some type of car like contraption and ran the car into a road block and the glider went flying off into the distance. At the time I thought that might be a cool loophole for some kind of challenge down the road.

glider

As I was testing the challenge with some different planes I happened to choose the pusher plane that I built a few days ago.

pusher

The challenge is set up so that when your plane crosses a certain line, it kills your engines and you have to glide to the finish. In the case of the pusher, I was expecting the same kind of result, except when I crossed that line nothing happened. I then realized it's because the plane has no engines and its forward thrust is generated entirely by the missile that is pushing it. The missile was unaffected and kept going at full power. And just like that, a loophole.

The way the code is set up, there are a couple other loopholes as well. I'm actually quite happy with having loopholes like this. Going forward, do I build challenges with these in mind and try to program them so there are a specific set of loopholes, or do I just build out the challenges and if loopholes exist, so be it? I've never been much of a puzzle game designer, so it might do more harm than good to try to force them in.

[billyboob]

Just realised this needs death star trench run as map. Space physics can come later (or never).

[forsy]

Just realised this needs death star trench run as map.

Definitely. We're going to need some tie fighters and x-wings though.

edit: Well, I gave it my best shot...

Space physics can come later (or never).

(or never).

Good call.

[forsy]

I made a death star. It wouldn't be appropriate unless it involved sky whale. I would have used supes but he can't fly anymore.

[Juan Raigada]

Update. FixedUpdate doesn't get called when timeScale is set to 0, and I set it based on key presses so I need to do that in Update. I might have to adjust the way it works because I think Update could be called twice in a row before FixedUpdate gets called and my single frame logic might not work. I haven't run into any problems yet though. Why do you ask?

Because of that same thing. It is called definitely more often than FixedUpdate is your framerate is good. In general, it's a bad idea to put logic in Update. I can see putting the controls in Update (the 0 timescale thing is an issue), biut not an automatic resetter, sinc eyou have no control over how frequently it's called.

Why do you need single frame logic?

One workaround would be using FixedUpdate except when you set timescale to 0 or back from 0 to a sensible number. That's the only case where FixedUpdate wouldn't work.

[forsy]

Why do you need single frame logic?

Because it's awesome

There's nothing specific to the gameplay that requires it, but it is fun to pause the game and step frame by frame to see how the simulation plays out during a crash or whatever. Like in the death star gif, I did that a couple more times and watched sky whale explode frame by frame.

To solve the issue at hand I'll just set timescale to 1 during Update and set a flag so when FixedUpdate runs the next time it can set timescale back to 0 if the flag is set.

[Juan Raigada]

Yeah, that's the solution.

This project is going to be so awesome to play with! You are getting me very excited about it!

[forsy]

Yeah, that's the solution.

This project is going to be so awesome to play with! You are getting me very excited about it!

Thanks Juan


And just a small update - in between building a death star and a tie fighter, I managed to put together an indiedb page for Lift yesterday.



Nothing new and nothing too exciting, but it definitely brought in a good number of new players. I don't know what that ranking means or how that system works, but it managed to get up to 41 at one point today. I probably need to proof read it again and maybe add some more details, but it seems good enough for now.

I am basically advertising this thing with all user generated content so far, so a big thank you to all who have contributed. And I really mean that. Each time I put these planes together for a screenshot, I can't help but be blown away by all the awesome stuff that has been created. Here are a couple images custom made for the indiedb requirements:





This environment I keep using is looking a bit stale. I need to open up environment editing so people can build all that content also

I have an updated build coming soon, hopefully early this next week. Nothing revolutionary, but there are a lot of changes and some new features.

Not a lot of people from indiedb tackled the editor, and those that did didn't produce much. My fears have come true, and the editor definitely needs a major overhaul. After this next update, I think I will make that the #1 priority. I have been thinking about it a lot and I have some cool things I want to try.

Just not enough hours in the day for all of this, especially with "real" work getting in the way.