I want to set the transform of both a given scn:SCNNode and its current presentation node, to a new value. However, I'm having trouble setting the presentation node. I've tried four ways:
Set presentation node's transform:
scn.position = newVal
scn.presentation.position = newVal
scn.presentation.transform is read only -- it can't be set. (BTW, setting the presentation node's transform compiles with no errors, perhaps something to clean up)
Use resetTransform():
scn.position = newVal
scn.physicsBody.resetTransform()
does nothing. The docs say it "Updates the position and orientation of a body in the physics simulation to match that of the node to which the body is attached". But it isn't changed. Not clear why!
Remove the physicsBody while setting:
let pb = scn.physicsBody
scn.physicsBody = nil
scn.position = newVal
scn.physicsBody = pb
This sets the presentation transform to newVal ("yea!"), but Physics does not work ("boo!"). Perhaps one cannot reuse a physics body.
Add a new physics body after setting:
scn.position = newVal
scn.physicsBody = SCNPhysicsBody(type:.dynamic, shape:nil)
but alas, scn.presentation.position doesn't have newVal.
Thoughts?
I've been noticing this as well in my SceneKit-using project. The direct answer to your question is: “The presentation node automatically updates its transform to match the scene node's transform. If it doesn't seem to be updating, make sure the scene node's isPaused is set to false.” However, it's likely that your scene nodes are un-paused and/or you're not using animations at all, and yet this issue occurs.
I started noticing this issue happening intermittently on iOS 11 when everything in my project worked great on iOS 10. I haven't touched SCNAnimations or anything like that— I have my own animation system, so I just update my nodes' .position every renderer(_:, updateAtTime:).
So AFAICT, the issue here isn't anything you're doing— the issue is that SceneKit has always been buggy and poorly-written (some parts of the API still haven't been fully updated for Swift), and will likely remain buggy and poorly-written because it seems the SceneKit team has completely moved onto working on ARKit. So the solution to your problem seems to be “just try a bunch of stuff, setting .position more frequently than necessary, or at a different time in the update loop, or really hack-y solution that seems to work-around the issues in SceneKit”.
For me, personally, I'm slowly working towards abandoning SceneKit in my project— I've mostly switched to custom Metal shaders, and then I'll do my own scene render loop, and eventually I'll replace the scene graph and SCNNode usage leaving me with zero reliance on the buggy mess that is SceneKit.
I wish I had better news for you, but I've been dealing with the weirdness of SceneKit for 2 years now. It's unfinished garbage.
Update: I ended up “fixing” my presentation nodes misbehaving by using a dirty hack that adds a tiny amount of “wiggle” to the node's position each frame:
public func updateNode()
{
let wigglePositionValue = SCNVector3(
x: Float.random(in: -0.00001...0.0001),
y: Float.random(in: -0.00001...0.0001),
z: Float.random(in: -0.00001...0.0001)
)
self.scnNode.position = _locationModel.value + wigglePositionValue
}
Side-note: As expected, “jiggling” node positions like this also disallows SceneKit from doing some of its batching/rendering optimizations, and (in my experience) incurs a performance hit. It's a horrible hacky work-around, only intended for worst-case scenarios (“the client says we have to go live with the game this week or we don't get paid, and now this stupid SceneKit bug?!”)
So yeah… the real solution here is “don't use SceneKit”.
I have the same issue using ARKit. Because physicsBody adjust itself according to presentation node instead of the node itself, and because the presentation node doesn't update immediately when you change the node's transform, the physicsBody you get might be weird.
There is one solution I found recently:
To change presentation node's transform, use SCNAction. For example, if you want to set position, use node.runAction(SCNAction.move(by: SCNVector3, duration: 0)) instead of simply node.position = SCNVector3. This way, the presentation node immediately updates and you get the right physics.
In addition, this approach only works on the node itself (not applying to children). So if you run action on the node's child, you still can't get the right presentation node and physics. To change the child node's transform and presentation transform, use the node.position = SCNVector3 approach.
To sum up, when changing node's transform, run an action, and when changing the node's children' transforms, directly set the transform.
Related
I encountered some difficulties while studying Godot.
I'm trying to add a shotgun class (Shotgun.gd). I have a function in the class that creates several RayCasts, a function that checks what they encounter and a function that calls these functions one by one. If I call these functions from the class where they are declared in the _process() function, everything works fine, but if I call these functions in another script, like Player.gd, it finds nothing when checking for RayCasts.
P.S Sorry for the sloppy translation, English is not my native language
Part of the code from the shotgun class (Shotgun.gd)
# Gen RayCast-ы
func gen_raycasts(player):
# Очистка списка
raycasts.clear()
var temp
for number in PELLETS_COUNT:
# Создание RayCast
temp = RayCast.new()
# Установка настроек
temp.set_cast_to(Vector3(LENGHT, 0, 0))
temp.set_enabled(true)
# Добавляет RayCast на сцену
player.add_child(temp)
# Установка положения
temp.transform.basis = Basis(Vector3(-0, 0, 0.1), Vector3(-0, 0, 0.1), Vector3(0.1, 0, -0))
temp.global_translate(Vector3(0, 1.65, 0))
temp.set_scale(Vector3(0.1, 0.1, -0.1))
# Рандомный разброс дробовика
randomize()
temp.rotate_y(deg2rad((-50 + randi() % 100) / 10))
temp.rotate_x(deg2rad((-50 + randi() % 100) / 10))
raycasts.append(temp)
#print(raycasts)
# Check Rayasts
func chech_raycasts():
in_raycast.clear()
for number in PELLETS_COUNT:
in_raycast.append(raycasts[number].get_collider())
#print(raycasts[number].is_enabled())
print(in_raycast)
Godot tree picture
Call from func _process()
Call from Player.gd
I'll venture to say that it is probably correct they collide with nothing.
Enable "Visible Collision Shapes" in the "Debug" menu, so Godot shows colliders in runtime (including enabled RayCasts), and check they are being positioned correctly.
I can think of a couple possible problems:
You are adding the RayCast before positioning it. This is not always a problem, and it is probably not a problem in your case. However, it might register a collision when added, before moved.
You are scaling the RayCast. This should not be a problem. However, there have been bugs related applying a scaling directly on collision shapes… So, I will avoid this, just to be safe.
A suggestion: Add a Position node, child of your Shotgun, marking the origin for the RayCasts. Then you can copy the global transform of the Position to the global transform of the RayCasts - and then apply the random rotation - before adding them as children. This should make it easier to update the position if you need to (e.g. if you changed the shotgun model, you can mode the Position node accordingly). It should avoid any typos when writing the coordinates in the code. And it should avoid the pitfalls mentioned above.
I'll remind you you are supposed to check is_colliding. I guess you are not doing it for demonstration purposes.
I'll also remind you that the RayCasts update with the physics frame. So, when calling the RayCast from somewhere other than _physics_process you are getting what they registered last physics frame (i.e. just before _physics_process ran last). You can make Godot update the RayCast by calling force_raycast_update on them.
If you don't need the RayCasts often, having them update every physics frame might be overkill. In that case, you might be interested in checking like this: get_world().direct_space_state.intersect_ray(start, end). See PhysicsDirectSpaceState. However, using RayCast should work. Using intersect_ray is only an optimization.
Unrelated: if you want to guarantee an uniform probability distribution distribution from the random functions, call randomize once at the start, instead of once per iteration. This is probably not noticeable anyway.
I am attempting to move a SKEmitterNode to follow a bullet in my game to give it a trailing effect however, no matter which way I attempt to implement this, it doesn't seem to work how I want it to and I'm at a loss for how to make this.
I have attempted to add the emitter to my main scene and manually moved the node a few times per second but it ends up not leaving a trail and keeping all the particles in one place like this:
Next I attempted to set the target node, however when I do this the trail goes for a bit then stops rather than following the bullet like it's supposed to. It also rotates and distorts from the rotation of the projectile like shown here:
For reference of the type of effect I'm looking for:
You should populate the targetNode property of your emitter with a node that is not moving like the scene.
emitterNode.targetNode = self // where self is the current scene
I am trying to connect together two SKNodes which both have equal size circular physics bodies. They are positioned so as to be touching each other, and I want them to be locked together. From the documentation, it sounds like I want a SKPhysicsJointFixed, and I have tried creating one with the anchor point being the midpoint between the two nodes - like this:
let fixedJoint = SKPhysicsJointFixed.joint(withBodyA: atom1.physicsBody!, bodyB: atom2.physicsBody!, anchor:midPoint)
but this causes an odd behaviour where after the joint is made the top node falls through the bottom node - where before the joint existed the physicsbodies rested against each other.
If I use a pin joint instead with the same code - it works as expected ie:
let pinJoint = SKPhysicsJointPin.joint(withBodyA: atom1.physicsBody!, bodyB: atom2.physicsBody!, anchor:midPoint)
locks the bodies together as I want them to be. I guess this is a perfectly fine solution - but I'm confused something about what is going on. Why does my pin joint do what I thought the fixed joint would do, and why does the fixed joint not do what I thought it would?
Perhaps you were running into the same problem I ran into. I've found that SKPhysicsJointFixed behaves very strangely if the SKNode.zRotation property in the two nodes you're joining is different. Here's the behavior I was trying to get, having nodes of certain types stick together when they collide. Note how, after the collision, they rotate around their common center of mass.
But I was often getting this sort of thing, and often even stranger than this. Notice that not only does it not rotate as expected, it starts to wiggle as it approaches the wall.
As you can see, the difference between the two scenarios is that the zRotations are equal in the first case, unequal in the second case. Seems like a bug in SpriteKit, if you ask me.
One workaround is simply to explicitly set the two zRotations equal before you create the joint, but this was unacceptable for my purposes. Fortunately, as you already found, you can consistently get the expected behavior from SKPhysicsJointPin. Of course, if you want the pin joint to behave like a fixed joint, you'll have to set the joint's shouldEnableLimits property to true.
I have a particle effect for a muzzle flare set up. What I'm currently using is a low numParticlesToEmit to limit the emitter to a short burst, and doing resetSimulation() on the emitter whenever I want to start a new burst of particles.
The problem I'm having is that resetSimulation() removes all particles onscreen, and I often need to create a new burst of particles before the previous particles disappear normally so they get erased early.
Is there a clean way start up the emitter again without erasing the particles already onscreen?
Normally particle systems have a feature missing from SKEmitters: a duration. This controls how long a system emits. I don't see this in SKEmitter, despite being in SCNParticleSystems
Never mind, a work around:
SKEmitters have a numParticlesToEmit property and a particleBirthRate. Combined, these determine how long the particle system emits before shutting down.
Using these as a control of the emission it's possible to create pulses of particles emitted in the way you want for something like a muzzle flash or explosion.
I'm not sure if it remvoes itself when it reaches this limit. If not, you'll have to create a removal function of some sort. Because the way to get your desired effect (multiple muzzle flashes on screen) is to copy() the SKEmitter. This is quite efficient, so don't worry about overhead.
There is a targetNode on SKEmitters that are suppose to move the particles to another node so that when you reset the emitter, the previous particles still stay. Unfortunately, this is still bugged from what I can tell, unless somebody else has figured out how to get it working and I just missed it. Keep this in mind though in case they do ever fix it.
Hi to help future readers, the code that I use to calculate the duration of the emitter is this:
let duration = Double(emitter.numParticlesToEmit) / Double(emitter.particleBirthRate) + Double(emitter.particleLifetime + emitter.particleLifetimeRange/2)
It works perfectly for me
Extension:
extension SKEmitterNode {
var emitterDuration: Double {
return Double(numParticlesToEmit) / Double(particleBirthRate) + Double(particleLifetime + particleLifetimeRange/2)
}
}
I'm making my first shooter game using Swift and SpriteKit and I've recently been running into problems with setScale(). I have a Laser class whose instances are added as children to a Ship class. I now realize that any down scaling of the parent node will scale its child as well. In my update method in GameScene I check the position of each child named 'Laser' to determine if it should be removed from its parent when offscreen. I recently updated some of my sprites- including their relative sizes, and I noticed that the position of each laser is way off, as they are removed far before they reach the end of the screen and upon debugging their x positions are in fact far larger than where they are displayed onscreen. I also noticed that the starting x of each Laser instance is relative to its original position within the Ship instance. So the ship may be halfway across the screen but the laser x position still starts at 0 and if the ship is able to pass the laser, the laser's position becomes negative--is there a way to grab its position on the screen rather than relative to its start within its parent?
This is the code I'm doing the check with:
self.aShip.gun.enumerateChildNodesWithName("laser",
usingBlock: { node, _ in
if let aLaser = node as? Laser { i
if(aLaser.position.x > self.size.width){
aLaser.removeFromParent()
}
}
}
)
It seems like scaling has a ton more baggage than I would normally assume, so any insight into this problem or how to manage the relation between code and sprites would be awesome!!
EDIT:
I found that adding let positionInScene = self.convertPoint(aLaser.position, fromNode: self.aShip.gun) under if let aLaser = node as? Laser {and consequently using positionInScene rather than the aLaser position works.. however, I still don't fully understand the scaling effect going on with aLaser and it's position and don't know if its efficient to have to convert positions like this at the rate of update (60 times a second).