3D and worlds

Modeling, texturing, geometry, reconstruction, materials, scenes and rendering

• articleWhat does Dwarf Fortress's creator say about generating stories from a simulation first, what mechanisms and principles does he report, and where does he say it falls short?
  Tarn Adams describes Dwarf Fortress as a world simulation whose history is a log of many autonomous agents; his stated method (2008) is to create actors with motivations and let them go, and (2019) to give dwarves autonomy so they are actors in their own stories while the player is the fortress's 'official will'. He is candid about limits: character motivations lag far behind stories, a recorded log needs post-processing to find highlights and can be boring without enough dynamics, numbers make poor stories (hence a body-part damage model), and the memorable stories come from forums and streamers, not from the game narrating them. His Game AI Pro chapter gives four simulation principles (iterate, break down the system, avoid overcomplication, use real-world analogs), but is about world generation, not narrative.
• articleWhat do Chamfer distance, F-score, CLIP score, FID/FD, ULIP/Uni3D and user-preference numbers in image-to-3D papers actually measure?
  The papers use four metric families. Geometry accuracy against a ground-truth mesh: Chamfer distance and F-score on sampled point clouds (TripoSR, SF3D, SPAR3D, TRELLIS, TripoSG for its VAE). Distribution quality of renders: Frechet/kernel distance or FID variants (TRELLIS FD/KD; Hunyuan CLIP-FID and CMMD). Prompt alignment: CLIP cosine similarity of renders to the prompt, and ULIP/Uni3D scores between a sampled point cloud and image or caption (Hunyuan, TRELLIS.2). Human or model preference: authors-run user studies (TRELLIS, TRELLIS.2, Hunyuan 2.0) and, for TripoSG, an LMM (Claude 3.5) judge. Geometry accuracy needs a ground-truth mesh; the alignment and distribution scores do not.
• 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.
• articleWhy does the leaderboard page list Odyssey-3 Pro at rank 02 while the vendor says 66.1 is the highest, and how should an agent compare rows across views?
  The two statements describe different views of the same data. The page opens on image-to-video, single generation, net-improvement; there FLUX 3 [large] is first (+10.86 pp) and Odyssey-3 Pro prompt-enhanced second (+9.74 pp). The vendor's 66.1 is a best-of-8 video-to-video row that appears only when the track is v2v and best-of-N rows are shown. Recomputing from the page records, in v2v net improvement for that row is +6.99 against a track mean of 59.11 (13 displayed rows), and in i2v single generation +9.74 against 40.25. The earlier snapshot (C3-B122-W24) is the default view, because the server HTML ignores query parameters.
• articleI see Physics-IQ Verified scores and a "net improvement" column quoted for video models; what do "Verified" and "net improvement" mean, and which view of the leaderboard am I looking at?
  Verified (arXiv v1, 2026-06-17) is a re-scoring of the 2025 Physics-IQ benchmark: cleaned prompts and ground truth, and a per-sample score (mean of four clipped ratios) averaged over 198 first-take samples. "Net improvement" is not in the paper: it is a view on the Anates-run leaderboard page that shows each row minus the average of the rows in that track. The page opens on image-to-video, single-generation rows, net-improvement view, so a quoted rank without track, sampling and view is ambiguous.
• 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 of the vendors' world-model claims have any published measurement behind them, who ran it, and does the third-party record agree with the vendor wording?
  Only Odyssey-3 has a public benchmark trail: a third-party leaderboard (Physics-IQ Verified) and a vendor-run WorldMark comparison. The leaderboard snapshot fetched here (net-improvement view) lists Odyssey-3 Pro second behind FLUX 3, while the vendor page says its Verified score of 66.1 is the highest reported; the metrics/views differ so the two are not shown to conflict. Neither Runway, Decart, Marble nor Genie appears in the extracted text of either benchmark page. Latency, fps and session-length claims (Runway, Odyssey-1, Decart) carry no protocol on the pages read.
• articleHow do the primary papers measure whether several players views agree on one world, and can their reported numbers be compared across papers?
  Six different consistency measures are in use: a VLM judge asked yes/no questions about screenshots (Solaris), depth reprojection error (ShareVerse, MultiWorld), DINOv2 feature similarity of corresponding regions (MetaWorld), a parser that compares objects across simultaneous views (MASS, zero by construction), detector-and-geometry agreement between clients (WorldCast), and attention maps shown as figures (MIRA). The numbers are not comparable: each paper retrains its own baselines, and the same Solaris model gets different FID values in Solaris and Gamma-World.
