Official Whiteboxing

I don't think that would work, unless we really block the camera in place. But in the current whiteboxing, the player has a lot of movement on the horizontal, which creates a lot of change in perspective so we need 3D elements somehow.

Actually one idea I had yesterday in the stream: in the latest @itsLevi0sa's whitebox, there's a big difference between the "lower town" (with the main square, fish market, isolated waterfall corner) and the "higher town" (with those few houses), so I was thinking that maybe we can reduce the issue if we bring the high town higher up. So when you're up top, you'd see the town below farther away, and we could get away with less objects. It could work?

Could be also fun to put the town song but very low in volume, to remark that we're still in the same location but the real action is far away.

To move up, the player wouldn't climb all the way up, but rather take a shortcut by entering maybe a "cave" in the mountain, which exits from another cave in the top part of town. The cave is not a natural cave but more like as if it was dug by the townsfolk. Or the shortcut could be located in a semi-open passageway, in between the rocks.

 

This could work for the town -- at least when going upward.

Going down could be a little more problematic.
My next point clarifies what I'm thinking here:

The problem (in my mind) is the player has a "jump" mechanic. And although the "jump" is not very powerful, it could still cause problems.
After all, Zelda OOT didn't (officially) have a "jump" mechanic -- yet players made all kinds of glitches and unintended sequence-breaking possible for the "jump-like" mechanics it _did_ have.
Without invisible walls _everywhere_ a higher/lower level exists (that scene-loading needs to happen), this will always be a headache trying to call-forth invisible loading zones (that the player may not have even intended to enter) which would unload any leftover content the player may have meant to address before the scene is reset to a new one.

Depending on how the player plays -- and what he/she tries to do -- keeping these things in check can be easier or harder depending on the terrain (and its eventual layout).

Also -- hard-coding things like this (and manually splitting scenes/terrains) leaves a lot less of a chance to iterate when a particular area or environment isn't working out later on (for example, in an instance like the town loading/unloading in unexpected ways for the player). The ability to iterate on a larger design is lost more and more frequently as more and more 'system-level' stuff gets delegated to a level-designer (letting more and more system-level control get taken away from to the actual game designer, in regards to how his/her game is meant to play).

Probably. But humor me just a little more please -- This is how I work my magic.

First off -- I don't think I was clear. Sorry. I suck at visual aids, but I was looking to find a video of one of the dungeon transitions I was thinking of online but I couldn't find it. However, here's one sorta example I could find (it's Jabu Jabu's belly):

https://youtu.be/Bcx62FOmH-s?t=165

That should show more along the lines of what I meant by "black background" along the walls during the fall transition, but, in this case, it was still a "wall" texture. However, generally in OOT, a "falling" session lets you see the floor below you only after falling so far down that the camera has time to move above you, but before that happens, the ground would attempt to be loaded before the camera even begins to move to an overhead location (to give the 'ground' ample time to 'appear' below you before you can ever actually see it thanks to the camera angle). This was mostly only done in dungeons because it would be too noticeable to rely on it outside in an open-world environment like in Chop-Chop (as the effect is less "directable" when the player can come at the loading plane from any angle).

The trick is mainly that the camera moves slowly overhead more and more (during the fall). The longer the fall, the longer it takes for the camera to slowly move to the correct point above Link to show the ground beneath him (giving the ground below more time to load before it becomes a truly overhead view) -- and the longer the fall, the longer time the game has to load the next floor (and unload the previous one). Sadly, again, this trick only works in dungeons -- not open-worlds.

This is why I suggested Imposters (for open-world scenarios), as they can be used anywhere -- even to simply allow the ability to hop from place to place (while still being very performant on mobile, as they are usually 2-8 tris max -- everything else is pixel-shader).

The "fall-camera-positioning-as-a-loading-mechanism" typically happened in vertical corridors (like in the video above) or where large expanses of black vertex coloring were used along the walls of dungeons between floors (during most long vertical descents -- such as the one where you get the Megaton hammer). The camera's slow movement toward a point above Link (as well as the black on the walls) act as a combined "transition" to give the lower area time to load (and the upper area time to unload after reaching a certain distance from it) -- usually by using a loading "plane" such as with the Jabu Jabu's belly situation in the video above.
In most cases, this loading "plane" was often invisible (and one-sided -- with the collision normal pointing toward the player as he fell, and often a second collision plane existed, with the normal pointing the opposite way if he was meant to be able to climb back up the same way -- which was extremely rare, as most long descents were meant to be one-way -- and the player easily "contained" within the transitional "falling" space.)

An open-world(-like) situation like ours would likely need a better trick to keep the "expansive" feel we have right now. Unlike the N64-era, a flat plane doesn't have enough fidelity to the source material these days to be convincing.

So the good news:

Imposters are not dependent upon shader-specific features -- They only use math and uv coordinates whose grid-based uv lookup result can be fed into any shader to display the final image. This lookup result can be anything, but is typically a single texture (like the ones pictured below) that consists of many angles of the object as it is rendered by the camera.
This doesn't have to be a "vanilla" render either (i.e. full color/lighting/etc.) It can consist of rendered "effects" too (i.e. normals/depth/vertcolors rendered to a single grid-based texture, as seen below, which can then be fed into any other shader's custom logic.

The only downside is that for these individual grid-based renders of different angles of the imposter to be used at different stages, these stages must be baked (or simulated) at edit time (i.e. in the Unity Editor).
It is extremely costly to do baking at the shader level at runtime, as multiple cameras/renders are typically required.


What does an "Imposter" with custom effects look like?

The below are essentially "Imposters" with custom effects (such as normal maps) ready for display in the custom shader. They don't require any special shaders themselves -- just a special texture lookup:

https://github.com/xraxra/IMP/blob/...xample/Objects/teapot/teapot_ImposterBase.png



I know they may look scary, but those textures are actually pretty straightforward:

The "ImposterBase" texture above is essentially a precalculated SDF (signed-distance-field) rendered to a texture that helps keep the image edges crisp and smooth at any depth / size from the camera. This SDF is necessary because a pixel-based depth texture would generate artifacts depending on its distance (and the edges wouldn't 'clip' properly around the alpha either).
The SDF also implies a sense of volume and depth that can be achieved cheaply and quickly at any distance, and any resolution, for the pixels that need to have relative depth calculations -- such as where an imposter boulder intersects with another imposter boulder or two -- all without needing a larger / more complex texture to simulate more accurate pixel-depth blending / etc.
Remember that these are farther away, so SDF is the best way to handle overlaps and depth without _really_ sorting a texture's depth, so depth calculations are mostly fine (but clearly can't ever be 100% accurate).
These SDFs are also used for handling multi-resolution alpha-clipping at the pixel level for custom shader effects (such as the normal map).
Fun fact: TextMeshPro uses precalulated SDFs (this same trick) to keep the text from being blurry at any distance from the camera.



