Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1409784 Posts in 69116 Topics- by 62786 Members - Latest Member: curvyhump

December 01, 2023, 05:24:14 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsGearBlocks - Build working physics based machines and mechanisms [EARLY ACCESS]
Pages: 1 2 [3] 4 5 ... 12
Print
Author Topic: GearBlocks - Build working physics based machines and mechanisms [EARLY ACCESS]  (Read 46630 times)
dangersam
Level 2
**



View Profile WWW
« Reply #40 on: July 10, 2014, 01:59:27 PM »

Tutorials

Here's a series of tutorials I've made that attempt to explain the basics of how to build stuff.  Hopefully they'll be useful to anyone who's just starting out playing my game!

Tutorial 1: Attaching parts rigidly -


Tutorial 2: Attaching parts that can rotate -


Tutorial 3: Part behaviours - https://www.youtube.com/watch?v=cCqKnFoQqFw
Tutorial 4: Gears - https://www.youtube.com/watch?v=WtG95K2A0nw
Tutorial 5: Building a simple car - https://www.youtube.com/watch?v=VdtGsk2zJWY
Tutorial 6: Making a car steering mechanism - https://www.youtube.com/watch?v=wzYQ_9hRqkY
« Last Edit: December 22, 2015, 09:16:13 PM by dangersam » Logged

dangersam
Level 2
**



View Profile WWW
« Reply #41 on: July 19, 2014, 12:26:10 AM »

A few minor updates

Over the last week I’ve mostly been working on project planning stuff, but I did make a few minor tweaks to the build.  Now the graphics and sound settings get saved and re-loaded.  There’s also an option to enable vsync, and when creating a new “sandbox mode” game, you can set some basic time-of-day settings.

Next week, more project planning.  Wanna get this out of the way so I can get back to designing & coding!
Logged

dangersam
Level 2
**



View Profile WWW
« Reply #42 on: July 25, 2014, 11:40:18 PM »



New stuff in the game this week: improved the rendered images of parts in your inventory, did a whole bunch of asset tweaks, and added some new parts to build with!
Logged

dangersam
Level 2
**



View Profile WWW
« Reply #43 on: August 06, 2014, 12:20:11 PM »

Rendering overhaul

In Unity, full-screen image effects, such as screen-space ambient occlusion (SSAO), bloom and tone-mapping, can only be applied after everything else has rendered.  You can optionally flag image effects to render between opaque and transparent stuff, but that doesn’t help me because image effects wipe the stencil buffer, which I need for object highlighting.

Previously there were many things about the rendering order in the game that were just plain wrong.  For example, SSAO was being applied after water and atmosphere / fog, and 3D UI elements were being bloomed and tone-mapped.  Ideally you want to be able to interleave image effects and other rendering at will.  The only way to do this in Unity is to use multiple cameras (with only the first one clearing the screen, the rest rendering on top).  Here is how I have things set up now to achieve the correct rendering order:-

Camera 1
  • Clear screen.
  • Render opaque objects (e.g. terrain and other solid objects).
  • Render object highlighter mask texture using stencil values written by object shaders.  This has to be done before any image effects, as they wipe the stencil values.
  • Render SSAO full-screen image effect.
  • Render atmosphere / fog as a full-screen image effect.

Camera 2
  • Render transparent objects (e.g. water), these apply atmosphere / fog in their shaders.
  • Render object highlighter full-screen image effect, using mask rendered earlier.
  • Render sun shafts, bloom and tone-mapping image effects.

Camera 3
  • Clear depth only.
  • Render 3D UI elements.
  • Render 2D UI / menus etc.
  • Render anti-aliasing full-screen image effect.

Unfortunately, using multiple cameras like this exposes some long standing bugs in Unity which really screwed me up for a while.  Luckily there are known workarounds for these, for more info you can check out these threads:-

Ambient occlusion

I’ve also fixed some issues with SSAO that were causing black speckly artifacts to show on the distant terrain.  Now that SSAO looks much nicer, I’ve enabled it by default.  I’ve also fixed a bunch of other bugs and issues!
« Last Edit: August 07, 2014, 10:13:54 AM by dangersam » Logged

Thanar
Level 0
*


View Profile
« Reply #44 on: August 07, 2014, 12:44:27 AM »

Hey! Great stuff so far =D I love Garry's Mod, and you got here some of its charm.

Do you plan on adding some kind of survival mechanics? like having to eat or waves of enemies from time to time?
Logged
dangersam
Level 2
**



View Profile WWW
« Reply #45 on: August 07, 2014, 10:48:52 AM »

