Thursday, May 7, 2015

Subdivision surfaces

Just got back from the states, so I still have a bit of jetlag (man I hate that). But anyway, someone suggested I should take a look at Mesh Fusion, which is a really interesting tool that does approximate CSG with subdivision surfaces.

This made me want to try to see if I can get my CSG algorithm to work with subdivision surfaces, which I never tried out. So here's my first attempt at performing subdivision surfaces on a cube mesh, about half a days work.


Next on my list of things to do is fix some t-junction issues on the final mesh that pops out of the CSG process. I need to get the whole plugin in a shippable status, after that I'll continue my research on subdiv.

Tuesday, April 14, 2015

CSG Unity plugin progress update 3 - Leaking Light

Until now I had a mesh per brush because I figured that would make it easier for the user to do whatever they want with the meshes they generate. They could use individual brushes for navigation, occlusion culling or give individual brushes different physics materials. I figured I would combine the meshes just before the game is played in the editor, or before the game is published to any particular platform.

Finally I hit a situation that clearly shows that I need to combine all meshes somewhere in the editor in real-time. This is unfortunate because I'd have to force the user to create parent objects for brushes that hold the meshes and I'm afraid this could be confusing to users when they create a brush (without a parent object) and nothing shows up.

The problems I bumped up against all have to do with Unity's lighting. 


Unity doesn't seem to like meshes being split into multiple different objects. For some reason, even when vertices of 2 objects align exactly (I checked this in the debugger), it'll cause leaks in the lighting. Maybe Unity introduces some minor floating point errors somewhere, I have no idea. Still, the light leakage is huge for seams that must be incredibly tiny (no matter how I orientate the camera I cannot see any seams, not even tiny flickering pixels). 

It is possible to get the lighting to not have seams by messing around with the light's bias parameters, but that doesn't seem like a long term solution to me. I don't want users to be force the users to spend hours messing around with lighting parameters just to make this work.

Another, much bigger problem, is that light-mapping using individual brushes is problematic to say the least. Technically it might be possible to join all brushes and force a re-bake of all the lighting when the game is published to a platform. It would cause changes in the appearance of the game between the editor and the run-time, and it would be SLOW to publish. So I'm pretty sure all I would accomplish is that I'd receive tons of hate mail and assassination attempts.

So now I'm rewriting some code so that there are these higher level components that capture all the meshes of it's child brushes and combine them in the editor in real-time. One problem is that unity would show this combined mesh as a single mesh in the editor. Select it and you select all the meshes of all the brushes that are combined in it at the same time. 

Fortunately I was already rendering brush outlines with custom code and was forced to implement my own ray-brush intersection / drag & drop code in the editor anyway, so I can actually work around Unity's limitations. It won't be pretty, but it'll work.

The silver lining is that doing things this way means that there won't be a gazillion MeshFilters, MeshColliders and MeshRenderes in the scene anymore. The brush components can also be changed into relatively simple classes that can safely be removed at run-time without side-effects. All that will remain at run-time are the meshes that have been generated by the brushes.

Update: 
I was wrong! Light leakage had to do with mesh size (not the size of the mesh in world-space). Apparently the shadow bias is calculated in the mesh's object-space, but then applied in world-space? So very large mesh + reasonable bias + downscale of mesh in world space = HUGE shadow bias that causes light leakage.

I (mostly) implemented the part where all CSG generated meshes are joined into one unity mesh and got a nice speed boost as well. I guess in retrospect, uploading all these tiny unity meshes was kind of slow. (which makes sense)

... now to fix a weird bug that causes all the brushes to be re-CSG-ed every frame, non-stop. *sigh*
(good thing it's still fast enough)

Thursday, March 26, 2015

CSG Unity plugin progress update 2 - drag & drop materials

Another CSG update! Now it's possible to drag & drop materials onto the brushes, either on one surface or multiple surfaces at the same time. The video also shows procedural brushes (that can be turned into regular brushes). Meshes are generated in real-time, this is not some rendering trick.

Wednesday, March 18, 2015

CSG Unity plugin progress update - vertex editing

Just a quick update on my Unity CSG plugin (now in Unity 5). I implemented a WIP vertex editing tool to edit brushes (convex polytopes) with. I also implemented a WIP tool to edit the translation of textures on surfaces by just dragging it across the surface. Also my first 60hz youtube. yay!

Tuesday, March 10, 2015

Realtime CSG in Unity3D (video)

Just showing the progress on getting realtime CSG to work in Unity3D.

In the video you can see a worst case scenario for the CSG algorithm. The performance of the CSG algorithm is determined by how many brushes intersect with a brush, In this case 128 brushes intersect with a single brush.

Try doing this scenario in UE4! You will give up long before you actually get to 128 brushes. I'm not saying this to bash UE4, but it's the fastest realtime CSG out there in the wild.

There's still a lot of work to be done, not the very least I need to implement a way to easily build and edit the brushes themselves. I also still have lots of ideas to improve performance even further and some ideas on how to bound floating point errors no matter how many times edges get split.

Tuesday, February 10, 2015

Mesh optimizations

The last couple of (work)days I've been working on some code to optimize meshes generated by my CSG algorithm, which now works in Unity. 
Before

After
I'm quite pleased with the results. From 2073 vertices and 6951 triangles to 536 vertices and 2340 triangles. A pain to debug though :)

It's actually a heavily updated version of the CSG algorithm I blogged about/written articles on.. the new version is much faster.

Voxel world experiment update

Found some time to work on voxel experiment again. (Well I actually did this months ago, I just never got around to post about it)
Implemented AZDO (approaching zero driver overhead) techniques, frame rendering time is now about half a millisecond. I'm still CPU limited because of all the chunks I'm generating though.
Also implemented weighted blended order independent transparency, which looks a bit worse, but doesn't take any CPU power and solves some visual artifacts, related to triangle sorting, that would've taken a lot of effort to work around.
Added a couple of small things like swimming (very rough) and waves in the water.
I can also now live edit the Voxel world from within the 'game'.