https://github.com/xraxra/IMP/blob/...xample/Objects/teapot/teapot_ImposterPack.png



The above "ImposterPack" texture above is the 2D normal map used to 'light' the 2d pixels of the 3d object, and uses an SDF to act as an "alpha cutout" of the normal maps above (once the particular 'angle' is chosen).


What are imposters specifically?

Imposters are not much more than multiple cameras "rendering" one (of many) angles of an object at once, storing the result into a single (often somewhat blurry) image texture that consists of many angles laid out in a grid-based fashion across the texture. The shader math does the lookup as to which "angle" is picked to be presented to the camera.

The 'angle' is chosen based on where a ray from the camera intersects a material's UV coordinate, picking the closest 'angle' on the 0-1 texture UV to display the flattened object.
The 'angle' corresponds to a particular portion of the texture for that particular angle's image source.

Any other custom shader effects like normal maps or custom inputs (such as vertex colors), required for fancy shader effects are pulled in from a separate camera-rendered texture (also consisting of a grid-based layout of many angles) showing the color inputs as renders on the texture. In the case of vertex colors, the grid-based renders show what vertex colors would be captured by the camera at that angle (i.e. see the normal map of the teapot above). This render of vertex colors would be pre-baked in the Unity Editor and take place while vertex colors of the object are (temporarily) displayed for baking to the render texture (in the Unity Editor) for a particular camera angle, ultimately baking the vertex color _result_ into one grid-based slot of the overall texture that includes all of the original individual angles. And now a new texture also includes these angles' respective vertex colorings / normal maps / etc.) for passing on the input to the custom shader.


@cirocontinisio

The above tutorial / explanation was written specifically for you, my friend.

Hopefully it helps to clarify some of the questions you might have on the technology, as I've not found any really good explanations out there on the subject. So maybe this will rectify that a bit.
Remember, I'm a designer -- not a math whiz. However, I'm all about researching practical applications of technology for game design. So, in that at least -- I know my stuff.
So any further questions, feel free to ask!

 

I guess the math is simple enough:
You have a picture e.g. every 10 degrees both around the x-axis and than vertikal from horizontal. If e.g. the camera is looking from a 43° angle around the vertical, you take 70% of the 40 degrees picture and 30% of 50 degrees picture. This method would be called linear interpolation. As you have to do the same with the vertikal, you would in total have to blend 4 pictures.

I see 2 problems though:

• The size of the texture. In your example it is 256 times the single picture. If we are mainly concerned about loading times and memory usage it's possible it costs more than it saves.
• The calculation effort. You would have recalculate the texture frequently as the player moves - possibly every frame or every few frames. Sure that's a job for a shader - but what if there is no dedicated grafic card, like on a mobile?

 

Just to clarify once again, we're not making an open-world game. It's divided into scenes. We don't load more than one scene at a time, and we don't dynamically load/unload scenes.

I knew about the tech, the question is whether it works with our game. For that, only a proper test in the editor will give an answer.

 

@awesomedata would you be interested to showcase an application of the above in the town scene? Just to show us how it might work? Otherwise, I think that placing the Upper Part way higher to get rid of details seems like a good solution to the problem we are facing.
In other news, I was thinking about the Forest Maze a bit. I guess in general we could just implement a simple maze with 1-2 false exits and a 3rd correct one using trees as “walls” and we’re done? But I wanted to share a thought:
What if we introduced some kind of loop to mess with our players’ mind? Make the player become lost and somehow pass through the same areas over and over again, until they find a way to break that loop? But this would require messing with the player’s and the map’s relative position, and honestly I don’t know if that’s doable or even makes sense for what we are doing. That’s why I share, no intention to bring chaos.
So I was thinking...could we perhaps try something that is not exactly a “linear” navigation? Could we possibly implement a maze like the one below where the maze boundaries seem as if they have been folded around their opposite sides to form a seamless loop?

(The purple dots are to serve as “landmarks”/ visual helpers that stand out so that the players can remember if they have passed by them before).

I actually got the idea by playing Manifold Gardens recently and watching the talk the creator made about its level design and this 2d world wrapping (07:48). But that requires teleport, which in our case to achieve a seamless result...we would need to re-adjust the environment instead of the player according to their position I guess. Basically make the environment repeat itself in the correct place once the player hits one exit/entrance seam. I imagine it like below:


Given the fact that we might have a top-down view we won’t see the greater environment, so the map could reposition endlessly without colliding with anything else.
Anyway these are all just ideas, just wanted to see what you people think, or maybe I am drunk. I know it probably is out of context. Nevertheless if you feel like diving a bit deeper into this there is also this cool site that has little demos of similar concepts. You could download the TorusGames example specifically to see the above idea in action.

 

Just to clarify once again -- I'm quite aware of that. You've said it numerous times. That one was on me though, as I didn't think to realize how shell-shocked you probably had to be by the words "open" and "world" appearing side-by-side -- and you having to manage something like that. So again -- my mistake.


What I meant to imply was a dungeon (in the Zelda example) is not an "open" environment -- i.e. where you can enter any room / scene / world / unloaded-environment from any arbitrary place from above / below / wherever -- nor is it a place you could see much of the dungeon's areas far away from you. This means it is more of a "closed" environment, and therefore is not "open" enough to need an optimization of distant details.

To be fair, knowing about the tech is MUCH different than knowing how it works.

And I explained how the technology works (in detail) above - and in another thread.

I can showcase it further if necessary, but I feel like I hit all the important bits.
I know it's a lot of words, but once you understand how the tech works, then you shouldn't need to see it in the editor to know whether it is able to work with your game (i.e. on the shader level) -- instead, you should just know.

This is why I spent the time to explain it.


All that aside:

I simply *hate* the thought that there are so few tools/methods (available to regular users) that increase the size of the environments / worlds able to be handled by the Unity Editor -- especially because this problem is almost entirely due to a lack of availability of proper tooling.

What better chance to increase the knowledge (and implementations) of a technique like this that can LITERALLY increase the size of people's game worlds in a huge way than to have it included in such an open (and public) project? -- I mean, it's not going to let you make MegaCity, but it's about as good as you can get with Monobehaviour alone (at least without streaming, DOTS, and/or a hugely powerful graphics card).

Sorry for the rant -- just my two-cents.

What you are thinking of is the old way imposters were done in the 90's with sprites that always face the camera that change drastically depending on the angle you're looking at them (i.e. think Duke Nukem 3d -- or any N64 game with 2D scenery objects or sprites viewed from different angles).