Hey! Great stuff so far =D I love Garry's Mod, and you got here some of its charm.

Do you plan on adding some kind of survival mechanics? like having to eat or waves of enemies from time to time?

Thanks Thanar!

I am planning on having a system based around energy (e.g. motors, lights etc. cost energy to run, materializing new parts costs energy, energy can be gained from solar panels, reactors etc.)  I want to incorporate player health into this too somehow, which would make it a survival mechanic of sorts.  I had thought of having NPC enemies, but they're cut for now, the scope of this project is already way too big! Smiley
« Last Edit: April 07, 2016, 08:35:09 PM by dangersam » Logged

Flatgub
Level 0
***


My existence is questionable at best


View Profile
« Reply #46 on: August 08, 2014, 01:15:10 AM »

This looks awesome! definatly following Azn
Logged

dangersam
Level 2
**



View Profile WWW
« Reply #47 on: August 26, 2014, 03:11:47 PM »

Dev diary:



Construction controls update

Over the last couple of weeks, I’ve made a couple of changes to the controls:-
  • After parts have been attached together, you can now cycle their attachments between available types (e.g. rigid or hinge), by hovering over attachments and pressing E.
  • Cloning and deleting entire constructions is now done via a separate menu (accessed by holding Shift + Q).

More rendering improvements and other fixes

Also now in the build:-
  • A load more rendering improvements following on from the previous overhaul.  The main difference being that the sky and distant water are now rendered before everything else, using another separate camera with a much larger far clip distance.  This prevents the horizon line from being clipped out.
  • Time-of-Day upgrade.
  • Reference grid in inventory part preview images.
  • Force zones now slow down objects at world boundaries.
  • A bunch of bug fixes.
« Last Edit: December 22, 2015, 09:05:46 PM by dangersam » Logged

Didi
Level 0
**


View Profile
« Reply #48 on: August 26, 2014, 05:17:31 PM »

Looking really good an interesting. Love the idea of game modes you had on the first page.

One of the first things that came to mind when I was seeing your devlog is the idea that you might need to build certain machines to create bigger machines or contraptions. Maybe it contradicts the freeze mechanic of building. But for instance, have to come up with some kind of crane to lift other players in order to build taller structures.

Anyway, just a random thought for the future. It's looking really good. Following.
Logged
dangersam
Level 2
**



View Profile WWW
« Reply #49 on: August 27, 2014, 11:31:53 AM »

Looking really good an interesting. Love the idea of game modes you had on the first page.

One of the first things that came to mind when I was seeing your devlog is the idea that you might need to build certain machines to create bigger machines or contraptions. Maybe it contradicts the freeze mechanic of building. But for instance, have to come up with some kind of crane to lift other players in order to build taller structures.

Anyway, just a random thought for the future. It's looking really good. Following.

Thanks for the words of encouragement Didi, means a lot!  Yeah, using machines to build even bigger constructions should be possible, using lifts and cranes etc.
« Last Edit: April 07, 2016, 08:35:34 PM by dangersam » Logged

dangersam
Level 2
**



View Profile WWW
« Reply #50 on: August 29, 2014, 10:15:42 PM »

Centre-of-mass indicator and bug fixes

This week not much outwardly apparent has changed with the game but I’ve fixed a load of bugs, including a fairly major error in the gear constraint code that sometimes caused gear trains to gain too much angular velocity.

I’ve added an indicator that shows a construction’s centre-of-mass when you freeze it.  This will be useful when you want to balance a construction around a pivot point or centre-of-lift (e.g. flying vehicle, see-saw, etc.).
Logged

dangersam
Level 2
**



View Profile WWW
« Reply #51 on: September 29, 2014, 11:39:59 AM »

Gear physics - a bit of a setback

I just realised it’s been ages since my last post!  This is because there hasn’t been anything new in the game to speak of over the last few weeks.  Unfortunately, progress on the project was completely halted when I discovered a serious flaw in my gear constraint implementation.

The problem is, it is only transferring rotational motion between gears, not linear motion.  This works for static constructions with rotating gears, but as soon as the gears themselves move about, it is totally (noticeably) incorrect.  If I can’t fix this, then it pretty much screws up the rest of the game as I have it planned.  So I need to try and get it sorted before proceeding with anything else.

Over the last few weeks I have been digging through Box2D and Bullet code for inspiration, and have tried a few different solutions with varying degrees of success.  I have one idea I’m pursuing at the moment that seems promising, but we’ll see, it may come to nothing.

