Forum Replies Created
-
Posts
-
Check the expressions section in the language reference:
Also, have a look at the files in modules/std/geom source for example code.
I’m already looking forward to the ‘ton of new stuff’…
Alas, much of it is internal. But the Scene saving/loading stuff is coming along really well, you can now open ‘.mojo3d’ scene files in ted2go!
That actually works better than I thought it would!
Hmmm, web version is acting up in chrome, boxes fall for about a second and then the page reloads!
But is working OK in nightly…
There is no collision detection built into ‘stock’ 2d monkey2 so you’ll need to look into either writing your own or using modules like chipmunk, pyro or timelinefx etc.
The way I used to do pixel perfect collision back in the day was to build a ‘bitmask’ of solid pixels, and ‘and’ masks together and check for non-0 results. That’s probably overkill for modern retina res devices so a polygon collision check might be the way to go there – not quite as precise though…
Duh, doesn’t help I broke mesh collider indicies in v1.1.10!
Fixed now which solves your demo’s problems, although the projectiles demo style ‘tunneling’ problems still exist…
Well, I don’t know what a rebase is and have no desire to find out right now, but I’m vaguely planning a release for next week – but this is subject to not finding any problems in a ton of new stuff I’ve added before then, and also my tendancy to add things at the last minute.
I don’t really consider these ‘releases’ to be terribly significant anyway – they are really just snapshots of progress that I put together to do something nice for patreon supporters. Actual monkey2 development is an ongoing process so rebasing could easily occur at any time, couldn’t it?
Fix coming in next update, along with fix for upside down image!
Yes, the ‘v1.1.xyrc’ branches are the ‘release’ versions, and I plan to create a new one for every release in future.
Just making pull requests for docs mods has worked fine to date IMO and I don’t want to make it more complicated than that right now.
Tweaking update rate alone probably wont do much, but there are several parameters for stepping the physics I’m not even using:
http://bulletphysics.org/mediawiki-1.5.8/index.php/Stepping_The_World
(Looking at the code now, I’m not even doing the stepping properly as it is!)
I’ll fix this and add a Scene.MaxSubSteps property so we can play with all stepping params.
I just did a quick test and could build promptinvasion and run it on an emulator OK.
I updated android studio and all my sdk bits in the process to:
Android Studio 3.1
Android SDK Build-Tools 28-rc1 (actually have lots of these installed)
Android SDK Tools 26.1.1
NDK 16.1.4479499
But in general, gradle *can* cause issues, usually just after upgrading android studio although this time it ‘just worked’ (for the first time ever I think). I usually end up fixing problems like this by just trying random things in android studio and googling. There do seem to be 2 ‘versions’ of gradle involved – gradle itself and a gradle wrapper for android studio – both of which seem to have their own version numbers so it gets hella confusing.
Also, the emulators appear to be fairly broken with the latest update – I can run stuff on them but there is resizing/snapshot weirdness.
Sorry, I thought you knew this!
Actually, I’m surprised you can’t even rotate MeshColliders (need to double check this but am knee deep in the guts of mx2cc right now) but I always knew that a mesh shouldn’t be moved in anyway after the simulation ‘begins’. And yes, I should add a check for this, but there’s currently no concept in mojo3d for begin/end simulation so this needs to be added too.
The problem I was talking about is best illustrated by the projectiles VR demo – if you change the ground BoxCollider to a MeshCollider (there’s a commented out MeshCollider in there) you can see stuff falling through the ground like crazy. Ditto, if you create a mesh for a terrain you get similar problems.
The TerrainCollider will be cool but it functions very much the same way as MeshCollider, although obviously it can store its data much more ffficiently. But both of these colliders really just return an intercepting bunch of triangles when simluation steps, so end result will/should be the same. I did have TerrainCollider going at one point but the anomolies were very similar to MeshCollider so I decided to ditch it for now so I can just concentrate on one thing.
I am hoping these problems are caused by triangle size and/or update ‘steps’ and I suspect making good use of a physics engine like bullet will be as much art as it is science!
This looks like a compiler bug to me – you shouldn’t be able to use ‘virtual’, ‘abstract’, ‘override’ or ‘final’ with functions (static methods).
It doesn’t make any sense to allow it either – without a ‘Self’, an object has no dynamic type.
An image property that may be use here is light depth, eg: image.LightDepth=blah (defaults to 100.0).
This is the z coordinate of the light, ie: its distance from the plane being lit, and increasing it should mellow out lighting a bit.
What I think I’ll do here is resurrect b3d/bmx style Keyboard.FlushKeys() that can be called to ‘clear’ any keypresses that haven’t been checked for. Look out for it in v.1.12 in addition to the texture fix.