This technique is much different. See below:

This is a pixel shader effect. In other words, each pixel is drawn relative to where it would be in 3d -- but this is only done for a small number of triangles (and pixel coordinates are based on explicit octahedral geometry, rather than expensive texture lookups and calculations).
The shader sources its pixels from the texture at different UV coordinates (based on depth/angles from the octahedral surface provided by the SDF -- sign distance field -- texture taken from the octahedron geometry). The pixels sort of move _with_ the camera for each triangle/pixel that is drawn. This makes the (barrel/tree/etc.) object appear to be changing perspective _with_ the camera in realtime, as it moves, essentially by using pixel-shading to 'redraw' the triangles/pixels of the image in a slightly different way as the imposter geometry angle changes relative to the camera.

This is really no different than drawing any other texture-based geo. It just needs a fairly large texture (that can be pretty blurry and with less subdivisions than the teapot above) since it is typically viewed from pretty far away.

The benefit of this technique is that the texture is loaded only once for the type of object it is (i.e. if you have 1000 rocks in your scene of the same style, you only pay 1 texture load, and just a few tris per object instance, to look amazing):







Clearly we have no HLOD tooling / technology available to us for the terrain meshes (so our world will have to be small by necessity), but at least the above technique would show some pretty amazing views from far enough away (like on top of a mountain) -- and still give the player plenty of room to move around while maintaining performance -- without a need to change scenes in a jarring way, just because you fall off the side of the town to a lower section -- or somehow manage to climb back up.

And obviously not everything would need to be drawn far away. Generally human-sized objects and below (i.e. Vendors / Bananas / Food) could be culled beyond a certain distance, even if it appears in the same scene. But things like Booths, large props such as Houses, Trees, and Rocks -- those would be great as Imposters. And turning on Texture Streaming in the Unity Editor? -- This would make things speed up (and use some of the lesser-known optimizations / features of Unity's editor).

The above, hopefully, gives some idea of that. I don't have lots of time right now, but I figured that _maybe_ my input would be valuable at least.

But maybe I'm simply overstepping my bounds a bit.
Seems like @cirocontinisio is against the idea on some level, so I won't push it any further.

 

I explained the formula how to calculate a pixel at runtime. As you can't have a different texture for every degree angle you need a smooth transition between the textures. This is what the shader has to do. It wouldn't change whatever the geometry is, including but not limited to 2D sprites.

What changes is the creation of the textures in the first place, you would have to stretch each triangle separately according to the texture coordinates (this is how the textures become blurry).

I can't see how it saves ressources compared to LOD if you want to do all of them separately, especially e.g. every single tree. Each impostor would be high effort in the first place - that only makes sense if it saves more on the other side. So it would have to be e.g. a complete row of houses or market stalls, including e.g. the trees and townspeople sprinkled between them.
I don't think we should cull townspeople when we take images - let them contribute to e.g. 2 pixels of the texture. Even if you can't e.g. recognize individual people in a football stadium you would still see the difference between a full and an empty stadium.

 

It's possible I misunderstood what you meant, but I still don't think I fully grasp what you're saying.

Though I bet the feeling is probably mutual at this point, lol.

I really hate to have to defend the performance of a technology that has been used in many AAA commercial games (including mobile), but for the sake of clarity and learning, I probably need to clarify some stuff -- For example, :

This gif shows the intersection being found on both grids, before and after unwrapping a virtual octahedral mesh. This demonstrates how finding the triangle in 3D also finds it in 2D. Notice the small white dot which is the precise camera ray to the center of each sphere. The color of the triangle at that single point is where the pixel weights (i.e. the 'stretching' bit you are probably thinking of) gets read from. This is the 'blending' factor that changes for each pixel as the camera shifts positions.

As you can see, a single (virtual) (octahedral -- half or whole sphere) UV map is laid out into a grid that doubles as a 2d (virtual) UV map. Finding the (virtual) triangle in 3d (based on the center position of the sphere/half-sphere from the camera) also finds it in 2d on the 2d (virtual octahedral) uv map. This means no further texture lookup / processing / uv stretching / etc. would be necessary for the actual texture coordinates (aside from the original texture lookup or texture reference already in memory). This means it is essentially (almost) as cheap as any other texture lookup.

The major cost is in how many different _types_ of objects you want to use imposters for at once -- but even that is typically a low cost, as long as you have many complex mesh objects far enough away to make it worthwhile (i.e. if wanting to draw a large forest -- or the rest of a town -- that is far enough away.)


To clarify a bit further -- and to bring the point home:

Processing an Imposter is somewhat akin to bump-mapping (which, again, is extremely cheap), but the difference is, in IMP, we generate a SDF texture (instead of a heightmap or depthmap) to make this multi-image parallax calculation faster (and texture-based):



The triangles themselves never move and are always facing the camera (i.e. like a sprite billboard). The difference between a sprite billboard and a true imposter is that the pixels themselves change.

Since the sprite billboard is always facing the camera, you get the (very convincing) illusion of a 3d rendered model -- but in reality, it is actually only two (real) triangles whose pixels are simply shifting based on the perspective offset towards a particular location in a texture map, which itself is based on a (virtual) octahedral uv map. Since the triangles always need to point at the camera for the pixel shader to do its magic -- nothing really happens to them:

The 'blurry' I spoke of earlier refers to the SDF (sign distance field) depth calculation and how it smoothly 'blends' between the pixels of different imposter angles depending upon the camera and its offset to the billboard. This 'blend' isn't exact (since the SDF isn't a perfect depth map) and therefore sometimes some pixels aren't even there, or some pixels 'blur' between themselves, but it is "close enough" to give a very good-looking result from far away.

Study the pine tree imposter in the videos above for an example of what I meant by 'blurring' between the imposter images, if you still don't quite understand the 'blurry' visual artifacts I was referring to.



On to your other points:

I'm not sure what you mean by "every single tree" -- You have a tree model, you generate an imposter (instead of a LOD), and all prefabs that use that tree model use the newly-generated "Imposter" for the final LOD instead.
The Imposter is simply a slightly different kind of LOD that comes with the model.

The only time you'd ever need to generate an entirely new Imposter is if you need to create an entirely new kind of tree model (as imposters handles scale/rotation and positioning automatically, since they're essentially just another LOD -- just with a fancy shader to create the illusion). If you simply change the colors of the tree or something -- that can be handled in the shader.

I get what you're going for here, but that would lead to more graphical artifacts (popping/blurring) than it would save on resources. I would suggest simply using a tiny LOD or a (VERY) low-res imposter for this purpose for the individual townspeople (if this aspect is important enough to you). This is done by other games, so it shouldn't be terrible. Still, culling would be the easiest, visually less-jarring, (and less 'expensive') option -- especially if you still think Imposters are too expensive.

