<?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>valentina-mkrtu</title>
    <description/>
    <link>https://speakerdeck.com/vmkrtu2000</link>
    <atom:link rel="self" type="application/rss+xml" href="https://speakerdeck.com/vmkrtu2000.rss"/>
    <lastBuildDate>2026-08-21 05:20:25 -0400</lastBuildDate>
    <item>
      <title>A pickup pulse in PixiJS: event, lifetime, cleanup</title>
      <description>A pickup pulse needs a clear lifetime: one collection event starts one short burst, the particles finish, and the owning scene releases or reuses the instance. This deck walks through a small PixiJS example built with nixie-fx 0.1.20, using procedural billboards and a fixed seed so the result can be replayed. It covers common integration mistakes, including restarting every frame, mixing milliseconds with seconds, using mismatched coordinates, and mistaking particle expiry for cleanup. The local test observed 24 particles at 0.5 simulated seconds, with no unsupported PixiJS features reported for the definition. That result applies to this small effect, not every material or backend setting. The slides include the tested preview and a concrete integration checklist. For the pixi js particle editor used by the runtime example, see https://nixiefx.com/pixijs-particle-effects/ .</description>
      <media:content url="https://files.speakerdeck.com/presentations/ed7e0258d7fc42cbaa9bb7a005c20494/preview_slide_0.jpg?40908187" type="image/jpeg" medium="image"/>
      <content:encoded>A pickup pulse needs a clear lifetime: one collection event starts one short burst, the particles finish, and the owning scene releases or reuses the instance. This deck walks through a small PixiJS example built with nixie-fx 0.1.20, using procedural billboards and a fixed seed so the result can be replayed. It covers common integration mistakes, including restarting every frame, mixing milliseconds with seconds, using mismatched coordinates, and mistaking particle expiry for cleanup. The local test observed 24 particles at 0.5 simulated seconds, with no unsupported PixiJS features reported for the definition. That result applies to this small effect, not every material or backend setting. The slides include the tested preview and a concrete integration checklist. For the pixi js particle editor used by the runtime example, see https://nixiefx.com/pixijs-particle-effects/ .</content:encoded>
      <pubDate>Wed, 14 Oct 2026 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/vmkrtu2000/a-pickup-pulse-in-pixijs-event-lifetime-cleanup</link>
      <guid>https://speakerdeck.com/vmkrtu2000/a-pickup-pulse-in-pixijs-event-lifetime-cleanup</guid>
    </item>
    <item>
      <title>Responsibility in transferable AI work</title>
      <description></description>
      <media:content url="https://files.speakerdeck.com/presentations/8d617dfbe7b74a35a3bb4360d6528aae/preview_slide_0.jpg?40907522" type="image/jpeg" medium="image"/>
      <content:encoded></content:encoded>
      <pubDate>Wed, 14 Oct 2026 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/vmkrtu2000/responsibility-in-transferable</link>
      <guid>https://speakerdeck.com/vmkrtu2000/responsibility-in-transferable</guid>
    </item>
    <item>
      <title>World-space fog motes in a Three.js corridor</title>
      <description>This deck walks through a proposed Three.js corridor effect built from sparse, world-space fog motes. It covers the emitter setup, a simple doorway-and-pillar test for depth behavior, and a controlled way to inspect transparency cost by changing particle size and count separately. The numerical settings are starting values to validate in a real scene, not benchmark results. No runtime screenshot or measured performance improvement is claimed.

For teams evaluating a three js particle editor, the NixieFX Three.js runtime reference explains the bundle loader, support reports, and scene lifecycle used by this workflow: https://nixiefx.com/threejs-runtime/

The final checks include repeated scene entry, resource cleanup, and recording the actual device and runtime versions. Billboard motes are not volumetric fog, and editor preview bloom needs its own game integration. AI generated this instructional draft; human technical and visual review remains required.
</description>
      <media:content url="https://files.speakerdeck.com/presentations/9f78c56396034bf39ef15e8949ede339/preview_slide_0.jpg?40888485" type="image/jpeg" medium="image"/>
      <content:encoded>This deck walks through a proposed Three.js corridor effect built from sparse, world-space fog motes. It covers the emitter setup, a simple doorway-and-pillar test for depth behavior, and a controlled way to inspect transparency cost by changing particle size and count separately. The numerical settings are starting values to validate in a real scene, not benchmark results. No runtime screenshot or measured performance improvement is claimed.

For teams evaluating a three js particle editor, the NixieFX Three.js runtime reference explains the bundle loader, support reports, and scene lifecycle used by this workflow: https://nixiefx.com/threejs-runtime/

The final checks include repeated scene entry, resource cleanup, and recording the actual device and runtime versions. Billboard motes are not volumetric fog, and editor preview bloom needs its own game integration. AI generated this instructional draft; human technical and visual review remains required.
</content:encoded>
      <pubDate>Tue, 13 Oct 2026 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/vmkrtu2000/world-space-fog-motes-in-a-three-dot-js-corridor</link>
      <guid>https://speakerdeck.com/vmkrtu2000/world-space-fog-motes-in-a-three-dot-js-corridor</guid>
    </item>
    <item>
      <title>The Hidden State Problem in Engineering Work</title>
      <description>Code is versioned. Deployments are recorded. Logs are retained. The reasoning behind unfinished engineering work often disappears when the person working on it changes. This deck looks at engineering handoffs as a state transfer problem and proposes a lightweight structure for making technical work resumable. 
https://wagglet.com/</description>
      <media:content url="https://files.speakerdeck.com/presentations/1f1219dd5bda4163bcfd14736b95dbac/preview_slide_0.jpg?40338830" type="image/jpeg" medium="image"/>
      <content:encoded>Code is versioned. Deployments are recorded. Logs are retained. The reasoning behind unfinished engineering work often disappears when the person working on it changes. This deck looks at engineering handoffs as a state transfer problem and proposes a lightweight structure for making technical work resumable. 
https://wagglet.com/</content:encoded>
      <pubDate>Fri, 21 Aug 2026 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/vmkrtu2000/the-hidden-state-problem-in-engineering-work</link>
      <guid>https://speakerdeck.com/vmkrtu2000/the-hidden-state-problem-in-engineering-work</guid>
    </item>
  </channel>
</rss>