• 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).
• articleWhich public RenderMan docs page defines points:shape, falloffshape, falloffpower and camerafacing for Points?
  The RenderMan for Maya 26 primitive-variables page lists falloffpower only ('used to create fuzzy particles') with no value range, and nothing on points:shape, falloffshape or camerafacing.
• articleWhich format should I use for a 3D handoff: glTF, USD, FBX, Alembic or OBJ?
  Each 3D format says what it is not, which gives a choice rule by payload. glTF 2.0 is for finished runtime assets and says it is not an authoring format. USD is for assembling and layering many assets into sets, shots and worlds, though UsdSkel does not provide general rig execution. Alembic is for baked, computed geometry such as simulation and animation caches, and is not rig storage or a native-scene replacement. OBJ is static geometry and materials, with no animation, skeletons, lights or camera positions. FBX (via the Autodesk SDK or independent readers like ufbx) carries rigged characters with skinning, blend shapes, lights and cameras. The rule itself is a proposal; what the receiving application imports still decides.
• articleWhat does OpenUSD's asset resolution layer (Ar) define for asset identity and versions, and what is left to the resolver plugin?
  OpenUSD's Ar layer defines hooks rather than an identity or versioning scheme. A resolver turns asset paths into resolved paths, chosen by URI scheme; contexts can be bound per scope, and any context used must be folded into the resolved path so downstream users need no context. ArAssetInfo offers optional plugin-filled version, assetName and resolverInfo (repoPath is deprecated). USD validates and parses nothing beyond scheme dispatch. Without a custom resolver, ArDefaultResolver treats paths as files with search paths, so database ids or hero-version logic must live in a custom resolver.
• articleWhat do the Smithsonian 3D (Voyager) scene schemas define for units, versions and copyright, and is there a licence field?
  Voyager's SVX document schema records a presentation-description version (required) and an optional copyright credit string; models carry a unit from inherit/mm/cm/m/km/in/ft/yd/mi; the meta schema has a free-form collection object and no licence field. A copyright credit is not a licence. The client's unit-conversion table has defects: every conversion into km or mi returns 1, and (curator addition) the mile row's inch, foot and yard factors are about 1000 times too large. Conversions involving km or mi are therefore wrong in this code (code reading, not executed).
• articleHow does Babylon.js handle gamma versus sRGB, and what must a custom shader or post-process author do to stay consistent?
  Babylon.js's documentation says its shaders encode and decode with a plain 2.2 gamma rather than the piecewise sRGB curve, to save operations, with an option for sRGB textures. Colour textures are authored in sRGB and data textures in linear. PBR materials honour a per-texture gammaSpace flag, and ImageProcessingPostProcess expects linear input, applying 1/2.2, so a custom post-process should hand it linear values. Node Materials convert nothing automatically.
• articleI baked a cloth simulation in Blender: is the bake itself something I can hand to another renderer, or do I export a different file?
  A Blender cloth bake is Blender's own cache (inside the saved .blend, or as .bphys files in blendcache_[filename] beside it), protected until cleared and replayed identically; the manual does not present it as interchange. To hand cloth to another renderer, export Alembic: it stores the baked vertex positions and transforms, not the simulation setup, with no particle-system support (hair as zero-width curves, particles as points) and material names only as face sets.
• articleWhat are a skeleton/rig, skinning weights and blendshapes (morph targets), and what do glTF, USD and FBX each store?
  A skeleton is a joint hierarchy, skinning weights say how much each joint moves each vertex, and blendshapes/morph targets are weighted vertex offsets: glTF stores linear blend skinning via skins, joints and JOINTS_n/WEIGHTS_n attributes and morph targets as deltas; UsdSkel stores skeletons, skinning and animation but explicitly not general rigging/execution (control rigs, IK), so formats carry the deformation result inputs, not the control rig.