While I didn't suggest using imposters like this, we do have a fairly small world (and a small need for resources), so there is nothing stopping you from doing it this way.
In fact, for our game, this might even be a great option. Imposter generation is generally a one-click operation, then a bit of tweaking to get the exact look you need at the exact distance you're wanting.
If we went this route though, for the NPCs, I would suggest letting them be clipped entirely at a distance (rather than baking them into the imposter) since they wouldn't move (and would then suddenly start moving when you approach them -- which could be very jarring).

An alternate (or parallel) way to go would be to simply make each house an imposter -- 2 triangles per house / stall, each with the same material / texture, would keep the number of unique textures / materials down. This would also allow one to use a house / stall model in unique locations that it wasn't originally intended. This wouldn't be possible without a re-bake of the imposter group using the method you described.

That said -- your method could just as easily be the better one (at least for the town).

My suggestion would be better for the large rocks/trees we use constantly to obscure and decorate things (which in themselves usually have a semi-high triangle count -- especially in large batches -- which is where Imposters + GPU instancing saves the most resources compared to LOD (which costs A LOT more in the end than we typically give it credit for).
LODs typically consist of some 3-4 (usually expensive) meshes / textures / materials (needing textures, possibly of different resolutions), and shaders (that may already be somewhat complex). Loading this into memory (all at once) and processing the LOD switching more often versus the usual 2-3 meshes Imposters require (i.e. the original high-res close-up mesh which is usually only for talking characters or FPS experiences / the reasonably distanced game-ready mesh / and finally the 2-triangle imposter version) that are infrequently swapped out (i.e. at large distances).

With that in mind, just think of how expensive each rock Ciro places is if it had the proper 3-4 LODs large models like that generally require. That's 3-4 (fairly high-poly, for the close-ups) meshes per rock mesh -- in memory -- at once -- including materials/textures/shader references. And to not look like garbage when not _too_ far away, these meshes need a reasonable triangle count (even from a distance), and may even still have a texture cost (possibly a complex one -- at least without different shaders per LOD), and swapping between them more often than you would an Imposter costs more (and more often) than two triangles and a small amount of additional work on the pixel shader to cover an entire object, with one or two (infrequent) swaps to/from an already distant Imposter version of the mesh with a low polycount / material cost.


This already infrequent LOD-swapping issue with Imposters is reduced further with Scene switching like Ciro wants -- it's just the Scene switching can be done less-often (and at less jarring points in time) with the Imposter method.

 

Indeed.... I feel misunderstood.

One problem is the distinction between runtime and the time of impostor texture creation.

I think we are in agreement that the texture is recalculated by a special shader at runtime - which is quite normal, albeit still some effort. You can only do so much of it, especially if you can't have it done on the grafic card.

You have confused me now whether the impostors should be octahedral spheres or 2 triangle billboards. Surely the impostor texture creation is simpler on billboards and will not involve inaccuracies caused by sin/cos functions.

Once someone has written the tool to do it...

 

That's fair -- There's a lot to digest here.

So, the "Imposter" textures are typically generated (that is, they are "baked") at edit time (i.e. while still in the Unity Editor) by an editor tool provided by IMP.
This tool should render all the angles to a single texture (along with their multi-image Normal Maps and SDF textures -- if I remember correctly).
These generated (baked) textures should then be used at runtime by the shader to handle heavy calculations (such as processing the geometry, normals, or vertex colors from many images / angles) to let the shader only focus on drawing the object as it normally would, with the pixel shader letting it process vert-colors/normals/etc., at various angles relative to the camera. Each pixel calculated by the pixel shader is filled into each (renderable) triangle of a 2-triangle mesh (that also always faces the camera at runtime).

Here is a (VERY poor) visual example of the steps involved:



This is extremely high-level, but the above describes the process roughly.

1. The "Imposter" texture and Mesh billboard (+ material / shader) are the major elements required at runtime.
   
   
2. An octahedral sphere (or half-sphere alternatively, if you wish less distortion from above instead) is used as a base calculation to determine where the higher-resolution "virtual" triangle/UV exists on the 2 triangle billboard texture (in conjunction with the runtime camera ray).
   This creates a sort of math-based uv "grid" projection across the whole flat/square texture, and therefore doesn't require a second set of uvs (since the triangles are all essentially equilateral / equidistant for an octahedral mesh across a 1:1 squared texture if they were properly "unwrapped" as a model in a 3d program -- and this is why I say we have a "virtual" triangle/UV coordinate).
   
   
3. The pixels from the "virtual" grid chosen to be rendered rely on the "virtual" triangle/UV selected based on the location from the virtual "center" of the virtual octahedron sphere/half-sphere before being unwrapped. This "spherical" point is actually found by pointing the camera to the center of the billboard (and always having the billboard facing the camera).
   The virtual 3d "uv" coordinates needed for the currently-rendering pixel can be generated by knowing where the flat portions of the main camera, billboard, and "virtual" octahedron sphere/half-sphere would mathematically line up on the texture, using the SDF to determine how close/far the pixel would be from the center of the sphere, letting us pick the correct angle for the pixel (i.e. image 1-8 in the texture would be picked for each pixel based on which virtual triangle the camera ray intersects with on the 2d billboard).
   
   
4. All pixels, ultimately, get rendered depending on the virtual triangle chosen by the math calculation, resulting in a (less than perfect -- but still very usable) result that faithfully represents the multi-image texture based on the camera's actual positioning -- in realtime.

One thing to note:

The "virtual" triangles that are virtually "unwrapped" (the octahedral / spherical / half-spherical ones) are not geometry or actual UVs. These are nothing more than a flat 2d mathematical representation of the sphere's equally-sized "triangles" as a grid that is virtually overlaid while calculating the current "triangle" to know where to grab the pixel to render for the correct angle. To let the shader know how to do this, the number of subdivisions (horz and vert) are passed into the shader manually to tell it how many triangles (or more understandably, how many angles/subdivisions) the procedural "sphere" should have across each axis. This knowledge allows the shader to virtually 'rotate' the sphere to a particular angle -- depending upon how the camera angle glances the surface of the 3d billboarded mesh.

I haven't tested this, but this should already be done:

https://github.com/xraxra/IMP/tree/master/Assets/Plugins/IMP/Editor


That Editor tool should contain the essence of the kind of tool we need to generate the imposters in the Unity Editor.

(Hopefully that should do it).

 

Hello fellow wizards, hope you are all doing great.
I wanted to share with you what I have been working on lately regarding the Forest Maze, to hear your thoughts. After @Smurjo 's and @cirocontinisio 's forest experiments, I tried to combine both approaches (3d person and top-down view) into my proposal that resulted in 2 levels: the first one (based on Smurjo’s design) being a transitional area between the town and the actual forest maze to get a nice overview of the whole forest in 3rd person view, and then the Forest Maze in top-down view as the main puzzle gameplay. There is also a bonus level regarding this 2nd top-down part, that could be optionally activated regarding some thoughts I had in a previous post that I wanted to try out. I know this was totally unnecessary, but it was an interesting study for me and I wanted to share the results nonetheless. I explain everything in the following video:

For the quick readers, here are some gifs-shots from the main part of the level that regard the reveal and interaction with the Key Character that stands in the heart of the maze, the Desserter.



I tried to have as much of the community’s contributions in mind as possible when designing this, leaving space for example for all the bridges and the tree trunk discussions/camera movements that I’ve seen taking place here that could be of use.
In retrospection, I only wanted to tinker a bit with that “infinite forest” idea and didn’t really expect to come down to this. I might say that this is also a first try to indulge myself a bit with the environment art apart from a rough level whiteboxing. Honestly, I didn’t expect it to be this hard. I was expecting to just lay out some trees and “we’re done”. Oh boy I admit that this whole approach seems over-designed though. A forest should definitely feel more organic and random. But at the same time, there are so many aspects to be considered and to actually produce a maze kind of feel (which I am not sure I achieved) some things I think need to be more carefully planned which comes in total contradiction to the randomness. So how can one achieve this? I mean, how can you bring sense out of randomness? *entering existential crisis in 3...2…* Nah, I am good.

Anyway, here is your Monday break of a person raving about a forest for 7 minutes and a half. In case you had nothing better to do (A PR might as well come soon, after finishing some house-keeping).

 

I'm sorry I disappeared, but I haven't forgotten about you all Everything that I'm seeing looks great, and the insights about how the level was put together are very interesting and helpful. Just a couple of things:

A lot of magic tricks are build on the fact that the human brain gives up its search for a pattern, which can happen when:
1) the pattern is especially hard to recognize, but especially
2) the object in question is supposed to hot have any pattern
(For example, if you pull out a deck of cards which looks like it has already been used, people will suppose the cards are shuffled: so, unless you explicitly tell them, they will fail to notice that they are, for example, alternating in color)
Now, a real forest is supposed to be random and organic; so if the players feel like they are in a forest, we're one step done - at least I think. One example, Wayward Cave from Pokémon Platinum:



