Minecraft Wiki:Standardized views

The wiki mainly uses special, standardized views of relevant game element in the form of images which can be found on the right-hand side of the page. These standardized views are axonometric representations with an approximately isometric viewing angle, as is also used for the inventory form of blocks in the game. These views are not simple screenshots, but special renders. In most cases, the game element is imported into a 3D graphics software or reproduced there, in order to then be able to create a shot from a special angle. Only PNG image format is used to maintain transparency.

The creation of standardized views directly in-game is not possible. The special viewing angle can be achieved by the parameters for rotation and head tilting with the command, but the distortion caused by the field of view prevents an ideal standardized view. Even at the minimum value, the field of view still causes a small distortion. Only with the help of mods can standardized views be created directly in-game. In the Indev phase of the game, it was possible to create isometric screenshots from the game world. This function has been removed.

This article contains instructions for creating the standard views used in the wiki. The instructions describe only one way to create the desired view. Individual authors may work differently. Any downloadable software is available free of charge, and the handling of paid alternatives may be easier and more convenient.

Only an approximately isometric angle is used for the views. The isometric axonometry is standardized and the exact viewing angle is 45° and 54.7359° (arctan $1/&radic;2$). However, for the views in the Wiki, a viewing angle of 45° and 60° is used.

Block Views
Block views are created with a 3D graphics software. The software can of course be freely chosen, very popular is the free program Blender, which can be downloaded on the right side of the page. When dealing with a model, it is always necessary to make as little work as possible. Therefore, you only create the sides of an object, which are actually visible from the viewing angle, from which the recording is finally made. The actual models therefore always look very strange, but on the end product, the representation for the wiki, but nothing is noticeable.

The templates in this section are only to be used for the actual views in the plug-ins, although the inventory form of the blocks can also be generated theoretically, but uses a different lighting than is preset in the templates. In order to display the inventory form of blocks it is therefore best to simply create a screenshot of an inventory with the respective block with the GUI size of Normal, as it has a size of 32×32px as the standard in the wiki, and must be cropped.

The templates for Blender provided in this entire section are intended solely for use in the Minecraft Wiki and are licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 license.

Preferences
Since block views can not be viewed directly in-game, it is particularly important to make them as detailed as possible, so there is no difference compared in-game. In addition, all renders in the whole wiki should be uniform, so that, as they are put in a page, there will be no serious differences in the way the rendering is made. Therefore, there are some special requirements that must be observed when creating block views. All templates provided in this section follow these guidelines, which do not require any further configuration. With a screenshot generated by a mod, these presets would not be achievable reliably, which is why a 3D graphics software is used.
 * A view angle of 45° and 60° is used for a render, the perspective being aligned to the north-west
 * Image size of 300×300px for each display, regardless of the actual size of the block, blank image parts are not cropped
 * The block is located exactly in the middle, exceptions apply only to blocks that are part of an animation and therefore need a special position (e.g. Flower Pot and open Fence Gate)
 * Equal lateral spacing for cubic blocks, horizontal 16px and vertical 2px, for bulky blocks (e.g. Rail and Glass Pane), one of the two spacing specifications must be adhered to depending on the respective shape
 * Uniform lighting with the exact values ​​as in the game, which is achieved by a proportional reduction of the color values ​​for the three visible blocks (parallel sides use the same values), upper side: 98%, left side: 80% and right side: 60.8%
 * No use of antialiasing, since it is not applied to individual objects in the game
 * No post-processing, and especially, no scaling, since the interpolation used for this purpose is used for antialiasing; If the render contains an error, it must be recreated

Cube Blocks
Most blocks have a single texture that is displayed on all six pages. With the corresponding template it is therefore very easy to create a block itself. The required template for creating blocks of dice blocks with Blender can be downloaded at the right side of the page under the name of.

In addition to the dice-shaped blocks, which work with a single basic texture, there are also dice-shaped blocks, which also use different textures on different sides. The template to be used in this case is  which can also be found in the download box on the right side of the page.

After opening, you should not let the block appear magenta, because no textures are assigned yet. Everything else is already fully configured, so you don't have to change any settings. To select the texture, an overview of all components of the project can be found in the upper right-hand part of the user interface. Simply select one of the block sides (,  and  )(1), and then scroll down with the chessboard icon(2) in the "Image" section. Then, click on the folder icon(3), which opens a menu for selecting the concrete texture.