The good news is, if I can fix this gear physics issue, it’ll fairly easily allow me to add rack and pinion gears (where linear motion is obviously crucial).

Honestly, I’ve been very demotivated by this setback.  The game wasn’t progressing as quickly as I’d like anyway, and this really hasn’t helped.  It’s been a real struggle to keep going.  Hopefully I’ll figure out a solution soon, wish me luck!
Logged

dangersam
Level 2
**



View Profile WWW
« Reply #52 on: November 01, 2014, 11:17:36 PM »

New gear physics

Well, after many weeks of trial and error, experimentation and frustration, I think I finally have a solution for the gear physics!  To recap, the problem with my old implementation was that it was only considering relative angular motion between the gears, and not linear motion as well.  This made the gears behave incorrectly if they had any relative linear velocity.

Need for a new solution

My old gear physics implementation was inspired by the one in Box2D, so I looked there again for ideas.  It turns out they work around this problem by also taking into account the angular velocity of the rigidbodies that the gears are attached to.  I played around with this idea for a while but I found it didn’t really extend well to my more general 3D case.

There were also other things to consider, like supporting other types of gear such as rack and pinion.  Also, the fact that my gear physics was only updated once per FixedUpdate (and not as part of the main PhysX solver update) caused lag, or “wind-up” between the gears under high torque loads.  A compromise I was living with, but was never really happy about.

Using configurable joints

So I decided to throw out my old approach and instead make use of the built in PhysX constraints (or “joints”), as exposed by Unity’s ConfigurableJoint.  The idea was to position the joint anchors at the current contact point between the two gears (right at the edge of the gears where they touch), and then lock the motion only along the tangent at that contact point.  Then every FixedUpdate, the joint anchors are re-positioned to the current contact point (as the gears will have moved slightly).  By carefully positioning the anchors like this, the gear ratio (relative torque transfer), and the relative angular and linear motion are all taken into account automatically.  This approach also makes it relatively easy to add support for rack and pinion gears.  And…by using built-in joints, the gear constraints are solved along with everything else, so there is minimal wind-up.



Sounds good in principle, right?  However the re-positioning of the joint anchors is where things get tricky.  If every fixed update, they are simply re-positioned exactly to the new contact point, the gears will gradually slip when under load.  This is because a joint doesn’t perfectly rigidly lock its anchors together, and there will usually be a small difference in position between them, even after the physics solve.  This error gets fed back into the new joint anchor positions and the error accumulates over time.

Correcting the joint anchors

So I tried correcting for this error by figuring out what the anchor position delta was vs. what it should have been.  This is not easy because there is not really an absolute angle for a rigidbody, only an absolute position.  The orientation angles of a rigidbody wrap every 360 degrees of rotation, so you’ve no idea how many of these rotations have happened since the last update.  You end up having to integrate velocity over time and accumulate the positional delta as found at the contact point between the two gears.  There are two problems with this.  First, I found that when comparing the contact point velocities between the two gears as reported by Rigidbody.GetPointVelocity, they seemed slightly off if the gears were moving linearly relative to one another.  Close, but not spot on.  This small error was compounded by the second problem, which is that by accumulating the contact position delta over time, any errors also accumulate - quickly.  It creates a feedback loop, the error feeds into the joint anchors, which causes the joint to pull the rigidbodies around too much, causing more positional error, which feeds into the new anchor positions in the next update, and so on.  This leads to unstable physics behaviour - high impulses, oscillations, and your machines exploding like crazy.

At this point I got pretty desperate, thinking I might have to abandon gears altogether, maybe even the whole game.  I even tried mocking up a solution using physics colliders (one BoxCollider for each gear tooth!), and using the collisions between the teeth to provide the gear behaviour.  Er yeah - that didn’t work unsurprisingly.

Predefined anchor positions

Then I came up with the idea for the solution I have now.  Re-positioning the joint anchors exactly to the gear’s contact point leads to accumulated error and gear slip.  So instead, each gear is given predefined positions at equal intervals around its circumference, and every update the one closest to the current contact point is found, and that’s the position used for the joint anchor.  As long as the distance between these predefined positions is greater than the distance between the joint anchors after the physics solve, you get no gear slip.



However, there is a problem with this if the gears are different sizes, as shown above.  The next / previous predefined anchor positions as measured along the contact tangent don’t quite line up due to the differing radii.  I tried correcting for this with a fun bit of trig, the maths worked out beautifully, but in practice it led me right back to another feedback loop, the joint and its corrected anchor positions ended up fighting each other, causing oscillations, exploding machines and much cursing.  In the end I just went with a simpler approach of just upping the number of predefined anchor positions, so that any differences along the contact tangent were minimised.  However, this of course means the distance between each predefined position is smaller, so increasing the chance of gears slipping under load.  In practice it’s actually not too bad though, it takes quite a high torque load to cause slip (to the point where axle hinge joints are also being noticeably pulled apart).

