User Tools

Site Tools


mv3d_mapping

Mapping for MV3D is different than mapping for the usual Rpg Maker maps.
While it uses the usual engine's mapping to set it, many common practices on the usual engine do not work the same way on an mv3d map.

Good on Editor, Bad on MV3D

Youtube channel ToastyTime made a video presenting MV3D that may be a helpful visual aid:


Walls

In an usual map on mv, due to the angular bird's eye view, the developer puts the “roof” tile, and some “side” tiles to the south of it. That gives the wall a visual effect of it rising from the ground.

That however is not needed for mv3d, due to the fact is actually rises from the ground.

While proper configuration right from the start is prefered, mv3d does come with some default settings for you to experiment with right away to get a feel of how it works.
Walls and Roofs on MV3DWhile that can be changed with configuration, A3 and A4 tiles are already expected to become walls, so mv3d already comes with those pre-set to have the height set on the plugin parameters as “Wall Height” (by default, 2).
Not only that, while “wall side” tiles only get the height, “wall roof” ones also have their side textures be the “wall side” right bellow them on he mapping's tile selection box.

Unfortunately that comes with the side-effect of, if someone does put “wall side” tiles expecting it to work like on usual mv mapping, both tiles will rise.

Normal vs MV3D walls comparison

The same idea works in all lower-layer tiles: if their height is different from the height around them, they will rise like walls, so there is no reason to put tiles for their side.

However, if they are not already roofs (the odd lines in the A3 and A4 tiles) they do not come with preset side textures - they would still have the same texture, their normal tile, on all sides and the tops. Anything else you have to set them yourself.

The Demo Project has a few examples, both in the Database's Tilesets and in some maps as Map Notes.

Of course, with the proper settings you can easily convert the walls to show just the same textures as the roofs… but when you reach that point of experience you should be experienced enough in the usage of this plugin you would find other uses for the tiles.

Decorations

In normal MV mapping, you just put the decorative tiles - from the B to E tiles - on the map editor and have an idea how they will be in the game.

Tiles that block are an X in the Tileset, that are passable but are under the player or events are a circle, and those passable and above are a star.
That allows to easily make something like a tree by putting one of more X tiles, depending on the width, and star tiles above it so the player can walk behind its top. Same deal for something like a three-tiles-high lamppost, one X with two star ones above it in the editor.

It also has a new, but not very advertised feature, of using two layers of decorations on the same tile.
Unless you put the top-left tile of B, supposed to set it as no decorations and thus always supposed to be fully transparent, any two decoration tiles placed on the same map tile will be put on up to two layers, the latest tile on the topmost layer.
This allows for combining decorations, for example having the tile of different empty tables, the tile of different foods and drinks, and when needed you put a table with a specific one you just put the right table with the right food, no more need for a tile for each combination of table and food.
Another use would be just a decoration being shown in front of another, for example two trees whose leaves cover the other's - in older RPG Makers, you would need to use an event as the second layer.

MZ has this feature automatically, but you can also select directly which of the four layers it gives to add any tile to. A very useful feature.

MV3D has different mapping methods than usual MV, or MZ.
Expecting decorations to just be translated to MV3D is the most common mistake.

Ground Decorations

The most common mistake is people expecting tiles to be stacked by putting one in the tile above the other, and them being turned into s two-tiles-tall tree just because the one on the upper tile has star passability.
While it makes sense to do so on the usual RPG Maker mapping, as it is a 2d map and being above the player is the most that can be expected, this will not work on MV3D.

While Circle, X and Star on the tileset still in a way change if a tile is passable, they are, by default, a flat image on the ground - or, in the case of a Star tile, floating in the air.

What those change is actually if they are platforms and if they have collision.
Platforms are for if the characters, be it player or event, can walk over them when in the proper height. For example, a bridge would be walkable on, thus a platform. A spike of ice, not so much. As they are by default in the Flat shape, their height is the same as the ground, and thus at proper platform height.
Collision, that is if they stop a character walking through them Something you would only be able to see in action when they are set to a different shape or height.
To explain better, something passable, the characters can walk through them, as if an illusion or a ghost.

A Circle and an X tiles, by default, both have collision… but a Circle is a platform and an X is not.

A Star tile has by default no collision, but also no platform, meaning they are just decoration.
However its main feature is that it also has the default Fringe added (set by default to be 2, but changeable in the Plugin Parameters), meaning they are floating two tiles above the ground layer under them.

