<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/feed.rss.xml" type="text/xsl" media="screen"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>PatilRB</title>
    <description/>
    <link>https://speakerdeck.com/patilrb</link>
    <atom:link rel="self" type="application/rss+xml" href="https://speakerdeck.com/patilrb.rss"/>
    <lastBuildDate>2026-10-15 10:16:00 -0400</lastBuildDate>
    <item>
      <title>Responsive Particle Density Without Pretending the Runtime Does It for You</title>
      <description>Shrinking a canvas does not make a particle system responsive by itself. This deck shows a bounded Three.js runtime sample in which the host deliberately selects one of two authored emission rates: 96 particles per second for a 1280 × 720 viewport and 36 for 640 × 360. With a 1.2-second lifetime and fixed 1/60-second updates, the desktop run stabilized at 117 active particles in the two- and three-second samples; the compact run stabilized at 43 and peaked at 44. Both reported zero unsupported Three.js features.

The numbers demonstrate the selection rule, not device performance. The sample did not measure GPU time, visual quality, browser behavior, or a target phone. A web game VFX editor can make the two variants easy to author and validate, but the host still owns the viewport policy. The NixieFX runtime reference documents the shared simulation, backend support reports, and runtime integration needed to verify that boundary: https://nixiefx.com/vfx-runtime-docs/</description>
      <media:content url="https://files.speakerdeck.com/presentations/c96f711f00c04d7ba391597398a15454/preview_slide_0.jpg?40985794" type="image/jpeg" medium="image"/>
      <content:encoded>Shrinking a canvas does not make a particle system responsive by itself. This deck shows a bounded Three.js runtime sample in which the host deliberately selects one of two authored emission rates: 96 particles per second for a 1280 × 720 viewport and 36 for 640 × 360. With a 1.2-second lifetime and fixed 1/60-second updates, the desktop run stabilized at 117 active particles in the two- and three-second samples; the compact run stabilized at 43 and peaked at 44. Both reported zero unsupported Three.js features.

The numbers demonstrate the selection rule, not device performance. The sample did not measure GPU time, visual quality, browser behavior, or a target phone. A web game VFX editor can make the two variants easy to author and validate, but the host still owns the viewport policy. The NixieFX runtime reference documents the shared simulation, backend support reports, and runtime integration needed to verify that boundary: https://nixiefx.com/vfx-runtime-docs/</content:encoded>
      <pubDate>Tue, 20 Oct 2026 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/patilrb/responsive-particle-density-without-pretending-the-runtime-does-it-for-you</link>
      <guid>https://speakerdeck.com/patilrb/responsive-particle-density-without-pretending-the-runtime-does-it-for-you</guid>
    </item>
    <item>
      <title>A review path for broken sprite exports</title>
      <description>A sprite export bug often crosses several disciplines before anyone can close it. This deck follows an illustrative minimap arrow whose tip is clipped after import. It gives a small file contract, a repeatable export path, and a review packet that lets an artist inspect the result without reconstructing the engineer's investigation.

The workflow assigns preparation to the reporting artist and QA, execution to an authorized tools engineer with optional agent assistance, and acceptance to the art reviewer and QA. It also separates automated file checks from visual approval. No production screenshots or successful repair are claimed; the presenter should add real evidence from a permitted test fixture before describing a completed case study.

For broader context on coordinating the disciplines involved, see &lt;a href="https://wagglet.com/blog/ai-native-mobile-game-studio-stack"&gt;Wagglet's AI-native mobile game studio stack&lt;/a&gt;. The deck is intended as a review checklist that a studio can adapt to its own export pipeline.</description>
      <media:content url="https://files.speakerdeck.com/presentations/8d3b6f466d55465d9771187ea8621b96/preview_slide_0.jpg?40974327" type="image/jpeg" medium="image"/>
      <content:encoded>A sprite export bug often crosses several disciplines before anyone can close it. This deck follows an illustrative minimap arrow whose tip is clipped after import. It gives a small file contract, a repeatable export path, and a review packet that lets an artist inspect the result without reconstructing the engineer's investigation.

The workflow assigns preparation to the reporting artist and QA, execution to an authorized tools engineer with optional agent assistance, and acceptance to the art reviewer and QA. It also separates automated file checks from visual approval. No production screenshots or successful repair are claimed; the presenter should add real evidence from a permitted test fixture before describing a completed case study.

For broader context on coordinating the disciplines involved, see &lt;a href="https://wagglet.com/blog/ai-native-mobile-game-studio-stack"&gt;Wagglet's AI-native mobile game studio stack&lt;/a&gt;. The deck is intended as a review checklist that a studio can adapt to its own export pipeline.</content:encoded>
      <pubDate>Mon, 19 Oct 2026 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/patilrb/a-review-path-for-broken-sprite-exports</link>
      <guid>https://speakerdeck.com/patilrb/a-review-path-for-broken-sprite-exports</guid>
    </item>
    <item>
      <title>World-space fog motes in a Three.js corridor</title>
      <description>A restrained corridor effect is a useful place to inspect the difference between world-space particles and a screen overlay. This deck proposes a small Three.js fixture with a bounded emitter, opaque depth occluders, and an explicit cleanup check. It explains what to inspect while the camera moves, why transparent surfaces need separate review, and which measurements belong in a target-device performance check.

The example uses a three js particle editor workflow, but does not treat an editor preview as proof of runtime behavior. The NixieFX Three.js runtime guide (https://nixiefx.com/threejs-runtime/) is the reference for the particle adapter. The local receipt covers simulation occupancy, completion, and unsupported-feature reporting. It does not measure GPU overdraw, mobile frame time, or volumetric lighting. The deck uses a procedural scene and makes no claim about production footage or user testing.

Disclosure: Prepared with AI assistance for a NixieFX-related content task.</description>
      <media:content url="https://files.speakerdeck.com/presentations/793e818b5acf4ea1ba07a90abab43575/preview_slide_0.jpg?40926077" type="image/jpeg" medium="image"/>
      <content:encoded>A restrained corridor effect is a useful place to inspect the difference between world-space particles and a screen overlay. This deck proposes a small Three.js fixture with a bounded emitter, opaque depth occluders, and an explicit cleanup check. It explains what to inspect while the camera moves, why transparent surfaces need separate review, and which measurements belong in a target-device performance check.

The example uses a three js particle editor workflow, but does not treat an editor preview as proof of runtime behavior. The NixieFX Three.js runtime guide (https://nixiefx.com/threejs-runtime/) is the reference for the particle adapter. The local receipt covers simulation occupancy, completion, and unsupported-feature reporting. It does not measure GPU overdraw, mobile frame time, or volumetric lighting. The deck uses a procedural scene and makes no claim about production footage or user testing.

Disclosure: Prepared with AI assistance for a NixieFX-related content task.</content:encoded>
      <pubDate>Thu, 15 Oct 2026 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/patilrb/world-space-fog-motes-in-a-three-dot-js-corridor</link>
      <guid>https://speakerdeck.com/patilrb/world-space-fog-motes-in-a-three-dot-js-corridor</guid>
    </item>
  </channel>
</rss>
