sometimes the code says foo.bar = function(blah) and sometimes function foo.bar(blah). might want to be consistent. i prefer the latter, i think.
I don’t know about child updates—that’s a good thought. I agree consistency is good, I usually wait until everything’s working to clean stuff like that up though.
ah. if you pass a class to entity:add, it will create an instance, and scene: update will auto-call the instance’s update.
to me, that’s a pretty good case for making our entities with classes.
anyway that’s what i was thinking about.
@John why is entity:add(type,...) restricted to one instance of a given type? and is that one per entity, or one for all entities? that is could i add a Mover to several entities? tests say yes.
to me, that’s a pretty good case for making our entities with classes.
To me it’s entirely neutral—in the context of this thread, how something works may be outweighed by how easy it is to understand how it works.
In which light, the fact that it took you to here to understand is at least somewhat of a good case against classes used in this way, to me.
as you wish.
So I’m having a problem with rigidbody: the camera has to be a child of the entity with the rigidbody, so that it automatically moves when the rigidbody moves, but whenever it’s a child of the entity with the rigidbody, it looks like it’s vibrating—there’s a double-image as it moves.
If the camera is not a child of the rigidbody, there’s no visible vibration at all.
I’m trying to make a stripped-down project that isolates the problem code, but for now if anyone wants to take a look at the effect in the regular project it’s attached here.
@UberGoober The only time I see anything wrong is when the object hits the wall and jumps over it. It’s not a smooth motion, but not that bad. I don’t see any vibration as the object moves around the floor so I’m not sure what to look for.
@UberGoober this is due to the physics timestep not matching up exactly with per frame update loop. I’ve never really noticed it much when I’ve used the rigidbody attached camera. There are ways to mitigate this (physics-interpolation) but I haven’t put those in as of yet
@dave1707 I tried to screen-record it but, funny enough, it doesn’t show up on screen recordings.
So it must be happening faster than the screen recording FPS I guess.
I’m using an iPad Pro (12.9-inch) (4th generation)
The vibration doesn’t show up on my iPhone.
Anyone else seeing it?
@John it sounds like my only option then is to detach the camera from the rigidbody entity and hand-calculate the positioning of it every frame, but would that even work?
Would it just have the same problem?
@dave1707 I’m trying to understand your rotation code and I am having some blocks.
I’ve given the variable names over-verbose new names to help my understanding but there are a few I can’t figure out what to call:
viewer.mode=FULLSCREEN
function setup()
bodyX,bodyZ,sx,vel,dir=0,0,0,0,0
scene = craft.scene()
ground=scene:entity()
ground.model = craft.model.cube(vec3(1000,1,1000))
ground.position=vec3(0,-5,0)
ground.material = craft.material(asset.builtin.Materials.Standard)
ground.material.map = readImage(asset.builtin.Surfaces.Desert_Cliff_Normal)
ground.material.offsetRepeat=vec4(0,0,10,10)
cam = scene:entity()
cam:add(craft.camera, 60, .1, 1000, false)
end
function update(dt)
scene:update(dt)
cam.eulerAngles = vec3(0,180+dir,0)
bodyX=bodyX-vel*math.sin(math.rad(dir))
bodyZ=bodyZ-vel*math.cos(math.rad(dir))
cam.position=vec3(bodyX,0,bodyZ)
end
function draw()
update(DeltaTime)
scene:draw()
dir=dir-sx/5
joyStick()
end
function joyStick()
if show then
distanceFromStartTouch=vec2(startTouchX,startTouchY):dist(vec2(currentTouchX,currentTouchY))
if distanceFromStartTouch<50 then
px,py=currentTouchX,currentTouchY
else
px=(currentTouchX-startTouchX)*60/distanceFromStartTouch+startTouchX
py=(currentTouchY-startTouchY)*60/distanceFromStartTouch+startTouchY
end
d1=vec2(px,py):dist(vec2(startTouchX,startTouchY))
sx=(px-startTouchX)/(d1/4+.01)
vel=((py-startTouchY)/(d1/4+.01))/20
end
end
function touched(t)
if t.state==BEGAN then
startTouchX,startTouchY=t.x,t.y
currentTouchX,currentTouchY=startTouchX,startTouchY
show=true
elseif t.state==MOVING then
currentTouchX,currentTouchY=t.x,t.y
elseif t.state==ENDED then
show=false
end
end
To wit: I can’t suss sx, px, py, or d1, and I don’t know what math.sin(math.rad(dir)) and math.cos(math.rad(dir)) are doing… and I’m not suuuuuuper sure I’ve got bodyX and bodyY labeled correctly.
Somewhat amusingly, the double-image effect disappears when low-power mode is on…
@John I’ve eliminated the jitter.
To make the camera rotate around the model properly, I had to write a function that updates the camera position, camera rotation, and model rotation whenever the joystick controller moves the camera.
I call this function in the entity’s update() function, but if I also call it in the function that applies force to the rigidbody, the jitter disappears.
math.sin(dir) and math.cos(dir) break out the x and y components, respectively. So if you multiple by vel, you get the x and y parts of the velocity (change), so when you add those to body x and y you get the new body positions.
Does that help?
It’s working (mostly)!
Check it out: a (mostly) proper third-person voxel player (renamed Joystick Player):
It includes a trick cribbed from Minecraft: as you look up, the camera position comes in towards the body, so that the camera is never lower than the player’s feet (in Minecraft it’s more dynamic than that, but this is good too for now).
@RonJeffries thanks, it does clarify a little, and ultimately I’ve used @John’s rx and ry values from OrbitViewer to manage rotation—for some reason, these overcome a rotation glitch that arises with EulerAngles.
Updated zip:
- now both the Joystick Player and the Voxel Editor are using the rig system.
@RonJeffries I’ve changed the start-up project so it’s a big empty grid, and all the tools now cause short tool descriptions to appear when tapped. Should you have a chance to check it out, I’d love to know if it removed some confusion.
i’ll see what i can do. 
@UberGoober based on that it’s probably due to the screen running at 120hz and the physics updating at 60hz, so the physics only moves once every 2 frames, but while recording it’s back to 60hz which matches the physics update rate