Next steps

This whole endeavour has been very frustrating, as the ideas I tried often worked fine most of the time, only to fail in particular use cases (certain combinations of bevel gears seemed to be particularly sensitive).  I spent a lot of time switching back and forth between my various approaches, trying different modifications, until homing in on what I have now.  It was so time consuming as I had to do lots of testing every time I made a change to check that I hadn't broken one of my many test cases.

Well, hopefully the implementation I ended up with will see me through.  I’ve tested a lot of situations (complex gear trains, high torque loads, high rpm, etc.) but the open ended nature of this game means I might have missed a case where things go bad, let’s hope not.  Next up I’m going to work on implementing rack and pinion gears, and probably worm gears too, I wanna really be sure these will actually work with no problems, before going ahead with any other part of the game.
« Last Edit: January 27, 2015, 11:26:28 AM by dangersam » Logged

dangersam
Level 2
**



View Profile WWW
« Reply #53 on: November 06, 2014, 09:42:16 PM »





New gears now in the game

This week I’ve been working on a Python script for Blender to procedurally generate the meshes for all the various gears I need.  I’ve also added support in the game for crown gears, which engage with neighbouring spur gears at 90 deg.

Next I’m gonna extend the Blender script so it can generate a rack gear mesh, and then have a go at implementing support for rack gears in the game.
Logged

dangersam
Level 2
**



View Profile WWW
« Reply #54 on: November 14, 2014, 09:12:20 PM »

New rack gear added

I’ve just added a rack gear to the game, useful for rack and pinion steering among many other things.  Rack gears engage with spur gears that are positioned directly above them.



The implementation is still preliminary and still needs a bit of refactoring / cleanup, but it seems to work well so far, which is a relief.  It looks like my gear physics solution is holding up!

There is one significant issue remaining with gears generally however, which applies to all gear types but is particularly highlighted by rack gears.  Whenever a construction is modified (by adding or removing a part), a search is performed to find pairs of gears that are next to one another and should be considered engaged, and then a physics constraint is set up between each pair.  However this is done only once, after the construction is unfrozen and things start moving about, the gear engagement pairings are not updated.  Obviously this becomes a problem if the gears move apart from one another, it also won’t engage gears that start off apart, but then move together.

So I think my next big task will be to overhaul the gear engagement system so that it updates dynamically.  It will need to be reliable, and not incur a big performance cost doing lots of spatial searches etc. could be tricky!
Logged

dangersam
Level 2
**



View Profile WWW
« Reply #55 on: November 26, 2014, 04:05:49 PM »

Dynamic gear engagement

The engagement between gears is now activated and deactivated dynamically.  This means (as the various parts of a construction move around) gears will engage if they move close enough to each other, and disengage if they move apart.  The test that checks if a pair of gears are engaged is fairly expensive, and obviously I now have to do these tests every update.  So to avoid doing this between every pair of gears in a construction (i.e. O(N^2), not good), I use trigger volumes around each gear to find pairs of gears that are close to each other, and then do the engagement check only on these.

New steering wheel part

I've added a steering wheel part to the game that attaches to axles.  It has a behaviour similar to the motor, where if "switched on" it will rotate in response to user input (i.e. the usual hold shift + directional controls).



Its obvious application is as a vehicle steering wheel, but more generally it can be used as a "control wheel" anywhere you want to rotate bits of your construction in response to user input.
Logged

dangersam
Level 2
**



View Profile WWW
« Reply #56 on: November 28, 2014, 02:35:05 PM »

Collision bug update 2 - fixed!

A while back I encountered a bug in Unity where adding parts (that had a mesh collider) in a particular order to a construction would cause physics collisions between some parts to fail.  This would break the construction mechanic from then on as I rely on getting collision callbacks to know when parts are positioned appropriately for attachment.

Well, as far as I can tell this has been fixed as of the latest Unity release!  I didn’t get any update on the bug report I submitted, so perhaps it was fixed in relation to some other bug, either way it seems to be sorted now which is awesome.  Here’s hoping I don’t find any other similar issues…

But…of course there’s always something else to worry about!  I’ve recently noticed an odd behaviour where long, thin rigidbodies (such as axles) that have angular velocity around their long axis, tend to completely lose that angular velocity when rotated around other axes.  It’s like a massive braking force is applied to their rotation.  So I need to do some experimentation to figure out if there’s anything I can do to mitigate this (perhaps by fudging the inertia tensor or mass).
Logged