• articleHow do VRM 1.0 humanoid, expressions and springBone define avatar rigging and secondary motion, and what changed from VRM 0.x?
  VRM 1.0 requires a core set of humanoid bones (hips, spine, head and limbs) with chest/upperChest/neck optional though required in 0.x, and forbids zero or negative bone scale; its expressions rename the 0.x presets (joy->happy, sorrow->sad, fun->relaxed), add surprised, and let expressions override mouth, blink and look-at; VRM 0.x specifies metres, right-handed Y-up, model facing -Z and T-pose, constraints the 1.0 files read do not restate.
• articleWhat does a Houdini Vellum cloth simulation carry into an Alembic file for rendering, and which attribute and packing details can change on export?
  Houdini's Alembic ROP writes only the extra attributes whose names match its point/vertex/primitive/detail patterns and turns primitive groups into face sets, which Alembic supports only on polygon and subdivision meshes; Vellum Unpack depends on the vellum_type attribute and does not update id attributes properly, so ids and constraint context should be checked before baking cloth to Alembic, which stores results rather than the simulation.
• articleWhat does the 2024 ICAT-EGVE poster map between FACS action units and ARKit blendshapes, in which direction, and what does it measure?
  The 2024 EGVE poster learns ARKit's 52 blendshape weights from 17 OpenFace action-unit intensities with a GRU, trained on 3,780 videos of nine Japanese speakers reading emotion-related sentences, and reports R2 about 0.75 with activation precision about 0.90 and recall about 0.85; it maps AUs to blendshapes for speech, so it is not a general AU-name lookup table and its population and task are narrow.
• articleWhat can Alembic ICurves carry for hair and groom data, and what do Blender's Alembic and USD hair exports each drop or change?
  Blender exports the same particle hair as linear, non-periodic, no-basis curves with UVs and normals (optionally child strands) to Alembic, documented as zero-width curves, but as cubic bspline or catmullRom pinned BasisCurves without widths to USD. Alembic ICurves itself can carry widths, UVs, normals, velocities, orders and knots, so the narrower content is Blender's export choice, not a format limit.
• articleHow does the USD BasisCurves schema at v26.08 describe hair-style curves, and what does Blender 5.2.2 write when it exports particle hair and Curves objects to USD?
  Blender v5.2.2 writes particle hair to USD as BasisCurves (cubic bspline, or cubic catmullRom with pinned wrap) with points, curve vertex counts and a display colour, and no widths. The USD schema description of BasisCurves for hair, the Curves-object writer (widths from radius, UV primvars, velocities) and the parents-only manual note remain producer-verified.
• articleWhat do MaterialX's own translation nodes say about converting standard_surface and OpenPBR to UsdPreviewSurface and gltf_pbr?
  MaterialX's translation graphs show where information is dropped: Standard Surface to UsdPreviewSurface outputs only diffuse, emissive, metallic, roughness, clearcoat, clearcoat roughness, opacity, IOR and normal (transmission, sheen and anisotropy are lost), while Standard Surface to glTF PBR keeps transmission, sheen and anisotropy; the OpenPBR (1.1.1) to Standard Surface graph flags anisotropic specular as not yet properly translated.
• articleWhen loading FBX with ufbx, which space-conversion mode should be used to normalise axes and units, and what pitfalls does the header document?
  ufbx converts FBX coordinates and units only when target_axes or target_unit_meters is set, using one of three modes: put the conversion on the root node, compensate per node with adjust pre-rotation/pre-scale, or additionally scale geometry. The scene settings still report the file's original axes, and FBX cameras are saved +X forward and +Y up unless target_camera_axes overrides it. Which mode to use depends on whether downstream code rebuilds transforms from raw properties (then adjust transforms must be accounted for).
• 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 WebGL and WebGPU specifications actually promise about colour spaces, sRGB formats and floating-point precision, and so how deterministic can a web 3D viewer be across devices?
  The WebGL spec makes drawingBufferColorSpace and unpackColorSpace default to 'srgb' at context creation. The producer's WebGPU (no colour management; -srgb formats gamma-encode on write) and WGSL (no rounding mode; ULP bounds; flush-to-zero) statements, which imply no bitwise cross-device equality, remain producer-verified only.
• articleIn three.js, what is the linear workflow, which color space does each input need, and what are the common mistakes?
  three.js at 9b4a2ac enables colour management by default with a Linear-sRGB working space and converts with the piecewise sRGB functions (thresholds 0.04045 and 0.0031308, slope 12.92, exponents 2.4 and 0.41666, the latter a truncation of 1/2.4). Texture annotation rules, outputColorSpace and the OutputPass double-conversion warning are from manual pages not re-read.
