25 Gemini 4 Carbon Examples: 3D, Games, SVG and Prompts

Key Takeaways

• Gemini 4 Carbon community examples span procedural 3D, voxel environments, SVG illustration, animation, and browser games. The collection below links to 25 demonstrations and comparisons.
• Model attribution requires care. Several early examples came from Arena sessions that reportedly displayed Gemini 4 Argon. Creator attribution does not independently establish which backend checkpoint produced an output.
• Prompt availability varies. One short prompt is reproduced as recorded by a public archive. Six additional prompts are original reference templates inspired by the examples, clearly separated from creator prompts.
• Visual quality and software reliability need separate evaluation. A compelling recording does not establish correct game rules, working controls, mobile compatibility, or reproducible results.
• Access remains a practical constraint. Google's October 28 announcement describes a phased rollout beginning with selected cyber defenders and trusted partners.

Updated: October 29, 2026.

Gemini 4 Carbon examples are especially interesting when they move beyond static illustrations: articulated objects, changing environments, coordinated animation, and games that respond to input. These tasks provide useful opportunities to inspect how generated code handles relationships between geometry, motion, state, and interaction.

This selection is a collection of notable community demonstrations, not a ranking by views or a controlled model benchmark. Original posts are linked throughout. Where direct post access is restricted, linked creator pages and public archives provide additional context.

How to Read the Evidence

Three distinctions make these examples more useful:

The community case repository explicitly distinguishes recorded outputs from verified implementations. Its Arena model labels and generation times are source-reported.

For the eight featured examples below, a complete original prompt was not established in the accessible evidence. Reference prompts later in the article are new testing briefs, not recovered originals.

1. Mechanical Flower with a Bee

Creator: @thtbee_

The creator describes a mechanical flower built entirely in Three.js, with a reported generation time of approximately 1 hour and 43 minutes. A small bee appeared despite not being explicitly requested; the creator says the instructions allowed creative freedom. The archived author thread preserves that explanation.

Why it is worth studying: a mechanical flower is a useful test of coordinated geometry. Petals, hinges, stems, and decorative mechanisms need to remain visually connected as they move.

Suggested inspection: pause the animation halfway through opening, rotate the camera, and check whether connected components still meet. A convincing front view can conceal disconnected parts elsewhere.

Potential application: an interactive product hero, digital sculpture, or educational mechanism viewer.

2. Interactive 3D Helicopter

Creator: @LuminaBench

Lumina reports generating the helicopter from a text prompt in Arena in slightly more than 30 minutes. The creator's demo library describes wireframe and engineering controls. In the subsequent comparison, the creator preferred Carbon's design but considered the Opus 5.5 result more polished overall.

Why it is worth studying: a vehicle viewer can test whether multiple display modes operate on a coherent underlying scene.

Suggested inspection: alternate between shaded and wireframe views, select components, reset the camera, and change animation speed. Check whether each control changes the intended object without disrupting the others.

Comparison limit: Carbon ran in Arena, while Opus ran in Claude Code. Reported completion times therefore describe different execution setups, not an isolated model-speed comparison.

3. Voxel Pagoda Island

Creator: @LuminaBench

The pagoda example also appears in a four-model comparison alongside Gemini 4 Argon, Claude Opus 5.5, and Claude Sonnet 5.5. The archived comparison records the creator's preference for Carbon's visual quality over Argon, together with a slower-generation caveat.

Why it is worth studying: repeated architectural elements expose structural inconsistencies. Roof spacing, floor heights, supports, and surrounding terrain must work together.

Suggested inspection: view the structure from above and below, then request a targeted change such as adding one floor. The useful question is whether the building remains coherent after editing.

Potential application: an explorable diorama, browser-game environment, or architectural concept viewer.

4. Two Black Hole Horizons

Creator: @thtbee_

The archived demonstration attributes the scene to Carbon and preserves a reported Three.js implementation time of approximately 1 hour and 40 minutes.

Why it is worth studying: this is a useful visual-effects challenge involving luminous structures, dark regions, camera movement, and apparent distortion.

