DeepSeek V4.1 Flash 1017 in Blender: a practical test of 3D model generation

This article examines DeepSeek V4.1 Flash 1017 as a language model for generating 3D character models and Blender projects. The author tested it at the maximum reasoning level through an OpenCode Go subscription and compared several ways of creating the same gnome character.

The result was suitable for prototyping but did not replace manual refinement. The models retained the recognizable appearance, clothing, and accessories, but errors in anatomy, attachment of details, footwear, and textures limited their readiness for direct use in a game or final scene.

Conditions of the DeepSeek V4.1 Flash 1017 test in Blender

The author conducted the test in Blender, using DeepSeek V4.1 Flash 1017 at the maximum reasoning level and accessing it through OpenCode Go. The test centered on a single gnome character with glasses, a beard, clothing, a belt, pockets, keys, and other decorative elements.

The comparison involved more than just different prompt formulations. In some scenarios, the author provided the model with the original image, a detailed textual description, or both sources at once. The fifth approach differed in its workflow: the project was first created in 3GS using a library and then transferred to Blender. The test description also mentions transferring from an 3ds Max project, so the exact designation of the intermediate environment should be understood as part of the author's description of the experiment, not as a universal characteristic of the Blender pipeline.

How the 3D models were evaluated

The author focused on features important for a game character and further editing:

• similarity to the original image of the gnome;
• correctness of the hands, fingers, face, and footwear;
• the presence and placement of glasses, pockets, fasteners, keys, and belt elements;
• the detailing of the clothing, beard, watch, and decorative objects;
• errors in the attachment of details and areas with visual artifacts;
• generation time and the cost of each scenario.

This was a practical test of one workflow, not a formal benchmark of the model. All quality assessments belong to the test's author and describe precisely the results they obtained.

Generating a gnome from a simple prompt

The first scenario used a simple text prompt. The author obtained a recognizable gnome model with glasses, clothing, and accessories. The input contained about 145 thousand tokens, the output was about 121 thousand tokens, and the amount of cached data was approximately 2,887 million tokens. Generation took 16 minutes 24 seconds and cost about 10 cents, according to the author.

The external appearance was fairly close to the specified character. The author counted five fingers on each hand, and the model acquired the main costume elements and accessories. For a first pass, the result looked acceptable, especially when the goal was to quickly obtain a foundation for further work.

The problems became apparent on closer inspection. The little finger was attached incorrectly, the ears looked wrong, the mouth was barely discernible, and the footwear turned out excessively square. These defects did not destroy the character's resemblance, but they showed the limits of the result: the model created a recognizable silhouette but did not control every anatomical and structural detail.

What the detailed prompt changed

In the second scenario, the author expanded the character description. The prompt included a watch, a gear, additional keys, pockets, fasteners, and belt elements. This request required about 272 thousand input tokens and approximately 234–235 thousand output tokens. The cache amounted to about 8,8 thousand tokens, the cost reached 20 cents, and generation continued for 32 minutes 19 seconds.

The detailed description did add more objects. The model gained a watch, a gear, new keys, pockets, and fasteners. The author also noted details on the belt and clothing. However, the increase in the number of elements did not lead to a proportional improvement in the model as a whole: in the author's assessment, the character did not become substantially better overall.

The main problem appeared in the hand. The thumb was on the underside, so the hand's position looked impossible for a human. Artifacts resembling cuts or a see-through shirt appeared on the back and clothing. The scenario demonstrates a practical limitation of a long prompt: a detailed list of objects helps the model avoid forgetting accessories, but does not guarantee correct geometry or proper attachment of every element.

Generating an 3D model from the original image alone

The third test used a single original image without a detailed textual description. Generation took 28 minutes 37 seconds, and the cost was approximately 18–19 cents. The author reported about 240 thousand input tokens, 212 thousand output tokens, and approximately 8,5 million cached tokens.

The character retained recognizable gnome features: glasses, a face, pockets, a belt, and clothing elements. However, the model was low-poly and sparsely detailed. The author compared its overall square appearance to Minecraft, emphasizing the simplicity of the form and the small number of polygons.

Decorative elements were often attached incorrectly, and the fingers were positioned wrong. In the author's subjective assessment, this version was the weakest of the first three. The image helped preserve the general appearance, but a single visual reference was insufficient to accurately reconstruct the three-dimensional structure of the clothing, hands, and small accessories.

Image together with a detailed description

The fourth scenario combined the original image and a detailed prompt. It was the most expensive and time-consuming of the options described: 461 thousand input tokens, 389 thousand output tokens, and 38,654 million cached tokens. The cost was 42 cents, and generation took 47 minutes 47 seconds.