They are all changeable, be collision, platform, fringe, or other settings, regardless of the passability set on the database.
Those changes can be made either through Map Notes, Tileset Notes or Terrain Tags.
Terrain Tags deserve special attention, as by default the Plugin Parameters come with two already set, 1 setting them to the shape XCross (the tile's image twice with one rotated 90 degrees forming a cross, but all rotated 45 degrees to be an X shape), Height of 1 (characters would be one tile over the ground to not collide or to use as platforms) and Fringe of 0 (not floating). 2 only sets them to use the shape Fence, for use in fences.

The main cause of confusion regarding passability is for making a decoration be more than a tile high.
As mentioned, a star tile will be floating instead of above the X tile. Even ignoring this, for example setting the fringe to 0, they will be rendered in separate tiles.
What to do?

The simpler answer: using the two layers of decoration MV allows you to.

As mentioned before, default MV allows you to put two decorations on the same tile, allowing you to make combinations. MV3D uses this for other purposes.
If you put two decoration tiles in the same tile, the upper one will be rendered on top of the other.
So if you have a two-tiles-tall tree, and set them to a terrain tag to have a shape with height (and, if one is a star, to have 0 of fringe), putting the bottom of the tree in the tile and then the top in the same tile, while not good visually in the editor, would make it a proper tree in the running MV3D game.
This of course has the limitation of using both layers.

The more complicated answer: set one of the tiles to use more than one tile on the map.
This one is considered more complicated because at this point you are setting the tile's texture, and some proper attention to the images and numbers is required.

You can set a tile to use more than the one tile as texture when rendered. As an example, I will use the lamppost on the default Outside tileset.
It's bottom tile, and the one that I will use on the map, is the tile B,3,28 of the tileset (that is, on the image set to the B tab, that tile is on the fourth column and 29th row (numbers start from 0, so one more that in the number used as the first in either would be 0)).
Shape shall be set to XCross. Texture, however, is the important part here. It shall be set to start on the tile two tiles above it (that is, the top of the lamppost), and to have a width of 1 tile and height of 3.
And finally Height will be set to 3, as putting nothing would be as if setting to 1 and would scale the image vertically to fit. In other words, the resulting settings would be

B,3,28:shape(xcross),texture(B,3,26,1,3),height(3)

That gives us a 3 tiles high lamppost using only one tile on the map.

Wall Decorations

Currently there is no known reliable method to decorate the walls through tilesets.
Only through either setting the tile to use a 3d model, or by using an event as decoration.

Decorating through Events

Events in MV3D work in a similar fashion to ground decorations, save they cannot be set to have the basic block shape.
In compensation, they have offsets and scaling.

This makes them extremelly useful, especially for things like wall decorations.

A good example would be a door, as it has to be set on the wall.
Thus it will be the one used as an example to explain how to make one as a Wall Decoration.

Usually on MV you put the doors or passageways as an event in the wall, add a teleportation to them, and call it a day.

In MV3D an event supposed to be seen on the wall needs to be properly set.
While more information can be seen on the proper explanation for Event Configuration, the four main things to have in mind when making an event for decoration is: shape, elevation, rotation and offset.

As it is very likely to be an Object Event, due to door character images usually having an ! or !$ at the start of the filename (in normal MV mapping, that removes the vertical offset to put it seemingly above the bottom of the tile to pretend characters are walking on it), Doors will have the default settings (which can be changed on the Plugin Parameters) of:

shadow(0)
shape(sprite)
scale(1)

Shape is the first thing you need to change.
Sprite, the one used for events by default, does change image when you change the camera direction (unless you set it not to), but rotates with the camera's pitch and yaw to always be in alignment with it.

We want the door's image to rotate with it just as a wall would.
For that, the most appropriate shape is a Wall shape, which will turn our event into a cardboard.

shape(wall)

Elevation is how high from the ground it is set on the door will be.
As a default, an event is set on top of the map tile it is put on. Which would be fine if you put it in front of the wall (we will talk more about this in offset), but if you put it on the wall itself like usual it will make the door be on top the wall instead(because, as far as the map is aware, that is the ground).

Thus you have to set it to have a fixed Z (that is, the vertical coordinate in the map).
This way it will always stay in the same elevation, no matter the height of the map in that tile.

z(0)

Rotation needs to be set because, by default, events will be made turned to the south of the map. And while it is not noticeable in Sprite shape due to turning to face the camera, Wall shape turns them into a cardboard, meaning even if your door is to be on the west side of the door will still be turned to the south.
To fix that you need to set a rotation for it.
As you may imagine, south has 0 rotation, or no need to set it. North, 180 rotation. East 90 and West 270.

rot(270)

Offset is important to make the door visible (unless the wall is transparent, or a hole in that particular space, mostly used for inside maps where it is just a division between rooms), and as already said the main difference from just using tiles as ground decorations.

By default the tile or event, in this case a Door, will be in the middle of the tile - that is, inside the wall.
However an event can use an offset, something purely visual but that will move the image around.

In this example we will use the offset to move the event's image to seem to be on the wall itself.

Two particulat offsets will be important here: X offset, that is west to east, and Y offset, that is north to south.
There is also a Z offset, but it is not important in this instance. Offsets are purely visual, so for all intents and purposes the whole tile is the event as usual. Elevation is not only visual, where the event appears to be, but also mechanical, the height the player has to be to interact with it. So unless you are aiming for a particular effect Z offset is not important.

X offset is, as mentioned, on the west to east, thus to be changed for doors set on those sides of the wall. Positive values move the door's image to the east, and negative ones to the west.
Y offset on the other hand is to north to south, thus for doors set on those sides. Positive will move the door's image to the south, negative to the north.

The values of course, are also important.
The image of the door will be, by default, exactly in the middle of the tile. As offset values are based on fractions of the tile instead of pixels, that means the edge of the tiles is at exactly 0.5 offset.
But that is not the value we want to set the event to. We want the door to be slightly outside the edge, hard to notice but still separated enough to avoid any visual glitches.

This is the point the position of the door, mentioned in elevation, comes in place.

If your door event is inside the wall, you want it visible slightly outside it, meaning the value you wish for is 0.51, just slightly outside its own tile.
However if you put the event in front of the wall instead, you will want it to be still on the same tile but just about to touch the wall, thus 0.49 would be a better value.
(setting to not have collision and to check if the player is facing the wall before activating the door would probably be needed too)

xoff(-0.51)
yoff(0.51)

Examples

Of course, this is all the basics, and you can see examples of them used together in the demo project.
Do not be afraid to experiment to find out what would fit better your personal project.

One very important example for decoration is the “home inside” map, of the insides of a house.
In there the bed and chair have their height and top and side textures changed through a map nodeblock, with an event set for the headboard and backrest respectively.

mv3d_mapping.txt · Last modified: 2021/04/13 22:17 (external edit)