SOSPOTLIGHTMANIP(3iv)

πŸ’– SoSpotLightManip β€” the SoSpotLightManip(3IV) page, bestie edition πŸ’–

okay so you opened the manual page for SoSpotLightManip(3IV) and honestly? iconic choice. this is the whole thing, nothing skipped, everything slayed. let's go 🫢


✨ NAME ✨

SoSpotLightManip β€” a spotlight node with a 3D interface for editing location, direction, and beam width. it's giving "light but make it touchable" πŸ’…


🌸 INHERITS FROM 🌸

SoBase > SoFieldContainer > SoNode > SoLight > SoSpotLight >
SoSpotLightManip

so it's got a whole family tree, and every single one of them is in the group chat. no cap. πŸ¦‹


✨ SYNOPSIS ✨

#include <Inventor/manips/SoSpotLightManip.h>

πŸŽ€ Fields from class SoSpotLight:

SoSFVec3f           location
SoSFVec3f           direction
SoSFFloat           dropOffRate
SoSFFloat           cutOffAngle

πŸŽ€ Fields from class SoLight:

SoSFBool            on
SoSFFloat           intensity
SoSFColor           color

πŸŽ€ Methods from class SoSpotLightManip:

                     SoSpotLightManip()
SoDragger *          getDragger()
SbBool               replaceNode(SoPath *p )
SbBool               replaceManip(SoPath *p, SoSpotLight *newOne ) const
static SoType        getClassTypeId()

πŸŽ€ Methods from class SoNode:

void                setOverride(SbBool state)
SbBool              isOverride() const
SoNode *            copy(SbBool copyConnections = FALSE) const
virtual SbBool      affectsState() const
static SoNode *     getByName(const SbName &name)
static int          getByName(const SbName &name, SoNodeList &list)

πŸŽ€ Methods from class SoFieldContainer:

void                setToDefaults()
SbBool              hasDefaultValues() const
SbBool              fieldsAreEqual(const SoFieldContainer *fc) const
void                copyFieldValues(const SoFieldContainer *fc, SbBool
                         copyConnections = FALSE)
SbBool              set(const char *fieldDataString)
void                get(SbString &fieldDataString)
virtual int         getFields(SoFieldList &resultList) const
virtual SoField *   getField(const SbName &fieldName) const
SbBool              getFieldName(const SoField *field, SbName &fieldName)
                         const
SbBool              isNotifyEnabled() const
SbBool              enableNotify(SbBool flag)

πŸŽ€ Methods from class SoBase:

void                ref()
void                unref() const
void                unrefNoDelete() const
void                touch()
virtual SoType      getTypeId() const
SbBool              isOfType(SoType type) const
virtual void        setName(const SbName &name)
virtual SbName      getName() const

πŸ’… DESCRIPTION πŸ’…

SoSpotLightManip is the base class for all SoSpotLight nodes that come with a built-in 3D user interface β€” and fr fr, it's the only such class provided with the Inventor toolkit. main character behavior, we love to see it. πŸ‘‘

since it's derived from SoSpotLight, any changes to its fields result in a change of lighting for nodes that follow it in the scene graph. in this case, the interface edits the location, direction, and cutOffAngle fields. also, the color of the manipulator's geometry will reflect the color of the light β€” but heads up bestie, you can not edit the color using this manipulator. πŸ™ˆ

typically, you will want to replace a regular SoSpotLight with an SoSpotLightManip (like when the user selects a light to be edited), or vice versa (like when the user is done moving the light and the interface should go away). use the replaceNode() method to insert a manipulator into a scene graph, and the replaceManip() method to remove it when done. so clean, so tidy. ✨

the SoSpotLightManip utilizes an SoSpotLightDragger to provide a 3D interface. however β€” and this part is lowkey important β€” the manipulator differs from the dragger: it lights other objects in the scene because, as an SoSpotLight, it alters the state. the field values and movement of the dragger, on the other hand, affect only the dragger itself. to find out more about how the interface works and what each part will do, see the reference page for SoSpotLightDragger. the interfaces of the dragger and the manipulator are identical. πŸͺž

the SoSpotLightManip utilizes its dragger by adding it as a hidden child. when an action is applied to the manipulator, such as rendering or handling events, the manipulator first traverses the dragger, and then the manipulator adds its lighting parameters to the state. when you click-drag-release over the manipulator, it passes these events down to the dragger, which moves as a result ("I can't help it, I'm a dragger!"). 😭 honestly same.

