It's been almost 2 years since you did this. My question is: how much could you improve the rendering with your knowledge today?Indeed, both WebGL and myself have improved since I initially did the Quake 3 demo, so it's interesting to look back and see what could be done better today given more expertise with WebGL and the evolution of the API.
Saturday, June 30, 2012
WebGL Quake 3: 2 years later
Got a great question in the comments on my Quake 3 Tech Talk post today from Daniel P.
Thursday, June 28, 2012
Building the Game: Part 6 - Isosurface Landscapes
See the code for this post, or all posts in this series.
See the live editor demo.
Well, it's been a long time coming, but I'm finally back with another official installment in the Building the Game Series! As mentioned previously I'm want to take the series in a different direction now, and as such this post represents a bit of backtracking from the previous one but I'm hoping that it will be a more productive direction in the end.
See the live editor demo.
Well, it's been a long time coming, but I'm finally back with another official installment in the Building the Game Series! As mentioned previously I'm want to take the series in a different direction now, and as such this post represents a bit of backtracking from the previous one but I'm hoping that it will be a more productive direction in the end.
Wednesday, June 13, 2012
Building the Game: Part 5.5 - Two steps forward, one step back
So this isn't really one of the "main" posts in the Building the Game series, but I feel it's important to bridge the gap between the last post and the upcoming one, since there's been a significant gap between them and the project's direction is going to change in some important ways. I've already hinted at some of the reasons why the series stalled out, but I want to go into some more detail about it now to give context to some of the decisions I've made.
The big issue that I ran into when trying to build on the last post was visibility culling. As you may have noticed, the live demo of the previous post wasn't exactly speedy, and that's because it was trying to render every piece of a very large scene every frame. The obvious next step is to introduce a visibility testing system that can quickly inform you of what meshes are potentially visible from a given point in the world. This isn't a new concept, and it's one that I've worked with before. Quake 3 and the Source engine both use a pretty straightforward PVS (potentially visible set) system, and I was expecting that Unity would expose similar information through it's APIs.
Unfortunately, it doesn't.
The big issue that I ran into when trying to build on the last post was visibility culling. As you may have noticed, the live demo of the previous post wasn't exactly speedy, and that's because it was trying to render every piece of a very large scene every frame. The obvious next step is to introduce a visibility testing system that can quickly inform you of what meshes are potentially visible from a given point in the world. This isn't a new concept, and it's one that I've worked with before. Quake 3 and the Source engine both use a pretty straightforward PVS (potentially visible set) system, and I was expecting that Unity would expose similar information through it's APIs.
Unfortunately, it doesn't.
Subscribe to:
Posts (Atom)