Physics tab for threejs editor

[Druidhawk]

I would appreciate, if at some time, you could add at least a rudimentary physic tab to the object properties panels. A basic one might consist of a shape selection [box, cylinder, mesh, sphere...etc] and a numeric mass, and a velocity vector. I don't think it needs to be tied to a particular physics library, just some generic concepts. Basically I would like to load a scene and have some guidance on what physics shape to wrap each object in.

[tschw]

Seeing little capacity for extending the editor and serialization being a doomed-to-halfbakedness, bottomless pit, I think it should be the other way around:

We need a property meta model to synthesize serialization and UI from it. This way, physics classes would just define what they have to offer...

@Druidhawk I'm sure that abstract physics classes will be a welcome contribution. Examples binding to different concrete physics libraries must be provided for proof of concept and documentation for other users, though. At this point it would also make sense to add UI, however, ideally we'll be fast enough so it can just "add itself".

[devingfx]

@Druidhawk You might for the moment add your physics values in userData and create scripts on theses objects to retreive the values to set your physic engine properties ...

// Create a cube with friction of .8 and restitution of .3
var mesh;
this.add( 
  mesh = new Physijs.BoxMesh(
      new THREE.CubeGeometry( 5, 5, 5 ),
      Physijs.createMaterial(
        new THREE.MeshBasicMaterial({ color: 0x888888 }),
        this.userData.friction,
        this.userData.restitution
    )
  )
);

@tschw Is there a starting point to refactorize the panel generation depending on class properties? I would like to participate on this. I might found a convenient way to get the types of properties based on the given class definition already made for tern (#6585).

[tschw]

@devingfx

@tschw Is there a starting point to refactorize the panel generation depending on class properties?

What we need is a meta model that allows a program to reflect the data structures of the library. First question is "what would we want to do reflectively? The two obvious answers plus use cases are:

Automate serialization / deserialization => to retire .toJSON methods & custom loaders => to serialize user-structured data, such as uniforms in ShaderMaterial => to allow pretty much anything to be mapped into an array (e.g. for animation)

Generalize property editing => to allow for editors that "write themselves" => to allow user-structured data to be edited with generic tools

The interface of an abstract THREE.Type may boil down to something like:

• instantiate( specObj )
• serialize( value, serializer )
• deserialize( deserializer )
• valueIsValid( value ) - derived classes may want to add more for enums, min/max, ...

I put some prototypical code into this gist.

[MasterJames]

I am also interested in adding physics. I don't think most people will need it and is likely best as an add-on or third party extension even. Mainly you need another separate matrix for torsion momentum mass angular momentum and probably something else you get the idea. Then a secondary aspect to the rendering procedure that accounts for those extra attributes aka physicsMatrix this probably should be integrated into the new animation stuff somehow. Also a procedural way of thinking is contimplated for even modelling as well as animation. I'm only familiar with Houdini but it lacks interactivity and Javascript, still the procedural approach there is well defined and demonstrated. This might be critical in shape morph (aka deformations) for collisions as an example. One that is really last on the last. Definitely not a core function and probably requires the forethought of a cloud based deployment level for distributed processing (voxels fluid fire) but not initially. Possibly it's arguable that's a priority to be competitive with future systems attempting the same ideas. Anyway the only thing I see (maybe) needed built into three JS for physics is this extra matrix and mainly because it would need to function on the GPU too ideally. I'm only recently familiarized with linear algebra via Python and don't wish to battle with GPU and that, but would be up for the challenge. Anyway this is for me 2 to 3 years down the road. There's so much to do with three getting to a version 1.0 is paramount so others can safely expand on it in these kinda of ways. It's not really ready for physics but now is a good time to get everybody dreaming/thinking about it, even if only in the corners of their/our minds/collective consciousness. Therfore: A simple helper (slash proof of concept) that adds procedural animation via a GPU computed integrated secondary matrix for aspects of physics (collisions or deflection of mass, momentum & heading). I think as pointed out such libraries exist already... which is the most integrateable or how to adjust three JS so it does? is another good route for discussion.

[Cy-Bo-Rg]

If you search on github there are many editors with some of the features that you're searching for,like this one : http://webglstudio.org/ The installation isn't documented and some information is missing but it's easy to get around those; I have it installed on a reserved space with a custom(personal) https certificate and it's quite nice.

[Mugen87]

I think it's better if the editor focuses just on three.js features. There is actually a long list of three.js entities which are not yet supported by the editor, see #16234. Besides, other feature requests like a flexible sidebar (#16897) or a faster auto-save implementation seem more relevant to me than the integration of physics (which is no part of the engine at all). This needs to be solved on application level.

Hence, I vote to close this issue.