Particle 1 for procedural 3D graphics: what the knight and fortress tests showed

This article examines Particle 1 as a model for creating procedural 3D scenes with code. The author tested it on two related tasks: generating a knight and a medieval fortress, then used the created elements in a game and on a website. The results show that the model can assemble functional browser prototypes, but it inconsistently retains small prompt details and sometimes loses elements that had already been fixed.

Conditions of the Particle 1 experiment

All tests revolved around one story about a knight who stands guard for 704 nights. This approach helped test the creation of individual objects and the reuse of results in different projects: the knight model from the first test later appeared in the game, while the author posted the model’s story and images on the website.

Particle 1 was run in a browser, and the author checked the results in Three.js. The workflow involved three steps: the model received a detailed assignment, the author inspected the result, and then requested one refinement when there were serious errors. The evaluation considered prompt compliance, appearance, details, functionality, cost, and time spent.

This was neither a laboratory comparison of several models nor a universal benchmark. All scores, prices, and conclusions relate to the test scenario described by the author. A full evaluation of assets in a production workflow would require identical assignments, multiple repetitions, and testing in different editors and game engines, since a single scenario does not show how the model behaves under all conditions.

Generating the knight: a complex prompt and the first version

In the first test, Particle 1 had to create a procedural 3D knight model without ready-made files or images. The model had to assemble it with code, add a closed helmet, a bell on the shoulder, a shield with an emblem, a cloak with a coat of arms, and a guard stance. The assignment also included walking and a sword swing, so the test covered more than just a static pose.

The first version took 57 minutes to create and cost 34 cents. After approximately 39 minutes and expenses of 25 cents, error 413 occurred. According to the author’s observation, the request exceeded the 16 MB limit. The author only assumed a connection with the screenshots and did not confirm it, so it cannot be considered the established cause of the failure.

The author rated the first model 5 out of 10. The main elements of the design were present, but the figure resembled a mannequin made of tubes, the head looked too large, and the metal surfaces were excessively bright. Some shield details did not match the assignment. For a procedural prototype, this meant that the overall silhouette and set of objects were preserved, but not the design accuracy required of a finished art asset.

What the knight refinement changed

The refinement took 15 minutes and cost 23 cents. The total cost for the knight was 57 cents, and the total time reached 73 minutes. After the fixes, the metal became darker, the helmet had more suitable proportions, the body became bulkier, and individual plates appeared on the boots.

The fix did not improve all parameters at once. The emblem disappeared from the front of the shield and from the tabard, even though some of the corresponding details had already been present. The guard stance became less readable. The cloak remained a flat trapezoid with almost no folds, while the dent and split in the bell were difficult to make out.

The walking and sword-swing animations were present in the refined model. The author gave the final version 6 out of 10, or 35 out of 50 under his scoring system. The result improved in terms of materials, proportions, and individual armor elements, but the refinement also demonstrated the method’s limitation: the model can fix one group of problems while damaging another.

The fortress of nine bells

In the second 3D test, Particle 1 was given a larger compositional task. The author requested a diorama of a fortress with nine bells, a section of land, a road, a bridge, a gate, walls, towers, and an open belfry. The scene was also supposed to contain nine places for bells, trees, rooks, and two banners bearing the knight’s coat of arms.

The first version of the fortress took 34 minutes to create and cost 23 cents. After approximately 29 minutes and expenses of nearly 20 cents, error 413 appeared again. Continuing in the same session ended in another failure, while a new session completed the work in 5 minutes. The refinement cost 28 cents and took 18 minutes. The total result was 51 cents and 53 minutes.

In the first version, the entrance to the castle was blocked by a wall, and the road hung over the edge of the plot. The rooks had rectangular wings and looked like small airplanes. The author rated this version 6 out of 10. The errors affected not decorative details but the scene’s navigation logic: the viewer could not immediately understand where the entrance was or how the road connected to the bridge.

How Particle 1 fixed the scene

After refinement, the passage into the castle was opened, the paved floor led inward, and the road connected properly to the bridge. A rocky ledge appeared in the composition, making the section of land more expressive. The birds looked more convincing, although the level of detail throughout the diorama remained at the prototype stage.

The fortress received 7,5 out of 10 and 37,5 out of 50 on the author’s scale. In his assessment, it was the strongest 3D result among the four related projects. The fortress succeeded not only because of its appearance: after the fixes, it conveyed the spatial structure better, since the entrance, road, bridge, and inner passage read as elements of a single scene.