• 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 do NanoVDB and vdb_tool documentation say about runtime use and frame-sequence processing?
  NanoVDB is a read-only, linearised GPU/CPU-friendly copy of an OpenVDB grid that can only be built with createNanoGrid or GridBuilder, so editing happens in OpenVDB; OpenVDB's vdb_tool reads and writes .vdb and .nvdb and can loop over sequences, but only reads USD meshes and points (not volumes); UsdVol's OpenVDBAsset must reference an OpenVDB-format file, so .nvdb files are not valid there.
• articleAcross the capture-to-render chain, which time base, unit and naming assumptions must be written down because no format in the chain carries them for the next step?
  Across motion and render handoffs, time, units/axes and names are carried differently by each format (ARKit metres; Live Link Face timecode in recordings; Alembic sample times; the USD Alembic reader assuming Y-up and leaving units unset; UsdRender and EXR names as site conventions), so each step needs a user-authored mapping; this is the producer's synthesis over verified statements.
• articleWhen animation leaves the DCC as UsdSkel or an Alembic cache, which of joint order, bind/rest pose, topology, velocity, time base and units are stated by the specs and what does the Alembic-to-USD reader do with the rest?
  UsdSkel stores joints in an ordered list with world-space bind and local-space rest transforms (rest may be omitted only with a complete, non-sparse animation; animation joint order may differ from the skeleton's). Alembic marks topology changes by full samples and stores explicit time samples; OpenUSD's Alembic reader takes the frame rate from archive metadata, assumes Y-up when none is authored and never sets metersPerUnit, so units and up-axis need checking after conversion.
• articleWhen an agent follows the repository ids, version names and sample counts printed in the 1X cards and README, which of them have drifted (renamed ids, v1.1 vs v2.0, 450 vs 250 test samples) and what must be pinned?
  At observation, the ids printed in the cards (1x-technologies/worldmodel and worldmodel_raw_data) answer with HTTP 307 to world_model_tokenized_data and world_model_raw_data, so a pin should use the sha, not the name. The GENIE cards and the README leaderboard refer to challenge v1.1 and data/val_v1.1, while the tokenised-data repository (sha 42e3e12f..., lastModified 2025-04-20) describes v2.0 as replacing v1.1 and still lists the v1.1 folders. The two dataset cards give different test-set sizes (450 vs 250 samples). These are observations of text and listings, not a history of changes.
• articleHow do WorldRoamBench's single-H20 throughput measurements for LingBot-World, HY-World 1.5, Matrix-Game 2.0/3.0 and Yume 1.5 compare with the authors' stated FPS, and what can and cannot be concluded?
  WorldRoamBench v5 (AMAP CV Lab, Alibaba Group; not the authors of the open models) timed 10 open models on one NVIDIA H20, 20 runs, as chunk frames over wall-clock chunk time. Measured: Matrix-Game 2.0 6.26 Hz (640x352, 12-frame chunks), Matrix-Game 3.0 5.34 Hz (1280x704, 40), Yume 1.5 6.49 Hz (1280x704, 32), LingBot-World 1.79 Hz (832x480, 12), LingBot-World 2.0 1.75, HY-World 1.5 1.30 Hz (832x480, 16). Against the authors' figures (LingBot 16 fps on one GPU node; Matrix-Game 2.0 25 FPS on one H100 per C3-B062-W13-05) these are lower, but the hardware, GPU count and settings differ, so none of the gaps shows an author figure to be wrong.
• articleWhat do contributors and users report when they time LingBot-World-Fast themselves on 8xH100 (chunk times, cold start, whole-clip time), and how does it compare with the authors' 16 fps / under-1-second statement?
  Non-author timing logs for LingBot-World-Fast (14B, 480x832, 81 frames, 8xH100) come from a contributor's profiling pull requests: steady chunks about 1.0 s, chunk 0 about 7.2 s, VAE encode+decode about 5.6 s (26% of generate()), whole generate() 22,146 ms unoptimised, 13,523 ms after three merged PRs and 11,668 ms with a fourth, unmerged PR. If a chunk is 12 frames (WorldRoamBench's chunk size; the PR sample uses chunk_size=3), steady-state is about 12 frames/s, below the authors' 16 fps; a separate user reproducing on 8xH100 with NVLink and FA3 saw about 2.5 s/chunk around chunk 7 (about 4.8 frames/s on the same assumption), twice the 1.21 s another user reported. The discrepancy was not resolved in the thread. No key-press-to-frame measurement was found.
