Upstream/dynmap
1
0
Fork 0
mirror of https://github.com/webbukkit/dynmap.git synced 2024-11-21 17:55:22 +01:00
Code Issues Projects Releases Wiki Activity
Page: Defining volumetric models
Pages
. AWS S3 Storage Addons Advanced Map Configuration Base Plugin Settings Boosting areas on Dynmap BoxRenderer Class Chunk Status Colors Chunk Version Colors Color Schemes Commands Common Features for Texture and Model Definition Files Component Configuration Configuration Configuration.txt Configuring Maps and Worlds using dmap Credits Custom Block Definitions Defining a Block using a Custom Block Renderer Defining a Block using a Volumetric Model Defining a Cuboid Block Defining a Simple Block Defining cuboid models Defining custom lightings Defining custom perspectives Defining custom shaders Defining volumetric models Dmarker Dynmap API Dynmap On Xenon Hosting Service, courtesy of mavbear Dynmap With IIS Using URL Rewrite and applicationrequestrouting thanks to kekec852 Dynmap with Apache httpd on Arch Linux Dynmap with IIS Dynmap with Nginx server on Centos Dynmap with Nginx Dynmap with apache2 on Debian Dynmap with lighttpd on Arch Linux Earthmc maps Example configurations and demo website Exporting World Data in Wavefront OBJ Format External Webserver Basics External Webserver on Linux External Webserver on Windows External Webserver on hosting providers FAQ Features FenceWallBlockRenderer Class File System Storage Forwarding Dynmap port through cloudflare Full list of predefined perspectives Guides HD Map Configuration Home How to compile Dynmap Incompatible mods Installation Setup of Dynmap on Linux Installation Internal Webserver with Caddy as a Reverse Proxy (Linux) Internal Webserver Lighttpd and SQLite on a Raspberry Pi 4 with DietPi Model Definition Files MySQL MariaDB Storage Nginx as a Reverse Proxy OCI; Oracle Cloud Instance; Quick how to enable DynMap PaneRenderer Class Permissions PostgreSQL Storage RedstoneWireRenderer Class Resources SQLite Storage Setting up Dynamic Map with apache2 under Debian Setting up Dynmap through hosting services Setting up the Dynamic Map plugin under Windows Setting up without the Internal Web Server SkullRenderer Class Special texture file types StairBlockRenderer Class Storage Setup Support for Minecraft Servers other than CraftBukkit Support for MinecraftForge based mods Support for Tekkit Texture Definition Files Textures of Dynmap Use dynmap via Pterodactyl Using Markers Using custom block renderers Web Setup Web UI Parameters Web ui login support and permissions World and template settings [Tutorial] Setting up a standalone web server with MySQL SQLite limiting render area
6 Defining volumetric models
mikeprimm edited this page 2013-11-28 07:42:35 -08:00
Table of Contents

Volumetric models are intended to provide a relatively convenient way to produce relatively complex shapes. The application of textures to the volumetric models follow the same pattern as is done for simple cubes and for cubiod models - the texture for each of the 6 faces is applied to the corresponding side of any of the subblocks within the model, with the texture scaled to the full size of the cube face. Consequently, the texture definitions in the Texture Definition Files are defined in the same way as for simple solid blocks and for cubiod models.

The volumetric models are based on dividing each dimension of the block by a provided constant (the scale), which can be any power-of-2 up to 16 (1, 2, 4, 8, or 16). This results in the cube being divided into a set of cubes, each of which is 1/scale x 1/scale x 1/scale. The model is then defined by indicating which of these smaller blocks are filled by the model versus being empty.

The model is defined in a number of lines: the first line is a "block:" line, and has the following attributes:

  • id - the block ID that the model is to be used for. At least one id attribute is required, but as many as are needed can be used - allowing the same model to be used for multiple blocks. See Block ID Numbers for details on specifying block ID numbers.
  • data - this provides the specific metadata values that the model is to be applied to. The default, data=*, indicates all metadata values for each of the blocks IDs indicated by the id attributes. Otherwise, one or more data=number attributes can be used to select specific metadata values for the model.
  • scale - this is the number of divisions used for each axis of the model. This results in the cube being divided into scale layers of subblocks, each of which is scale by scale subblocks.

For example, the model for the piston extension facing down can be produced by a volumetric model by first dividing the cube into 8 parts on each axis:

 block:id=34,data=0,data=8,scale=8

After the "block:" record, one or more layers of blocks can be defined - ranging from layer 0 (the bottom layer) to layer (scale-1) (the top layer). Each layer is defined by a "layer:" line, which has a comma separated list of numbers indicating which of the layers are being defined (if more than one layer uses the same pattern of subblocks, only the pattern only needs to be defined once). The next scale lines after the "layer:" line define the pattern of the subblocks: each line represents one step of blocks in the Z axis (first is lowest, last is highest), and each has scale characters (representing the subblocks from the lowest to the highest on the X axis) - a '*' for a subblock filled by the model, or a '-' for a subblock left empty in the model. Any layer not specified is assumed to consist of empty subblocks.

For the piston extension facing down, the full definition is:

 block:id=34,data=0,data=8,scale=8
 layer:2,3,4,5,6,7
 --------
 --------
 --------
 ---**---
 ---**---
 --------
 --------
 --------
 layer:0,1
 ********
 ********
 ********
 ********
 ********
 ********
 ********
 ********

In this case, the cube is cut into 8 x 8 x 8 pieces: 8 layers of 8 x 8 subblocks. The head of the piston fill the bottom two layers (layer 0 and 1), while the pushrod of the piston occupies the center 1/4 of the other layers (layer 2 to 7).

Volumetric Model Rotation

As an alternative to manually defining additional volumetric models manually, additional volumetric models can be defined by rotating an existing volumetric model around the Y axis by 0, 90, 180, or 270 degrees.

To define a volumetric model by rotation, add the "block:" line as normal (be sure that the scale attribute matches the scale from the source model), and add a "rotate:" line immediately following it. The attributes of the "rotate:" line include:

  • id - the block ID of the source volumetric model (the model to be copied and rotated). See Block ID Numbers for details on specifying block ID numbers. One id attribute is required.
  • data - the metadata value of the source volumetric model. One data attribute is required, and is required to be a number.
  • rot - the rotation value, in degrees around the Y axis. Valid values are 0, 90, 180, and 270. The rot attribute is required.

Note: rotating the volumetric model has no effect on the application of textures to the model: a texture applied to the north face of the unrotated model would still be applied to the north face of the model after rotation, for example.

Contents

Setup

Advanced Configuration

Mod Support

Developers