the manipulator maintains consistency between the fields of the dragger and its own fields. let's say you use the mouse to widen the cone of the dragger β€” callbacks insure that the cutOffAngle field of the manipulator will change by the same amount, thus changing the lighting of nodes which follow in the scene graph. similarly, if you set the cutOffAngle field of the SoSpotLightManip, the manipulator will widen the beam of the dragger accordingly. they're synchronized, they're in sync, they're literally the same vibe. 🌈

because the dragger is a hidden child, you can see the dragger on screen and interact with it, but the dragger does not show up when you write the manipulator to file. also, any SoPath will end at the manipulator. (see the Actions section of this reference page for a complete description of when the dragger is traversed). πŸ‘€

if you want to get a pointer to the dragger you can get it from the manipulator using the getDragger() method. you will need to do this if you want to change the geometry of a manipulator, since the geometry actually belongs to the dragger. sneaky little geometry custody situation, but we move. πŸ’œ


πŸ¦‹ METHODS πŸ¦‹

  • SoSpotLightManip() β€” Constructor. the birth of a legend. πŸŽ€
  • SoDragger * getDragger() β€” Returns a pointer to the dragger being used by this manipulator. given this pointer, you can customize the dragger just like you would any other dragger. you can change geometry using the setPart() method, or add callbacks using the methods found in the SoDragger reference page. go off, customize. πŸ”₯
  • SbBool replaceNode(SoPath *p ) β€” Replaces the tail of the path with this manipulator. the tail of the path must be an SoSpotLight node (or subclass thereof). if the path has a nodekit, this will try to use setPart() to insert the manipulator. otherwise, the manipulator requires that the next to last node in the path chain be a group.

the field values from the spotlight node will be copied to this manipulator, and the light node will be replaced.

the manipulator will not call ref() on the node it is replacing. the old node will disappear if it has no references other than from the input path p and its parent, since this manipulator will be replacing it in both of those places. nor will the manipulator make any changes to field connections of the old node. the calling process is thus responsible for keeping track of its own nodes and field connections. ⚠️ no take-backs, bestie.
  • SbBool replaceManip(SoPath *p, SoSpotLight *newOne ) const β€” Replaces the tail of the path, which must be this manipulator, with the given SoSpotLight node. if the path has a nodekit, this will try to use setPart() to insert the new node. otherwise, the manipulator requires that the next to last node in the path chain be a group.

the field values from the manipulator will be copied to the spotlight node, and the manipulator will be replaced.

the manipulator will not call ref() or unref() on the node which is replacing it, nor will it make any changes to field connections. the calling process is thus responsible for keeping track of its own nodes and field connections. πŸ’€ yes this is on you now.
  • static SoType getClassTypeId() β€” Returns type identifier for this class. your little class ID card, periodt. ⭐

🌈 ACTION BEHAVIOR 🌈

πŸ’– SoGLRenderAction, SoCallbackAction, SoGetBoundingBoxAction, SoGetMatrixAction, SoHandleEventAction, SoRayPickAction

first, traverses the dragger the way an SoGroup would. all draggers place themselves in space, but leave the current transformation unchanged when finished. then the SoSpotLightManip adds a spotlight to the state, just like its base class, SoSpotLight. 🫢

πŸ’– SoSearchAction

searches just like an SoSpotLight. does not search the dragger, which is a hidden child. peekaboo but make it private. πŸ™ˆ

πŸ’– SoWriteAction

writes out just like an SoSpotLight. does not write the dragger, which is a hidden child. if you really need to write valuable information about the dragger, such as customized geometry, you can retrieve the dragger with the getDragger() method and then write it out separately. okay so that's the workaround, noted. πŸ“


πŸŽ€ FILE FORMAT/DEFAULTS πŸŽ€

SpotLightManip {
    on           TRUE
    intensity    1
    color        1 1 1
    location     0 0 1
    direction    0 0 -1
    dropOffRate  0
    cutOffAngle  0.785398
}

the defaults, served fresh, exactly as written. πŸ“


⭐ SEE ALSO ⭐

  • SoDragger
  • SoSpotLight
  • SoSpotLightDragger
  • SoDirectionalLightManip
  • SoPointLightManip

go read those too, they're all in the same friend group. πŸ’«


and that's the whole page, bestie β€” it signs off as SoSpotLightManip(3IV)(), that's the source/version stamp on the page (no date on this one, she's timeless πŸ’…). now go move some lights around. you ate. πŸ‘‘βœ¨