Suggested inspection: ask the implementation to identify which effects are artistic approximations and which, if any, follow a documented physical model. A dramatic black-hole image is not evidence of a scientifically accurate simulation.

Prompt caveat: the archive's field labeled Prompt contains a fragment of the author's commentary, not a complete reproduction prompt. It should not be presented as the original instructions.

5. First-Person Zombie Game

Creator: @LuminaBench

The creator's demo library lists a zombie FPS published on October 22, describing it as a one-prompt project built from scratch. The recording runs for just over three minutes.

Why it is worth studying: an FPS prototype provides opportunities to test interacting systems rather than appearance alone.

Useful checks include:

• Starting and releasing pointer lock.
• Pausing and resuming without stuck movement keys.
• Enemy collisions and damage boundaries.
• Resetting health, enemies, ammunition, and timers after death.
• Preventing repeated restarts from creating duplicate update loops.

Evidence limit: these are recommended acceptance checks. The recording does not independently establish that every behavior works.

6. Mario-Style Platformer

Creator: @LuminaBench

The creator reports approximately 30 minutes and a successful first attempt. The archived discussion also contains an important practical detail: the creator explicitly declines to distribute the game file, citing copyright concerns.

Why it is worth studying: platformers expose errors that screenshots cannot reveal, particularly around jumping, collision resolution, checkpoints, and level transitions.

Suggested inspection: test jumping beneath platforms, landing on edges, simultaneous movement inputs, dying during a transition, and restarting after completion.

For a reusable project, request original characters, artwork, names, and levels, while retaining the general challenge of a side-scrolling platformer.

Availability: treat this as a demonstration, not an available download or verified playable embed.

7. Block-World Sandbox

Creator: @Haleeeemahh

The community record describes first-person navigation, a block toolbar, and block placement. Complete game logic and backend model identity remain unverified.

Why it is worth studying: editable environments introduce persistent state. Adding a block should affect the visible world, collision behavior, and subsequent interactions consistently.

Suggested inspection: place a block next to the player, remove one near a boundary, switch materials, and reload the page if saving is claimed. Compare the restored world with the state before reloading.

Potential application: a small building toy or level editor. Survival mechanics, multiplayer, and large-world generation should be treated as additional requirements.

8. Four-Season Pelican Cycling SVG

Creator: @hamoudi_yo

The case archive describes a cycling pelican presented across seasonal scenes. The publisher attributes an Arena output displayed as Argon to a Carbon checkpoint; that mapping is unverified.

Why it is worth studying: this challenge combines recognizable illustration, coordinated movement, and changes to presentation state.

Suggested inspection: switch seasons repeatedly while the animation runs. Wheel rotation, pedal movement, and the character's contact points should remain consistent, with no accumulating animation loops.

Potential application: an animated explainer, interactive greeting card, or compact SVG coding benchmark.

17 More Gemini 4 Carbon Examples to Explore

The following entries complete the 25-example collection. Unknown means complete original prompt wording was not established in the accessible record; it does not prove the author never shared it elsewhere.

The first eleven entries are documented in the GitHub collection and case archive.

Six further comparisons have individual archived records:

The records for Rick Sanchez, the cheetah, and Lightning McQueen preserve their respective comparison details.

The cycling cow, themed chess, and sunset cyclist records describe the tasks but do not reproduce complete prompt wording.

Available Creator Prompt: Pixel-Art Running Cheetah

The archived @duke_mv comparison explicitly records this wording:

640x360 pixel art of cheetah running

This is an archived prompt quotation, rather than a newly reconstructed prompt. The record does not establish the complete session configuration, tool access, or preceding instructions.

For a fair comparison, preserve that short prompt unchanged. Adding requirements about looping, rendering technology, or camera movement creates a different test.

A separate, stricter follow-up can evaluate whether the output has the requested dimensions, a stable animation loop, recognizable anatomy, and consistent ground contact. Record the original result separately from any repaired version.

Six Reference Prompts for Building Similar Projects

The following prompts are newly written templates. They are not the creators' original prompts and have not been validated against Carbon. They provide explicit deliverables and acceptance criteria for related projects. They can also be used with other coding models, provided those runs are labeled accurately.

