Jump to content
  • Advertisement

Unity Weekly Updates #35 - Can You See Me?



Well hello there! And welcome to this new installment of your favourite Weekly Update blog!

I won't lie: this week wasn't as productive as I wanted.

Although I was able to still add some new things in the game taking care of my niece and nephew took most of my time (especially earlier this week).

Nevertheless, there's still new stuff to talk about, so let's get right to it.

New gun animations

First thing first, let's talk about the gun.

For those who didn't know there's a gun in the game. With it, the player can have a ranged weapon that doesn't need to charge to the expends of having limited ammo compared to the bow.

Previously the gun was completely static: it didn't move at all.

Now there are new animations for it.

When the player reloads the gun you can now see the actual reloading.

Here's a video of it:


Another big thing is that now the game occludes obstructed rooms.

Previously when the player clears a room the next one is activated and fully rendered. It was fine at the beginning of the level, as there were only a few geometries to render. 

However, as the player advanced the number of geometries got progressively bigger and bigger, to the point where the framerates were taking a noticeable hit.

Unity themselves recommends to keep the vertices count below 200k, but with all the geometries rendered at once (even for a low poly game) I actually was well above 200k. This meant FPS that got below 25 (yikes!).

Of course, it was unacceptable. The game needed to be able to hide unseen geometries. Here comes our hero: Occlusion Culling. 

The idea is quite simple really: hide geometries that are occluded by others.

Unity actually got their own Occlusion system, however, to function properly it requires baking. Needless to say that for a procedurally generated roguelite baking was out of the question. In order to fix this, I needed to implement my own occlusion algorithm (or at least integrate one).

Enters portals.


I've may or may not mentioned this before but I used to makeTF2 maps in my spare time. It was fun and all. 

The Source engine can look quite archaic on the surface, but there's a lot of interesting technologies here too.


One of them was the use of Area Portal. These were specially marked brush that indicates some type of opening (a window, door. hole and whatnot).


The idea is that when the player is inside a completely closed area it skips rendering any other area. This is effectively some kind of occlusion by itself.

This applies to properly closed areas. If the area isn't properly closed (AKA there's a leak) then that functionality is not applied, meaning that everything will be rendered at once.

In some area (like a house for example) there are actual openings like doors and windows. On the surface, you might think that once in the house the engine got to render everything as it isn't a sealed space. But we can do better...

This is where the area portal brush gets quite useful. With it, the mapper can tell the game that this whole is a portal to the outside. Once this is said the engine can now shut it close and open at will.

Once closed, every geometry outside the sealed area will be skipped. If it's open then the engine will only show the geometries in the direct line of sight of the camera.

This is quite useful. By doing this we can hide unseen geometries and save ourselves some frames.



Because I already knew about Area Portals I knew that this was the way to go with the game as well.

The Algorithm

To be frank, I didn't come up with the implementation myself, but I did get the main gist of it.

(To illustrate this I'm taking a top-down view but you'll get the idea)

The idea with portals is that each portal describes a connection between two areas. 


If the camera is in a given area then we check each of its linked portals and do a bit of testing.


Fist, we need to find the actual visible part of that portal. To do this we simply need to protect the camera's frustum onto them (essentially taking a slice of the viewing pyramid)


If the camera is in full view of the portal then its B area is activated.

We then recursively test the other visible areas by getting each point of the projected camera frustum and creating another frustum from which we basically do the exact thing until there are no more visible portals.


And voilà! All our visible rooms are rendered!


In essence, we're basically checking whenever or not two portals overlap each other. If it is them we render the connected room.

With this, depending on the level I can get the vertice count below 100k. This effectively means glorious 60 FPS!

The whole algorithm is actually based on Id Sofware's DOOM 3 code (idWinding). The only thing is that it translated for Unity. 

Here's where I've got the code from.

I won't lie though: there's still a bit of bug here and there but nothing that a nice debugging session can't solve...

I would show you this but, well, it's occluded...