In this menu it is now necessary to select the original text of the block. This should, of course, have already been extracted from the standard resources. In an extended field at the top of the menu, the location(1) must first be selected, then the individual texture can be clicked in the underlying large field(2). Press "Accept"(3) to confirm the selection. If you work with, the texture is automatically applied to all three blocks. However, in the template, all steps must be repeated for all of the sides of the block.



Since everything is already set, and the necessary textures are stored, the image only needs to be rendered. To do this, click on "Render"(1) in the top left of the menu bar and select "Render Image"(2). Alternatively, you can simply press.



Now, the "UV/Image Editor" has opened, where the finished render of the image can be seen. It just has to be saved. To do this, click on "Save As Image"(2) in the lower left corner under "Image"(1). Alternatively, you can simply press.



In the following menu, the location(1) and the filename(2) have to be filled up, and the process is confirmed with "Save As Image"(3), then the block render will be saved. The result of the example can be seen at the right edge of the screen. Your own blocker can now be uploaded to the wiki.



Irregular Blocks
In addition to the normal blocks with a cube shape, there are also some blocks in the game, which are irregular. However, the templates used so far are only designed for the cubic blocks. For irregular blocks, depending on the shape, different templates are required, all of which have to be specially designed and configured. The table in this section provides various templates for different types of such blocks.

The use is the same as described in the above instructions. Block should use several textures, if necessary, for which page the individual textures can be assigned. If the block is based on only one texture, any page can be selected. Pages of the model which use the same basic texture automatically take over them if they have already been assigned to one of the pages.

Troubleshooting
It may happen that after the rendering in the final image, which is shown in the "UV/Image Editor", missing textures or minor errors such as a wrongly turned texture are noticeable. These two errors are discussed in this section.

In some cases, if textures that are used by multiple blocks at the same time, Blender can not update them all the time, the texture for a page should be changed. This is merely a charging fault, which occurs irregularly. It can easily be fixed by selecting the corresponding block page at the top right of the element selection(1), and the text-specific settings tab with the chessboard icon(2) will move to the section "Image". Just click on the reload icon(3) and the texture is loaded correctly.



By re-rendering the block via the corresponding menu or by pressing, the corresponding side is also displayed in the image with the correct texture. If other sides are affected, the process must also be carried out for them.



When using the template, the final image should always be checked for its accuracy. Since blocks with several textures in the game, use entirely their own block models, so the textures in their rotation and reflection sometimes behave differently than in normal blocks. The used template for Blender can not cover each of these individual cases, but is only designed for the standard model. Individual deviations must be optimized manually.

In the example, the finished image shows that an error has occurred on the top of the block: the texture is mirrored, the brighter edge of the arrow should be on the right and not on the left side. As the finished render and block in the game are not to be distinguished at all, it is important to fix even a small error. To do this, the top of the block must first be selected(1), and the mirroring must then be made in the texture settings(2). In the "Mapping" section, this is the simplest way to change the sign of the X, Y, and Z values ​​under "Size". In the example, a mirroring on the X axis is necessary, so the sign of the Y value is changed(3).



By re-rendering the block via the corresponding menu or by pressing, the error is fixed as seen in the picture. This can now be saved as usual.



Entity Renders
Although standard renders of entities can also be created using a 3D graphics software, it is not recommended to use one. It is extremely difficult to reproduce the correct model, as each entity has different sizes and models. However, other entities, such as shulkers, are cube-shaped, so Blender can be used to render one. In addition to the workload, lighting is the real problem. Light behaves in Minecraft very differently, and the exact behavior in the environment of a 3D graphics software is extremely difficult and in most cases not exactly possible.

In this case, instead of a 3D graphics software, mods are instead used. Mineshot, created by a former editor of the wiki, BarracudaATA, is the best mod which can be used to render entities.



Non-animated Entities
After Mineshot has been installed, it can be started. Before recording, a suitable environment must first be created. Since the presentation in its final version should contain a transparent background, it is best to work with a monochrome background. Green screens or blue screens made of concrete blocks or specially textured blocks which are already very helpful, but since the lighting of Minecraft also colors different blocks with the same texture, an even simpler background should be chosen: the sky. It is recommended to create a superflat world with the preset "The Void". The sky is divided into two halves colored in a different blue tone, but these can also be standardized with the additional mod called OptiFine.