The coded presence of an object did not guarantee its visual readability. The scene included nine places for bells, but from the overall view it was difficult to see all nine positions and the one empty place. Cracks on the bells were nearly indistinguishable, and the gate grille blended into the shadow. This limitation is significant for a game diorama: an object may exist in the scene without fulfilling a narrative or visual function.

Small details and the stability of refinements

The test’s main weakness was the difference between a detail being present in the code and being perceived in the frame. The emblem on the knight could disappear after refinement, cracks on the bells remained indistinguishable, and the flat cloak was formally present but did not create a convincing impression of fabric. The model handled large objects and composition better than graphic symbols, surface damage, and folds.

But what happens if you ask the model to fix a scene that is already working? According to the author’s observation, a new iteration sometimes broke elements that had previously worked well. In the case of the knight, the emblems disappeared and the guard stance became less clear. A refinement cannot be accepted without rechecking the entire object: you need to assess the requested change while also monitoring the old requirements.

Error 413 recurred in three of the author’s four projects. After a failure, it was never possible to continue working in the same session, so the projects had to be completed in new sessions. The author did not establish the exact cause and identified the most likely connection with the screenshots as an assumption. In such a situation, a developer needs saved code, intermediate versions, and a brief description of the scene’s state before each continuation of the work.

Comparison of the knight and fortress

The fortress turned out to be cheaper and faster than the knight, and its final rating was higher. The difference is related to the nature of the tasks. The knight required a precise combination of proportions, materials, coats of arms, damage, and animations. The fortress relied on large-scale composition, where fixing the entrance, road, and bridge noticeably improved the perception of the entire scene.

Across all four projects, the author spent 1 dollars 65 cents and 3 hours 37 minutes. In addition to the knight and fortress, he created a browser game and a website about 704 nights. Each project received an overall rating of 35 out of 50 for the knight, game, and website, while the fortress received 37,5 out of 50. These values reflect the author’s opinion, not an official quality rating for Particle 1.

What to check in Blender and Godot

The Three.js test showed that Particle 1 can create interactive browser prototypes, but it did not answer questions about asset portability or suitability for further production. The author considers additional testing in Blender and Godot necessary. This stage should include importing geometry, checking materials, object structure, animations, scale, lighting, and scene behavior after saving, since a browser result alone does not confirm that an asset is ready for use in another environment.

Animation control is especially important for the knight. Walking and a sword swing may be present in the code, but that does not by itself indicate natural movement or convenient further editing. In Blender, it would be worth checking individual clips, the skeleton, attachment points, and the ability to retune the pose. In Godot, the import, frame rate, collisions, character controls, and material display under game lighting should be checked.

The fortress requires a different kind of testing. The developer needs to make sure that the entrance remains open, the road really connects to the bridge, and the bells and banners are visible from the game camera. If the nine places for bells are needed for the assignment or interface, they should be checked not only in the source code but also through separate viewpoints, highlighting, and game triggers.

Conclusion of the Particle 1 test

Based on the author’s experiment, Particle 1 performed best as a tool for rapid procedural prototyping. It created a knight, fortress, game, and website around a single story, added animations, and fixed major compositional errors. The fortress was the most convincing result because, after refinement, its main spatial relationships read noticeably better.

The model’s weakness appeared in its precision and stability. Small details were often lost, and a new edit could remove an element that was already working. Error 413 complicated continuation of the work and forced a move to a new session. In the author’s subjective assessment, Particle 1 did not become a reliable solution for full-scale 3D generation and showed an average level of performance, though its capabilities proved practical for low-cost prototypes.

A developer should treat this result as a starting draft rather than a finished production asset. The code, scenes, and models will need to be checked manually, saved by version, and tested in the target environment. Only importing them into Blender and Godot will show whether the procedural scene retains its functional properties beyond the browser prototype.

Frequently asked questions about the Particle 1 test

How much did generating the knight cost?

The first version cost 34 cents, and the refinement cost 23 cents. The total was 57 cents, and the total time reached 73 minutes.

How much did generating the fortress cost?

The first version cost 23 cents, and the refinement cost 28 cents. The entire project took 51 cents and 53 minutes.

Was it possible to preserve all the prompt details?

No. The large elements were present, but the emblems, cracks on the bells, cloak folds, and some aspects of the pose were lost or difficult to distinguish.

Can Particle 1 be considered a finished tool for 3D production?

The described test does not confirm this. It shows that the model is suitable for procedural prototypes in Three.js, but asset portability and quality require separate testing in Blender and Godot.