Unity 3d

After talking about spending time learning Unreal this year, I changed my mind and decided on Unity instead 🙂
There’s a few reasons:

  • I’ve had friends pushing me in this way for a few years
  • Unreal 4 may still be a while off a public editor release
  • C#. C#. C#. Yay.
  • Asset Store. Even if I don’t use it, I love the idea that if there’s a part of a game / tech demo that I don’t want to write, I can just buy it. I don’t plan to do that much, because this is all just a learning exercise anyway, but it’s nice having the option

The first thing I plan on tackling is getting a basic Catmull Clark subdivision lodding system working.

I don’t want to spend a huge amount of time on it, though, because soon every half decent engine will have a OpenSubdiv implementation of some description.
If they don’t, I will be both saddened and shocked.
Sometime in the next few years, games artists will be SUBDIVIDING ALL THE THINGS, mark my words. And I will be crying into some sort of horrible profiling software, drowning in a sea of tessellated wireframes.

Anyway… I think the only reason someone hasn’t had a red hot go at implementing OpenSubDiv in Unity already is because OSD takes cubic patches as inputs, and Unity pre-triangulates everything.

In other news, here’s a bit of a lion head:


I feel like I need to post an image every time I do an entry 🙂

This is nothing to get excited about, yet, because I’m just pre-computing the high lod in Modo, then importing into Unity.
I have written some custom lodding code that controls where each of these is rendered, so that I can just use the high one up close, but this is all basically just about me learning Unity right now 🙂

My goal for the next few weeks (although, realistically, the end of April, due to holidays, etc), is to:

  • Import only the base mesh, and generate higher order Catmull Clark edge weighted lods on import
  • Have a reasonably nice UI for this, and the custom lodding system
  • Implement an edge-loop based mesh reduction system for the lods.

Known obstacles:

You’ll notice that in the shot above, my GoLion (Voltron) is missing 90% of the model.
Here’s the original:

Red GoLion
Red GoLion

This is because

a) Unity only supports 16 bit index buffers, and splits up meshes that have more than 65k vertices (so I deleted the other bits) and

b) Importing the high res bits takes a long time (which hopefully won’t be as much of an issue when I generate them myself).

Second problem… I mentioned that Unity pre-triangulates meshes.
It seems that it isn’t possible to get information on how that triangulation was achieved, so it’s not really feasible to build an alternative version of the mesh as cubic patches based on information coming into Unity alone.

For that reason, I will probably go down the path of re-processing the asset from the DAE on disk to generate the patches. I already have some code for doing parts of this, so I don’t see it being a huge problem, but it will be energy sapping, and very prone to error, considering the Collada schema is fairly flexible.

So, we’ll see how it all goes. At any rate, it will be a fun Unity learning experience, hurrah! 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s