Since a background is now selected, basically only the enttiy has to be spawned then the recording can be done. It is important to summon an entity with the data tag of  so that it does not rotate or move. By the way, barrier blocks are best suited as the floor, since they are invisible.

To start recording, a special camera mode is switched on in Mineshot. This is done by pressing the default key, which can be zoomed in and out by pressing and  respectively, both of which can be found at the number keypad. Do not change the angle of the camera. The default values ​​(45° and 60°) correspond exactly to the values ​​required for the standard view.

The camera is centered on the player's position, but is only rendered by the game when it is not in the first person view. If the field of view is properly adjusted, a normal screenshot can be created. The actual picture object does not have to be exactly in the middle, because the recording is still postprocessed anyway.

When recording multiple variants of an entity, it is important not to leave the camera mode during each shot, nor change the zoom. If you make the slightest change, the previous setting can not be restored. The result is that the individual recordings do not exactly fit one on top of the other, but this is used in many plug-in letters and makes the recordings useless. Entities can be easily changed with commands, such as, without having to change anything on the camera between individual shots.

Since the recording has now been successfully done, it can be improved in an image processing program. The software used does not matter, but a download for a free program GIMP can be found at the top right of this section. First, the sky is removed, for which the color selection tool (magic wand) is best suited. In doing so, care must be taken that all places where the sky is visible are removed. Entities such as skeletons have many holes in their model, where there will still be individual pieces of sky.

After the background is gone, cropping is done. The width of the image should be minimal, for example, the two edges directly adjacent to the last pixel of the image object. The height should have enough scope, and this must not be cut so radically, otherwise the picture object "stick" at the upper edge. If there is nothing else to edit in the rendering, and it can be exported, and uploaded in the wiki.

During image processing, it is important not to scale. As a result, only very little quality is lost and the file size increases dramatically, instead of falling. A smaller recording should be created directly with Mineshot and a smaller zoom level. In the wiki itself, the image size can also be changed very easily as a parameter during the integration.



Animated Entities
A challenge when creating renders is to create entities whose model has a permanent animation. For example, in the case of silverfish, the body of which is continually moving, and also in guardians, whose spines are moving, and which constantly causes a swimming movement with its tail. A start to creating a representation of these creatures would be, of course, just to press the trigger at the right moment, but that is too unreliable and the absolutely right moment to catch is almost impossible.

At this point, it might be advisable to switch to a 3D graphics software, but as already described, certain difficulties occur. The solution approach is therefore to prevent animation of the entity. It is unfortunately not possible, even with commands or the data tag, now one has to really make the model. The models of entities can unfortunately not be controlled by resource packages, which makes this project a bit more difficult. Mods such as OptiFine or ENIM have this function, but the effort to create a complete model without the animation is just too big.

Instead, the model can be modified in the program code. This of course requires knowledge of the programming language of Minecraft called "Java" and a certain experience with the program code of the game. A work with the Mod Coder Pack, where the code could be changed directly, is still unfortunately not possible, since the required mod Mineshot can not be loaded since this requires Minecraft Forge. It must be in a programming environment with Minecraft Forge. The code and the model can not be edited directly, but Forge offers enough possibilities to easily overwrite an existing model. This works best through  using.

The actual recording is still in-game, and the steps are already described in the previous section.



Szenenansichten
Die Aufnahme einer Szene unterscheidet sich nur wenig von der Aufnahme einer Kreatur oder eines Objekts, lediglich ein paar weitere Sachen gibt es zu beachten. Auf eine 3D-Grafiksoftware wird erneut verzichtet, da auch in diesem Fall der Nachbau unnötig aufwendig ist. Wieder ist daher die Modifikation Mineshot von BarracudaATA bestens geeignet.

