- articleIs there a primary source (a named previs supervisor, studio or published study) giving a proportion of previs that is used versus discarded?
No proportion was found in the sources actually read. The one pinned primary statement is a qualitative one from a named Third Floor previs editor (Ian Differ, ProVideo Coalition interview, 11 August 2018): sometimes previs work ends up in the film and sometimes it does not. A '99 percent' figure in the same interview is about where handheld camera shake comes from, not retention, and should not be cited as a discard rate. The negative is scoped to the pages read plus web-search leads that were not fetched.
- articleHow does an open head-tracked binaural rendering specification (AOMedia IAMF) express head-locked versus world-locked rendering and reverberant filter profiles, and does it cite or encode the externalization, room-acoustics or latency evidence?
The AOMedia IAMF specification at commit 55683fae00e541cd4f0849918f19af0e04bc629c lets an element be rendered head-locked or world-locked when head tracking is enabled, and signals a binaural filter profile of AMBIENT, DIRECT or REVERBERANT. In the text searched (whole index.bs, whitespace-collapsed), the words externalization, HRTF, BRIR and latency do not occur and the profiles carry no stated acoustic parameters, so the specification names the switches that the psychoacoustic evidence is about without citing it or giving values. The mapping to the evidence (world-locked rendering ~ source fixed in the world; REVERBERANT profile ~ reverberant versus anechoic) is a synthesis.
- articleDo individual HRTFs matter for localization, front-back confusion and externalization in head-tracked headphone playback, and how do room reverberation and training modify the answer?
In one open-access head-tracked VR experiment (Jenny & Reuter 2020; 39 listeners, headphones, free field, noise from a visible moving drone), listeners rated their own measured HRTF as easier to localize, easier to externalize and more natural than the KEMAR or two other nonindividualized HRTFs, and reported front-back confusions in 27% of KEMAR responses versus 0% with their own. A 2020 review reports mixed results for externalization in reverberant conditions (no individualization effect in Begault 2001 and Leclere 2019; a gain in Werner 2016), and a 2021 Acta Acustica abstract reports that adding a dry room response accelerated learning of non-individual HRTFs. Which factor dominates in reverberant, head-tracked content is not settled by the sources read.
- articleBeyond the head-rotation study already catalogued (ips012), what do open-access sources report about head movement and head tracking for externalization and front-back confusion with generic or individual HRTFs, and what do they say about tracking latency?
Catalogue ips012 already holds the head-rotation primary results (Brimijoin 2013; McAnally & Martin 2014) and the 22 to 33 ms update latency of that implementation. Added here: Hendrickx et al. 2017 (abstract only) report that head tracking with non-individualized HRTFs substantially improved externalization, especially for frontal and rear sources, and that it persisted after movement stopped; a 2020 review adds that self-initiated movement helps more than source movement and that benefit is larger for central sources; and Jenny & Reuter 2020 report self-reported front-back confusions of 27% with a generic HRTF versus 0% with the listener's own in head-tracked VR with free head movement. The sources read assert that latency matters but report no measured latency threshold.
- articleWhich cues set how far away a virtual sound seems, and what do open-access sources say about the role of reverberation and the direct-to-reverberant ratio when placing a sound at a distance?
A 2016 open-access review (Kolarik et al.) reports that the main auditory distance cues are sound level, reverberation (notably the direct-to-reverberant ratio, DRR) and frequency, that distance is judged most accurately when level and DRR are both available, that DRR sensitivity is about 2 to 3 dB near 0 and +10 dB DRR and 6 to 8 dB at -10 and 20 dB DRR for wideband noise, and that near sources are overestimated and far sources underestimated. Reverberation helps distance but degrades azimuth localization. One primary study read here (Gil-Carvajal 2016) shows playback-room reverberation changing distance ratings for static headphone playback. No source read tests DRR with head-tracked binaural rendering.
- articleWhat happens to externalization, distance and direction when a binaural recording made in one room is played back in a different room, and does the cause lie in what the listener sees or hears?
In one open-access experiment (Gil-Carvajal et al. 2016; 18 listeners, individual BRIRs from a 0.4 s room, static head, headphones), playing the binaural speech back in a much more reverberant room (2.8 s) left only about 18% of distance ratings correct, while direction and compactness ratings did not depend on the room; changing only what listeners could see had no effect, whereas changing what they could hear did. Reviews report a different study (Werner 2016) that found a visual effect, and caution that it lacked head motion; the sources therefore support the auditory-congruence finding for static headphone playback but not a settled answer for tracked playback.
- articleHow do reverberation tail length, binaural versus diotic reverberation and early reflections in a headphone render affect externalization and localization, and what do open-access sources say about how much room detail to include?
Two open-access reviews (Best et al. 2020; Neidhardt et al. 2022) report, from cited primary studies not re-read here, that externalization improves with the first roughly 80 ms of binaural reverberant tail, depends on interaural differences in the reverberation, and matters more for midline sources whose direct sound carries weak binaural cues. Neidhardt et al. report that sensitivity to early-reflection detail is limited, but simplified early reflections can still alter coloration, apparent source width and localization. No primary open-access full text that varies RT60, DRR or early-reflection patterns on a headphone render was retrieved; the quantitative claims are therefore review-reported.
- articleWhy does binaural headphone audio often sound inside the head, and which cues does a spatial-audio workflow need to provide so a listener hears it outside the head?
A 2020 open-access review (Best et al., Trends in Hearing) reports that diotic headphone sound is typically heard inside the head and that externalization is more likely with binaural reverberation, with sources that stay fixed in the world when the head turns, and with cues consistent with what the listener expects of the room. Evidence on whether listener-specific HRTFs are needed is described as mixed. The review is a secondary, keyword-search synthesis; its statements are leads to the cited primary studies, of which one (Gil-Carvajal 2016) was read in full here and others are covered by catalogue ips012.
- articleWhere is AI documented in 360-film attention work (saliency prediction, script-driven object highlighting, generated 360 scenes), and what evidence supports it?
Two documented AI connections were found. (1) Sitzmann et al. adapt existing 2D saliency predictors to 360 panoramas by multiplying with a learned equator bias and propose saliency-based cut alignment (static-panorama data, not reproduced). (2) da Silva et al. (SVR 2024, arXiv 2026, CC BY 4.0) chain Grounding DINO and Segment Anything to find the object named in a text script and apply a vignette to it in a 360 tour; their text shows frames from a university video tour, one SAM failure, and a conclusion that 'user experience' improves, but the extract shows no user study or measurement supporting that claim. No source linking generated 360 scenes to viewer-attention outcomes was found in a bounded search.
- articleWhat public head-movement and saliency datasets exist for 360-degree content, and what do they show about where viewers look (and what they cannot show about story)?
Two open-access datasets papers were read: Sitzmann et al. (arXiv v2; 22 computer-generated static stereo panoramas, 169 users, 1980 gaze-and-head trajectories, three viewing conditions) report an equator bias and strong between-user agreement; Nasrabadi et al. (MMSys 2019; 28 videos built on a moving-object by camera-motion taxonomy, 60 participants, no audio; MIT-licensed GitHub repo with traces, questionnaires and scripts) report preliminary signs that viewers tend to look at moving targets, with exceptions, and more dispersed viewing in higher-altitude shots. Nasrabadi et al. also list other datasets with participant counts (e.g. 59 participants/5 videos; 48 subjects/20 videos; 57 subjects with eye data) and note viewing is more scattered under free viewing than when questioned afterward. These datasets describe viewing of short, mostly narrative-free content and do not test story comprehension or missed events.
- articleWhat is actually measured about viewers missing events or fearing they will miss events (FOMO) in 360-degree film, and which statements are only claims or hypotheses?
In the open full texts read, FOMO and missed events are asserted or hypothesised, not measured: the 2019 review hypothesises that guidance reduces fear of missing something, the 2017 abstract reports that some viewers seemed afraid of missing something and cites a case study (Syrett et al.) of missed storyline, and two practitioner accounts treat missing detail on a first viewing as expected. The measured CHI 2021 study (Aitamurto et al., 'From FOMO to JOMO') could not be fetched (ACM and UIC copies blocked or JS-gated), so its reported findings (a search snippet: FOMO did not reduce presence and fell on second viewing) are leads only. The closest measured proxy in retrieved texts is that over a third of viewers did not follow the best cue in a 32-person study.
- articleIs there a consistent, quantified effect of guidance cues on viewer experience in cinematic VR across studies, or do the results conflict?
A 2024 arXiv preprint (Zhang et al.; ACM template with placeholders, peer-review status not shown on the page) screened 3444 papers, reviewed 45 and meta-analysed 13 on CVR viewing modalities versus a 'swivel-chair' control, and reports inconsistent effect sizes even within the same modality, small samples, interchangeable use of presence/immersion/engagement, and mostly negative results for limited or forced rotation. It supports the batch's central caution: there is no universal rule, and individual cue studies (candidates 03 to 05) are not additive. The outcomes are questionnaire experience measures, not missed-event or gaze-target accuracy.
- articleWhich diegetic cues (sound, light, motion) were reported to change where 360-film viewers look, including targets outside the field of view, and how does the 2019 taxonomy organise cue choices?
Rothe, Hussmann and Allary's 2017 VRST extended abstract (head-direction heat maps from one within-subject viewing of a staged kitchen movie; participant number not given in this two-page report) reports that new sound and moving objects or lights changed viewing direction, static lights did not, and guiding at the start of a scene is hard. The 2019 Rothe-Buschek-Hussmann review (CC BY) organises guidance methods on seven dimensions (diegesis, senses, target, reference, directness, awareness, freedom) and offers use-case advice that is the authors' own proposal. The fuller 2018 AVR paper by the same group is already in the catalogue (cr-063 claims); this candidate adds the 2017 abstract and the 2019 taxonomy.
- articleDo a central arrow and a peripheral flicker differ in how well they send a 360-video viewer to a region of interest and in what the viewer remembers, in an eye-tracked HMD study?
Schmitz, MacQuarrie, Julier, Binetti and Steed (IEEE VR 2020; accepted manuscript read) tested a central arrow and a peripheral flicker with 25 adults (analysed n=24 for eye tracking and memory) in an eye-tracking HMD, guiding them to 14 regions of interest across two panoramic videos. 81.25% of cues were followed and neither cue type changed the number followed, time to reach and observe regions, memory or engagement; the flicker moved gaze farther in the first 500 ms (10.99 vs 6.02 degrees), but most users preferred the arrow. The authors conclude traditional central/peripheral attention assumptions do not transfer cleanly and that cues should be optional. The sample is young, small and the cues were conspicuous overlays, not diegetic cues.
- articleIn a controlled comparison of attention-guidance methods for 360-degree video (including forced rotation, a follow-the-object cue, an actor guide and gestures), which worked best, and under what conditions and sample size?
Speicher et al. (TVX 2019; 32 participants, within-subjects, 8 methods x 2 devices = 512 trials, short static-camera party-game clips without sound) report that every tested guidance method beat no guidance on identifying a blinking target, with a coloured follow-the-object sphere best and an actor who guides second, forced rotation not significantly less accurate than the others but lowest in user experience with the most disorientation, and an object-blink halo poor. More than a third did not follow the best cue. The result applies to this task (spotting one blinking object), seated viewers, static camera and no audio; it does not measure story comprehension or missed story events.
- articleWhat staging methods have Google Spotlight Stories people publicly stated for 360 / mobile VR animation (Pearl, Back to the Moon), and which statements are first-hand versus reported by someone else?
Reported Spotlight Stories methods are: helper characters and music changes to bring viewers back to the action (TechCrunch's 2016 report of a Google I/O talk), framing action from a fixed passenger seat using the car's geometry (Pearl, director's account), roughly twice as many cuts in the 2D version than in VR (producer, Google blog 2017), and, from a blogger's second-hand report of a 2018 Jan Pinkava talk, a front/side/rear zoning and an 8x45-degree story table plus a real-time story that waits until the viewer looks at it. Only the Pearl blog is first-person; the other items are journalists' or a blogger's paraphrases, and the '70% frontal' figure is unsourced.
- articleWhat did Oculus Story Studio say it actually did about viewer attention and staging in its first 360-degree VR short (Lost), and how reliable is that account?
Saschka Unseld's 2015 first-person post (read here from a 2017 Wayback snapshot because the live oculus.com URL now redirects to a generic Meta blog) reports that the Lost team tried audio cues, a flying bird and set design to steer gaze, found heavy use felt forced, and instead opened with a firefly 'ritual', gave viewers about 40 seconds to settle before using the bird, and aimed for story content in all directions. This is a practitioner's account of one four-minute piece: it gives no sample sizes, no measurements and no test of whether viewers actually missed events; the post itself calls the lessons suggestions, not rules.
- articleWhat footage will Autodesk Flow Studio (Wonder Studio) accept for character replacement, clean plate and camera tracking, and what shooting rules does the documentation give?
At help.wonderdynamics.com pages stamped "Updated on October 19, 2026", Flow Studio documents hard limits (.mp4/.mov, 2 minutes, 15 shots, hard cuts only), partial support for occlusion, no support for object or actor interactions, a standalone Clean Plate tool (humans only, up to four actors, hidden background must be visible at some point) and a standalone Camera Track tool (no variable zoom; best with wide shots, parallax, distinctive surfaces). No accuracy figures are published on these pages; the limits are vendor-documented constraints, while claims such as the Live Action Easy page wording ("let our advanced AI handle all the heavy lifting") are vendor claims (E16).
- articleWhat can I give Move.ai (Move One single camera, Genesis multi-camera), what do I get back, and what capture conditions do the Move docs require?
At docs observed 2026-10-22 Move documents two products: Move One (single phone camera or an uploaded .mp4/.mov/.avi up to 1 GB, 30 s free / 60 s paid clips, credit-metered per person-second) and Genesis (6-12 calibrated cameras, on-premise). Outputs are FBX/USDC/USDZ/Blender (Move One) and FBX/BVH/GLB/USDZ/Blend/C3D/JSON plus preview video (Genesis). Capture rules are practical (full body visible, locked camera, contrast clothing, no mirrors) and the docs publish no accuracy numbers; capability tables are vendor specifications, not measurements.
- articleWhat do the primary papers leave unshown for collaborative previs or multiplayer games with a generated shared world, according to their own stated limitations and evaluation protocols?
Each paper states a limit that matters for collaborative previs or multiplayer play: Solaris and MIRA lose persistent state beyond the context; Gamma-World may accumulate inconsistencies in long rollouts; MetaWorld does not model physical contact; WorldCast does not model hits or network faults; MultiWorld has not been trained at scale. Beyond these, in the eight papers read no paper reports art-direction or director controls, a multi-human study, or output-use rights for generated clips. The last three are absences in the passages read, not demonstrated impossibilities.
- articleWhat documented checks show that a captured lighting HDRI is complete (no clipped sources, full coverage) and calibrated (exposure and colour tied to reference), and what do the manuals leave unsaid?
No source read gives a numeric acceptance test. The documented checks are scattered: the original paper shows a radiance map stepped down 7 stops with no saturation and compares a rendered local scene with the photograph (differential rendering); a later paper states that diffuse and mirrored estimates must agree if no light clips; a practitioner says the darkest frame must have no clipped sources; a work-in-progress CAVE page neutralises HDRIs with a bracketed chart whose 18 percent patch sets base exposure. Vendor manuals read (Blender, VES guide) state use or purpose only. The checklist assembled here is a synthesis proposal, not a standard.
- articleWhat lighting reference should be shot at a setup so CG can be lit to match, and what does each item (grey ball, chrome ball, colour chart) tell the lighting artist?
Two practitioner pages and the VES guide agree on the kit: a grey ball (light direction, intensity, shadow), a chrome ball (where lights, camera and set are) and a colour chart (to set exposure and white balance), shot where the CG will sit and slated to the shot. The VES guide (a standards-body list) names charts, HDRIs and material props but not the procedure; the procedure and cautions come from practitioners. Cautions: painted balls may not be neutral, the chart is for exposure/white balance not colour correction, and real-world bounce on the reference should not be compensated by editing shaders.
- articleIf a shoot needs tracking markers, what shape, size, colour, count and placement do practitioners and tool manuals recommend, and where do they disagree?
Two practitioner accounts (2016) agree markers are a fallback and should be small, simple and at different depths, but disagree on numbers: one says at least nine dots visible at any moment, the other at least seven. Marker size is given only relatively (just visible in the widest shot) plus one anecdotal tape size (half-inch squares). The tool manuals read (Nuke, Blender, SynthEyes) describe what the software needs from features (non-coplanar, high contrast, not reflections, mask movers) but state no physical marker size, spacing or count.
- articleBefore a camera track, how much do I need to know about the lens focal length and sensor size, and what do I enter when I do not know them?
Both tool manuals read treat focal length and sensor (film back) as inputs to give the solver when known and as values to be estimated when not. Nuke CameraTracker offers five focal-length modes (Known, two Approximate, two Unknown) and says approximate values are refined in the solve; Blender can refine focal length but needs approximate starting values. Two practitioner/trade sources say nominal lens and sensor numbers are only starting points (manufacturer tolerance, cropped sensor areas, stabilisation), while Nuke says accurate physical data gives a better track; the sources are not directly comparable and no source here measures the error.
- articleWhat do the 4D reconstruction and generation papers say about relighting, editing, topology and render cost, i.e. the limits that matter for VFX, volumetric capture or virtual production?
Across nine primary papers (HTML bodies, before reference lists) no text contains the words relight, albedo, BRDF or virtual production; lighting appears only as scene variation to be fitted (Real-time 4DGS) or as an uncharacterised factor (DyCheck). Gaussian colour is stored as spherical-harmonic coefficients, so appearance is baked and view-dependent; relighting is therefore not a documented capability of these systems. Editing is demonstrated for rig-captured persistent Gaussians (edit propagation, object insertion, camera attachment) and described as naive transformation in 4D-GS. Topology: persistent Gaussians give point correspondence over time, DG4D gives a per-frame obj mesh sequence, and no read source reports a stable mesh topology. Render speed is high for small scenes on a consumer GPU (author-reported tens to hundreds of FPS) but is tied to Gaussian count, resolution and deformation network size; clips are seconds long and scale to large scenes is a stated limit. Produc...
- articleHow are chrome/grey balls and HDRI light probes captured on set for CG lighting, and what goes wrong with each?
Practitioner sources describe a two-tier approach: a half-chrome, half-matte-grey ball shot at each setup (fast, shows light direction, balance and sheen) and, when the set can be held, a bracketed HDRI taken where the CG object will sit. The original light-probe paper adds the failure cases: a single low-dynamic-range ball photo mis-lights the CG, and a single ball image shows the camera, its own support and samples the area behind it poorly; two images 90 degrees apart removed the camera in the authors' setup. Practical advice from the talk notes: long lens, whole sphere in focus, ball exactly where the CG object will be, and stop crew from striking lights.
- articleWhat could an agent reuse from these text-to-3D-layout papers for previs set dressing or game level blocking, and which parts are documented results versus a proposed use?
Documented: Holodeck generates AI2-THOR scenes for embodied-agent training (validated by ObjectNav), SceneCraft outputs Blender scripts and tests on Sintel scenes with a video-model conditioning experiment, Graph-to-3D edits scenes through a scene graph. Not documented in any inspected paper: use for previs set dressing or game level blocking with production assets and review. Those uses are proposals; this candidate lists a small test that could separate them.
- articleHow does Runway describe authoring a world for GWM Worlds 2 (WorldPrompt), and what does an agent have to supply?
Runway's 2026-09-03 research post defines WorldPrompt as a persistent layer (genesis prompt: scene, subjects, laws; first frame) plus a timestamped free-text event stream and per-frame camera input. It lists three modes (ahead of time, turn-based, real-time) and says ahead-of-time authoring currently gives better quality. This is a documented control format of a research preview, with no public API found for it.
- articleWhich Marble export formats and editing operations are documented, what do they cost in plan terms, and how would a program request them through the World API?
Marble's docs name inputs (text, image, multi-image, panorama, video under 100MB, Chisel coarse 3D), editing (pano edit, expand, variations, compose, record) and exports (SPZ and PLY splats, collider and high-quality GLB meshes, panorama PNG, video). Export is plan-gated: the Free plan can generate but not export; collider meshes and splats come with Standard; textured high-quality mesh and expand come with Pro. The World API documents an export call for PLY (from SPZ) and GLB mesh. Several doc statements disagree on details (below).
- articleWhat is the normative definition of MaxCLL and MaxFALL that is openly readable, and what does it say about how they are measured?
The CTA-861.3 text is paywalled, but ITU-T H.265 (V11, 01/2026) clause D.3.35 is a free primary text that defines the content light level SEI in terms CTA-861.3 relies on. Per pixel, take EMax = max(R,G,B) in linear light, convert to a light level as the CIE 1931 luminance of equal-amplitude RGB at EMax, scaled so peak white is 10,000 cd/m2 for PQ. max_content_light_level is an upper bound over all samples of the coded video sequence; max_pic_average_light_level is an upper bound on the maximum, over pictures, of the average over samples. The SEI does not itself specify the conversion from decoded samples to linear light.
- articleBeyond first order, what do the ambix converter, Spatial_Audio_Framework (SPARTA) and IEM Plug-in Suite code define for FuMa support, N3D/SN3D gains and channel order?
Tools disagree on how far FuMa goes, so a higher-order FuMa file converts differently depending on the tool. The ambix converter has real FuMa-to-SN3D gains through 3rd order (W x sqrt 2; 2nd-order 0.866 except the centre 1.0; 3rd-order 0.791/0.745/0.843/1.0). Its table continues to 10th order, but every entry above 3rd order is 1.0 (placeholders, not FuMa definitions). The Spatial Audio Framework (used by SPARTA) supports FuMa at first order only and zeroes higher channels. IEM's plug-in header has only SN3D<->N3D factors (sqrt 3, sqrt 5, ... per order) and no FuMa. ambix converters older than v0.2.6 (April 2016) used a different FuMa W scaling.
- articleWhat does the MPEG_animation_timing glTF extension define and what governs its use?
MPEG_animation_timing is a vendor extension (not KHR) in the Khronos glTF registry. It carries only a required pointer to an accessor of BYTE/SCALAR timing samples whose format and synchronisation meaning are defined in ISO/IEC 23090-14 clause 7.6.3, so the README alone cannot be implemented. It also requires MPEG_accessor_timed, MPEG_buffer_circular and MPEG_media. The README was registered for the first edition in February 2023, still cites the FDIS text, and has not changed since March 2023. Use is under the ISO licence and IPR policy, not a Khronos licence.
- articleIs ACES 2.0 appearance consistent between SDR and HDR outputs, how does mid grey change with peak luminance, and what do game-engine implementers report about matching SDR and HDR?
ACES 2.0 deliberately lets mid grey rise with display peak (18% grey at about 10 nit for 100-nit SDR, 13.2 nit at 500, 14.5 nit at 1000), coded as a 0.14 grey-change weight in the tonescale. Forum participants state ACES 2.0 was not tested against dynamic (variable SDR white) mapping and that scaling HDR to match gained-up SDR is an untested suggestion; no source read quantifies SDR/HDR appearance match.
- articleWhich public HRTF/SOFA-convertible measurement sets state terms an agent can check (MIT KEMAR, Viking), and where is the SOFA catalogue?
MIT's KEMAR HRTF data (1994) are free to use without restriction provided the authors are cited (710 positions, 44.1 kHz); the Viking HRTF dataset v2 on Zenodo (2020) is licensed CC BY 4.0 in its record metadata and distributed as SOFA files plus 3D scans. Terms for third-party SOFA conversions of KEMAR were not readable (SOFA hosts refused connections to producer).
- articleWhat public documentation exists for Dolby Atmos ADM BWF masters (container, limits, pairing rules), and who publishes it?
The only Dolby Atmos master rules readable here are a distributor's: Prime Video requires ADM BWF in a BWF-RF64 .wav (codec DOLBY-ATMOS-ADMBWF), 24-bit 48 kHz LPCM, at most 128 tracks, 118 objects and 10 beds, a matching-locale non-Atmos source with a 5.1 mix, and no M&E, MOS, silent or commentary tracks in the Atmos source. Dolby's own ADM profile PDF could not be reached by producer or curator.
- articleWhich axis, handedness, unit and time conventions does each of glTF, OpenUSD, FBX (via ufbx), Blender, Unreal, Unity, Maya and Houdini document, and where do they have to be converted?
Default conventions differ: glTF is right-handed, +Y up, asset front facing +Z, in metres; OpenUSD is right-handed with a per-stage upAxis (Y or Z; files should always set it) and a metersPerUnit scale; FBX (via ufbx) usually uses centimetres and its 'front' axis is the opposite of forward; Unreal's editor is left-handed Z-up; Blender works Y-forward Z-up and its USD exporter can convert orientation. Any conversion must reconcile handedness, up/forward axis and unit scale explicitly.
- articleWhat do the OpenXR registry and the META viseme chapter not define about visemes (ratification, timing, mapping to blend shapes)?
The viseme extension is a vendor (META) extension without a ratified attribute in the 1.1.65 registry, and its chapter defines no viseme-to-blend-shape or ARKit mapping, no output rate and no latency; an agent mapping these visemes to a rig must supply its own mapping and timing assumptions.
- articleWhat does XR_META_face_tracking_visemes define (viseme list, value semantics, validity, dependencies) in the OpenXR registry and spec source?
OpenXR (release 1.1.65) defines the Meta viseme extension XR_META_face_tracking_visemes (number 542, layered on XR_FB_face_tracking2) with 15 visemes (SIL, PP, FF, TH, DD, KK, CH, SS, NN, RR, AA, E, IH, OH, OU) reported as probabilities that sum to 1 when valid; it is meant to match common 15-viseme sets and the older Oculus Lipsync visemes, and apps can request visemes without blend shapes by setting weight and confidence counts to zero.
- articleCan I get an edit list (EDL or OpenTimelineIO) of a cinematic out of Unity or Godot, or do their exporters only write animation?
In the documents read, neither Unity nor Godot offers an edit-decision-list export for cinematics: Unity's FBX Exporter writes one Timeline animation clip at a time (animation data, not an edit), and the OpenTimelineIO adapter list has no Unity, Godot or Unreal adapter (Maya sequencer is the only DCC sequencer), although custom adapters can be registered. This is a limited-search negative.
- articleWhen I render or record a cinematic from Unreal, Unity or Godot, which stage tone-maps and tags colour before the file is written, and what do the engines' docs leave unstated?
Unreal 5.1's Movie Render Queue documentation says 8-bit image sequences (BMP, JPG, PNG) are clamped to [0-1] with the sRGB encoding curve, while EXR keeps HDR values: roughly [0-1] with the Tone Curve enabled, linear [0-100] or more with it disabled, and never sRGB-encoded. Godot's Movie Maker documentation and PNG writer state no colour space or transfer for written frames, so an agent must measure or assume; Unity's inspected HDR pages (producer) cover display output, not recorded frames.
- articleHow does ARRI embed camera and lens metadata in SDI (KLV in ANC packets), and what do the lens fields, including the newly documented effective focal length and entrance pupil, say?
ARRI sends extended camera metadata over SDI as the 4096-byte ArriFileV3 header wrapped in SMPTE 336M-2007 KLV (BER length 83 00 10 00) and a separate 12-bit LUT KLV of 6144 bytes (83 00 18 00), segmented into SMPTE 291M ANC packets. ALEXA 35 SUP 1.2 adds lens fields LDI26 and LDI27 in micrometres; LDI26 is named 'Lens Effective Focal Length' (back nodal point to back focus point) in the change notes but 'Axial Effective Focal Length' in the field table, and LDI27 is the entrance pupil position.
- articleWhat are V3C, V-PCC, MIV, V-DMC and MPEG scene description, which ISO/IEC 23090 parts are they, and what public material exists when the standards text is paywalled?
MPEG-I splits volumetric and immersive media into separate parts: Part 5 (V3C/V-PCC point clouds coded with video codecs; a new edition adds V-DMC technology), Part 12 (immersive video from multiple texture-plus-depth views for 6DoF viewing), Part 14 (scene description building on glTF for timed media) and Part 29 (video-based dynamic mesh coding, still in progress). The standards texts themselves were not read.
- articleWhat byte-level structure do Apple's vexu, prji, pack and lnsc boxes define, and which fields are reserved or undefined?
Apple's preliminary ISOBMFF additions (v1.9.8 beta) signal immersive and stereo video with a vexu box containing required-box, eye, packing, projection and lens-collection boxes: projection is one 32-bit FourCC (rect, equi, hequ, prim; fish reserved), and frame-packed stereo uses a 32-bit packing FourCC for side-by-side or over-under; the document says it is preliminary and subject to change.
- articleWhat do Sony's public help-guide pages state for FreeD (free-d D1) tracking-data output on the BRC-AM7 and ILME-FR7: ports, Camera ID, destinations, position fields and delay conditions?
Sony's BRC-AM7 PTZ outputs free-d D1 camera tracking to up to four IPv4 destinations (port 1024-65534, default 40000) with a settable Camera ID (0-255, default 255) and a manually entered camera position, and output may lag in some modes; the FR7 outputs both free-d D1 (lens encoder, iris, position, orientation) and OpenTrackIO (adding focal length and entrance pupil position), synchronised to the sync signal.
- articleWhat does an external lens calibration file for FreeD look like, and how does it compare with Unreal's Lens File model?
Ventuz's lens file keys OpenCV calibration points by the FreeD zoom value and allows up to 14 OpenCV distortion coefficients (k1-k6, s1-s4, Tx, Ty; missing ones taken as 0), while Unreal's Lens File keys five Brown-Conrady parameters by focus and zoom; the files describe different models and cannot be swapped directly (conversion would need refitting or truncation).
- articleWhat does an Unreal Engine Lens File store, what inputs does it need to be calibrated, and how is it evaluated at runtime?
Unreal's Lens File stores five Brown-Conrady distortion parameters (K1, K2, P1, P2, K3), camera intrinsics and nodal point offsets keyed by focus and zoom, interpolated between calibrated points; Epic says to make a new Lens File for each lens and camera body combination.
- articleHow does Unreal nDisplay layer colour grading and OCIO for LED panels and the inner frustum, and what does the SMPTE RIS colour paper say it covers?
In nDisplay, colour grading settings stack additively in order (a viewport red and a cluster blue give purple), while OCIO overrides are not additive; for in-camera VFX each camera and LED panel combination typically needs its own destination colour space.
- articleWhat do public docs say about synchronising an LED volume's render nodes, cameras and trackers, and how is tracker latency/offset represented?
Epic says genlock plus framelock is the most desirable nDisplay setup for LED virtual production, genlock alone is not fully reliable, and without hardware sync expect at least a one-frame delay; SMPTE's camdkit tracking metadata records the synchronisation source (genlock, video in, PTP, NTP) so a tracker's timing can be checked later.
- articleIf I compress a splat cloud with the SPZ library for the draft glTF SPZ extension, which SPZ version and coordinate system must I use, and what has SPZ changed since v3.0.0?
The draft glTF SPZ extension targets SPZ v2 and requires LUF axes, while SPZ main defaults to pack version 4 (ZSTD) and RUB storage with an UNSPECIFIED source system, so a producer using SPZ defaults will not match the draft. The draft's SH table maps degree 1 to COEF_0, COEF_2, COEF_3, which does not match the base extension's COEF_[0-2] (likely a typo; unconfirmed with authors).
- articleI have a Gaussian-splat glTF: which compression extensions for KHR_gaussian_splatting exist, and which of them are ratified or only open drafts today?
Only the base KHR_gaussian_splatting extension is ratified at the observed main commit; splat compression/transport proposals (SPZ v2, EGSC, L-GSC, MPEG vendor) remain open PRs with Draft status, and the base spec expects compression extensions to decode back to its attributes (a fallback basis).