Random "work in progress" shots
category: general [glöplog]
It's just a screencap from the image converter so far. I'm afraid aiming for the MSX this time :) Time is running out pretty baaad...
</spoiler> :)
spoiler
</spoiler> ;)
hehe :)
that's rad cupe!
:D
Trolololol.... It's ok, I'll GTFO.
A few WiP shots and bits of coding anecdotes from working on Tensile.
About 8 months before Revision, we thought that it would be pretty neat to have mesh fracture in our next intro. I picked up a few papers about the topic, thought that it would be fairly easy, and after about 6 weeks of coding, complete frustration and nightly muttered swearing at broken code, I had a first working implementation of a 3D voronoi mesh in 64k (which did not respect mesh boundaries):
Then, two more weeks of work later, it worked on arbitrary meshes (video).
Now, between the first pic and the video, there is a time difference of about 4 months. After getting the initial unclipped voronoi to work, I was so fed up with the algorithm that I simply dropped it and planned to never come back. I more or less told the other guys from my group to forget about mesh fracture in 64k, until at some point I silently picked it back up (can't leave things unfinished, now can I). Getting a bit of a break was definitely a good thing, since the rest of the code was done much quicker.
I completely underestimated the complexity of implementing 3D voronoi fracture, because my first implementation in 2D was finished within a day and I figured 3D would be just as easy. Well, I was wrong! The main problem is that you typically need a 3D delaunay tetrahedral mesh to construct the voronoi mesh. In 2D, the Delaunay triangulation algo is fairly easy, but in 3D, it has many more annoyingly complicated tetrahedron split cases and notoriously unstable geometric predicates, so getting it to work was a real pain. I you're not doing 64k, I can only advise you to use an established library like CGAL or do what most groups do and simply have your modeling program prefracture your models and load those.
Originally rigid body physics were also planned, but there was simply not enough time to get it ready for revision - for the prod, we just used the fracture code as a neat effect and as a content generator in some places.
Some day, we're hopefully going to do the "physics shit exploding everywhere 64k" we had planned.
One week before revision, there was still a jarring lack of content in our repo to make an intro with. Luckily, the Demodays orgas had already sent us the flyers for the party, giving me an excuse for hacking in a procedural tree. Tree generation is fairly straight-forward with the space colonization algorithm, and thanks to geometry shaders, generating the mesh gets super easy.
Wip video 1
Wip video 2
Shortly after, trying out spherical harmonics lighting:
Spherical harmonics (SH) are pretty neat, because they capture the essential colours of an environment map with few coefficients (perfect for 64k) and the compression "artifacts" look like super smooth blobs, which was exactly what I was going for, since that makes it easy to fake diffuse specular reflections . They were used both for backgrounds and surface reflection to get a consistent look. Also, they helped to avoid "coder colours" by allowing us to simply feed the SH compressor photographed light probes.
For diffuse lambert lighting, the first 3 SH levels (9 coefficients) are perfectly enough, but for diffuse specular reflections you'll need more. Ultimately I went with the first 10 levels (100 coefficients) since we had more than enough space anyway, but you could probably go with less (5-7 levels).
Final result in the intro:
And finally, wednesday before Revision, there was still this pesky scene at the end where we had absolutely zero content to fill it with (well, except heaps of distance fields, which unfortunately didn't really fit the style of the intro). At that point I figured we might as well live up to our name and modified the space colonization algorithm to produce gears instead of branches and out came this:
The code avoids self-intersection and produces a tight machine with interlocking gears with more or less no effort (since it's an incremental construction). By abusing the geometry shader because I'm a lazy bum, generating the geometry didn't need much more than a few dozen lines of code.
Of course the scene is still pretty random, but with tangent space shading it looked kinda neat and hey, you can never go wrong with gears!
Given that we had about a week for producing actual content, the end result is somewhat okay, but there is still a distinct lack of polish and consistency. Also, nobody really seemed to care about the fracture (we failed to show it off), which was a bit of a bummer considering the time that went into it - I guess this just means we'll have to try harder next time.
About 8 months before Revision, we thought that it would be pretty neat to have mesh fracture in our next intro. I picked up a few papers about the topic, thought that it would be fairly easy, and after about 6 weeks of coding, complete frustration and nightly muttered swearing at broken code, I had a first working implementation of a 3D voronoi mesh in 64k (which did not respect mesh boundaries):
Then, two more weeks of work later, it worked on arbitrary meshes (video).
Now, between the first pic and the video, there is a time difference of about 4 months. After getting the initial unclipped voronoi to work, I was so fed up with the algorithm that I simply dropped it and planned to never come back. I more or less told the other guys from my group to forget about mesh fracture in 64k, until at some point I silently picked it back up (can't leave things unfinished, now can I). Getting a bit of a break was definitely a good thing, since the rest of the code was done much quicker.
I completely underestimated the complexity of implementing 3D voronoi fracture, because my first implementation in 2D was finished within a day and I figured 3D would be just as easy. Well, I was wrong! The main problem is that you typically need a 3D delaunay tetrahedral mesh to construct the voronoi mesh. In 2D, the Delaunay triangulation algo is fairly easy, but in 3D, it has many more annoyingly complicated tetrahedron split cases and notoriously unstable geometric predicates, so getting it to work was a real pain. I you're not doing 64k, I can only advise you to use an established library like CGAL or do what most groups do and simply have your modeling program prefracture your models and load those.
Originally rigid body physics were also planned, but there was simply not enough time to get it ready for revision - for the prod, we just used the fracture code as a neat effect and as a content generator in some places.
Some day, we're hopefully going to do the "physics shit exploding everywhere 64k" we had planned.
One week before revision, there was still a jarring lack of content in our repo to make an intro with. Luckily, the Demodays orgas had already sent us the flyers for the party, giving me an excuse for hacking in a procedural tree. Tree generation is fairly straight-forward with the space colonization algorithm, and thanks to geometry shaders, generating the mesh gets super easy.
Wip video 1
Wip video 2
Shortly after, trying out spherical harmonics lighting:
Spherical harmonics (SH) are pretty neat, because they capture the essential colours of an environment map with few coefficients (perfect for 64k) and the compression "artifacts" look like super smooth blobs, which was exactly what I was going for, since that makes it easy to fake diffuse specular reflections . They were used both for backgrounds and surface reflection to get a consistent look. Also, they helped to avoid "coder colours" by allowing us to simply feed the SH compressor photographed light probes.
For diffuse lambert lighting, the first 3 SH levels (9 coefficients) are perfectly enough, but for diffuse specular reflections you'll need more. Ultimately I went with the first 10 levels (100 coefficients) since we had more than enough space anyway, but you could probably go with less (5-7 levels).
Final result in the intro:
And finally, wednesday before Revision, there was still this pesky scene at the end where we had absolutely zero content to fill it with (well, except heaps of distance fields, which unfortunately didn't really fit the style of the intro). At that point I figured we might as well live up to our name and modified the space colonization algorithm to produce gears instead of branches and out came this:
The code avoids self-intersection and produces a tight machine with interlocking gears with more or less no effort (since it's an incremental construction). By abusing the geometry shader because I'm a lazy bum, generating the geometry didn't need much more than a few dozen lines of code.
Of course the scene is still pretty random, but with tangent space shading it looked kinda neat and hey, you can never go wrong with gears!
Given that we had about a week for producing actual content, the end result is somewhat okay, but there is still a distinct lack of polish and consistency. Also, nobody really seemed to care about the fracture (we failed to show it off), which was a bit of a bummer considering the time that went into it - I guess this just means we'll have to try harder next time.
Whoa, thanks a lot for the write up. Fascinating stuff.
Great write-up indeed, thanks for sharing!
wow, thanks for that writeup noobody. awesome stuff. also, i noticed you used something like proper involute gears this time, living up to your name :)
on a related note, you might want to check out my thesis (in german) on breaking meshes into more-or-less voronoi pieces. it never got implemented in an intro because it is a shitload of code and i used maya's mesh intersection which i would have hated to write myself.
on a related note, you might want to check out my thesis (in german) on breaking meshes into more-or-less voronoi pieces. it never got implemented in an intro because it is a shitload of code and i used maya's mesh intersection which i would have hated to write myself.
+1!
noby, activate the doomsday machine.
well since I'm writing code doesn't that mean it's already activated pretty much?
yeaaah thaat's right...
pls switch to an actual platform instead