Bei Szenen geht es anfangs vor allem darum, alle zugehörigen Blöcke an einen geeigneten Ort zu verlagern. Prinzipiell darf die Aufnahme nur in der Oberwelt erfolgen, da in Nether und Ende auf Grund des fehlenden Sonnenlichts die Beleuchtung überaus miserabel ist. Geht es also darum, eine Aufnahme einer Netherfestung oder Endsiedlung zu tätigen, muss das Bauwerk in die Oberwelt transferiert werden. Ein Nachbau ist natürlich ausgeschlossen, da ungewollte Abweichungen die ganze Aufnahme unbrauchbar machen würden. Stattdessen bietet sich die externe Bearbeitungssoftware MCEdit zur Versetzung an, deren Downloadlink in der entsprechenden Sektion am rechten Seitenrand gefunden werden kann.

Sollte sich die Szene bereits in der Oberwelt befinden, sind aber auch hier in den meisten Fällen noch Änderungen vorzunehmen. Schließlich muss eine geeignete Umgebung geschaffen werden. Bauwerke wie Minen oder Verliese sollten nicht unter der Erde bleiben, sondern in den Himmel verschoben werden, damit sie optimal durch das Sonnenlicht beleuchtet werden können. Der ist hierfür überaus nützlich, wodurch in diesem Fall auf eine externe Software verzichtet werden kann. Aber selbst Bauwerke direkt an der Oberfläche können von einer Verschiebung in den Himmel profitieren. Wie bereits im vorherigen Seitenabschnitt beschrieben, bietet sich der Himmel wegen seines geringen Farbspektrums als hervorragender Hintergrund an, da die spätere Transparenz so ohne Umstände eingefügt werden kann. Wurde die Szene hoch genug versetzt, ist die Oberfläche nicht einmal mehr sichtbar, was die Nachbearbeitung umso mehr vereinfacht.

Es muss ebenfalls auf die Ausrichtung der Szene geachtet werden. Wie bereits beschrieben, zeigt die Blickrichtung bei den Ansichten für das Wiki immer nach Nordwesten. Die Szene sollte also dementsprechend ausgerichtet sein. Ist dies nicht der Fall, gibt es für kleine Blockstrukturen die Möglichkeit, diese mit der Hilfe eines Strukturblockes zu drehen. Bei größeren Bauwerken bleibt nur die Anwendung von MCEdit übrig.

Befindet sich die gesamte Szene nun in der gewünschten Ausrichtung an dem richtigen Ort, muss sie für die Aufnahme vorbereitet werden. Dies ist besonders bei geschlossenen Räumen, deren Inhalt sichtbar sein soll, wichtig. Dafür werden die Decke und zwei Wände entfernt, und zwar die beiden Wände, die dem Betrachter am nächsten sind. Es müssen nicht zwingend alle Bestandteile der jeweiligen Wand entfernt werden, befindet sich bspw. ein Eingang in einer der Wände, empfiehlt es sich, diesen einschließlich der Umrandung aus Blöcken zu erhalten. Befinden sich aber z. B. Leitern an einer zu entfernenden Wand, ist es natürlich naheliegend, diese ebenfalls zu beseitigen. Ein konkretes Beispiel einer Öffnung solch eines Raumes kann am rechten Seitenrand für den Portalraum einer Festung betrachtet werden.

Da nun die Szene selbst vorbereitet ist, spielt nur noch die Position des Spielers eine Rolle. Dabei muss stets bedacht werden, dass die Kamera von Mineshot auf dem Spieler zentriert wird, wobei dieser aber nicht zu sehen sein wird. Soll der Spieler in der Szene sichtbar sein, muss lediglich die First-Person-Ansicht verlassen werden. Die konkrete Position des Spielers innerhalb der Szene ist zwar unwichtig, wichtig ist immerhin nur, dass die gesamte Szene abgebildet wird, allerdings werden bestimmte Blockobjekte wie Truhen und Köpfe vom Spiel nur dargestellt, solange sich der Spieler in einem Radius von 64 Blöcken befindet. Auch Partikel sind sogar nur bei einer maximalen Entfernung des Spielers von 32 Blöcken sichtbar, sollen diese also sichtbar sein, muss auf diese Einschränkung geachtet werden.

