You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the author and maintainer of TresJS, I would like to simplify and clean the custom renderer nodeOps to make the code more readable and easier to maintain.
At, we are using overpopulation the property userData for the scene and objects on the scene graph as a workaround for accessing state or adding extra properties and methods that we need for TresJS nodeOps like this:
userData is a property that the end-user can also use, we need to add the .tres__ prefix to avoid naming collisions, adding an extra cognitive load to the code.
Code ends up being kind of difficult to read:
remove(node){if(!node)return// remove is only called on the node being removed and not on child nodes.if(node.isObject3D){constobject3D=nodeasunknownasObject3DconstdisposeMaterialsAndGeometries=(object3D: Object3D)=>{consttresObject3D=object3DasTresObject3Dif(!object3D.userData.tres__materialViaProp){tresObject3D.material?.dispose()tresObject3D.material=undefined}if(!object3D.userData.tres__geometryViaProp){tresObject3D.geometry?.dispose()tresObject3D.geometry=undefined}}constderegisterAtPointerEventHandler=scene?.userData.tres__deregisterAtPointerEventHandlerconstderegisterBlockingObjectAtPointerEventHandler=scene?.userData.tres__deregisterBlockingObjectAtPointerEventHandlerconstderegisterAtPointerEventHandlerIfRequired=(object: TresObject)=>{if(!deregisterBlockingObjectAtPointerEventHandler)throw'could not find tres__deregisterBlockingObjectAtPointerEventHandler on scene\'s userData'scene?.userData.tres__deregisterBlockingObjectAtPointerEventHandler?.(objectasObject3D)if(!deregisterAtPointerEventHandler)throw'could not find tres__deregisterAtPointerEventHandler on scene\'s userData'if(object&&supportedPointerEvents.some(eventName=>object[eventName]))deregisterAtPointerEventHandler?.(objectasObject3D)}constderegisterCameraIfRequired=(object: Object3D)=>{constderegisterCamera=scene?.userData.tres__deregisterCameraif(!deregisterCamera)throw'could not find tres__deregisterCamera on scene\'s userData'if((objectasCamera).isCamera)deregisterCamera?.(objectasCamera)}node.removeFromParent?.()object3D.traverse((child: Object3D)=>{disposeMaterialsAndGeometries(child)deregisterCameraIfRequired(child)deregisterAtPointerEventHandlerIfRequired?.(childasTresObject)})disposeMaterialsAndGeometries(object3D)deregisterCameraIfRequired(object3D)deregisterAtPointerEventHandlerIfRequired?.(object3DasTresObject)}node.dispose?.()},
Suggested solution
Add a local state for each instance called __tres which contains:
exportinterfaceLocalState={type: string// objects and parent are used when children are added with `attach` instead of being added to the Object3D scene graphobjects: Instance[]parent: Instance|nullprimitive?: booleaneventCount: numberhandlers: Partial<EventHandlers>memoizedProps: {[key: string]: any}}
We could include the context of TresContextProvider on the scene object to handle the register of cameras and event handlers or even inside each LocalState on a potential property root
exporttypeLocalState={type: string// objects and parent are used when children are added with `attach` instead of being added to the Object3D scene graphroot: TresContext,objects: Instance[]parent: Instance|nullprimitive?: booleaneventCount: numberhandlers: Partial<EventHandlers>memoizedProps: {[key: string]: any}}
Description
As the author and maintainer of TresJS, I would like to simplify and clean the custom renderer
nodeOps
to make the code more readable and easier to maintain.At, we are using overpopulation the property userData for the scene and objects on the scene graph as a workaround for accessing state or adding extra properties and methods that we need for TresJS nodeOps like this:
scene.userData.tres__registerAtPointerEventHandler = registerObject
userData
is a property that the end-user can also use, we need to add the.tres__
prefix to avoid naming collisions, adding an extra cognitive load to the code.Code ends up being kind of difficult to read:
Suggested solution
Add a local state for each instance called
__tres
which contains:We could include the context of TresContextProvider on the scene object to handle the register of cameras and event handlers or even inside each LocalState on a potential property
root
Alternative
No response
Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: