Author introduction "Shoichiro Inoue" Position: Engineering Dept. Client Team Date joined: February, 2021 Industry experience: Three years Getting Started Hi everyone, my name is Shoichiro Inoue from Holoearth's engineering client team. I'm mainly responsible for implementing the building mechanics in Holoearth. Many games in recent years have included building and housing mechanics, and windows are an integral part of this kind of mechanic. However, in many games windows can only be placed in specific places, such as on a wall with a hole specifically made for window placement - but we want to place windows wherever! I'll introduce the solution we worked out for this problem in this development blog. But first, here's a short video demonstrating the end result. https://holoearth.com/wp-content/uploads/2024/04/mado_setti.mp4 As you can see in the video, it is possible to freely place a window wherever you want! The part of the wall where a window is placed disappears, revealing the outside. But in addition, it is also possible to cut a hole in the wall's collider as well. This allows for the possibility in the future to have battles where, say, arrows can be shot through windows that were installed. Here, I explain the process of how we approached the problem. Solving the Problem Requirements The wall has to be in place first to install a window, the window must be installed such that it's flush with the wall, and the window's rotation must adjust automatically to the proper orientation with respect to the wall. I won't go into detail about this part. The window "prefab" must include the following information: Collider (to use collisions to detect which wall it is being placed on) Window width and height Workflow 1. The window contains a collider and retrieves which wall it is to be placed on. 2. When colliding with a wall, the window passes its position and size data to the wall and requests to make a hole there. 3. The wall in question executes scripts to change its shader and collider values to create the hole. And if the window is destroyed it asks the wall to restore those values. I'll talk about the shader that creates the appearance of a hole and the script that makes a hole in the collider later on. So far the scope of this mechanic is limited as follows: It doesn't take into account how the window's edge protrudes from the wall, so we use raycasts to make sure all four window corners are on the same wall. It can't allow for multiple windows on a single wall, so if a second window is added it will destroy the first window. Using Shaders to Make the Window's Appearance In essence, the wall's shader will not render where the window's coordinates overlap the part of the wall being rendered. This means the sides of the model will be empty, revealing the reverse side of the wall's mesh, but this is covered by the 3D model of the window frame on the sides of the window. (Left: Wall being overlapped by a window is removed by the shader. Right: Placing a window frame over the removed portion.) A surface shader is created to grab the coordinates of what is being drawn. The window's center coordinate and size (width, height) are obtained from its script. Making Calculations We split the problem into the two parts below. 1. Whether the coordinates being drawn are in the window on the horizontal plane, and 2. Whether the coordinates being drawn vertically are in the window. 1. Horizontal plane We make a line on the x-z plane using the formula: z = kx + b. Let k be the slope of the line perpendicular to the window when viewed from directly above. Then there are two lines, b, which are the lines passing through the front and back edges of the window, respectively. Let us denote them as b1 and b2. There's no need to draw within the yellow area bounded by lines z = kx + b1 and z = kx + b2. That is, if the coordinates we are drawing now are x1, y1, and z1: kx1+b1 < z1 < kx1+b2 Then the coordinate is in the window on the horizontal. *k can be obtained from the window's y-axis rotation = rotY. *Since the tan of 0 is undefined, we need to set up a branch process to avoid specifying 0 as the argument of the tan function. k = tan(rotY/180f * π + 0.5π) *b1, b2 can be obtained from the coordinates of both ends of the window b = z / kx 2. Vertical Direction Now, the Y axis: In Holoearth, the window rotates only on the Y-axis, so the equation is simple. _windowBottomY < position.y < _windowTopY We know that we are in a window in the vertical direction if the above is true *The _windowBottomY and _windowTopY can be obtained by adding the window width to the window center point Y coordinate. Taking all the above into account the code looks like this: bool isInsideWindow(Vector3 pos) // pos: world coords of point to be drawn { 　　// Is in window on x-z plane 　　var isInsideXZ = _k * pos.x + _b1 < pos.z && pos.z < _k * pos.x + _b2; 　 // Height is within window 　　var isInsideY = _windowBottomY < pos.y && pos.y < _windowTopY; 　　return isInsideXZ && isInsideY; } *The actual shader was created by the same team. They are modified and shown here for clarity. *To reduce processing loads, _k, _b1, _b2, _windowTopY, and _windowBottomY are calculated when the window is placed. Future Endeavors Right now this can't support shapes other than rectangles. To accommodate other shapes, the area of that shape needs to be calculated. For example, a circular window can be implemented by projecting the drawing coordinates onto the x-y plane and then making sure the distance between the point being rendered and the center point is less than the radius of that circle. Making Openings in Colliders Now I'll explain more about creating an actual hole, rather than just in appearance. The wall collider consists of a single box collider. The original collider is replaced by four box colliders to avoid the window part, each of which is divided to avoid the window section to represent a hole in the wall. The way to do it is pretty simple: we attach a new four-box collider after deleting the original collider, which requires computing the center coordinates and size of each collider. This will result in the following variables: A 3-dimensional vector (vector3) for the size of the wall, wallSize Relative coordinates of the window to the wall in another vector3, windowCenter Length of one side of the window in a vector2, windowSize The actual calculation is as follows: *The collider is a local coordinate system, so rotation doesn't need to be considered. *The origin of the wall is at the center of the bottom surface, and the origin of the window is at the center of the length and width ▼Upper collider var sizeX = wallSize.x; var sizeY = wallSize.y - (windowCenter.y + windowSize.y); var colSize = new Vector3(sizeX, sizeY, windowSize.z); var posX = 0f; var posY = wallSize.y - sizeY/2f; var colCenter = new Vector3(posX , posY, windowSize.z/2f); ▼Lower collider var sizeX = wallSize.x; var sizeY = windowCenter.y - windowSize.y/2f; var colSize = new Vector3(sizeX, sizeY, windowSize.z); var posX = 0f; var posY = sizeY /2f; var colCenter = new Vector3(posX , posY, windowSize.z/2f); ▼Left collider (The x-axis is zero at the center of the wall, so the coordinate of the left end of the wall is -wallSize.x / 2f) var sizeX = - wallSize.x/2f + windowCenter.x - windowSize.x/2f; var sizeY = windowSize.y; var colSize = new Vector3(sizeX, sizeY, windowSize.z); var posX = -windowSize.x/2f + sizeX/2f; var posY = windowCenter.y; var colCenter = new Vector3(posX , posY, windowSize.z/2f); ▼Right Collider var sizeX = wallSize.x/2f - (wallCenter.x + wallSize.x/2f); var sizeY = windowSize.y; var colSize = new Vector3(sizeX, sizeY, windowSize.z); var posX = wallSize.x/2f - sizeX/2f; var posY = windowCenter.y; var colCenter = new Vector3(posX , posY, windowSize.z/2f); Set these values to position the collider so that it doesn't cover the window area. Future Endeavors With the process described here, it is difficult to make holes in the collider with non-rectangular shapes. At the moment windows of different shapes can't be made, but there are possible ways to accomplish this: Increasing the number of box colliders and arranging them like an integral, which could make shapes really close to circles and triangles. But this drastically increases the number of box colliders as accuracy increases. Preparing colliders with triangular or circular holes in advance. After making holes in a rectangle, place these prepared colliders inside the holes. It takes time and effort to prepare colliders with special shapes, but it might reduce the number of colliders necessary. Final Thoughts The combination of shaders and collider management allows us to create an experience where windows can be placed freely on walls! We hope to create more and more awesome building features! If you're interested, definitely give it a try in Holoearth!