A. Mechanical flower in Three.js

Build an interactive mechanical flower in Three.js using procedural geometry.

Create articulated petals, visible hinges, a central mechanism, and a small animated bee. Opening and closing must preserve the connections between moving parts. Use a coherent metal-and-enamel material palette.

Add orbit controls, an opening slider, play/pause, animation speed, and reset. Keep the interface compact and usable on a narrow screen.

Deliver runnable source with exact dependency versions and setup instructions. Do not use external model or texture assets.

Verify that repeated reset and play/pause actions do not create duplicate animation loops. Distinguish checks actually performed from checks that remain untested.

What this adds: explicit motion relationships and state checks, making the result easier to inspect than an unrestricted beauty shot.

B. Interactive helicopter viewer

Create a procedural 3D helicopter viewer in Three.js.

Organize the fuselage, cockpit, landing gear, main rotor, and tail rotor as named components. Add shaded and wireframe modes, component selection, rotor-speed control, and camera reset.

Include an exploded-view slider that separates components predictably and restores their exact assembled positions at zero. Label the model as a visual approximation, not an engineering-validated aircraft.

Use original geometry and a compact, keyboard-accessible interface. Deliver runnable source and dependency versions.

Test repeated mode switches, selection during animation, window resizing, and restoration from exploded view. Report any observed intersection or alignment problems.

What this adds: reversible structural changes, which help reveal whether the scene remains editable.

C. Voxel pagoda island

Build an explorable voxel island with a five-story pagoda, terraced paths, flowering trees, a bridge, and water.

Use a consistent voxel scale and procedural geometry. Make the pagoda floor count configurable without manually rebuilding each floor.

Provide orbit navigation, daylight and evening presets, pause, and reset. Keep the architecture readable from every side.

Use a fixed random seed for reproducible terrain and vegetation. Include an adjustable detail setting and document the chosen performance tradeoffs.

Deliver runnable code. Verify that changing the floor count preserves roof spacing, supports, and camera framing. Report measured performance only if it was actually measured.

What this adds: deterministic generation and an editable parameter, allowing comparisons beyond the default scene.

D. Four-season pelican SVG

Create a self-contained HTML page with an original SVG illustration of a pelican riding a bicycle.

Animate the wheels, pedals, and legs coherently. Keep the feet aligned with the pedals and the wheels aligned with the road.

Provide spring, summer, autumn, and winter themes. Changing the theme must preserve the current animation state and must not create additional animation loops.

Add play/pause, speed control, accessible button labels, and a reduced-motion presentation. Use inline SVG rather than embedded raster artwork.

Deliver the complete source. Check repeated theme changes, resizing, pausing, resuming, and resetting. State any remaining limitations.

What this adds: explicit coordination and transition requirements, rather than merely asking for seasonal decoration.

E. Original browser platformer

Build a small side-scrolling browser platformer with original characters, names, artwork, and level layouts.

Use Canvas 2D. Include movement, jumping, solid platforms, collectibles, one enemy type, a checkpoint, a completion state, and restart.

Support keyboard input and simple touch controls. Define the game states clearly: title, playing, paused, game over, and complete.

Keep the first version to one polished level. Use time-based movement with a bounded update step. Do not depend on copyrighted game assets.

Deliver runnable source. Verify collision from above and below, edge landings, death and restart, pause/resume, and resetting all mutable state after completion.

What this adds: a bounded scope and concrete gameplay acceptance criteria.

F. Small block-world sandbox

Build a compact first-person voxel sandbox in Three.js using original procedural assets.

Include movement, collision, a block-selection toolbar, placement, removal, and a visible targeting indicator. Prevent placing blocks inside the player's occupied space.

Keep the world bounded and provide an obvious reset action. Save edits locally with a versioned save format, and handle missing or invalid saved data gracefully.

Support pointer-lock entry and exit without leaving movement keys stuck. Document desktop controls and any unsupported mobile interactions.

Deliver runnable source and setup instructions. Verify placement, removal, collision changes, save/load consistency, and repeated resets. Do not claim multiplayer or survival features.

