Forum Replies Created
-
Posts
-
It works fine in Firefox here — what version are you running, and on what platform?
Just added two very simple demos, simpletest and simplertest — first drops a box and allows F5 to drop again (with random sizes/bounce), second just drops a box. Includes the VR demo.
Thanks!
For any Monkeys with a VR headset (that’ll make at least two of us!), this is the same demo modified for OpenVR.
We can’t render text in a VR view for now, and it’s keyboard-driven (not the best combination!), so you just need to remember/look up the keys!
Cursors, A/Z + Shift: Move
Space: Shoot bullet where you’re lookingEnter: Reset seated position
D: Drop boxes
S: Toggle shadowsF5: Reset scene
That’s the controls I remember anyway…
[EDIT: Now in main zip, see next post.]
Most people will probably find the movement spewy, so just find a position and experiment from there!
That code doesn’t seem to crash for me, though I did get a crash on the web demo once.
I notice you’re using an older version of mojo3d, though, as the current version of Scene.Render doesn’t take a camera parameter, so it might be worth upgrading to see if that resolves it.
Nice!
In my last demo (showing as toybox-1.7z), if you change the car loading code to this, you can see that the complexity of the mesh is sort of irrelevant by replacing it with a cube:
[/crayon]1234567891011121314151617181920[crayon-5cbaa0ce0dcc7075590732 inline="true" ]' Local car:Model = Model.Load ("asset::car_default.fbx")' If carLocal car:Model = Model.CreateBox (New Boxf (-50, -50, -50, 50, 50, 50), 1, 1, 1, New PbrMaterial (Color.Red))Local carbody:ModelBody = New ModelBody (car)Local car_scale:Float = 0.05car.Mesh.FitVertices (New Boxf (-car_scale * (car.Mesh.Bounds.Width * 0.5), -car_scale * (car.Mesh.Bounds.Height * 0.5), -car_scale * (car.Mesh.Bounds.Depth * 0.5), car_scale * (car.Mesh.Bounds.Width * 0.5), car_scale * (car.Mesh.Bounds.Height * 0.5), car_scale * (car.Mesh.Bounds.Depth * 0.5)))carbody.Move (0.0, 100.0, 10.0)carbody.Rotate (45, 45, 45)'carbody.Position (0.0, 0.0, 10.0)carbody.Start ()' EndifFor some reason, it just doesn’t get any rotation applied during collisions…
Interesting, thanks, was curious how people found Monkey2 without direct exposure to Blitz!
Try example 3 here:
Ignore the physics, but look at the bullet spawning child/parent code, might be of use anyway.
I would prefer a language with a better type system and the possibility to export to HTML5. So, I’am here
Out of interest, what brought you here, of all places? It’s not exactly a heavily-marketed language!
(Welcome!)
Oh, yeah, have a look specifically at the rotation comment, just doesn’t seem to be taken into account — whether by mojo3d or Bullet I can’t tell…
That’s so weird! I remember maybe 20 years ago [18 years? Almost certainly as a result of Blitz3d collision comments] reading online about turning spheres into capsules to predict their position at a future point in time! I have assumed this would be just the norm since then! Wow.
Did notice the y-update this morning, thanks!
Hi Mark,
Doubt I’ll see it again — the code looks like what I thought I had before, but is clearly working! That did remind me of another point, though:
5) I felt like ProjectToViewport should be returning 2D-style co-ordinates, but I’m having to invert the y result like below to correctly draw in 2D — and I imagine this would be the main use for projecting 3D-to-2D:
[/crayon]123[crayon-5cbaa0ce1ebe9028733224 inline="true" ] Local pos:Vec2f = camera.ProjectToViewport (b.model.Position)canvas.DrawText ("X", pos.x, Height - pos.y)For constraints, I’ve mostly been after fixed and ball-socket/point-to-point, going by:
http://bulletphysics.org/mediawiki-1.5.8/index.php/Constraints
The first would allow simple rocket bodies with boosters attached, and the second would allow for thrust-style orbs!
/aside: I actually was looking at a javascript demo of the double-pendulum effect yesterday, and thinking it could be used to make great random dogfighting movements:
https://nullprogram.com/double-pendulum/
(Imagine the outer ball being an enemy circling the player ‘aircraft’ at the centre! You’d probably have to position the pendulums ‘off-world’ and just use the position results to manually position a model around the player, rather than attach the pendulum to the player, but would probably look really cool if it worked!)
So, ball socket ought to at least allow a few interesting options…
One thing I’m not sure about, but seem to recall reading Bullet could do, is having constraints break apart depending on force (for more realistic bullet-hitting-wall simulations), but maybe a bit early for that.
Bullet does have built-in vehicle and ragdoll simulations, no doubt a bugger to set up, but those would be awesome to have at some point.
Wonder why Bullet is apparently so poor with the mesh stuff? Perhaps you have to supply it with ‘nicer’ meshes or something… could a QuickHull-type of thing help, or even something like whatever Maplet did to generate simplified ‘clean’ hull meshes?
Failing that, might be worth experimenting with manually-simplified collision meshes (ie. not the complex ‘real’ mesh), just to see if that works… can always specify that it’s up to the coder to produce these if it’s not automate-able (?!).
I’d swear I’ve seen Bullet doing terrain demos, but could be wrong!
I have troubling visualising scaled/translated meshes versus the visible version, but I thought what I’ve done in the attached would have worked (not sure if you class this as ‘scaled’, or if you just mean scaling the entity) — this to me reads like it’s ‘unscaled’ in the sense that the core mesh has just been amended, prior to physics being attached — note that colliders and rigidbodies are only set up in xBody.Start (), allowing for repositioning, rotating, etc prior to starting physics.
In short:
[/crayon]123456789101112131415161718[crayon-5cbaa0ce1ebf0748241445 inline="true" ]Local car:Model = Model.Load ("asset::car_default.fbx")If carLocal carbody:ModelBody = New ModelBody (car)Local car_scale:Float = 0.05car.Mesh.FitVertices (New Boxf (-car_scale * (car.Mesh.Bounds.Width * 0.5), -car_scale * (car.Mesh.Bounds.Height * 0.5), -car_scale * (car.Mesh.Bounds.Depth * 0.5), car_scale * (car.Mesh.Bounds.Width * 0.5), car_scale * (car.Mesh.Bounds.Height * 0.5), car_scale * (car.Mesh.Bounds.Depth * 0.5)))carbody.Move (0.0, 100.0, 10.0)carbody.Rotate (45, 45, 45)'carbody.Position (0.0, 0.0, 10.0)carbody.Start ()EndifIt almost does work (seems to collide at the right point in terms of model size), other than the end result doesn’t actually rotate in any way! Notice the carbody.Rotate (45, 45, 45), but the end result is it lands as if attached to an un-rotated cube. Wonder if this is related to the overall problem, ie. there’s simply some rotation not being applied or taken into account?
Welcome!
OK, I’d deleted the code… now, on recreating it… it works perfectly, of course.
I’ve attached the code just for reference.
Few things I ran into/wished for while doing it:
1) More physics — would like to play with constraints in particular.
2) This code was just me trying to wrap all of the Collider types in a way I can fathom, but I found that Convex/Concave are unimplemented and MeshCollider is well dodgy (you referenced this being a Bullet problem in one of your mojo-vr tests). Any plans for these aspects? I got a cool-looking terrain but couldn’t drop my boxes onto it!
3) While trying to get MeshCollider working, I was struggling with obtaining the world-space size of the mesh inside a scaled-down entity, could use a way to get that if possible; also a way to visualise these things would be nice. Also, Model.Width/Height would be nice, was a struggle locating those, think I had to dig into mesh bounds boxfs or something!
4) Any chance of a pure flat-shading-mode-pretty-please?There were more but gotta go back to work and can’t remember off-hand!
Yeah, will do tonight.
