I'm currently creating a system of spheres which can actuate to push each other away. There are center bodies (teal) at each corner which are connected to connecting bodies (yellow) via PrismaticJoint which are connected in the same way to the next corner.
When creating a one dimensional system of spheres, for example, a 1x1x4 system, I run into no errors and the system behaves as expected.
In trying to create a system of eight spheres in a 2x2x2 orientation, I'm running into mobilization errors.
Here is what the system looks like:
And the error:
terminate called after throwing an instance of 'std::runtime_error'
what(): This mobilizer is creating a closed loop since the outboard body already has an inboard mobilizer connected to it. If a physical loop is really needed, consider using a constraint instead.
Aborted (core dumped)
I understand that the error comes for joints sharing child or outward bodies, like in the case for two sides of the cube actuating one corner. Unfortunately, I haven't found a way to pivot using constraints successfully. How can I better define this system?
One way to address this is to use a Drake bushing element (essentially a stiff spring and damper) to emulate a "weld" constraint. There is a nice example of this approach in Drake -- see examples/multibody/four_bar.
The general idea is to break topological loops by sawing through one or more bodies, then welding them back together with a bushing (which does not count as a topological loop).
Related
This is a very common question, and I am not asking for technical details. What I am looking for is an approach or best practice guidance for the following situation:
Imagine a jump and run game entirely made with SceneKit. The game is played by controlling a character running to the right or left side, climbing up walls and jump over obstacles. (it is a 2½-D style game where the character always runs in one direction or it's opposite. Mainly on the x-Axis)
At certain "locations" (on the scene x-axis) I need to implement some specific actions, that should occur as soon as the main character walks, jumps or runs over that specific point.
What I have done so far, is adding simple invisible SCNPlanes with static physics bodies, with the bitmask configured to detect only the contact (no collision). In the physics handler (physics delegate) I can now fetch contact of the objects the character trespasses. Currently I have a large switch-statement to fetch the names of the "Action-Walls" as I call the planes through which the character walks. So, I can trigger whatever specific action that I want to happen at that location.
It is working this way, even quite good, but I wonder if there is a way to add some better "action points" using i.e. Gameplaykit, but I only find information about agents and behaviors or pathfinding.
What I am looking for is some static point, when trespassing it, an associated action happens.
I have no clue about the possibilities of Gameplaykit. Can anyone tell me an approach using Gameplaykit or whatever Apple has in its magic box of useful tools to make this better than using action walls of SCNPlanes and the physics handler?
I have made an application for the hololens with the holotoolkit. The app gets an array with 3D positions and spawns GameObjects based on these positions.
After walking a bit in the room and change some realworld objects (maybe open a door or something) the hololens will recognized it, then a window opens and says 'Finding your space' and all of the GameObjects are in the wrong position.
How can I use SpaitalMapping, but not allow to replace the GameObjects i place?
After walking a bit in the room and change some realworld objects (maybe open a door or something) the hololens will recognized it
I'm not sure the details of the changes you made on realworld objects, but some changes in the real world may have a great impact on the lighting conditions. For example, after opening an outward door in a dimly lit room. a lot of daylight will enter the room.
Lighting can make a difference in the visual features that HoloLens detects. So changeable lighting conditions might cause HoloLens to lose tracking.
Besides, in environments where the visual features change because most objects move, will also cause the same problem.
I recommend that you try the steps in I see a message that says Finding your space to fix this problem. In short, make sure your artificial lighting conditions and WiFi signal are stable and try moving more slowly.
I'm making a game in ROBLOX, which has a cutscene in it at the start. At the end of the cutscene, the camera zooms up on the character and you spawn in. However, when I spawn in, I can see the dummy I used for the cutscene, so how after a certain interval can you make that dummy disappear?
Does the dummy just need to become invisible? If so, every physical object in ROBLOX (or more formally Part) has a .Transparency field that spans from 0 (for no transparency) to 1 (for full transparency, or in other words, invisible). I don't know what your "dummy" looks like in the object hierarchy, but let's say your dummy were a Model located at workspace.dummy, and that it has a head, torso, left arm, etc. located at workspace.dummy.Head, workspace.dummy.Torso, workspace.dummy.LeftArm, etc. To make the Parts of the dummy invisible, you would have code that looks like this:
workspace.dummy.Head.Transparency = 1
workspace.dummy.Torso.Transparency = 1
workspace.dummy.LeftArm.Transparency = 1
...
And so on. This, however, will make the dummy invisible to all players. If you are making a single-player game, this will not matter; however, if it is a multiplayer game, then this could be a problem. Making the dummy non-transparent again to do the cutscene for a new player would make the dummy visible to all players. If this is a problem for you, there are two things you could do that I know of:
The first and easiest way would be to just have the cutscene take place at a location very far away from where your game occurs; for example, you could shift everything in your cutscene 10,000 studs in the X direction. This would ensure the objects in the cutscene would be out of the render distance of the players playing the actual game, so only the players whose cameras are being manipulated to carry out the cutscene would see it.
The second, more complicated, and not future-proof option involves a very useful bug that is frequently taken advantage of but subject to being fixed at any time since it is not an official feature. This bug is the exploitation of a Camera (or less commonly a Message, which is deprecated) to create what are called local parts—Parts only visible to a certain player. How to create local parts and discussion of benefits and consequences of using local parts is a little complicated and beyond the scope of this answer. Go here if you'd like to learn more. Taken directly from the ROBLOX Wiki at the time of writing:
Local parts are in no way supported by Roblox. They exploit unspecified replication behaviour - at any given moment, the development team could release an update that changes how Camera and Message instances behave, preventing you from making local parts.
I'm a total newcomer to SpriteKit and game development in general, I've been toying with SpriteKit to make a strategy game set in space.
My backend architecture use a grid system to represent the Universe, I have empty cases and cases with systems/planets/etc...
My grid is backed by GameplayKit GKGridGraph, I use an algorithm that generate a node with random properties for each node of the grid and I subclassed it to add a custom entity to it, which all the properties of this specific universe case.
To render it, I simply use SKShapeNode and SKPriteNode with various colors, shapes and textures.
I enumerate all nodes (GKGridGraphNode) in my GKGridGraph instance, and for each of those nodes I get generate the corresponding SKNode (my SKNode generations is a component of each GKGridGraphNode entity attached object), and I set them a position, and add them as a child to my main node (let's call it mapNode) which is a simple SKNode. In the end it looks like a grid.
It works well for a 30/30 grid, I have 60 FPS while scrolling my grid (custom implementation, I modify my mapNode positon as the user move his fingers).
But as soon as I try a 50/50 or a 100/100 grid, I have literally too many nodes on the screen for the scrolling to works. I know I shouldn't add every of my node on the screen, so I thought about various strategies and I wanted some input on them:
Instead of scrolling my mapNode, I could render only the nodes I see on the screen, and then add/remove nodes as the user scroll left/right/up/down. So it's not really scrolling anymore, it simulate it. I can think of it, but not really how I should implement it in practice. Is it the right solution?
Maybe I could render all my node as one big node? Is there a way to do that? But then I'll loose functions such as nodeAtPosition, which I use extensively to get the entity (custom object) associated with my nodes.
Edit: Actually, my current code is open source, here is the scene in I'm rendering: https://github.com/Dimillian/LittleOrion/blob/master/Little%20Orion/Little%20Orion/scenes/UniverseScene.swift
Is there any other smart way of doing that?
SKTileMapNode was made just for this in Xcode 8
https://www.raywenderlich.com/137216/whats-new-spritekit-ios-10-look-tile-maps
Alternatively, you would only want to load the nodes that are in and near your current view. You would need an algorithm to do this, and would be a big headache compared to tilemaps.
I suspect the algo would involve checking which nodes are in the view's .frame' and then using 'addChild' on them--concurrently, add a reference to them to an array, which you would check against nextupdate()andremoveFromParent` if they were no longer visible ..
It would get hairy trying to optimize this though. The goal would be to load only a few nodes out on each end so that way you have some buffer in moving the camera (less updates).
You could create a math function to pre-determine which nodes are where in relation to the current frame coordinates--so you don't have to iterate through the nodes--but that would require even a lot more work and headache--and it's what people developing on consoles, etc, have to do with high-end games and limited power.
I recommend skimming through a Direct3d/DirectX/OpenGL game development book, just to get an idea of what goes into everything... They aren't hard to find: walk into a bookstore and look for the thickest / heaviest book--that will be the DirectX game development book.
You will see how what we can do with 30 lines in SK requires thousands of lines and vector calculus in C++ and low-level AV frameworks. It will give you an appreciation, understanding, and perspective of game dev, which will help you in your SK journeys :)
We have a simple robotic model with revolute joins in v-rep. The joints are in force/torque mode, and they are controlled via non-threaded child script using simSetJointTargetVelocity function of the simulator. The collision is enabled in the model, and some toy weights are set to the connecting poles.
The error we have is that the blue part of the joint (the movable part) "wiggles" around and eventually out of the red part of the joint (the fixed case). Here's a screenshot showing the error.
(The blue part of the upper joint should be inside the red part, as is in the lower joint)
How to fix the moving part of the joint so that it doesn't move around, but only rotates as requested by the velocity settings?
What do you mean by "toy weights" ?
You should keep in mind that physical simulations are relatively fragile and that some restrictions apply. In your case, it seems the masses you set are making the simulation behave strangely. Try to keep the mass ratio between linked objects below 1/10.
You can also modify the simulation settings, to increase its precision. You can do that in the simulation settings dialog (http://www.coppeliarobotics.com/helpFiles/) and in the general dynamics properties dialog. You can also try if your simulation works better with another physics engine than bullet (I suggest "Newton").
For more info you should take a look at http://www.coppeliarobotics.com/helpFiles/en/designingDynamicSimulations.htm, especially at the "Design considerations" section.