icetCompositeOrder(3)

💖 icetCompositeOrder(3) — IceT Reference 💖

okay bestie, gather round, we're talking about icetCompositeOrder — the lil function that tells IceT who goes first when it's stacking up everyone's pictures. it's giving director energy, lowkey. ✨

---

🌸 Synopsis 🌸

#include <IceT.h>

void icetCompositeOrder( const IceTInt * process_ranks );

---

🦋 Description 🦋

so here's the tea. if ICET_ORDERED_COMPOSITE is turned on, and the strategy you're running actually supports ordered composition (you check that with the ICET_STRATEGY_SUPPORTS_ORDERING state variable, slay), then the order in which images get composited is whatever you hand over to icetCompositeOrder. periodt.

now, vibe check on when this even matters:

• if compositing is happening with z-buffer comparisons — like when icetCompositeMode gets called with ICET_COMPOSITE_MODE_Z_BUFFER — then the ordering literally does not matter and you should probably just turn ICET_ORDERED_COMPOSITE off. no cap.
• but if compositing is happening with color blending — like when icetCompositeMode gets called with ICET_COMPOSITE_MODE_BLEND — then bestie, the order the images are composed in can drastically change the output. like, whole different picture. 😭

for ordered image compositing to actually work, the geometric objects each process rendered have to be arranged so that if one process's geometry is "in front" of another process's geometry for any camera ray, that ordering holds for all camera rays. and no, IceT is not doing that detective work for you — it's the application's responsibility to make sure such an ordering exists and to find it. easiest way? make each process's geometry fall cleanly into regions of a grid, octree, k-d tree, or some similar structure. clean little territories. iconic. 👑

once you've figured out the geometry order for a particular rendering viewpoint, you give it to IceT as an array of ranks. the process_ranks parameter should have exactly ICET_NUM_PROCESSES entries, and every single one has to be a unique, valid process rank. first process = the geometry that's "in front" of everybody else, next one directly behind that, and so on down the line. also, real talk: the application might only impose a partial order on the geometry, but that can easily be converted into the linear ordering IceT requires.

when ordering is on, it's fully accepted that icetCompositeOrder gets called in between every frame, because the order of the geometry may change as the viewpoint moves. per-frame glow-up, fr fr. 🎀

and if data replication is in effect (peep icetDataReplicationGroup), all processes are still expected to show up in process_ranks. correct ordering is achievable by making sure all the processes in each group are listed in contiguous entries in process_ranks. keep the group together, bestie. 🫶

---

💀 Errors 💀

• ICET_INVALID_VALUE — not every entry in the process_ranks parameter was a unique, valid process rank. rude.

---

🙈 Warnings 🙈

None. we're chill.

---

🔥 Bugs 🔥

if an ICET_INVALID_VALUE error gets raised, internal arrays pertaining to the ordering of images may not be restored properly. so if that happens, the function should be re-invoked with a valid ordering before you keep going. otherwise? unpredictable results. and not the fun kind of unpredictable. 😭

---

👑 Copyright 👑

Copyright (C)2003 Sandia Corporation

Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains certain rights in this software.

This source code is released under the New BSD License.

---

🌈 See Also 🌈

• icetCompositeMode(3)
• icetStrategy(3)

---

and that's the whole page, bestie 💅 this came to you straight from the IceT Reference, dated August 9, 2010 — go forth and composite in the correct order, you got this 🦋✨💖