vpSetVoxelField(3)
π vpSetVoxelField π
okay so bestie, welcome to vpSetVoxelField(3) from the Library Functions Manual β this is the one where we tell VolPack what our voxels actually look like on the inside. she's a function AND a macro, she's booked and busy. β¨
πΈ NAME πΈ
vpSetVoxelField, vpFieldOffset β define the size and location of a voxel field
π SYNOPSIS π
#include <volpack.h>
vpResult
vpSetVoxelField(vpc, field_num, field_size, field_offset, field_max)
vpContext *vpc;
int field_num;
int field_size;
int field_offset;
int field_max;
int
vpFieldOffset(voxel_ptr, field_name)
vpContext *vpc;
LITERAL field_name;
π ARGUMENTS π
vpcβ the VolPack context you got fromvpCreateContext. your whole world lives in here.field_numβ which field number you're defining. first field is0, no cap.field_sizeβ how big the field is, in bytes.field_offsetβ how many bytes from the beginning of the voxel to the beginning of the field. it's giving "where does this field start, exactly".field_maxβ the maximum possible value this field could ever hold.voxel_ptrβ pointer to a C structure that defines the fields in the voxel.field_nameβ the literal name of the voxel field inside that C structure. yes literally the name, iykyk.
β¨ DESCRIPTION β¨
vpSetVoxelField is your girl for defining the size and location of every single field in a voxel. π
So here's the flow, bestie: once you've picked your sizes and your order for the voxel fields, you call vpSetVoxelSize once, and then you call vpSetVoxelField once for each field. that's the whole ritual, periodt.
Every field gets a unique field number β that's the field_num argument. first field is 0, next is 1, and so on, all the way up to one less than the total number of fields you defined with VpSetVoxelSize.
The field_max argument is what determines the required size for lookup tables that get indexed by the value in a particular field. the maximum field value can be any number from 0 up to the maximum unsigned integer that's representable by the field size. π
π¦ declaring your voxel with a C struct π¦
If you've declared the layout of a voxel using a C structure, you can use the sizeof operator and the vpFieldOffset macro to compute your field sizes and offsets. vpFieldOffset returns the number of bytes from the beginning of a C structure to the beginning of a particular field in that structure.
for example, here's how you'd declare the size and offset for one voxel field:
struct voxel {
char field0;
char field1;
short field2;
} *dummy_voxel;
#define SIZE_0 sizeof(char)
#define OFFSET_0 vpFieldOffset(dummy_voxel, field0)
#define MAX_0 127
vpSetVoxelField(vpc, 0, SIZE_0, OFFSET_0, MAX_0);
π the rules, and you WILL respect them π
- the size of each field must be
1,2or4bytes. that's it. that's the list. - you also have to obey any byte-alignment restrictions your hardware demands. on many machines, two-byte fields must begin on a two-byte boundary, and four-byte fields must begin on a four-byte boundary.
- the total size of a voxel may also need to be padded so that voxels packed one after the other still obey the alignment restrictions.
- if you declare your voxel as a C structure and use the
sizeofoperator and thevpFieldOffsetmacro, then you should always get correct results. π― - however β and this is the shady part β if you don't consider alignment restrictions when you're choosing the voxel field ordering, the compiler may have to insert padding for you, and that's wasted memory. not cute. π
π§ fields that other routines need π§
Some VolPack routines require you to declare fields of a particular size so they have somewhere to store their results. the functions that precompute surface normals and gradient magnitudes (see vpVolumeNormals(3), vpScanlineNormals(3), vpClassifyVolume(3), vpClassifyScalars(3) and vpClassifyScanline(3)) can optionally store a one-byte scalar value, a one-byte gradient magnitude, and a two-byte surface normal value in each voxel.
the following constants, defined in volpack.h, give you the corresponding maximum field values: VP_SCALAR_MAX, VP_GRAD_MAX, and VP_NORM_MAX. π
If you choose not to use these functions, then there's no need to declare these fields. skip them, live your life.
π«Ά opacity tea π«Ά
It's usually not necessary to declare a field for the voxel opacity if the opacity can be computed from the other voxel fields. see vpSetClassifierTable(3) for further discussion.
β οΈ heads up bestie: if the call to vpSetVoxelSize succeeds, any existing precomputed volume data structures in the context are destroyed. gone. bye. π
β STATE VARIABLES β
You can retrieve the current voxel field parameters with these state variable codes (see vpGeti(3)): VP_FIELD_SIZES, VP_FIELD_OFFSETS, VP_FIELD_MAXES.
π₯ ERRORS π₯
The normal return value is VP_OK. the following error return value is possible:
VPERROR_BAD_VALUEβ the field number, size or offset is out of range. someone's not colouring inside the lines. π
π SEE ALSO π
VolPack(3), vpCreateContext(3), vpSetVoxelSize(3)
and that's the page, bestie!! this iconic lil manual came to you from VolPack, under the name vpSetVoxelField(3) β go forth and define your voxel fields correctly, no cap. πβ¨π
π¦ where this page comes from
- fedora 43: volpack 1.0c7-35.fc43 Β· BSD-3-Clause
- fedora 43: volpack 1.0c7-35.fc43 Β· BSD-3-Clause
- fedora 44: volpack 1.0c7-36.fc44 Β· BSD-3-Clause
- fedora 44: volpack 1.0c7-36.fc44 Β· BSD-3-Clause
- Copyright (c) 1995-2008, Stanford University
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms