Editor should have most of THREE's features

[Temdog007]

Description of the problem

There are several features of THREE that aren't accessible from the Editor. When I say accessible, I mean combination of:

• properties are not visible for editing
• objects not being able to be created
• objects not being able to be imported or exported.

Ideally, the Editor should be capable of creating and editing most objects and features that the API contains. This issue is really more to keep track of what the Editor can and can't do currently. I'm listing features that I think the Editor would be capable of handling.

Cameras

• PerspectiveCamera
• OrthographicCamera
• ArrayCamera
• CubeCamera
• StereoCamera

Core

• BufferAttribute
• BufferGeometry
• Layers
• InstancedBufferAttribute
• InstancedBufferGeometry
• InstancedInterleavedBuffer * (Serialize Instance Buffer Geometry and Interleaved Buffers #16050)
• InterleavedBufferAttribute

Geometry

• BoxGeometry
• CircleGeometry
• ConeGeometry
• CylinderGeometry
• DodecahedronGeometry
• EdgesGeometry *
• ExtrudeGeometry
• IcosahedronGeometry
• LatheGeometry
• OctahedronGeometry
• PlaneGeometry
• RingGeometry
• ShapeGeometry
• SphereGeometry
• TetrahedronGeometry
• TorusGeometry
• TorusKnotGemetry
• TubeGeometry
• WireframeGeometry **

Lights

• AmbientLight
• DirectionalLight
• HemisphereLight
• PointLight
• RectAreaLight (Editor: Add RectAreaLight #16251)
• SpotLight
• LightProbe

Materials

• LineBasicMaterial
• LineDashedMaterial
• MeshBasicMaterial
• MeshDepthMaterial
• MeshLambertMaterial
• MeshMatcapMaterial
• MeshNormalMaterial
• MeshPhongMaterial
• MeshPhysicalMaterial
• MeshStandardMaterial
• MeshToonMaterial
• PointsMaterial
• RawShaderMaterial
• ShaderMaterial
• ShadowMaterial
• SpriteMaterial

Objects

• Group
• LOD
• Line
• LineLoop
• LineSegments
• Mesh
• InstancedMesh
• Points
• SkinnedMesh
• Sprite

Textures

• Texture (properties not editable Texture panel for all textures in Threejs Editor #13882, THREE JS Editor: Added texture's properties to UI Texture object  #15695)
• CubeTexture (CubeTexture Support for the Threejs Editor #13880)
• VideoTexture

Misc

• Animations
• Audio
• Post-Processing

* = Serializable, but not deserializable
** = Serializable, but not as the original geometry (i.e. WireframeGeometry is serialized as BufferGeometry)

Three.js version

• Dev
• r103

Browser

• All of them
• Chrome
• Firefox
• Internet Explorer

OS

• All of them
• Windows
• macOS
• Linux
• Android
• iOS

[webprofusion-chrisc]

If you have used the threejs inspector chrome extension (which is not really operational anymore, especially for modules) https://chrome.google.com/webstore/detail/threejs-inspector/dnhjfclbfhcbcdfpjaeacomhbdfjbebi?hl=en you can see it has many options for adjusting material scale/wrapping and lighting attributes. This lets you take you current screen and adjust elements in real time (like materials, bump map scaling etc) and is great for experimenting.

It would be great if the editor could be fired up for any active scene (by including it as a module) like a dev tools for three.js and relevant to this issue it would be great if you could really access all properties - so perhaps where there is no UI to adjust something you could still set it using some custom json against that scene object?

[mrdoob]

I'm hoping we can create an official extension later this year.

[makcreative]

Can I please leave my two cents regarding the Editor supporting export of animations. This would be a very valuable feature to have. I love using the editor so a thank you to everyone for creating it and all of it's features!

[Mugen87]

Can I please leave my two cents regarding the Editor supporting export of animations.

You can already export animated models to glTF.

[Mugen87]

@mrdoob What do you think about introducing Object3D.animations. It would be an array that holds the model's animation clips. In this way, the editor would not save/restore animations separately anymore but could use Object3D.toJSON() and ObjectLoader.parse(). And animation clips would be present in JSON files when using Export Object or Export Scene.

There are use cases where animation clips are not necessarily assigned to a single 3D object e.g. when using AnimationObjectGroup. Object3D.animations seems to be a good default though.

[mrdoob]

@Mugen87 Hmm, what about adding it to Scene instead?

[Mugen87]

Normally I would expect that clicking on objects in a 3D editor shows the respective animations. If the animations are added to Scene.animations (assuming a flat array of clips), it's not possible to reflect this relation.

Think about importing multiple animated glTF assets into the editor. Once you reload the scene, you would not know which animations belong to which model.

Besides, how would this work if you just want to export a single object (and not a scene)?

[mrdoob]

I was thinking it would be a reference list, instead of a flat array.

In fact, the editor already has a animations property and when we select an object, we look through that list. I think this should support importing multiple glTF assets?

I think a centralized list of animations is also how glTF does it. If we added them to Object3D and some animations were reused, we would end up with duplicated animations when exporting.

Besides, how would this work if you just want to export a single object (and not a scene)?

I think it's okay to not support animations when exporting single objects.

[Mugen87]

If we added them to Object3D and some animations were reused, we would end up with duplicated animations when exporting.

If we serialize animation clips similar to materials or geometries, this won't happen. 3D object would point with UUIDs to their clips.

Nevertheless, I see you favor the Scene approach. I'll playing with it around and see how it goes.

[webprofusion-chrisc]

On the topic of animation, I was looking at this the other day and wondering how to re-use character animations (walking, running) across multiple models, so yes for me animation may be relevant to more than model in the scene. I've barely used animations the three so I've not idea what the technical limitations of that are.

On a tangent it would still be great if the editor could be hooked up to an existing (non-editor created) THREE scene, via extension or included as a module, as a way to play with the scene in memory (adjusting lights etc) - perhaps this is already possible? I was playing with the idea of a 3d interactive storybook tool (https://dojo3d.webprofusion.com) and a lot of the coding effort for kids using it is spent messing with positions/scale etc of objects.

[Mugen87]

@mrdoob Do you know the origin of the following code section in ObjectLoader?

three.js/src/loaders/ObjectLoader.js

Lines 133 to 137 in 45b0103

	if ( json.animations ) {
	object.animations = this.parseAnimations( json.animations );
	}

I do not understand how json.animations is created. Should I remove this code when implementing the scene approach?

[Mugen87]

Nevertheless, I see you favor the Scene approach. I'll playing with it around and see how it goes.

I've implemented this approach today here: Mugen87@c27d8c2

https://raw.githack.com/Mugen87/three.js/8917105377839889844f77c127d4d479f1844998/editor/index.html

My conclusion is that managing animations on Scene level introduces an unnecessary complexity that you don't see if you manage animations on Object3D level.

• As you can see at the Scene class, you need an API that assign animations to 3D objects. Something which is not required if you have Object3D.animations. Animations on object level are required though since you usually want to work with all animations of a specific 3D object. The editor is a good example for this (clicking on an object in the outliner and display all respective animations).
• The problem is now the PR builds this relationship in Scene and decomposes it again in editor. You can see this in SidebarAnimation where the code requests the object's animations from the scene.
• If we would handle animation clips similar to shapes or textures, it would be possible to maintain them on object level without serializing the same clip multiple times. So managing animations on object level does not lead to duplicate JSON.

To sum up: I do not recommend to manage animations on scene level. If we do this on object level, we can still ensure that clips are serialized once and not nested inside the JSON structure. Sorry but I'm currently not able to see the benefits of having animations on scene level. Benefits which justify the additional complexity in code. It's like assigning materials to Scene instead of Object3D and then model the relationship between 3D objects and materials in Scene. It's just does not feel right.

[mrdoob]

@Mugen87 Thanks a lot for giving a try 🙏 Yes, lets add animation to Object3D instead.

[JaimeTorrealba]

Hi guys @mrdoob @Mugen87, I would like to contribute to the editor. How is the process? Is there a roadmap or something?
or just I open an issue to see if is accepted or no ¿?

[mrdoob]

What do you want to add?

[JaimeTorrealba]

What do you want to add?

Well, I was thinking of adding more THREE stuff like extrude or shape, but you have already in the code, so maybe layers, line or others functionalities like focus or isolate objects?.
Maybe another section for objects in the add-ons (could be a good idea to group the "add" menu in sub-menus, otherwise could grow too much, like cameras, primitives, lights, etc.) wdyt?

[davcri]

Does the editor support GLTF variants? If not would it be a good issue to work on?