The quality of the hands improved noticeably. The thumb was in the correct place, and each hand had five fingers. The detailing also surpassed the result generated from the image alone. The author noted a gear, a watch with a chain and a dial, additional pockets, fasteners, an improved belt, glasses with distinguishable glass elements and reflections, an indication of a mouth, and characteristic stitches on the beard.

Full accuracy was still not achieved. Some buttons and footwear details were floating in the air. One key was floating, while another was attached to the trousers instead of the pocket. This kind of error matters for a game asset: a decorative detail may look convincing from one angle but immediately reveal incorrect geometry when the model is rotated or its animation is configured.

The variant with project creation in 3GS

The fifth workflow began with generating a project in 3GS using a library. The project was then transferred to Blender. In one of the described runs, processing the input and output data amounted to 285 and 41 million tokens, respectively; the cost reached 35 cents, and the entire stage took 52 minutes. A significant portion of the time went not only to generation but also to creating the project in the intermediate environment and transferring it.

According to the author's assessment, this approach produced the best result among those tested. The hands were made correctly, the thumb was in the right place, and the keys were located in a pocket. The author also rated the beard, lip, nose, eyes, eyebrows, glasses, hat, pockets, belt, and clothing positively.

Errors remained. One key partially entered the body, some colors were displayed incorrectly, and the watch chain contained defects. The buttons were not perfect either. The author considered some of the problems fixable already at the 3GS stage, that is, before transferring the result to Blender. The possibility of making corrections early was one of the reasons why the author preferred this scenario over the others.

Comparison of approaches

How much time and money the test took

The author spent 2 hours 57 minutes 24 seconds and 1 dollars 27 cents on all the tests. These figures relate to the author's experiment, specific runs, and the access method used. They cannot be automatically applied to any future work: usage depends on the length of the context, the number of iterations, the selected mode, and the cost of access to the model.

The simple prompt was the cheapest. The combination of an image and a detailed description took the most time and cost more than the other options mentioned. The fifth scenario was not the fastest, but the author considered its quality closer to the desired level.

What will need to be fixed manually in Blender

Before using the model in a game, animation, or final render, the artist will need to check not only its appearance but also the object's structure. First of all, the hands, thumb, number of fingers, and the points where the hands connect to the body should be inspected. Errors that are unnoticeable in a wide shot become critical when deforming the skeleton and setting up animation.

• correct the position of the fingers, little fingers, and thumbs;
• rebuild the ears, mouth, and individual facial elements;
• check the footwear and remove excessively square or merged forms;
• attach buttons, keys, chains, and decorative details to the correct surfaces;
• remove objects that are floating in the air or intersecting the body;
• check normals, intersections, and material display;
• correct color artifacts on the clothing and accessories;
• assess the mesh density and prepare the model for optimization.

And what happens if such a model is transferred directly into a game scene? Problems will appear during camera rotation, lighting, export, and animation. Incorrect attachment of a key or button will no longer be a minor visual inaccuracy, and an object intersecting the body will require separate geometry repair.

What DeepSeek is suitable for

According to the author, DeepSeek V4.1 Flash 1017 is suitable for quickly creating a character concept, a rough Blender asset, and a foundation for further modeling. The model can retain the overall appearance, add the listed accessories, and create an editable base, especially when an image is used together with a detailed description or an intermediate project in 3GS.

This result is useful when an artist needs an initial three-dimensional reference, character blocking, or a set of ideas for the shape of clothing and accessories. A specialist then checks the mesh, corrects the anatomy, adjusts the materials, and decides which details to keep in the geometry and which to replace with textures or normals.

For the ongoing production of finished game characters, the approach looks less convincing. The author believes that at this quality level, the time and financial costs may not be justified if every model requires extensive manual correction. In scenarios where precise anatomy, clean topology, rigging readiness, and consistent reproduction of the result are important, the author allows that stronger models, including the mentioned Opus or GPT, may have an advantage if access to them is available.

Conclusion of the DeepSeek V4.1 Flash 1017 test

DeepSeek V4.1 Flash 1017 managed to create a recognizable 3D gnome and several variants of its model for Blender. A simple prompt was enough for the basic character, a detailed description added accessories, and combining an image with text improved the detail and hands. The author called the best option the one involving creating a project in 3GS and subsequently transferring it to Blender.

The author’s main conclusion from the experiment is that DeepSeek can be used to generate 3D models, game logic, and prototypes, but the result cannot be considered a final asset without verification. The model saves some manual work at the start, but it does not eliminate the need for modeling, retopology, checking attachments, materials, and preparation for animation.