Gemini 3.8 Flash: Copyable Prompt and Workflow for a Three.js 3D Grass Hut Demo (Reddit)

One-sentence takeaway

The post publishes a complete Three.js rendering prompt for Gemini 3.8 Flash. Starting from an existing scene and reference image, it asks the model to implement grass, wood, roof, lighting, and LOD optimizations within a mobile-browser budget, and to deliver a single HTML file that runs offline. The author also records a multi-round prompt comparison with Astra, but provides no controlled benchmark or independent verification.

Use cases

• Suitable tasks: Visual upgrades to an existing Three.js scene, grass and material enhancement, mobile performance trade-offs, and single-HTML runnable prototypes.

• Prerequisites: Access to the existing scene, reference image, a Three.js runtime, and a test directory that can be rolled back; “preserve the existing scene” in the prompt cannot replace the actual input assets.

• Unsuitable tasks: Requesting an exact reproduction without a reference scene, or treating a one-off visual demo as proof of production-grade performance, cross-device compatibility, or code quality.

• Applicable model version: The original post explicitly uses Gemini 3.8 Flash; it does not disclose an API model ID, thinking level, temperature, or context configuration.

• Applicable client, agent, or API: The client is not specified; the case concerns a code-generation / browser 3D prototyping scenario.

• Recommended reasoning level and parameters: Not disclosed in the original post. Fix the browser, Three.js version, device, and reference assets before comparing results.

Ready-to-use content

1. Complete English prompt published in the original post (verbatim)

Act as a senior Three.js rendering engineer and technical artist with Naughty Dog–level attention to detail.

Objective: Make a playable 3D demo.

Prioritize:

- Realistic grass with curved, tapered blades, central folds, varied heights, darker roots, subtle translucency, and natural wind.

- A hybrid rendering approach: detailed blade geometry nearby and efficient textured tufts farther away, with smooth LOD transitions.

- Better wood, bark, and roof materials through restrained surface relief and roughness variation.

- More natural ground variation, lighting, shadows, and atmospheric depth.

Preserve the existing scene from the image, touch-friendly orbit camera, walking controls, collisions, and interactions. Analyze the reference critically; adapt useful techniques rather than copying its rendering costs or bugs.

Aim for PS4/PS5-inspired visual richness within realistic mobile-browser limits. Use instancing, spatial culling, GPU wind animation, and scalable quality settings.

Deliver the implemented improvement as one self-contained HTML file with Three.js and all assets embedded, runnable locally and offline without installation or a server. Verify functionality and shader compatibility where possible, and clearly distinguish tested results from unverified visual or performance expectations.

2. English usage version (faithful translation, not the Reddit original)

Act as a senior Three.js rendering engineer and technical artist with Naughty Dog–level attention to detail.

Objective: Make a playable 3D demo.

Prioritize:
- Realistic grass with curved, tapered blades, central folds, varied heights, darker roots, subtle translucency, and natural wind.
- Hybrid rendering: use detailed grass-blade geometry nearby and efficient textured tufts farther away, with smooth LOD transitions.
- Improve wood, bark, and roof materials through restrained surface relief and roughness variation.
- Create more natural ground variation, lighting, shadows, and atmospheric depth.

Preserve the existing scene from the reference image, the touch-friendly orbit camera, walking controls, collisions, and interactions. Analyze the reference critically; adapt useful techniques rather than copying its rendering costs or defects.

Within realistic mobile-browser limits, aim for PS4/PS5-inspired visual richness. Use instancing, spatial culling, GPU wind animation, and scalable quality settings.

Deliver the improvement as one self-contained HTML file containing Three.js and all embedded assets. It must run locally and offline without installation or a server. Verify functionality and shader compatibility where possible, and clearly distinguish tested results from unverified visual or performance expectations.

3. Minimum configuration implied by the prompt

The following execution configuration is organized from the source; it is not a separately disclosed API configuration from the original post:

Input–output cases

Comparison inputs recorded in the original post

• Input: The same set of 3D modeling prompts and the same type of reference scene; the author ran 3 groups of tests in total, none of them one-shot.

• Gemini 3.8 Flash: This grass-hut test used 5 prompts and took about 8 minutes in total; the author recorded a size of about 115 KB (the original post does not specify what this figure refers to).

• Astra: The same test used 2 prompts and took about 10 minutes; the author recorded a size of about 779 KB (the original post does not specify what this figure refers to).

Observable output and the author's assessment

• The output target is a playable 3D demo containing grass, materials, lighting, interactions, and performance strategies, rather than a single rendered image.

• The author believes Gemini 3.8 Flash completed the result in this test group with a smaller model footprint and shorter total time, and on that basis concludes that it outperformed Astra.

• The original post does not include the complete generated HTML, browser/device specifications, frame-rate logs, a shader compatibility matrix, or itemized scores; “faster/smaller” above can only be treated as the author's one-off record.

Test/workflow steps

1. Prepare a rollback-capable Three.js project, reference image, and fixed browser/device; record the Three.js version, assets, and whether network access is allowed.

2. First enter the complete original prompt, asking the model to preserve the existing scene and interactions and explicitly output one self-contained HTML file.

3. Open the HTML locally and offline, then check the camera, walking, collisions, interactions, grass wind, LOD transitions, materials, shadows, and mobile touch controls item by item.

4. Check the browser console, WebGL/shader errors, and whether the assets are actually embedded; record frame rates and load times at different quality levels.

5. Split the results into four columns: “verified functionality,” “unverified visual effects,” “unverified performance expectations,” and “simplifications made by the model.” Do not treat the model's self-report as test evidence.

6. If comparing other models, hold the same input, reference assets, device, start time, and acceptance checklist constant; record the number of prompt rounds, elapsed time, output size, and manual fixes separately.

Applicability boundaries and verification notes

• “PS4/PS5-inspired” is a visual target, not a promise of console-level image quality or performance; the mobile browser's GPU, memory, and touch capabilities require separate acceptance testing.

• “5 prompts,” “about 8 minutes,” and “115 KB,” along with Astra's “2 prompts,” “about 10 minutes,” and “779 KB,” are all one-off community records from the author, not a controlled experiment, and cannot directly establish the models' overall superiority or inferiority.

• The original post does not disclose the complete output HTML, test logs, frame rates, device, specific reference image, or model API parameters; these variables must be filled in when reproducing the test.

• The “all assets embedded” and “offline operation” requirements may conflict with external font, audio, or browser-module dependencies; check that the HTML truly makes no external requests.

• Complex grass and GPU wind may create substantial geometry, transparency, and shader costs; provide a quality-degradation path or a way to disable effects, and do not validate only on high-end desktop hardware.

• Use this only with projects and assets that you are authorized to access; do not embed credentials, user data, or internal resource URLs in the prompt or generated single file.

Source excerpt or observation (compliance-limited short quote)

The post's most reusable design is putting the “visual target” and “engineering boundaries” in the same prompt: it asks for grass, materials, and atmospheric effects while also requiring instancing, spatial culling, scalable quality, offline single-file delivery, and a distinction between tested and unverified conclusions. The author's cross-model time and size records should still be treated as community experience awaiting review.