[DruggedBunnyParticipant]

I’ve run into that — it’s a problem with Emscripten’s own installer, from what I read, and I only resolved it by installing in a root directory.

[DruggedBunnyParticipant]

Nice, I briefly thought about doing <T> but didn’t really need it.

Not really familiar with Where, but I think I see how that works, which is cool.

I’d say it’s a bug, though, if float zero ever evaluates to 0.0000000000001! Although floats can definitely not represent all numbers, and direct value comparisons are generally a bad idea, floating point zero should still always be 0.0[… 0] no matter what — all bits being set to zero.

Already found mine really useful, great for getting finer control from joystick inputs!

[DruggedBunnyParticipant]

Oh, yeah, same here!

Monkey 2 Files

[EDIT: Er, the forum turned the URL into a preview there!]

[DruggedBunnyParticipant]

No problem, just had a quick look and it’s very out of date, though I’m currently having some problems (noted on Github), having converted to using Components to control my entities.

One thing I would say if you’re looking at the physics:

DON’T use ApplyImpulse/ApplyTorqueImpulse for real-time control like this version does!

Use ApplyForce/ApplyTorque, as you’ll otherwise run into problems with different framerates and other quirky stuff.

ONLY use the *Impulse versions to apply changes that should be instant, eg. I now use them only to start my SpaceGems (which now use the physics engine) spinning at a fixed rate when created — otherwise they would be slow to spool up — or you might use them to start a bullet firing instantly, for example.

With impulses, the force is applied instantly, unlike in reality, where its effect takes place over time.

(If you’ve started using them, convert to ApplyForce/Torque right away — you’ll need to increase the values significantly.)

That’s my top tip for now! (Also, I had to remove the lights attached to SpaceGems, as they were causing slowdown.)

I’ll post the source once it’s working again…

[DruggedBunnyParticipant]

Also, on Window 7, debug mode will often crash Ted2Go, but Mark’s minimum target is really Windows 10.

[DruggedBunnyParticipant]

The executables definitely won’t be the same! While the C++ output from mx2 will be the same, both compilers will optimise that code differently.

The main reason to use MSVC on Windows is that build times are significantly faster (after first build), and you can build for 64-bit on Windows, whereas gcc doesn’t work yet for some reason (though it does do 64-bit on Linux).

[DruggedBunnyParticipant]

Updated source to new physics-controlled no-collision-response gems…

http://www.hi-toro.com/monkey2/bust/thrusting.7z

[DruggedBunnyParticipant]

Little feature request:

Monkey

body.btBody.setCollisionFlags (bullet.btCollisionObject.CF_NO_CONTACT_RESPONSE)

1	body.btBody.setCollisionFlags (bullet.btCollisionObject.CF_NO_CONTACT_RESPONSE)

Can we have no collision response option built into RigidBody?

The above works perfectly, but isn’t exactly intuitive…

I’m converting my SpaceGems to RigidBodies instead of the current (manually-rotated) non-physics entities, obviously don’t want my rocket bouncing off them when colliding, just want to detect the collision.

I’m using ApplyTorqueImpulse (yup!) on gems when New’d to set their fixed rotation speed (so it’s instantly applied), removing their angular damping and applying inverse gravity to keep them suspended. (All working great so far!)

—

EDIT: Spoke too soon — my gems appear in Debug but not Release, so guess they’ve shot off somewhere in Release for some reason! The detection certainly works in Debug…

EDIT 2: This was due to Scene.Update being needed prior to applying forces — otherwise things don’t appear. Run into this before, didn’t realise it was only in Release mode though! Also, weirdly had to change inverse gravity to half inverse gravity when moving the gem update into SpaceGem from Game.Update. Dunno why, but it works…

All working great now with no-response collisions!

[DruggedBunnyParticipant]

Updated source in link above — stupid tab mixup with old import meant uploaded version was uncontrollably fast!

[DruggedBunnyParticipant]

OK, all sorted! ApplyForce/ApplyTorque were the key, as you thought — I read up on force vs impulse at work today, and sort-of realised the difference, since force = mass x acceleration, where acceleration is a change in velocity over time; however, impulse = mass x ‘acceleration’ where ‘acceleration’ is an instant change in velocity, which is impossible in real life*.

http://www.hi-toro.com/monkey2/bust/thrusting.7z

Key learning point: Should have used ApplyForce all along!

I believe ApplyImpulse would be there to allow for (technically impossible) instant changes in velocity within the physics simulation.

Anyway, it now runs the same in both non-VR (60 fps) and VR (90 fps) — you can now easily switch between them in superthrust.monkey2, the main file.

*  I think with impulse, it’s like the usual “acceleration = (end_velocity – start_velocity) / time“, but where time = 0, so would cause a real-world “divide by zero”!

[DruggedBunnyParticipant]

Oh, weird, same here, with terrain back up to 1024 x 1024! I get 90 FPS with no SpaceGem lights.

Did think they may be a bit much even in non-VR…

EDIT: Bonus ball — figured out how to toggle VR/non-VR at compile time, so I can now more easily compare the boost scaling, which will be my next job…

[DruggedBunnyParticipant]

Ah… doing:

Monkey

ground.Visible = False

1	ground.Visible = False

… immediately puts it to 90 FPS!

That said, ground is kind of a key feature…

Even cutting the camera range to 100 still leaves me at 40 FPS…

Scaling the heightmap to 512 or 256 does get me up to around 60-70 FPS — will need adjusting for scale, as it looks weird — but at least I can see that this is having a significant impact.

I suppose it’s a lot of vertices after all, 1024 x 1024 being 1.something million!

[EDIT: Ignore VR/non-VR selection for now, might have just figured it out… ]

[DruggedBunnyParticipant]

I think I need to dig into this a lot deeper… for some reason, the program runs at only 30-40 FPS in VR, yet full 60 in non-VR, as reported via App.FPS.

However, basic VR test programs do run at 90 FPS, as expected.

I don’t change the update rate anywhere, as far as I can tell, so something’s slowing it down in VR mode, but disabling various aspects has made no difference (eg. not updating the scene, not updating the player, not updating the HUD, etc, etc).

Any ideas as to where I ought to be looking?!

[EDIT: Source with VR and non-VR versions: http://www.hi-toro.com/monkey2/bust/thrusting.7z — could really do with a way to compile-time comment out VR-specific stuff, though, so I only have to work on one version. (eg. #If VR_MODE/#Else etc.) Is there currently a way to do this? I wasn’t able to get anything to work!]

[DruggedBunnyParticipant]

Thanks, Mark, I did finally sort of grasp what you meant by the time aspect, so will experiment with that… it’s hard to tell what aspect of the overall system is going slow, but I think you’re right there.

[DruggedBunnyParticipant]

Thanks, Mark, will mess about with this later and see what happens!

[Author]

Posts