• articleHow do the open-source Maya Alembic exporter, maya-usd and Houdini handle sub-frames and non-integer frame rates like 23.976 and 29.97?
  maya-usd v0.37.0 maps Maya's 23.976, 29.97 and 29.97 drop-frame units to exact rational rates (24000/1001, 30000/1001) and writes the value as both timeCodesPerSecond and framesPerSecond, unlike Blender's USD exporter which writes only timeCodesPerSecond.
• articleWhen Blender exports USD or Alembic from a 23.976 fps scene, which time values and sub-frame samples does it actually write?
  Blender v5.2.2's USD exporter writes stage timeCodesPerSecond from the scene rate (e.g. 24000/1001) and exports whole frames only, so it cannot emit sub-frame motion samples, and it does not write framesPerSecond; its Alembic exporter writes shutter-based sub-frame samples and stores the scene fps as FramesPerTimeUnit metadata.
• 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).
• articleWhich OpenUSD changes from v25.05 to v26.11 can break existing assets, tools or builds, and what migration step does each note give?
  OpenUSD 26.11 rejects binary crate files older than 0.4.0 by default (update with usdupdatecrate; 0.4.0-0.8.0 still read with a warning; a build constant can restore older reads), removes prim relocates, and treats physics:rigidBodyEnabled = false as if RigidBodyAPI were not applied (collider ownership and joints move to the nearest enabled ancestor), which can change existing physics scenes.
• articleHow does Core Specification v1.0.1 relate to OpenUSD releases, and which OpenUSD behaviours documented after the spec text diverge from or are absent from it?
  The spec says it derives from OpenUSD and treats OpenUSD behaviour as expected where the spec is silent (an unintentional omission). Spline inner loops are specified in v1.0.1 but deprecated in OpenUSD 26.11, so a spec-compliant implementation carries a feature the reference implementation now warns about; the removal of prim relocates in 26.11 is consistent with the spec listing only layer relocates.
• articleHow do hdPrman and Karma name the AOVs/EXR channels they write from USD RenderVars?
  At OpenUSD v26.08, hdPrman names each RenderMan AOV after the RenderVar prim name and passes sourceName (prefixed 'lpe:' for LPE sources); the display driver comes from the product file extension (exr/tif/tiff/png, otherwise openexr with a warning; deepRaster + .exr -> deepexr). The render settings prim drives the pass only when the env setting is on or the pass has no AOV bindings, so the same scene can name outputs by different paths. Karma/husk instead derives EXR channel suffixes from the RenderVar data type, with an opt-in lower-case flag.
• articleWhich parts of an IES file do Blender, Unity and Unreal actually read, ignore or reject when used for virtual lighting?
  The parsers differ in tolerance: Blender v5.2.2 skips TILT=INCLUDE tables (never applying tilt), ignores lumens and units, accepts types A/B/C, mirrors missing quadrants ('much more forgiving than the spec') and converts candela with a fixed 4*pi/177.83 factor; Unity recognises versions from IESNA91 to IES:LM-63-2019 but rejects any TILT other than NONE; Unreal documents candela brightness and clipping of profiles to the spot cone.
• articleWhat do IES and EULUMDAT files describe, and which of them do Blender, Unreal Engine and Unity accept as a light profile?
  IES (LM-63) and EULUMDAT (.ldt) both tabulate luminaire intensity by direction, but the Blender, Unreal and Unity HDRP documentation and the Unity and Blender importer code read handle IES only (Unity registers only the .ies extension; Blender parses from the IES TILT line); no inspected source mentions EULUMDAT, so .ldt files need external conversion.
• articleI want to look up a Poly Haven asset by API: what identifies it, what version signal does it give, what units are its dimensions in, and where is its licence?
  Poly Haven's API keys assets by slug, exposes date_published, img_version and files_hash (a SHA1 of the files listing that changes when files update) and dimensions in millimetres, but no per-asset licence field: the README states assets are CC0 while the live API requires a 'Powered by Poly Haven' credit, and the API software itself is AGPL.
