Forum Replies Created
-
Posts
-
Wow, interesting, handy to know.
Messing about with polys/update rate to no avail…
http://www.hi-toro.com/monkey2/toybox/tmp/toybox_meshtest.zip
Easier to play about with than the VR demo at least. The cube and sphere seem to catch all boxes that drop, while the cone pretty much ignores them.
Tried both low (4) and high (256) values for cone segments, makes no difference.
One thing I noticed was that even though boxes all seem to bounce off the cube and sphere correctly, they can roll into them (or at least the cube) from the side. Wonder if it’s something to do with more vertically-aligned polys, as in it seems the sides of the cube and the entire cone are failing? (Horizontally-flipped collider ‘polys’ or something?)
Quick test: inverting the cone causes falling boxes to collide correctly with its horizontal (‘bottom’) surface…
cone_body.Rotate (180, 0, 0)
Seems something to do with vertical polys… ?
If I do this, dropped cubes can fall through the ‘sides’ of the cube (see frontmost/topmost face) — might have to re-drop a couple of times to see it:
box_body.Rotate (45, 0, 0)
Aw, crap, was convinced that was it! Got to be missing something somewhere, surely. Will have to try and dig up other examples from Github, online tutorials or something… gah!
Would it be possible for Ted2Go to be able to load new themes at runtime? I tried modifying one myself, but it seems the new theme only gets detected when you restart Ted, which makes quick tweaking difficult. Maybe I’ve missed something, though!
I would at least comment on 1)…
Report with runnable example and see what Mark makes of it, in that mx2cc fatal errors basically shouldn’t happen.
Added physics object states/state colouring:
BrickSh!tHouse with state colouring [Web demo]
This is pretty cool, in that you can watch the bricks go to sleep, then shoot and see the affected bricks come to life and sleep again. (Red: normal brick colour; Yellow: physics engine thinks brick should maybe sleep, since not much is happening; Orange: sleeping.)
The FPS is directly affected by the sleep state, in that as objects finally sleep (ie. aren’t being affected by physics), the FPS creeps up to 60 (for me!).
Just to check — have you turned off Debug mode?
Just a passing note (unrelated to Adam’s case) — I’ve realised why it seems so slow, even though it mostly runs at 60 fps for me: scale!
The bricks in the latest wall examples are like 5m wide, and weigh a kilogram each, so when you’re looking at them and thinking they’re brick-sized, it looks slow (because you’re perceiving your own view to be at that larger scale, I think)…
Scaling down to realistic measurements shows much more realistic (ie. faster) speeds, though the tower collapses right away — likely needs more friction at that scale.
Not that you’d be building an entire tower from life-sized bricks in a real game… !
Might be worth trying to build for desktop and see if that works for comparison. Failing that, it would need to be reported for Mark to look into. Shadows are definitely working here at least!
They’re working fine here (I didn’t clarify that), so possibly a driver discrepancy with your setup at a guess? (Just to check, have you tried toggling the shadows on/off? Any visual difference?) Would need to be reported for Mark to investigate if they’re not actually working there.
Yeah, that’s just default mojo3d stuff. I don’t like the landscape reflection either, assume it’s a texture buried somewhere in the output. Standard shadows, too. Might be worth raising as an ‘issue’ for Mark to look at, with graphic card details, etc.
Little update — added a brick wall, which is a more realistic upgrade to the earlier wall, in that the bricks are interleaved, resulting in much more realistic collapsing behaviour. (More realistic still would be to have easily-breakable joints between them… )
Here’s the latest version:
Here’s a simple brick wall to shoot in-browser:
Here’s a brick ‘shot’ house, also in-browser. Note that hitting F5 will rebuild it 3 times the height — this is a lot slower, but looks really cool when it falls, especially if you turn shadows on (which slows it down even more)…
(
I suspect the slow speed in the latter is in part due to using a unique material for each individual brick, just for cosmetic purposes*, and mojo3d being not overly-optimised at this time.)* Update: Not true! Quick test using same material for all makes no difference at all to FPS, at least here on Desktop target.
If you have VR, try the demo in the archive! It’s something else to stand inside a huge tower and see it starting to shift, twist and… collapse upon you!
* NOTE: I use the Github ‘develop’ version. Think it should work with the latest Patreon version too.
Thanks!
Cool! It’s Ethernaut’s demo, but I think the intention is that it will be a ‘banana’ sample… there is an older version in bananas/toy-plane. I assume the source to the latest version is already available somewhere, as I see therevills built it earlier in the thread, but I could be wrong… ?
Hmm, it seems version 52 added support for wasm by default, but I’ve just found this page:
https://browserengine.net/firefox-52-0-released-find-out-what-is-new-2/
… which says:
Firefox 52.0 ESR
Firefox 52.0 ESR marks the beginning of a new extended support release cycle. This release is important for a number of reasons:
[… ]
Service Workers, Push Notifications, and WebAssembly not enabled by default. To enable, set dom.serviceWorkers.enabled, dom.serviceWorkers.openWindow.enabled, dom.push.enabled and javascript.options.wasm to true.
