Develop Reference

Terrain map THREE.JS

Tell me who knows about THREE.JS. I implement a map grid similar to the game SimCity 50x50. I rendered blocks of ground with different heights (as in the screenshot), now I want to smooth out the height transitions so that there is a smooth relief, while maintaining the 50x50 grid. As planned, everything should be like in the SimCity game: the user changes the type of landscape, change the relief of the landscape.
Image: How it looks now - Image: What I want to get
Implemented as follows: there is a json array where for each cell its XZ coordinates are listed for placement on a 50x50 map and a Y coordinate for the height of the land block, as well as the type of terrain (grass, earth, stone, etc.). Each block of land is a BoxGeometry.
There were thoughts to somehow add vertices to the upper side and smooth out the transitions by their positions, but I did not find this.

This could be accomplished with BlockGeometry objects, but that would be far more trouble than it's worth. For example, you'd have to analyze the surrounding terrain to know how to rotate the BlockGeometry to modify it correctly, and you might have to rotate it again when the terrain is edited. < That's not to mention the number of objects; at your size of 50×50, you'd be adding 2,500 objects to the scene. > A single mesh is much more natural in these circumstances.
First, notice that the map only comprises four cell shapes, not counting rotations: flat cells, cells that slope parallel opposite edges, cells that bend up to form a corner, and cells that bend down to form a corner.
Think of your terrain not as a set of blocks, but as one continuous surface quilted from square cells. Each cell is a mesh of four triangles.
Looking at a cell down the negative y-axis, starting at the top-left corner and moving clockwise around the cell, we'll label the vertices at the cell's corners a, b, c, and d. We'll place a fifth vertex, e, at the exact middle of the cell when viewed from this perspective. These vertices form four triangles, △abe, △bce, △cde, and △dae.
For any cell, the Y value that you're currently storing becomes the y-position of vertex a< e >.
To get the y-position of vertex b, we look at the cell one column to the right. The y-position of that cell's top-left corner (a), i.e., that cell's stored Y value, is also the y-position of the top-right corner (b) of the cell we're currently building. Similarly, the y-position of our current bottom-right corner (c) is the stored Y value of the cell down one row and to the right one column. The y-position of our current bottom-left corner (d) is the stored Y value of the cell down one row.
Vertex e is a bit trickier, but it can be solved like this:
If any three of a, b, c, and d have the same y-position, then e shares that y-position (this is a level cell or a diagonal slope).
If two adjacent vertices of a, b, c, and d share one y-position and the other two share another y-position, then the y-position of e is the average of those two y-positions.
If neither 1 nor 2 is true, we have an error (because the SimCity 2000 map didn't allow other types of geometry).
Now, actually generating the mesh is another matter, but there are plenty of tutorials available (via Google: Procedural terrain meshes in ThreeJS).
< I've created a proof of concept that you can see at https://pnichols04.github.io/sc2k-map/, with source code at https://github.com/pnichols04/sc2k-map. >

How to draw a line (path, svg) between two elements that aren't always rectangular

I'm making a diagramming library in Blazor which uses HTML nodes and SVG links. I am wondering how can I draw links between two nodes when they aren't always rectangular.
All the solutions I find are based on nodes that are rectangles/squares, where it's easy to draw a link on the borders (or even the center, but only works for direct links).
But what about nodes that have custom stuff in them that makes them non rectangular, for example a div with border-radius: 50%?
One possible solution is to draw the lines from/to the center of the elements, but that would only work with simple lines, curved lines would look weird.
In this example:
How does arrow position get calculated?

You need to have an container, width and height of the container, then inside the container find the x / y point of the element that you want to connect and draw a line to the next elements x / y point, the x/y points can be calculated using x,y,w,h of the element, for an example x:100 y:100 w:100 h:100 the center point sits at x:150, y:150 x = x + ( w / 2 ), y = y + ( h / 2 ).. using math just calculate the point of connection of the elements, the complexity of math for calculating the connection point is in the shape of the element, for each different shape you need a different calculation metod if not in center

Find all free rectangular regions in a 2-D box with random positioned obstacles inside

I have a pre-defined-size rectangular area with some other rectangles inside, which represents filled regions, or, let say, obstacles.
All the rectangles are axis-aligned.
Origin of the axis (i.e. 0,0) is top-left.
The X and Y coordinates of all the rectangles, as well as the horizontal and vertical size is known.
Information about the rectangles inside the main area is contained in an already-sorted array, where i[0],i[1] are the X,Y coordinates of the upper-left corner and i[2],i[3] are respectively the x and y size:
[
[10,1,14,7],
[34,1,14,15],
[16,22,27,44]
]
How can i get all the rectangles covering the free remaining space, like in the image below?
(credits: Jukka Jylänki, A Thousand Ways to Pack the Bin - A Practical Approach to Two-Dimensional Rectangle Bin Packing http://clb.demon.fi/)
I don't need an algorithm for optimal bin-packing, as the rectangles are already placed, nor to find the biggest rectangle, but i'm aware that these can be related arguments.
I have also read some papers about the line-sweep algorithm, but i'm not able to get a working implementation, and so i cannot imagine if this would be the right solution for my problem.
My first attempt (clearly wrong) was to gather all the cuts generated by all the sides (inverse intersection):
[
[24,8,37,8],
[1,16,60,6],
[1,22,15,44],
[43,22,18,44],
[1,66,60,5],
[1,1,9,70],
[10,16,6,55],
[24,1,10,21],
[34,8,9,14],
[43,8,5,63],
[48,1,13,70]
]
...but this would require an additional step to to join adjacent rectangles and then filter out those inside a bigger one. See for example, the red-marked rectangles in this picture:
Could be this a way to go, though not optimized?

How to rotate image - canvas pixel manipulation?

I use getImageData and putImageData to draw on canvas from a buffer canvas. I use these methods because I have a large number of particles and these proved to provide the best performance.
Now I'd like to add rotation of particles but I'm having problems with that.
Here is a jsfiddle which uses transformation matrix for rotation. As you can see in the picture (or fiddle) there are holes in the resulting image which I kinda expected from using this matrix.
nx = ~~ (xx * Math.cos(angle) + yy * Math.sin(angle) + cx);
ny = ~~ (xx * Math.sin(angle) - yy * Math.cos(angle) + cy);
But I don't know how to make this better, especially when I'm looking performance effecient solution?
jsfiddle demo
Image - square after rotation (square is used as a simple body):
Currently my backup is procedurally generated sprite animation which is prepared in advance with standard canvas states: save -> translate -> rotate -> restore.
Thank you very much for any directions you can give me.

The problem is that you are trying to map a single pixel to a single pixel. When you rotate an image, each pixel in the original can influence any of the surrounding pixels in the new image. You are effectively mapping the top left corner of each pixel to it's location in the new image, but you need map the center of each pixel to it's location in the new image and then check the overlap of this rotated pixel with that location, and the 8 surrounding pixels in the new image.
Here you can see the effect. The yellow dots are the centers of the pixel which find the "home" location for the pixel (i.e. where the majority of the influence will be placed). You then need to figure out the percentage of that pixel (the underlying blue/white grid) cell is covered by the original pixel (black box surrounding the yellow dot). Once you figure out the home location influence, you need to repeat that process for the 8 surrounding pixel with respect to current pixel in the original image. In your current code, you are using the top left corner of each pixel to find the home pixel for the new image. You should use the center of the pixel.
Since multiple iterations might affect the same pixel, you'll need to calculate the transformation in a buffer before drawing it to the final image. For pixels in the transformation that are not fully covered by pixels in the original image, figure out the percentage of the pixel that is covered and use that to influence the alpha channel. You'll have to take care when applying the pixels to the final image that you account for the alpha portion and blend with what's already there.

Isometric engine drawing issue

I'm trying to write a game engine in js (canvas). So far so good.
But i got one problem my world is diamond shaped and i render the tiles from top to bottom.
The problem is when i have a tile that's bigger than 1 tile (so 2x2 as example) this will happen:
The house is defined on tile (2,1).
The left rock is placed on (1,0)
The tile (1,0) is rendered first and the next tile is (2,1) because it's on the same row and on the right.
How can you solve this?

You should be able to avoid the problem by breaking your graphics down into smaller pieces - one piece per tile on the grid. A good way to think of it is like this: If you could view the grid from directly above, each sprite should not overflow the edges of the cell they're allocated to.
For example, this cell below should probably only contain the front section of the house shown by the smaller cube:
At some point you may need to also micromanage multiple sprites in the same cell, but that's the same concept in a smaller space.

For this specific example there's a simpler solution.
Right now the house occupies these spaces: 2x0, 3x0, 2x1, 3x1
And you're drawing the house from position 2x1
If you instead drew the house from position 2x0 (and still occupy the same original 4 tiles) all the tiles would draw in correct order.
As long as you're drawing tiles top (back) to bottom (front) in screen rows, you can use oversized tiles that are 2x2, 3x3, 4x4, or any square size easily without slicing. Just draw these larger tiles along their middle row position. I often use the left corner as the grid anchor for these large tiles. It makes sense in my head this way because as soon as you draw the leftmost (or right) corner of a big isometric square, you separate everything already drawn behind it from what comes in front of it.
Rectangular oversized tiles (e.g. 2x1, 2x3, 2x4, 3x4, 4x5) usually require a more complex draw order algorithm than just screen rows top to bottom. I opt to slice these into square tiles.
Side note, that medieval house tile does already have original parts split into vertical slices if you want to go that route (my originals are on OpenGameArt).

I think the best solution here is clearly to divide your graphics using a pre-defined metric (width of a tile for instance).
The tile-based system is widely used for 2D-game, including isometric games.
Example: http://www.spriters-resource.com/pc_computer/fallouttactics/

My solutions (Also thanks to Marty Wallace!)
I can cut the sprite in 3 pieces shown on the image below
The first part gets drawed on coord (2, 0)
The second part gets drawed on coord (2, 1)
The third part gets drawed on coord (3, 1)
So we slice it vertically on the bottom tiles (the drawed tiles are like a V shape)
This should work for every tile size like 4x4
We can forgot about the tile (3, 0)
Blue: The actual png
Red: the cut lines
The lines are a bit off, but it's about the idea
And i need some sleep (that last 2 is 3 ofcourse)
This also gives us a simple calculation:
sizeX - 1 = The number of sides on the right of the middle section (the big one)
sizeY - 1 = The number of sides on the left side of the middle section
And every slice is half the tile width, and the middle slice is the full tile width.
The right slices contain only the most right part of the tile, and the left the most left side.
We can easily use tiles like 3x1 or 1x4 etc