Collision "meshes" are too computationally expensive in JS, and wouldn't really be viable in a game. Already the collision system is difficult to get good performance out of, and it's pretty highly optimized with spatial hashing.
Alright, well, I guess that makes sense.
The oimo behaviour however does support compound structures you can setup through events, although it can be pretty tricky to work out positioning the pieces at first.
I'd say. This is where I am having most trouble atm and where mesh colliders would help immensely. Making complex collision structures would be a whole lot easier if the model didn't keep offsetting itself, trying to center into the middle between every collision shape added - even when the model's fit and center settings are at "unaltered". I don't want to be stuck nudging fractions, and adding unnecessary collision shapes to offset every other collision shape, just to make a complex model work. Is this easily fixed? Is there a viable work-around? Is there already a setting for this to stop? I'm asking since I am essentially stuck because of this.
Additionally, being able to access information about the collision shapes themselves would also be nice. Expressions such as " Get shape X size of 'DefaultShape0' " and the like. Maybe even loops like "For every collision shape" although that's not as necessary.
(...) and the capsule collider is actually a compound object as well!
Interesting. I was wondering why I couldn't assign the height of the capsule collider, turns out it's probably because it's a hardcoded cylinder with two spheres. Aight'.
And no worries about the color thing
I await the next update with high hopes!