This doesn't look very random seen like this. But when you are inside, and you look at it like THIS:



1) Your view is restricted to a very small area, and 2) textures and rocks (and music) makes you feels like you're in a cave (...kind of) and immediately pattern recognition becomes harder.

Hope that this makes sense. What I'm saying is that if something is somewhere between tidy and completely random, people see the randomness more than they see the tidyness.

Apart from this, one of the risks of a forest maze is that it easily leads to unbeliavable barriers, or barriers that don't look like they are barriers. I think I already shared this article before on the forum, but I'm kind of obsessed with these things.

Anyway, as soon as I finish my exams I will be able to get back on track in here (and maybe this time give some real contributions)

 

This is only true when the environment is mostly 'tidy' to begin with.


It's like that one stray hair that just seems to poke out at every angle -- no matter which way you turn your head.
Everybody sees it. You can't forget about it either. Especially if your hair is otherwise tidy.

That is -- until it becomes "the norm" -- then everybody decides it's an everyday part of who you are, and it becomes a pattern, so now everybody ignores it and it blends into the background.


The more 'clean' and 'easy-to-read' something is, the more 'random' sticks out. In contrast, if the environment is mostly 'random' or 'messy' to begin with, the more 'clean' and 'tidy' stand out.
The trick is to establish a visual "norm" -- and only break that pattern in a way that is proportional to how much you want something to stand out.

This is called dissonance.

You put a triangle where there are lots of circles -- and your brain picks up on it FAST.
If you put an oval there instead -- you might miss it entirely.
The principle is the same for chaos and order, light and dark, or really anything else that can be contrasted.

 

Thanks for the replies! I have opened a PR (https://github.com/UnityTechnologies/open-project-1/pull/435) where i submit the following scenes:

• A TransitionArea scene (3rd person view) as a link between the town and the actual ForestMaze giving an overview of it based on Smurjo’s design.
  

• A FiniteForest scene (top-down view)
• An InfiniteForest scene (top-down view)

Both Finite and Infinite forest scenes share a common area that consists of some same specific Tiles, the purpose of which is:
1. To provide a common ground for a scene change that could perhaps become unnoticed between the two scenes.
2. To have the tiles constantly rearranged seamlessly around the player on the Infinite scene to produce an infinite result. This Infinite scene has no skybox and is only meant to be experienced temporarily until the player reaches their goal. Once the goal is reached, I guess a switch back to the FiniteForest scene would be necessary to show the background, skybox, cinematics etc.

The scenes have included the recent tree scale update that actually solved some of my past concerns. Actually, I’ve scaled the trees at an even bigger size as a lot of times the view was very obscured. It currently looks like that:


After that scale change, I felt there was no need to use a linear arrangement of trees as maze “walls” anymore. Some trunks were so big they are an obstacle on their own, and the leaves occasionally obscuring the player’s vision I think are ok for what we might want to achieve here regarding the “how much structure vs organic-ness do we want for a forest to function as a maze” concern.

So now the things that are still concerning me are:
1. What happens at the borders?
What seemed to work better is to just have more forest that is not traversable. If we were to put a clear end like the sea, the player would then easily navigate around and the maze feeling would seriously deteriorate as I feel happens in the FiniteForest scene. Hopefully the Infinite one does provide some solution to that.
2. How do we present the Key Character to the players but still prevent them from reaching her?
The goal -I think- should be pretty straightforward to see but a bit challenging to find the way in. Plus I think we should also aim for some kind of special entrance/preparation as a reward. Currently I’ve surrounded her with non-traversable vegetation and I know it’s not a good solution. The use of water is also a bit…”flex-y”?
3. Top-down view vs overview
The current top-down scenes do not function well in an overview (should we want one) due to the current tree size. So for the TransitionArea a “fake” forest with a lower tree size was used for the skybox.

I’ll end my forest journal somewhere here. Of course take whatever you want from this try, this was more of a study for me that hopefully might bring sth to the table.
PS1: I have not submited the LocationSOs in the PR. Should you require them I could add them in a new commit.
PS2: Apologies for my long posts, but there are simply a lot of things that would normally become long discussions to fit in just one post. Cheers.

 

Thanks @itsLevi0sa, great work as always! I have merged the scenes into the

main

branch.

I have to say, the infinite level feels a bit confusing. I know it's the point (it's a maze, right?) but it shouldn't be unpleasant for the player. I need to think about it.