• articleDoes OpenUSD's Hydra pipeline (hdParticleField, hdSt, hdEmbree) at v26.08 use ParticleField3DGaussianSplat sortingModeHint and projectionModeHint?
  At v26.08 no Hydra path read consumes the splat hints: the schema calls them advisory (sortingModeHint allows zDepth, cameraDistance and rayHitDistance), the usdImaging adapter only has a TODO to pass them, the hdsi conversion never mentions them, and the sample renderer sorts by view-space z regardless.
• articleI author a splat prim in USD: should I set sortingModeHint and projectionModeHint, and will Hydra renderers honour them at v26.11.0?
  The hints are advisory: at v26.11.0 they reach Hydra scene data, but Pixar's inspected consumers (hdPrman conversion, sample renderer) do not read them, so setting them is harmless and should not be expected to change output there; the docs now describe rayHitDistance and say rasterizers may treat it as cameraDistance.
• articleWhat changed in OpenUSD's Gaussian-splat particle-field path between v26.08 and v26.11.0, and does any renderer path now use the sorting or projection hints?
  At v26.11.0 usdImaging exports a Hydra particleField container with kernelType (hardcoded gaussianEllipsoid) and both hints, closing the v26.08 TODO; the new hd schema exposes only kernelType, and the hdsi conversion, hdPrman plugin, sample renderer and schema.usda are byte-identical to v26.08, so by code reading none of them consumes the hints.
• articleHow do the intensity units, normalisation and symmetry rules differ between IES (LM-63) and EULUMDAT files, so values are not mis-scaled?
  EULUMDAT stores relative intensity (cd per 1000 lm) with a conversion factor and luminaire flux, and only the symmetric C-plane portion indicated by Isym; public tables differ on whether type indicator 0 exists (AGi32 lists 0-3, DIALux 1-3). IES stores candela scaled by a multiplier and ballast factors; Unity treats negative lumens-per-lamp as absolute photometry and clamps negative multipliers to 0, while Blender discards lumens-per-lamp and applies a fixed candela-to-watt factor. Copying values between formats needs an explicit flux/1000 scale.
• articleWhich glTF features and extensions does Unity glTFast (6.20.0) say it imports, and which survive import into Unity materials, meshes and animation?
  glTFast (Apache-2.0; Unity 6000.0+) claims full glTF 2.0 core support with minor remarks: sparse accessors only for morph targets and vertex positions, up to eight UV sets imported but only two used by its shaders, animation via the legacy system (Mecanim clips import unassigned; Playables removed because SetCurve works only for legacy clips at runtime), clearcoat partial in URP, full in HDRP and absent in Built-In, DOTS experimental. Known issues from Unity API limits: duplicated shared accessors/images, minFilter overriding magFilter and NEAREST_MIPMAP_LINEAR falling back to NEAREST.
• articleWhat does Unreal Engine 5.8 documentation say about which USD features load through the USD Stage (prims, animation, blend shapes, materials, variants, payloads), and could the Unreal glTF importer documentation be obtained?
  Unreal's Beta USD Stage represents static and skeletal meshes, HISM, materials, lights, cameras, variants, animation and blend shapes as prims, loads .usd/.usda/.usdc/.usdz, supports payload loading, UsdPreviewSurface textures and PreviewSurface/DisplayColor materials (MDL via a schema), shows xform animation as Transform tracks and other animated values on a Time track in a Level Sequence, and needs FORCE_ANSI_ALLOCATOR=1 for runtime loading. Unreal glTF import docs were unreadable (producer).
• articleWhat do the SPZ v4 and PlayCanvas SOG formats specify for compression, structure and licensing, and how do viewers describe their support?
  SPZ v4 (MIT) is a 32-byte plaintext NGSP header plus independently ZSTD-compressed attribute streams (24-bit fixed-point positions, smallest-three 10-bit rotations); v1-3 gzip files are read-only. PlayCanvas's SOG stores quantised attributes as WebP images with log-domain positions/scales and gamma-space DC colour in a right-handed +Y-up frame, and PlayCanvas compares SOG (15-20x smaller than PLY, lossy), SPZ (about 10x, lossy) and lossless GLB with KHR_gaussian_splatting. Its SPZ script parser accepts only v4, up to 3 SH bands, ignoring the antialiased flag and vendor extensions.

More