dangersam
Level 2
**



View Profile WWW
« Reply #57 on: December 15, 2014, 06:40:29 PM »

Another physics problem

A few weeks ago I noticed an odd physics bug in the game, where if part of a construction was rapidly rotating around one particular axis, that rotation would be massively slowed if the construction as a whole was also rotating about another, perpendicular axis.  For example, a rapidly spinning axle (acting as a drive-shaft) running longitudinally in a car would be almost completely stopped if the car yawed or pitched (say when steering or coming off a jump).

There is a gyroscopic effect that applies to a rapidly spinning object, where if you try and rotate it about a second axis perpendicular to its spin axis, it will want to rotate about about a third axis perpendicular to both.  Similarly, if you prevent it rotating about one perpendicular axis, it will resist rotation about the other.  This happens in game physics, just as it does in the real world (it's what keeps bicycles up!)  In Unity's physics (PhysX 2.83) when this resistance to rotation is counteracted by the hinge constraints holding the object's rigidbody in place, it's as if a large torque gets applied that dramatically reduces the rigidbody's angular velocity about its spin axis.  I'm no expert on the physics of gyros, it's possible that this is a real world effect that is just exaggerated in PhysX - but regardless it didn't feel correct to me and could completely screw up a construction's behaviour in the game.

I did some tests using other physics engines - a later version of PhysX (3.3) and Bullet.  I reproduced the same issue in both, so I'm assuming it's a common behaviour among most, if not all, physics engines, and that porting over to a different one isn't going to help me.

Hack and slash

I tried hacking around the problem by overriding the mass and inertia tensor of a rapidly spinning rigidbody, but to no avail.  I tried adding an "artificial" torque to counteract the slowing down effect on the spinning rigidbody, but that just caused stability issues with the hinge constraints.  It was as if all the forces were fighting each other, and something had to give!

I considered implementing a custom pseudo-physical solution specifically for drive-trains (i.e. motors, axles and gears), but this would have been a huge amount of work, it would have been very difficult to integrate nicely with the PhysX physics, and would have almost certainly limited the behaviour and physical realism of the constructions.

At this point I was really stuck.  I contemplated ignoring the issue and simply living with it, but that just wasn't acceptable to me.  Another option would have been to completely remove all rapidly spinning stuff (like gears and axles) from the game, but after all the work I've done so far, I really didn't want to do this.  Besides, it would have hugely reduced the scope of what could be built in the game, and taken away from what I think will make it unique compared to other building / sandbox type games.

An error / performance trade-off

Fortunately I found a way out.  I discovered that reducing the physics fixed update time-step minimised the problem to an acceptable level (albeit not eliminating it altogether).  I believe the issue is due to mathematical error that occurs with a combination of very rapidly spinning rigidbodies and a fairly large time interval between physics updates.  I can't really lower the cap on how fast stuff can spin (not without placing undue limits on the constructions that can be built), so my only option was to update the physics more frequently with a smaller time-step.  Of course this comes with a significant performance cost, but it looks like it's a trade-off I'll have to make.

So when you play the game now you may notice a performance slowdown (depending on the complexity of your constructions, and your computer spec).  Next up, I plan to remove as much code as possible from my fixed update callbacks (these get executed at the same rate as the physics update), to try and mitigate this as much as I can!
Logged

dangersam
Level 2
**



View Profile WWW
« Reply #58 on: December 19, 2014, 05:42:20 PM »

Fixed update optimisations

Now that I’ve had to reduce the physics update time-step, any code in my fixed update functions is much more performance critical.  So this week I tried optimising as much of it as I could.  Unfortunately there weren’t really any places I could move update code out of the fixed update altogether, but I did manage to speed up a few things.

I’ll probably have to revisit fixed update performance at some point, but for now I’m gonna move onto the next thing.  Next up I think I’ll look at reworking the system that determines how parts can attach together, to make it more flexible and allow for more interesting part pairing relationships.  This’ll be required for some of the new parts I want to add in the future.
Logged

dangersam
Level 2
**



View Profile WWW
« Reply #59 on: December 20, 2014, 09:43:33 PM »

Here’s a dev diary vid showing the results of my work over the last few months!


« Last Edit: December 22, 2015, 09:05:01 PM by dangersam » Logged

Pages: 1 2 [3] 4 5 ... 12
Print
Jump to:  

Theme orange-lt created by panic