What this adds: persistent-state requirements that distinguish a building tool from a navigable scene.

What the Examples Suggest—and What They Cannot Prove

Suggested interpretation: visual composition is worth testing separately from interface design. In the mechanical-flower discussion, the creator still criticizes default UI quality and recommends giving clearer interface direction. The helicopter comparison similarly favors Carbon's design while favoring Opus's overall polish. Those are creator observations, not universal rankings.

Selection matters. A best-of-four castle and a claimed first-attempt platformer represent different evidence. Both may be impressive, but they cannot support the same conclusion about reliability.

A successful edit can reveal more than another screenshot. Ask the model to change one relationship while preserving the rest: increase a building's floor count, change a character's animation speed, or replace a game's scoring rule. Then inspect for regressions.

One prompt is not a complete cost or workflow description. It does not establish how many internal tool calls occurred, whether assets were supplied, how much compute was used, or whether the creator selected the result from several attempts.

Official Engineering Examples Beyond Visual Demos

Google's Carbon announcement describes three additional application areas:

• Long-running engineering: internal teams reportedly used Carbon for multi-day debugging and patching across complex codebases.
• Chrome patch generation: the Chrome team reported substantially stronger patch results than an unnamed competing frontier model.
• Defensive security evaluation: Wiz reported strong performance on web penetration-testing benchmarks.

These are vendor-reported engineering results, distinct from the community showcase. They do not establish that the visual demos were generated by the released checkpoint or that every coding task will improve similarly.

How to Evaluate a Gemini 4 Carbon Demo Properly

Use the same evaluation record for every model and attempt:

Three independent attempts can provide an initial view of variability, but they are not enough to establish a precise model-wide success rate.

For games, prioritize state and collision checks. For 3D scenes, prioritize geometry, controls, and resource use. For SVG, inspect the actual markup and animation behavior rather than assuming the recording proves the implementation method.

Common Pitfalls When Recreating These Examples

• Treating a task title as the full prompt. A label such as mechanical flower may omit references, constraints, or previous messages.
• Copying a broken prompt extraction. A field labeled Prompt can contain caption text or an incomplete sentence, as the black-hole archive illustrates.
• Assuming a video is a playable application. Require an actual runnable artifact before describing a project as available to play or embed.
• Comparing different execution environments as model speed. Tool access, queueing, test execution, and repair work can affect elapsed time.
• Publishing only the strongest attempt. Record failures and retries alongside the chosen result.
• Counting a repost as another generated project. Group recordings and comparisons that reuse the same underlying output.

A useful additional test is to request a small modification after the first successful run. If the model cannot preserve working behavior while making that change, the project still needs engineering work.

Frequently Asked Questions

Can everyone use Gemini 4 Carbon now?

As of October 29, Google's announcement describes limited, phased access. An earlier Arena sighting does not guarantee current access to the same checkpoint.

Are these all confirmed Carbon outputs?

No. They are attributed to Carbon by their publishers or archives. Some early sessions reportedly displayed Argon, leaving backend identity uncertain.

Are the original prompts available?

The cheetah comparison records a short prompt. Most other accessible records establish the subject but not complete original instructions. The six longer templates above are newly written reference prompts.

Can the games be embedded on another website?

A social video provides no playable iframe endpoint. A working application URL, permission to reuse it, and compatible embedding behavior must be checked separately. The platformer creator explicitly declined to share that game's file.

Do these examples prove Carbon is better than Opus or Astra?

No. They provide individual outputs and creator opinions. A defensible comparison needs matched inputs, comparable execution conditions, multiple attempts, and functional evaluation.

Conclusion

The most useful Gemini 4 Carbon examples combine visual ambition with behavior that can be inspected: articulated machinery, editable environments, coordinated SVG animation, and working game states.

The 25 examples offer a practical starting collection, but their value increases when prompt provenance, model identity, and implementation limits remain visible.

Choose one example, open its creator link, and define three acceptance checks before rebuilding it. Use the recorded prompt where available or one of the clearly labeled reference templates. Keep the runnable result, failed attempts, and verification notes together so that an impressive demonstration becomes an inspectable project.