Um nun die Aufnahme zu erstellen, wird in Mineshot der spezielle Kameramodus eingeschaltet. Dies geschieht standardmäßig mit NUMPAD5. Mit ADD und SUBTRACT (beide im Nummernblock) kann nun heran- und herausgezoomt werden. Am Winkel der Kamera darf auf keinen Fall etwas geändert werden. Die Standardwerte (45° und 60°) entsprechen genau den Werten, die für die genormte Ansicht benötigt werden.

Nachdem die Aufnahme nun erfolgreich erstellt wurde, kann sie in einem Bildbearbeitungsprogramm verbessert werden. Die verwendete Software spielt keine Rolle, ein Download für das kostenlose Programm GIMP ist dennoch am Seitenrand verlinkt. Zuerst wird der Himmel, also der Hintergrund entfernt, wofür ein Farbauswahlwerkzeug (Zauberstab) am besten geeignet ist. Dabei muss vor allem darauf geachtet werden, dass auch wirklich alle Stellen, an denen der Himmel sichtbar ist, entfernt werden. Szenen, die bspw. Eisengitter müssen in dieser Hinsicht besonders genau behandelt werden, da sich in den vielen Löchern noch einzelne Stücke des Himmels befinden werden.

Nachdem der Hintergrund weg ist, geht es ans Zuschneiden. Die Breite des Bildes sollte minimal sein, also die beiden Kanten direkt an die jeweils letzten Pixel der zur Szene gehörenden Blöcke grenzen. Bei der Höhe gibt es genug Spielraum, dieser muss und sollte nicht so radikal zugeschnitten werden, da sonst der Bildgegenstand am oberen Rand des jeweiligen Steckbriefes "kleben" wird. Ansonsten gibt es nichts weiter in der Darstellung zu bearbeiten, und sie kann exportiert, und im Wiki hochgeladen werden.

Während der Bildbearbeitung ist es übrigens wichtig, keine Skalierung vorzunehmen. Dadurch geht nur unnütz viel Qualität verloren und die Dateigröße steigt vorerst drastisch an, anstatt zu sinken. Eine kleinere Aufnahme sollte lieber direkt mit Mineshot und einem geringeren Zoomlevel erstellt werden. Im Wiki selbst kann die Bildgröße außerdem sehr leicht als Parameter bei der Einbindung noch verändert werden.

Optimierung
Da die Darstellungen immer sehr viele transparente Bereiche und ein geringes Farbspektrum enthalten, lohnt es sich, die einzelnen Dateien zu komprimieren. Neben dem offensichtlichen Effekt, dass Speicherplatz gespart wird, hilft die geringere Größe außerdem beim Anzeigen des Bildes im Browser, da dieser weniger Daten vom Wikiserver laden muss.

Eine nachträgliche Skalierung einer Darstellung ist zum Verringern der Dateigröße keinesfalls eine gute Lösung, sie bewirkt hingegen einen gegenteiligen Effekt. Dies liegt daran, dass bei fast allen Skalierungsarten eine Interpolation genutzt wird, die u. a. Kantenglättung durchführt. Dadurch wird das Farbspektrum stark erweitert und die Dateigröße steigt entsprechend an. Außerdem geht bei der Skalierung der ohnehin schon geringauflösenden Minecraft-Texturen mitunter viel Qualität verloren.

Stattdessen empfiehlt es sich, eine verlustfreie Kompression zu nutzen. Sowohl für Windows, also auch für macOS und Linux ist genau für diesen Zweck die Anwendung PNGOUT verfügbar. Je nach Bild bleiben nach der Komprimierung nur noch 80% bis 20% der ursprünglichen Dateigröße übrig, ohne das am Bild sichtbare Änderungen durchgeführt werden. PNGOUT kann am rechten Seitenrand für das jeweilige Betriebssystem heruntergeladen werden.

Unter Windows nutzt PNGOUT u. a. eine grafische Benutzeroberfläche. Zu komprimierende PNG-Dateien müssen lediglich ausgewählt werden und das Programm verkleinert sie. Unter macOS und Linux kann PNGOUT nur über das Terminal genutzt werden. Daher empfiehlt es sich, um wie unter Windows gleich mehrere Bilder automatisch verarbeiten lassen zu können, ein Skript zu nutzen. Unter Windows kann PNGOUT ebenfalls mittels der Konsole aufgerufen werden und mit einem Skript automatisiert werden.

de:Hilfe:Genormte Ansichten