The other thing I wanted to mention is that I feel like with these "whiteboxing" levels we could go more whiteboxey Right now they feel very final, and as such it's really hard to tweak them. So next thing for me on my list is to whitebox again the whole game, following the existing scenes of course, and make a playable version of that (i.e. connect all the entry/exits, and also to the main menu, etc.) so we can test the whole environment in one.
But in any case, I will use your scenes (and Smurjo's) for learning.

Stay tuned!

 

Thank you for the feedback and the quick reply!

Sure thing, I did get carried away with the environment art which the whitebox shouldn't be concerned about. I tried to group all those extras separately (on each tile sadly, not on the level as a whole) but hopefully deleting/disabling them could bring everything back to a rougher layout for you to work on.

I hear that. To be honest, this idea was out of context from the start anyways. The only way I can think of to justify an approach like that would be to...explicitly aim for that unpleasant feeling perhaps. Meaning, if the player ate "something" that produced an unpleasant effect, like a poison one (thinking of a poison icon appearing ie. on top left/right fading in and out to show the effect taking place for some brief period of time, or some vignette, or occasional blurriness/camera shake, you know, something extra to accompany this -out of place- concept.) But still, not the direction we are heading to. I think the solution lies somewhere in the middle: a view-only finite forest surrounded by sea for an overview (should we want it) and another finite one for the actual gameplay without "clear" boundaries where the player will only get to see more forest everywhere. But that's about it from my side.

Of course, in the end this has to be done by you, the team, we know our proposals are mainly meant as a foundation for you to work on. Hopefully we helped. We still haven't showed the mountain some love.

 

What is required to be done to improve upon the maze?

 

Hey @aby_gamemaker . My issue is that the maze is not really a maze in this proposal and the only thing that resembles a “puzzle” is how to reach the Key Character which is basically done by finding an opening inside a cliff, pretty easy stuff. Perhaps the environment art gives away too many points of reference so making everything appear more similar would aid the feeling of being lost as Ciro has pointed out before:

If you’d like to step in, you could open the project (on main) and you’ll find the forest proposal in Assets>Scenes>Whiteboxing>Forest>Proposal_3>Scene_FiniteForest
You’ll see that the level consists of several tiles (ignore their namings). I’d encourage you to try play around with the tiles by arranging them differently and make your own tweaks of course and see what you can come up with. Hope this helped! For more details on the problems we've run into you can also see the previous posts.

 

I've been working on a "semi-final" whitebox of the whole island, to get the sense of scale (again) and if things work together. We recently worked on the town and forest (thx @itsLevi0sa) but we left beach, glade, etc. a bit behind.
In fact, the two ok-ish scenes we have in the Locations folder are based on the initial whiteboxing, which we deemed too big (remember? ), so I set out to remake them on the basis of @Smurjo's second attempt, the one which is mid-sized.
So, I took all the scenes produced so far and I mashed them together (somehow) trying to stay as faithful as possible to the existing designs.
Here you can see Smurjo's mid-sized Beach, Glade, her Farmlands, then itsLevi0sa's Town v3, the original Smurjo forest, and I think I forgot the rocky path




What I got to so far is this:



Basically, at this stage I want to finalise what I call the "landmasses", that is the patches of "terrain" (they're just meshes) that the different locations are standing on. They need to be kind of level, they need to connect, and they need to touch what I labelled the "seafloor", which is going to be an empty plane lightmapped at an abysmally small resolution, just to get the same colour as the landmasses.

Second thing I'm doing is I'm defining view-blocking structures with the rocks, to know where one location ends and the other starts. This helps me understand how many scenes we need and how are they connected (i.e. where the entry points and exit points are).

The next step is to break this mega map into the actual locations, which will in time become the effective scenes in the build. I will take care of this.

Regardless, I invite you to try this mega map, walk around, and tell me how it feels here in this thread. You'll find it in main, it's called WhiteboxingMaster_v1.

--

Note on the Forest area: the amount of plants and its layout is not really representative of the final forest area. In the interes of simplification, this is more or less "the mass of trees" you'd see from afar, but when the player is in it there will be many more plants.

Note on the Path area: this is a big draft. I just tried to create some vertical progression, but we will make the layout more intricate when detailing it.

 

I tried it, being all white and simple definitely helped to take a “step back” and re-evaluate what we have. I feel the scale and scene connections are just about right for the gameplay that is aimed for. And I think it’s coming together nicely now! Hope other people feel that way too. I would add the following notes:


Just like we have the Farmlands as a moment of “pause” and transition between the glade and the town, I still think we’d need something similar between the town and the forest (at a way smaller scale of course), as currently I think it’s appearing right “in your face” when you exit the town without taking the time needed to go from one “mood” to the other. I’d also put some extra rocks on the back side of the mountain, so that it doesn’t end up so steep, I think it feels a bit unnatural. But this might only be needed if we are to have a cinematic of a whole island overview I guess, no point to add them if we are not going to see them.
Nevertheless I think it looks promising in all its simplicity, and also the skybox just adds so much to the experience. The islands in the distance, and the sky that seems to come straight out of a Miyazaki's film, hopefully the players will be tempted to take some screenshots

 

Some extra notes on the individual scenes as a separate post (since they do not really regard the general whitebox take):
Note on the Forest: After a lot of thoughts on the “maze” aspect between structure vs organicness, similarity vs diversity, top-down view vs 3rd person view that resulted in scenes that are (again, I know) a bit too big, I think @Smurjo ’s forest was great from start in terms of exploration possibilities which I personally favor on each case over anything else. I think if we stay at 3rd person view and add the Key Character to be hidden at the end of it for the player to find, it could be enough for what we want to achieve. Perhaps like this:


Note on the Rocky Path: Right now, it seems we have one connection to the Rocky Path coming from the main square meaning that the Rocky Path will probably have a circular form, taking you from a lower to a higher level and then back down (option 1 in the image below). I am wondering if we are going to witness the “back down” part at all, and whether we are going to have a 2 way option enabled (doing this circular path clockwise or counterclockwise).


If we don’t want them to experience the “back down” part by providing a scene exit, wouldn't it make sense if the scene exit would lead them to the Upper Town part (option 2) since it is at a higher level? This would also give the Upper Town a more connecting/important role other than just offering a nice view.
But that also raises a new question: What if the player decides to go to the Upper Town part first, and enter the rocky path from there? They will experience the same level in reverse, from upper level to lower level where the entrance from the main square would then serve as exit (option 3). Similar to the clockwise-counterclockwise experience of option 1. Just raising this as a concern, since for the Rocky Path we know from the story that we need to find a Golden Egg, so we need to make it clear in all takes (lower - to upper-to lower(1), lower to upper(2), upper to lower(3)) where the Egg is and how the player might get there.

 

That's a good idea, it also goes pretty well with the intention to create some more or less interesting gameplay, but also easy to test and demo (given this is first and foremost an educational piece). This way once you know where the character is, it's easy to just head straight there and talk to them.

Good question. Maybe from the rock path they could just drop "into" the upper town, so there would be no way to do the opposite (they would have to climb or fly). I'll think about it.

Thanks for the suggestions, as always very well thought!

 

Thank you.

Yeah, I know this is the plan in the first place - stay simple and show the game, no need to go “over the top” with the levels or anything!

Since we have an Egg to find, it’s easier to look down (and go from higher to lower level) to trace it than up (considering the height of the rocks and how the camera behaves when looking up or down). So maybe we could consider the opposite? The player can only enter the Rocky Path from the Upper Town and exit in the main square but at a certain height, so that they can jump down but won’t be able to reach it once they are at the square.

Regarding the educational aspect of this project, after the forest top-down try, I found it intriguing how an experience of a single game (both in design and in playing) could be so different depending on how the game is framed. Since this is sth you are already showcasing with the cinematics, I was thinking of trying to design sth for the Path with some more camera changes in mind too - conceptually, regardless of whether they are going to happen or not - worst case scenario we have a level and we stay in 3rd person centered view. I know decisions like these are to be made by you - I do not wish to step on your toes - however since whiteboxing does concern the gameplay a lot I like to imagine some concepts when designing.

 

------------ Long Post ahead (really sorry) --------------------
I was thinking about whiteboxing the Rocky Path. Wanted to share my thoughts through some rough initial ideas - and hear yours if you’d like to shape this together.
Overall Goal: I was thinking of making a path from a higher to a lower level accessing it from the Upper Town part. Our goal is to find a Golden Egg and manage to pass through all the Rock Critters to get it. The whole gameplay should probably last around...4 minutes?
Let’s start with our goal - the Egg: It needs to stand out. Gold is shiny. Perhaps our Egg could glow a bit to replicate that shine and be some shade of yellow (right @Smurjo ?) But if it’s in the open in broad daylight it won’t really stand out. Would be better if it was in a darker place. -> Decision 1: We’ll need to enter a cave to find it.
Issue 1: Should then the whole RockyPath be inside a big cave?
My answer: I think the Cave could become our first subgoal, splitting the Rocky Path in 2 parts(2 scenes?) and give a sense of achievement when you enter it.

1st part: Starting from the outside
What I’d like to achieve in this initial phase is:

• Design a narrow path, ascending at start, along big rocks (point (1) in image above) that will pass over a void (showing the sea level) so that the player realizes the height they are at and feel a bit claustrophobic/acrophobic (2). Would also help if the path has a turn to not know what might lie around the corner and stay alert, while also put the player at the edge of a cliff to feel even more tiny and fearless in this vast setting (3).
• Entering the cave (second Scene?): The path leads to an opening between some rocks. I imagine the entrance more like a big hole in the ground (4) rather than an entrance ahead, mainly cause I’d like him to “jump in the unknown” - like a leap of faith, instead of normally walking into another setting. When we then load the cave scene our player could even start mid-air so we get to see him falling.

2nd part: Inside the cave


1: The player lands in the cave. I imagine a fixed camera here (looking at the player) almost ground level looking up to show where our character came from and make him seem more grand in that angle. I kinda liked the skybox appearing through the hole as the only spot that sheds some light in the scene, makes a nice contrast (wouldn’t achieve that view with the normal gameplay camera)
2: We could then transition(?) -very briefly- in a platformer/2.5d kinda style to familiarize with the process of jumping rocks down and combat/avoid rock critters.
3: Main cave could be experienced with Hamlet at ⅓ of the screen so the rest ⅔ will put the focus to our goal (Egg) and the spiraling path to get there. At the bottom of it we could find the exit leading to the Town square.

Here’s a video of some good camera changes example from another game as a reference for the above -> Nier Automata:

Again, these are just concepts I like to think of. I don't have the knowledge to play around with the cameras and I don't want to take the focus away from what actually needs to be done.

Are all these too much? Thank you for your time, any feedback welcome!

 

So I made the golden egg. It isn't entirely golden, but the other rock critter egg material with gold veins. I also made the gold veins glow in the dark.

We might need to think about the size we want the eggs - we want them neither to easy nor too difficult to spot. We would want to experiment with the camera here - which btw seems challenging to me to handle in the cave.

 

Can we do a boss monster protecting the egg in the cave? If we can't model from scratch we could just make a different coloured rock critter whose huge in size and attacks by throwing rocks at us.

 

Like the veins idea, looks cool! Heh, didn't realize their size, Rock Critters are already tiny so from further away it will definitely be hard to spot one such egg...Should probably have a nest with multiple ones and a pointlight? Wondering if the veins idea could be applied to an alternative Rock Critter material too, to have a specific rock critter stand out indeed as @aby_gamemaker says to be easier to spot. Also wondering too if it could be bigger, (perhaps stronger? They are already pretty tough) to give that idea of a "boss". I've run a small test, and actually looks a bit fun to me. We could have a little "wait for it...." moment for that

The size is tripled+, of course its exaggerated (we're not making Little Nightmares), but a bigger size could actually become a moving obstacle to step on and reach something else like below.

Hm. Interesting?

 

This is awesome @itsLevi0sa
Now we can use his stomping to maybe attack hamlet by dropping stalactites from above. We would need markers on ground to warn hamlet where will the stalactites fall.

As for the golden streams on the boss we could colour him eggplant violet to accentuate the gold streams formed on him.

 

These are all cool ideas. I really like the cave structure you have in mind, and the path to get to it.
I'm trying to think of how can we do it in reasonable times, in my mind we have locked the scenes and the layout but it shouldn't be too hard to rethink that section of the map (I've left it undone intentionally, given the discussion going on in here).

Taking from the current map, what about something like this:



The path is to the right. To the left you would already see a tall rock and on top of it an entrance to the cave, but you wouldn't be able to reach it. So you go right along the path.
I really like the idea of walking high above the sea level, we need to place a lot of rocks but it might be worth it The light will also create a lot of interesting spots, I believe.

This would be a scene that is ascending, going all the way around the actual cave, in a series of higher and higher rock steps (and some ground). Once at the top, you "turn left" and you're on top of the cave, where you see this mysterious dark hole. You jump in, and the actual interior Cave scene loads (not pictured in the above image).

The Cave would be as described by @itsLevi0sa, so you land in the centre at the bottom, and you need to make your way up a series of rocks (with Rock critters everywhere) to get to the egg. Once done, going back to the bottom of the cave (where you land) leads you to a side exit. Once you take this exit, the Rocky Path scene loads again, and you are on top of a rock and you can jump down, going to the beginning of the path where you started, and where you can easily go back to town.

I'd like to avoid jumping from Town Upper to the cave, since there we have one of the famous "Prefab walls", which block the view and allow us not to have detailed rocks just beyond them. So from Town Upper you would see very little of the Mountain / Path in general.

In terms of gameplay, I like the idea of using a bigger Rock Critter as a step, but I wouldn't go above 2x or they look out of scale. So I guess, can we make it a precise jump? Otherwise, we can just do normal jumps and the critters would just be an extra obstacle.
By the way we made it so the Rock Critters never die, when they are hit enough times they are just stunned, and they recover a few seconds later. We thought it was a fun and simple enough idea to execute to make it stand out from the Slime critter.

Thoughts?

 

This week I'll be working on setting up the base for the changes mentioned in the previous post, i.e. breaking the scene "Mountain" into two (Mountain_Path and Mountain_Cave), will post here when I'm done!

 

Did the "far off" prefabs for the path around the mountain



Unsurprisingly, we have very few structures and models to use in this dangerous path, I am planning of using mostly the simple bridge and just rocks (obviously setup in a much more interesting way for the detailed version).

 

Hello, there has been quite some nice work done by you all, really eager to see the 1.0 version!
I am sharing the point I reached on my work on the path, before I submit a PR (currently tidying up a little but will post soon). @cirocontinisio I saw and agree with the path leading to the mountain, have been trying to include the changes but totally don’t mind if you want to continue with the path you made Below I am sharing some stuff on the Cave scene:
I had 2 more parameters in consideration:

1. If the only light we have is from the initial hole you come into, we are going to have a really dark scene as we progress. Right? So either: We make little holes along to let more light shine through or...I thought of using the emission of the rock critters eyes as a potential light source. Bit of environmental storytelling I guess, but I thought of having some critters stuck on the rocks as if sleeping so if you pass by or hear you coming they would open their emissive eyes and shed some light in the scene (with point lights).
2. A user (@randomscribe ) made some really cool Pressure Plates. I thought of using them as some unstable platforms that will collapse as soon as you walk on them.

This is what I got (lights are not baked though on the examples below):

1. You land inside the cave (Point A).
2. You familiarize yourself very quickly with combat - jumping on a big critter(2x times the original size) to reach a higher platform - recognize unstable platforms that will fall if you jump on them (Point B).
   

This part I had it in my mind as 2.5d. I know its not gonna happen so I also made a working 3rd person view:


3. Below, reaching the main objective using the same steps as before(Point C, 2nd gif is the continuation of the 1st):




4. The exit part - going back to town:


I mainly experimented with some mini disruptive events along the way. I find it a bit hard to draw the line of where the whitebox ends and irrelevant stuff start. Everything is grouped though, so if we don’t want the rock critter effects-decor at all we can totally delete them quickly, and even skip the Point B part if it’s too much. Whatever it takes to make it on time!
Question for the PR: Should I submit the external-internal path as one scene? They are currently in one scene, but grouped into two separate groups so it should be easy for you to make a new scene out of each of them.
PS: I don’t see any reason to walk all the way up to this cave hole. I think if we change scenes we could already be half-way and just climb our way up just for some secs to enjoy the view before going into action. So I’ll only submit the last part designed and you can keep whatever suits you of course.

 

Glow in the dark vines and bioluminescent mushrooms inside the cave could be one way to provide light.

 

These are all cool ideas
However, I'm really keen to wrapping up the project, so we will need to cut new functionality. I like the idea of the critters used as lights, not sure how practical it is but we can make a test.

In general, what we need now is to move forward with final locations. So if you can submit your whiteboxed one when you're done it would be great. I'll evaluate how much we can do. My worry is that the cave right now looks enormous, but we only have 4 types of rock. And they can't be scaled huge, I usually go up to 5x or maximum 7x when they are close. So for each mega-rock you have, we'll need to manually place a lot of them. (and by the way, if you are keen to do it I'd be super happy)
Stalactites/stalagmites, we also don't have them unfortunately, I've just done a quick test using Rock4 and it doesn't look that good.

As for the pressure plates, the floating platform look a bit weird. Why there's floating stones in the cave?

So, as an action plan. I've pushed the two new scenes as mentioned above, Path and Cave. You can find them on main, for reference. You can push the whiteboxed changes in one or in two scenes, I'm not against using some of your Path work if it's easy to implement (you always have fun ideas ), I am just wary of time.

 

I tried to shrink it a bit. In the main cave it takes our character literally 4-5 jumps to reach the objective. Didn't think it was too much, still...feel free to chop off whatever is not necessary! I replaced the mega-rocks with the rocks we have, not exceeding the forementioned scales. I decided to submit a PR with just the cave scene and not the path so you can take a quick look. It was done in a bit of a hurry since I won't be able to work on it this weekend and wanted to have an opinion on what we have so I could work on it further (?). So apologies if anything is messy, also there are no Lightmaps currently so expect weird colored rocks. I based the scene on the Mountain_Path one, I know some things will need to be repositioned or even discarded. I have everything in groups though, so hopefully it won't be a pain. I think the biggest challenge is the smooth camera movement..And also what will happen if we fall down before reaching the egg? Respawn?Maybe we should place rocks to climb back up. Anyway.
Link to the PR: https://github.com/UnityTechnologies/open-project-1/pull/475
Cheers!

 

Hello, I want to ask a question. If I change the Layer of the Beach (or any other) landmass to something else other than Default, such as ground or any new layer, it just disappears from the scene. Is that right? And how to you manage things from layers, such as OccludingObjects and OccludingTransparent?

Thanks

 

Is it a new layer? It's probably because of the RendererData, which renders specific layers in different passes... and maybe doesn't include new layers by default. (check Assets/Settings/Graphics/ToonRendererData)

What do you need a new layer for?

 

This is a new thing for me. Thanks.

Really I want to implement some debug functionality where the player can walk (or run) through all the obstacles, such as rocks, trees, NPCs, and enemies don't attack on it. I have implemented it, and it's ready. Just I saw that ground is not on the ground layer but on default layer, resulting in falling of poor Hamlet. And if I changed the layer of land, it mysteriously disappeared. I will push it to my Debug-system PR, when I will fix this layer thing.

Thanks.