SOPOINTLIGHTMANIP(3iv)
π SoPointLightManip(3IV) β the glow-up your lighting deserved π
okay bestie, so this page is SoPointLightManip(3IV) β that's the manual name, that's the vibe, that's the whole thing. Buckle up, we're doing lights with a 3D interface and it's gonna be a whole journey. β¨
πΈ NAME πΈ
SoPointLightManip β a point light node that comes with a built-in 3D interface for editing its location. yes really. it's giving "light, but make it interactive." π
π¦ INHERITS FROM π¦
SoBase > SoFieldContainer > SoNode > SoLight > SoPointLight > SoPointLightManip
a whole ancestry moment fr fr π
β¨ SYNOPSIS β¨
#include <Inventor/manips/SoPointLightManip.h>
Fields from class SoPointLight:
SoSFVec3f location
Fields from class SoLight:
SoSFBool on
SoSFFloat intensity
SoSFColor color
Methods from class SoPointLightManip:
SoPointLightManip()
SoDragger * getDragger()
SbBool replaceNode(SoPath *p )
SbBool replaceManip(SoPath *p, SoPointLight *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
like. look at all those inherited methods. generational wealth. π«Ά
π DESCRIPTION π
SoPointLightManip is the base class for all SoPointLight nodes that have a built-in 3D user interface β and heads up, this is the only such class provided with the Inventor toolkit. exclusive. main character energy only.
Since it derives from SoPointLight, any change to its fields changes the lighting for nodes that follow it in the scene graph. the interface here edits the location field. also, the color of the manipulator's geometry reflects the color of the light β but no cap, you can not edit the color using this manipulator. look with your eyes, not with your hands. π
Typically you'll want to swap a regular SoPointLight for an SoPointLightManip (like when the user selects a light to be edited), or the other way around (like when they're done moving the light and the interface should go away). Use replaceNode() to insert a manipulator into a scene graph, and replaceManip() to remove it when you're done. in-and-out, no mess. π
The SoPointLightManip utilizes an SoPointLightDragger to provide that 3D interface. But β plot twist β the manipulator differs from the dragger: it lights other objects in the scene, because as an SoPointLight it alters the state. The dragger's field values and movement, on the other hand, affect only the dragger itself. Want the full tea on how the interface works and what each part does? Go read the reference page for SoPointLightDragger. The interfaces of the dragger and the manipulator are identical. twin behavior fr.
The SoPointLightManip utilizes its dragger by adding it as a hidden child. When an action is applied to the manipulator β rendering, handling events, whatever β 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 those events down to the dragger, which moves as a result ("I can't help it, I'm a dragger!"). iconic quote honestly.
The manipulator maintains consistency between the fields of the dragger and its own fields. Say you use the mouse to translate the dragger β callbacks insure that the location 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 location field of the SoPointLightManip, the manipulator will place the dragger accordingly. mutual. synchronized. obsessed. π
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 β yes, that's the ACTION BEHAVIOR bit below, we got you. π)
If you want a pointer to the dragger, you can get it from the manipulator using the getDragger() method. You need to do this if you want to change the geometry of a manipulator, since the geometry actually belongs to the dragger. not your manipulator's business, respectfully. π
π₯ METHODS π₯
SoPointLightManip()β 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 thesetPart()method, or add callbacks using the methods found in theSoDraggerreference page. go forth and customize bestie πSbBool replaceNode(SoPath *p )β Replaces the tail of the path with this manipulator. The tail of the path must be anSoPointLightnode (or subclass thereof). If the path has a nodekit, this will try to usesetPart()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 point light 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. you're on your own for the bookkeeping, bestie, that's the deal π
SbBool replaceManip(SoPath *p, SoPointLight *newOne ) constβ Replaces the tail of the path, which must be this manipulator, with the givenSoPointLightnode. If the path has a nodekit, this will try to usesetPart()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 point light 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. same energy as before, no free rides π«Ά
static SoType getClassTypeId()β Returns type identifier for this class. your class's little ID card π³
π ACTION BEHAVIOR π
SoGLRenderAction,SoCallbackAction,SoGetBoundingBoxAction,SoGetMatrixAction,SoHandleEventAction,SoRayPickActionβ First, traverses the dragger the way anSoGroupwould. All draggers place themselves in space, but leave the current transformation unchanged when finished. Then theSoPointLightManipadds a point light into the state, just like its base class,SoPointLight. dragger does its little walk, then the light does its little job. teamwork! πSoSearchActionβ Searches just like anSoPointLight. Does not search the dragger, which is a hidden child. sneak level: maximum πSoWriteActionβ Writes out just like anSoPointLight. 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 thegetDragger()method and then write it out separately. it's giving "I'll handle that myself, thanks." π
π FILE FORMAT/DEFAULTS π
PointLightManip {
on TRUE
intensity 1
color 1 1 1
location 0 0 1
}
defaults so clean they could be a skincare routine β¨
β SEE ALSO β
SoDraggerSoPointLightSoPointLightDraggerSoDirectionalLightManipSoSpotLightManip
and that's the whole page, bestie!! π¦ this came out of the SoPointLightManip(3IV) manual, and the footer is literally just SoPointLightManip(3IV) again with no version and no date β minimalist, understated, kind of a slay honestly. now go light something up. no cap. ππΈβ¨
π¦ where this page comes from
- debian bookworm: inventor-doc 2.1.5-10+dfsg-2 Β· LGPL-2.0-or-later
- debian trixie: inventor-doc 2.1.6+ds-2 Β· LGPL-2.0-or-later
- ubuntu jammy: inventor-doc 2.1.5-10-24
- ubuntu noble: inventor-doc 2.1.5-10+dfsg-2.1build2 Β· LGPL-2.0-or-later
- ubuntu questing: inventor-doc 2.1.6+ds-2
- ubuntu resolute: inventor-doc 2.1.6.1+ds-1 Β· LGPL-2.0-or-later
- ubuntu stonking: inventor-doc 2.1.6.1+ds-1 Β· LGPL-2.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms