SOLOD(3iv)
π SoLOD β bestie, it's the distance-based level-of-detail switching group node π
manual page: SoLOD(3IV) β yes that's the whole vibe, section 3IV, we're in Inventor territory now π¦
πΈ INHERITS FROM πΈ
SoBase > SoFieldContainer > SoNode > SoGroup > SoLOD
so it's a whole family tree situation β everything SoGroup can do, this baby can do too, plus its own lil LOD magic β¨
π SYNOPSIS π
#include <Inventor/nodes/SoLOD.h>
Fields from class SoLOD π
SoMFFloat range
SoSFVec3f center
Methods from class SoLOD π
SoLOD()
static SoType getClassTypeId()
Methods from class SoGroup π«Ά
void addChild(SoNode *child)
void insertChild(SoNode *child, int newChildIndex)
SoNode * getChild(int index) const
int findChild(const SoNode *child) const
int getNumChildren() const
void removeChild(int index)
void removeChild(SoNode *child)
void removeAllChildren()
void replaceChild(int index, SoNode *newChild)
void replaceChild(SoNode *oldChild, SoNode *newChild)
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 β¨
okay so picture this: you've got one object, but you have multiple versions of it at different detail levels, and you want the app to justβ¦ pick the right one automatically based on how far away the camera is. That's literally what this group node is for. π
The children of this node typically represent the same object or objects at varying levels of detail, from highest detail to lowest. Then the node computes the distance from the world-space eye point to the transformed center of the LOD</>, and draws one child, based on the values in the ranges field. Obsessed, honestly.
More precisely β and bestie, this is the part you actually need β if the distance from the world-space eyepoint to the transformed center is D and the ranges array contains LAST_RANGE+1 values (numbered 0...LAST_RANGE), then:
if D < ranges[0] : Child 0 is drawn
else if ranges[i-1] < D < ranges[i] : Child i is drawn
else if D > ranges[LAST_RANGE] : Child LAST_RANGE+1 is drawn
So the math is mathing: N ranges and N+1 children should be specified. π
And if you mess up the ratio (no judgement, we've all been there):
- If you specify too few children, the last child will be used for the extra ranges.
- If you specify too few ranges, the extra children will never be used.
π¨ not me warning you: getting the counts wrong doesn't error out, it just silently does the thing above. So count your children, bestie.
Two lil tricks that are genuinely iconic:
- It's often useful to define the lowest detail child to be an
SoInfonode. That makes the object completely disappear if it's far enough away from the eyepoint. - Defining the highest detail child to be an
SoInfonode can also be useful if you want the object to disappear if it gets too close to the eyepoint.
π FIELDS π
SoMFFloat rangeβ the world-space distances you're using as your switching criteria. this is the whole decision-maker fr fr.SoSFVec3f centerβ the object-space center of the model. π―
π METHODS π
SoLOD()β creates a distance-based level-of-detail node with default settings. baby's first LOD, slay. β¨static SoType getClassTypeId()β returns the type identifier for this class. iykyk. π
π₯ ACTION BEHAVIOR π₯
SoGLRenderAction, SoRayPickAction, SoCallbackAction
Only the child with the appropriate level of detail is traversed. That's the whole point, and it ate. π
others
All implemented as for SoGroup. no extra drama, it just does what the parent class does. π«Ά
π FILE FORMAT/DEFAULTS π
LOD {
center 0 0 0
range [ ]
}
π¦ SEE ALSO π¦
SoSwitchSoGroup
and that's the page!! signed off at the bottom as SoLOD(3IV)() β that's your manual name, section and all, sitting pretty in the footer with no date and no extra source info, so don't go looking for a version string that isn't there bestie ππ stay detailed, stay culled, periodt β¨
π¦ 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