Minor changes

  • Added a grass density calculation.
    • Previously every room got a set amount of grass strains.
      • This meant that small grass patches were densely populated with strains
      • This wasn't really good on the CPU and on the aesthetics
    • To remedy this I've simply added a density function that calculates the number of strains a room need based on the amount of grass square it got.
  • Added even more LOD models (I'm on a roll bae)
  • Changed the appearance of liquids
    • Now the liquid floor looks a lot deeper.
    • There are also new SFX playing when a collectable items fall in a liquid floor.
    • Changed steps SFX so it sounds like the player is swimming through it rather than walking on it shallow depts. 
  • Fixed bugs with the ammo counter not being displayed when picking up a gun.
  • Fixed a bug with gun reserves not getting loaded in the gun properly.
  • Remodelled the mall models to patch up any holes in the geometry.

Next Week

Next week is probably going to be me finishing up LODs and whatnot. I also need to fix bugs with the occlusion algorithm.

Other than that I really want to touch-up enemies. Probably add another one or changing that behaviour tree altogether...

Otherwise, it's the usual suspect if I have time.

I'm trying as much as I can to get that demo up, although for some it might be too early yet (It's only been technically like about 7 months in development so yeah)


Recommended Comments


Posted (edited)

Hammer was a great tool.  It was the first program I learned that allowed users to create game content.  Great memories.  When I uploaded my map in 2006 it got 4 downloads haha, and it had models made in milkshape ( where I drew inspiration for z-model ).

Edited by Awoken

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • What is your GameDev Story?

    In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

    (You must login to your GameDev.net account.)

  • Blog Entries

  • Similar Content

    • By Rof
      Hello guys! I am new to Unity3D and also new with C#. I am currently working on a 2D Platformer game. This would be my first game ever. I really need some help in coding and animation. I was able to create script already for my Player Movement. I already have the basics coded and working (Walking, Jumping, Attack, Dash). I also have an extra feature which allows the player to jump longer if he/she presses Space for a longer period of time.

      I just need help in fixing the Jump + Attack. Whenever the player Jumps and Attacks at the same time, the character will ignore the x velocity of the object and will only continue the x velocity after the attack animation.

      I'll really appreciate any help that you can give me 
      Have a great day!
    • By TreektusPL
      Hi everyone!
      I'd like to introduce you to my android game.
      Sphere Control is a simple adventure and recreation game. In the game, we move the ball. The game has currently completed 10 levels. Each level differs from the previous one and introduces new elements to the game, eg a new trap, obstacle, mechanism. Our task is to get all the crystals at a given level. We will be hindered by various traps, obstacles such as moving objects and tasks that we must solve earlier. The game is in a low-poly style.
      The game is now available on Google Play: play.google.com/Sphere-Control
      Website: worthout.com
      FB: facebook.com/Worthout

    • By snacktime
      Looking for feedback from someone who has done this, mainly just to confirm that my guestimates are not way off.  I know enough to be dangerous not my area of expertise.
      Trying to budget for a custom 3D skeletal animation system with cross fading and 2 layer blending.  Context is Unity.
      My thought is someone who has done it before could probably get the core features working in some form in a month.  But by the time you factor in everything like bugs, performance refactors, platform specific gotcha's, whatever, it's probably around a 6 month job to get something actually usable in game.
      Does that sound reasonable?
    • By Data7 Games
      Roles Required: Experienced Animator/Rigger
      My Role: Creative Director, Game Designer & Writer
      My Previous Projects: 2 small mobile games

      Team Size: 6 At The Moment (including me)
      Project Length: Estimated to be completed sometime in 2020/2021

      Project Description: Rift One is a half-life inspired FPS game, you play as mark maxin, a police detective who is mysteriously kidnapped by a secret organisation! They want you to enter a portal, to another world, or they will kill you if you don’t, but before you can, the lab is invaded! And you are forced to enter, in order to survive the crumbling lab.

      - Create Animations as told by Project leads.
      - Polish Animations as told.
      - Working closely with other team members.

      - At least a tiny bit of experience in game development
      - Ability to solve problems creatively and effectively
      - knowledge of Animation/Rigging, the unity engine & FPS Games such as Doom, half life etc.
      - Ability to Create Animation and rig
      - Strong communication required
      this is currently **A KICKSTARTER PROJECT** Meaning you won’t be paid until we are funded!
      we are currently planning and researching for our kickstarter.
      Email me at Data7games@gmail.com if interested
    • By RoKabium Games
      Which one of the 4 menus in SAMA is your favourite? 1, 2, 3 or 4?

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!