Greetings from the Holoearth Management Team! For this edition of the development blog series we interviewed our 2D Art Director, YK-san, and 3D Environments Designer, Shimano-san. We asked them all about the process of taking in-game areas such as the Simulation Room and Kyo-no-Miyako from the 2D concept art phase to fully-fledged 3D, what the communication process is like, and more! Interviewee introduction "YK-san" Position: 2D Art Director Date joined: April, 2021 Industry experience: 8 years Interviewee introduction "Shimano-san" Position: 3D Environments Designer Date joined: April, 2022 Industry experience: 20 years First of all, please tell us about your professional history and your current roles. YK-san (hereafter YK): Before this I worked for 8 years as a concept artist for console games. From there I joined the Holoearth development team as an art director, and I'm going onto my third year here. I oversee the concept art designs for backgrounds, props, and other things that will be implemented in Holoearth. ▲Some of YK-san's concept art Shimano-san (hereafter Shimano): Like YK I also came over from the gaming industry, where I got about 20 years of experience in console and arcade games, mobile, and even pachinko and slots, touching pretty much every genre at one point or another. It's just now two years since I joined the Holoearth development team. I primarily oversee specifications, production, and final quality control for in-game environments. What was the state of Holoearth development when you first joined? YK: I joined the company when the Holoearth project plan had just been established. The first thing shown to me was 3D models of [hololive] talents running around free Unity assets. We only had a very rough mock up of what we wanted to achieve with Holoearth, but there wasn't yet a very concrete framework in place. Shimano: When I first joined the 3D there essentially wasn't yet a 3D environment team, so I was asked to be a core foundational member of the new team.  So you were involved in the planning when it was still being set up! Do you mind telling us how you are approaching your work at the moment? YK: For starters, we receive new requests from the producer and directors. With the Simulation Room, for example, we were asked to create a gameplay area where building and crafting would be possible. We then worked with the producer to design something that would both fit in the Holoearth setting and satisfy UX requirements, such as "when [players] cut down a tree, they will receive lumber that can be used for crafting and building." And the 3D team takes the concept art to work with. Is there anything you're sure to keep in mind when creating 3D models from the concept art? Shimano: Absolutely. On the 3D side of things, we can't really create a world as we see fit without the original concept designs. I think that if the role of 2D artists is to take a concept from 0 to 1, the purpose of my work is to take that 1 to 100. So we strive to reproduce the concept art as closely as possible and take it to 100 by creating scenery and small details not visible in the 2D art. Finally, we also make adjustments to achieve a good visual balance. ▲YK's concept art for the Simulation Room ▲Creating the area behind the tree and small details not depicted in the concept art Looking at the development framework it would appear like the 2D and 3D teams are working together in tandem. When the concept art is finished and passed on for 3D modeling, the two teams are still communicating closely with one another, correct? Shimano: We simply ask [the 2D team] when we need to clarify anything. For example, when we are unsure of what kind of feel to give something we're turning into 3D we'll just approach YK and think together on a good workflow that includes the considerations of the 2D side and the circumstances of the 3D side. YK: I don't really think everything can be conveyed in 2D from the very beginning, so it's great to be able to further express what I had in mind when creating designs through this sort of informal conversation. Shimano: It's good to have the artists right at hand to continue production smoothly with the final image in mind. In this new frontier of the "metaverse," the sentiments of the producer and directors must change quite a lot - how do you maintain flexibility in this rapidly evolving environment? Shimano: For me, breaking things we have created is part of the creative process. It's not "one and done," but more a process of creating something as a launchpad for something else, and fixing it with feedback along the way. On the other hand, the 3D team is also in charge of the final output of each design, so we have to be very conscious of deadlines. Due to this, we are always torn between wanting to continue working on something and establishing a firm line in terms of quality in order to meet a deadline.  YK: I'll decide what I feel must absolutely remain in the design and what has more wiggle room within the scope of the schedule so we can come to a compromise. As the team has grown, how do you approach communication and team building with the various team members? YK: As far as the 2D team is concerned, we haven't established absolute requirements as such. I ask team members to decide what they want to do, and we then try to incorporate it into the design process in a way that best utilizes those ideas. Shimano: When it comes to the 3D environments team, we divide everything into discussions about the big picture and the detailed process. For the big picture, this is all about members sharing their important values. These are values we all share as a team: mutual respect, willingness to rebuild things, not isolating anyone, not flat out rejecting ideas. The detailed discussions are for concretizing each member's tasks at hand. In making to-do lists of all the tasks that need to be done, including verbal requests, we are able to manage the process so that we don't miss anything or take on more than we can handle, and also each task can be handled by the right person in the right place at the right time.  As a team what is on your mind as you work to create something like Holoearth that hasn't really been seen before? YK: This relates to what we were talking about previously, but we place full importance on the world-building and guidelines envisioned by the producer, and work to expand the values of each team member and reflect those in Holoearth as much as possible. Incidentally, YK-san, how do you expand your worldview and update your own personal values? YK: I'm always thinking of areas that no one has challenged and expanding my own strong points. I like to reference things that actually exist while, say, combining A and B in such a way that no one has seen yet. I explore combining various environments and settings each day to create something new. I also try to keep my antennae out for environments and values that can further enhance the general setting thought of by the producer. Shimano-san, when were your thoughts when creating the Simulation Room? Shimano: We created the Simulation Room once YK's concept art was released. First of all, we poured over the 2D art to make sure it could be built well in 3D by envisioning the finished 3D version. Then we saved that 3D image in our minds and began work on reconstructing it in 3D with DCC (digital content creation) tools.  In bringing something to 3D, as much as possible I want to honor YK's original without losing anything. Once we feel we have achieved this, we turn our attention to creating a 360° view of the environment that is not depicted in the 2D art - within budget. 1. Concept art 2. Modeling and overall construction phase 3. Lighting to adjust overall color and brightness 4. Completed version with surrounding areas and gameplay elements (portal) Finally, we work with the technical artist (TA) to add custom shaders with movement and a distinct style to increase the graphical quality by one or two more degrees. ▲Working with the TA, stencils and omnidirectional video were combined to create a unique parallax effect for the sky There are instances where the final detailing can't be completed with 3D models alone, so you work with the TA to achieve the final product? Shimano: That's right. The interesting part is, what happens is a cycle where the concept art moves to the 3D phase, the 3D team consults the TA, and the TA in turn refers back to the original art to help create the final version. That's what I think is particularly interesting and how I know it will get even better.  Is this something you didn't see much in development until now? Shimano: As far as I'm aware this kind of creative environment isn't too common. Typically, you are so busy working just to meet deadlines from start to finish.  But with Holoearth's development, there is actually time to spend thinking about things like, "what should we do with the look of this asset?" When it suits us we spend something like 60-70% of our work on this instead. YK: Usually the art team doesn't really get to be involved with anything after it goes to 3D, but with Holoearth what's interesting is we get to have responsibility for helping supervise the final output and polishing it together. And that's how the Kyo-no-Miyako and Simulation Room areas came to be last year. Looking at the response from players, has anything come to your attention? YK: I feel a lot of encouragement seeing people enjoy what we have so far despite not having a ton of content out yet. Shimano: Seeing so many players visit the Simulation Room and Kyo-no-Miyako, running and jumping and poking around every corner, makes me really happy but also a little nervous. Those who are playing Holoearth are coming at it from both a kind but also critical perspective. We get tons of positive comments, but also sometimes critical feedback, which we are grateful for.  So days when new content is released are the most nerve wracking but exciting moments. ▲Many players gathered for "hatsumode" in the New Year's version of Kyo-no-Miyako released on Jan 1, 2024 ▲Players sit around the kotatsu to enjoy the "holo Out, holo In 2023 ▷ 2024" stream YK: In the console world, releasing content publicly while at this stage of development isn't really heard of. Shimano: That's true; this feeling of doing something to the tune of almost a live performance is quite intriguing.  You are in a spot where you can be creating and building while also being able to have back-and-forth with users at the same time. Shimano: Also, we have a guideline from the producer where "this is something that we will continuously be creating, so the real finished product can be shown a little later," which lends some sense of relief.  Thanks to that, we can keep our feet firmly planted on the ground and sort out what needs to be prioritized, such as whether to make this asset now or carry it over to next time, so we don't have to make a lot of compromises to finish something if it's not ready. In this way, players can hopefully anticipate more improvements and growth each time. YK: To that end, we place great importance on not betraying players' trust as we work on development.    How about we end on what you both would like to challenge going forward. Shimano: Just as in the beginning, I still think we cannot be 100% dependent all the time on the art team and instead we need to complement each other. If we have something that doesn't seem like it can be designed totally from scratch, the 3D environments team would like to propose perhaps creating it in reverse and being involved with the design, when possible. For example, the "Alternative City" we are currently making is a large city area, so it may not be possible to have the art team solely take care of every detail. So if it is a motif that can be seen readily in the real world, such as roadside trees or plants, the environments team is gradually working to help with the design aspect as well. I'd like to further strengthen this capability in the future. YK: I'm always thinking about how unique the Holoearth experience is, and I hope the environments, creatures, and other aspects of the world can immerse players in an experience that can't be had elsewhere.