positive reports</th>	total reports</th>	priority</th> </tr> </thead>
6</td>	93</td>	-0.861</td> </tr>
1</td>	25</td>	-0.793</td> </tr>
3</td>	8</td>	-0.098</td> </tr>
0</td>	2</td>	-0.038</td> </tr>
0</td>	1</td>	-0.010</td> </tr>
0</td>	0</td>	+0.000</td> </tr>
1</td>	1</td>	+0.010</td> </tr>
2</td>	2</td>	+0.038</td> </tr>
7</td>	12</td>	+0.098</td> </tr>
7</td>	7</td>	+0.329</td> </tr>
25</td>	27</td>	+0.749</td> </tr>
47</td>	52</td>	+0.779</td> </tr>
52</td>	53</td>	+0.929</td> </tr> </tbody> </table></div> As you can see, both the number of reports and their accuracy are being taken into account to provide a priority metric that makes sense—the more meaningful someone's contribution is, the higher priority their reports will have, and vice versa.</p> From there, client-side</strong> anti-cheats could be removed altogether, or at least be made less disruptive. This doesn't mean that there is no place for software detection at all. It'd always be helpful for a game developer to be able to find cheaters without requiring any assistance from the community—this can be implemented by flagging users with a high K/D ratio or win rate, or why not by adding a server-side</strong> deep learning system^{[4]</a></sup> that would learn from the ingame behaviour of players that were reported.</p>} It is important to note that any detection software should NOT</strong> have an authoritative decision. It should never directly ban a player, only flag them for human review.</p> I might be biased but this seems like a bulletproof detection system to me—I bet that any community would be happy to contribute if they'd be rewarded accordingly, as long as they'd be guaranteed that their efforts won't go to waste by getting the offenders banned for good.</p> Keeping the Offenders Out, For Good</h3> If I was developing an online multiplayer game, I probably wouldn't bother too much about crafting complicated anti-cheats. But the caveat would be: if you get caught, you're out of my game, for good</strong>.</p> How'd you do that? How'd you uniquely identify each player regarding on which game account they might be using? Not with an IP address, not with an HWID, but with an actual proof of identity and/or physical address.</p> For example, such a verification system could require either one or a combination of the following:</p> providing a scan of an official document from the government (national ID, passport, driving license, ...).</li> entering a verification code that was sent by the game developer through post mail to a given physical address.</li> taking a selfie next to a verification code that is displayed either on a phone or printed out on a piece of paper.</li> </ul> Of course you shouldn't have to provide a proof of identity only to play a game online. But I bet that the part of the community that truly cares about playing in a good, safe</strong>, environment, which I'm hoping is the majority of us, would understand the benefits of providing such a proof of identity and would be fine complying with it? It could even be handled through an external, independent, platform, and be made available to all games, so you'd have to go through the verification process only once.</p> Such a system would be optional</strong>.</p> You could decide not</em> to opt-in and have access to the ‘normal’ matchmaking queues, or you could opt-in and also gain access the ‘verified</strong>’ queues.</p> Once a verified offender would get caught, it means that not only their game account would be banned but also their actual physical identity</strong> would be blacklisted. It wouldn't be possible for that person to join a ‘verified’ queue ever again, thus ensuring that these queues become safer and safer over time.</p> How Does That Sound?</h2> I know for one that I'd be happy to be part of a community where we'd fight toxicity and cheating all together</strong>, hands in hands with game developers, to provide the best possible online multiplayer gaming experience. Hell, the concept could probably be extended to other type of online communities.</p> Would you be willing to join the fight against cheating and toxicity if such a concept were to be implemented?</p> Priority Formula Code</h2> Here is the Python snippet used to compute the priority table from above:</p> #! /usr/bin/env python</span> # -- coding: utf-8 --</span> """Formula to compute a priority value according to the reports received. The priority number fits in the range [-1.0, 1.0]. Everyone starts at 0, synonym to a neutral priority level. """</span> _DATA_SET = ( (0</span>, 0</span>), (0</span>, 1</span>), (0</span>, 2</span>), (1</span>, 1</span>), (2</span>, 2</span>), (1</span>, 25</span>), (3</span>, 8</span>), (6</span>, 93</span>), (7</span>, 7</span>), (7</span>, 12</span>), (25</span>, 27</span>), (47</span>, 52</span>), (52</span>, 53</span>), ) # Magic number—the higher, the more weight will be given to the ratio</span> # `positive_count / total_count` as the number of reports increase.</span> _THRESHOLD = 10</span> def</span> _compute_priority</span>(positive_count, total_count</span>):</span> if</span> total_count == 0</span>: return</span> 0</span> x = float</span>(total_count) / _THRESHOLD weight = 1</span> - 1</span> / (x * x + 1</span>) ratio = (float</span>(positive_count) / total_count) * 2</span> - 1</span> return</span> ratio * weight def</span> _print_results</span>(results</span>):</span> print</span>("+---------------------------------------------+"</span>) print</span>("\| positive reports \| total reports \| priority \|"</span>) print</span>("+------------------+---------------+----------+"</span>) for</span> priority, (positive_count, total_count) in</span> results: print</span>("\| {:16d} \| {:13d} \| {:+8.3f} \|"</span>.format</span>( positive_count, total_count, priority)) print</span>("+---------------------------------------------+"</span>) def</span> main</span>():</span> results = sorted</span>((_compute_priority(x), x) for</span> x in</span> _DATA_SET) _print_results(results) if</span> __name__ == '__main__'</span>: main() </code></pre> Footnotes</h2> Riot's Approach to Anti-Cheat</a>.↩</span></a></li> Hacks! An investigation into the million-dollar business of video game cheating</a>↩</span></a></li> Feeling the Cheat: The Game Hack Sellers Working Under the Radar</a>↩</span></a></li> GDC 2018: John McDonald (Valve) - Using Deep Learning to Combat Cheating in CSGO</a>↩</span></a></li></ol></aside> Houdini: Flame 2018-06-13T12:00:00Z A while ago I did simulate a flame in Houdini based on a video reference that had a lot of character to it (see below), to the point where it almost produced a stroboscopic effect.</p> I was happy with the result that I obtained but alas I could not share the scene because I lost the definition of some custom digital assets that I was using. Rejoy as I have recreated it from scratch!</p> </span>Watch on Vimeo</span></a></span></p> The effect is pretty simple to achieve. The only tricks are to provide a pulsatile temperature source but also to find a good balance between the pyro solver's shredding, which brings some of the character out but shorten the flame's height, and the buoyancy plus temperature multiplier combo. Too much of shredding and the motion becomes too frenetic, and not enough temperature/buoyancy and the flame becomes too short.</p> Download</h2> </span> flame-01 v1</strong></a></p>* This file contains a scene created with SideFX</a>’s Houdini 16.5 as well as any required asset.</p> </div> References</h2> https://www.youtube.com/watch?v=aCpBT3sIPc4&t=80</a></li> </ul> Rexo: A Unit Testing Framework in C 2018-06-11T12:00:00Z In the serie of reinventing the wheel for the sake of learning, let me introduce you to the unit testing framework!</p> Update</strong></p> A full redesign of Rexo has since been released, see Rexo: A Unit Testing Framework in C (Part 2)</a>.</p> </div> View on GitHub</span></a></span></p> Test Registration</h2> While looking around for unit testing frameworks written in C, I noticed that the vast majority were fairly verbose and didn’t provide any sort of automatic test registration like most of their C++ counterparts do.</p> There had to be some sort of additional constraints inheritent to C, but which ones? In an effort to learn more about the C language, I set out to answer this question by writing my own unit testing framework from scratch, in C89.</p> The reason why automatic test registration is not available in C quickly became obvious. C++ frameworks like Google Test use some clever static initialization trickery that registers each test to a global factory class with the help of some macros to nicely hide the registration logic away from the user [1]</a></sup>.</p> But no function, not even static, can be called at the file scope in C. All that is allowed is defining simple constant values and functions, so no such trickery allowed here.</p> As an example, the simple code snippet below works perfectly fine in C++ but triggers a compilation error in C.</p> `#include</span> <stdio.h></span></span> static</span> int</span> foo</span>()</span> </span>{ return</span> 123</span>; } static</span> const</span> int</span> bar = foo(); int</span> main</span>()</span> </span>{ printf</span>("bar is %d\n"</span>, bar); return</span> 0</span>; } </code></pre>` Some C frameworks such as NovaProva</a> workaround this limitation by reading the DWARF debug information</a> generated during a debug compilation while Criterion</a> parses the generated executable file formats to read the contents of specific data sections.</p> I wasn’t ready to dig into such involved approaches so I picked the more standard route with this first iteration of Rexo and went for the manual registration choice with all the verbosity that it comes with.</p> API Design</h2> Rexo provides both a diagonal API for ease of use and an orthogonal one for maximum customizability.</p> The diagonal API is just one function, `rxRun()</code>. It takes the suites as parameter and run them.</p>` The orthogonal API is made of all the smaller logical parts that rxRun()</code> uses to get the job done, that is rxInitializeTestCaseReport()</code>, rxTerminateTestCaseReport()</code>, rxRunTestCase()</code>, and rxPrintTestCaseRunSummary()</code>. If you go down this path, it means that you need to write your own function to run the tests, and it’s also up to you to use the provided orthogonal functions or here again to write your own variants... but at this point, you’re probably better off writing your own framework from scratch.</p> `Simple Usage</h2> Here’s a basic example on how to use Rexo, with a fixture and a display of a few of the available assertion macros, which are declined in CHECK</code> and REQUIRE</code> variants, respectively for nonfatal and fatal failures.</p>` #define</span> RX_DEBUG_LOGGING_LEVEL</span> #include</span> <rexo/rexo.h></span></span> #include</span> <stddef.h></span></span> #include</span> <stdio.h></span></span> #define</span> PI 3.14159265358979323846</span> struct</span> Fixture</span> {</span> int</span> zero; unsigned</span> int</span> one; }; enum</span> RxStatus setUp</span>(void</span> *ppFixture)</span> </span>{ struct</span> Fixture</span> pData</span>;</span> pData = (struct Fixture )malloc</span>(sizeof</span> pData); if</span> (pData == NULL</span>) { return</span> RX_ERROR_ALLOCATION; } pData->zero = 0</span>; pData->one = 1</span>; ppFixture = (void</span> )pData; return</span> RX_SUCCESS; } void</span> tearDown</span>(void</span> pFixture)</span> </span>{ free</span>(pFixture); } RX_TEST_CASE(testBasics) { struct</span> Fixture</span> pData</span>;</span> pData = (struct Fixture )RX_FIXTURE; RX_CHECK_INT_EQUAL(pData->zero, 0</span>); RX_CHECK_UINT_EQUAL(pData->one, 1</span>); RX_CHECK_FP_ALMOST_EQUAL(sin</span>(PI), 0.0</span>, 1.0e-6</span>); RX_CHECK_FP_ALMOST_EQUAL(sin</span>(PI 0.5</span>), 1.0</span>, 1.0e-6</span>); RX_CHECK_STRING_EQUAL_NO_CASE("abc"</span>, "ABC"</span>); } RX_TEST_CASE(testFailure) { struct</span> Fixture</span> pData</span>;</span> pData = (struct Fixture )RX_FIXTURE; RX_CHECK_INT_EQUAL(pData->zero, 1</span>); } static</span> const</span> struct</span> RxTestCase</span> cases</span>[] =</span> {{"basics"</span>, testBasics}, {"failure"</span>, testFailure}}; static</span> const</span> struct</span> RxTestSuite</span> suites</span>[] =</span> {{"example"</span>, sizeof</span> cases / sizeof</span> cases[0</span>], cases, setUp, tearDown}}; int</span> main</span>(int</span> argc, const</span> char</span> *ppArgv)</span> </span>{ rxRun(sizeof</span> suites / sizeof</span> suites[0</span>], suites, argc, ppArgv); return</span> 0</span>; } </code></pre> Which results in the output:</p> `[PASSED] "example" / "basics" (0.009188 ms) [FAILED] "example" / "failure" (0.010063 ms) ./rexo/tests/example.c:57: nonfatal test failure: ‘pData->zero’ is expected to be equal to ‘1’ 0 == 1 </code></pre>Where Is It?</h2> On GitHub</a>, as always!</p> Footnotes</h2>See this condensed example on Stackoverflow</a>.↩</span></a></li></ol></aside>` Zero: Dynamic Arrays 2018-05-26T12:00:00Z Dynamic arrays stand for arrays that can grow and shrink in size. They are conceptualized in C++ through the std::vector</code> class, but no such facility is available out of the box in C, leading to countless different implementations by countless different developers. This is my contribution to it!</p> A trendy, minimalist, implementation comes from Sean Barrett’s stretchy buffer</a> but I decided to go for a slightly</em> more involved approach.</p> View on GitHub</span></a></span></p> Inspired by C++ templates, the library provides a ZR_MAKE_DYNAMIC_ARRAY()</code> macro that generates all the functions needed to manipulate a dynamic array for a given type. The library’s code is slightly abominable but it’s pretty neat on the user’s end, with all the type checking you’d get with the usual function signatures.</p> One cool feature, as shared by Zero’s allocator library</a> and Sean Barrett’s stretchy buffers, is that these arrays are not wrapped into any sort of structure to make them work—all the bookkeeping required is instead stored in a header invisible to the user, so you can still pass your arrays around as if they were plain C arrays.</p> For the manipulation side of things, three main families of functions provide facilities to add new elements into an array:</p> extend</code>: adds new uninitialized element(s) at a given position and returns a pointer to the first element added</li> insert</code>: adds new element(s) at a given position and initializes them by copying the given input values</li> push</code>: adds a new element at a given position and initializes it by copying the given input value</li> </ul> And a single one is dedicated to removing elements: trim</code>.</p> Each of these 4 functions come in different flavours. While the base one offers an explicit control over where the modification needs to occur, two variants exist as a shortcut to focus on the front and back ends of the arrays.</p> Here’s a usage example, with error checking omitted for brevity:</p> #define</span> ZR_DEFINE_IMPLEMENTATION</span> #include</span> <zero/dynamicarray.h></span></span> ZR_MAKE_DYNAMIC_ARRAY(IntArray, int</span>) int</span> main</span>(void</span>)</span> </span>{ int</span> pArray; int</span> pSlice; int</span> values[2</span>]; zrCreateIntArray(&pArray, 2</span>); pArray[0</span>] = 1</span>; pArray[1</span>] = 2</span>; / pArray: {1, 2} /</span> zrResizeIntArray(&pArray, 4</span>); pArray[2</span>] = 7</span>; pArray[3</span>] = 8</span>; / pArray: {1, 2, 7, 8} /</span> zrExtendIntArray(&pSlice, &pArray, 2</span>, 2</span>); pSlice[0</span>] = 3</span>; pSlice[1</span>] = 6</span>; / pArray: {1, 2, 3, 6, 7, 8} /</span> values[0</span>] = 4</span>; values[1</span>] = 5</span>; zrInsertIntArray(&pArray, 3</span>, sizeof</span> values / sizeof</span> values[0</span>], values); / pArray: {1, 2, 3, 4, 5, 6, 7, 8} /</span> zrPushIntArrayFront(&pArray, 0</span>); zrPushIntArrayBack(&pArray, 9</span>); / pArray: {0, 1, 2, 3, 4, 5, 6, 7, 8, 9} /</span> zrDestroyIntArray(pArray); return</span> 0</span>; } </code></pre> I’m not sure what the drawbacks of this approach are (if any) but that’s exactly</em> why I decided to experiment with it!</p> If you have some feedback, please do share!</p> The implementation is available on GitHub</a>.</p> Houdini: Ray Tracer in VEX 2018-05-23T12:00:00Z I’ve seen many people sharing fun ray tracers experiments with Houdini’s VEX in the past,[1]</a></sup> and it just happens that I’ve had many ~10 min bursts of time to spare due to waiting for simulation computations, so I grabbed a copy of Peter Shirley’s mini book Ray Tracing in One Weekend</cite></a>[2]</a></sup> and gave it a go.</p> </span>Watch on Vimeo</span></a></span></p> I’ve used Houdini facilities when possible, such as various SOP nodes to build the scene and the built-in VEX functions like intersect()</code>, fresnel()</code>, reflect()</code>, refract()</code>, and others, which allowed me to take a few shortcuts.</p> Hence it’s more of an adaptation rather than a 100% faithful implementation of the book, but the results are fairly similar.</p> Still, it’s been plenty enough to give a good introduction to ray tracing and I’m happy with that!</p> </span></span></p> Performance-wise though... it’s not there yet. Probably a good contender for an implementation using an OpenCL SOP node?</p> The scene is available in the download link below, but I’ll also throw the VEX code here for quick reference:</p> #define</span> MAX_BOUNCES 8</span> #define</span> NEAR_DISTANCE 1.0e-3</span> #define</span> FAR_DISTANCE 1.0e3</span> #define</span> MATERIAL_LAMBERT 0</span> #define</span> MATERIAL_METAL 1</span> #define</span> MATERIAL_DIELECTRIC 2</span> #define</span> GEOS_INPUT_IDX 1</span> #define</span> SKY_RAMP_NAME "sky"</span></span> #define</span> ALBEDO_ATTRIB_NAME "Cd"</span></span> #define</span> NORMAL_ATTRIB_NAME "N"</span></span> #define</span> MATERIAL_ATTRIB_NAME "material"</span></span> #define</span> FUZZINESS_ATTRIB_NAME "fuzziness"</span></span> #define</span> IOR_ATTRIB_NAME "ior"</span></span> struct</span> Ray</span> {</span> vector</span> origin; vector</span> direction; }; struct</span> Hit</span> {</span> int</span> prim; vector</span> uvw; vector</span> pos; vector</span> normal; }; void</span> trace</span>(export</span> int</span> hitten; export</span> Hit hit; const</span> Ray ray)</span> </span>{ vector</span> pos; vector</span> uvw; int</span> prim; prim = intersect( GEOS_INPUT_IDX, ray.origin + ray.direction {NEAR_DISTANCE, NEAR_DISTANCE, NEAR_DISTANCE}, ray.direction * {FAR_DISTANCE, FAR_DISTANCE, FAR_DISTANCE}, pos, uvw); hitten = prim > -1</span>; if</span> (hitten) { hit.prim = prim; hit.uvw = uvw; hit.pos = pos; hit.normal = primuv( GEOS_INPUT_IDX, NORMAL_ATTRIB_NAME, hit.prim, hit.uvw); } } void</span> evalLambertianMaterial</span>(export</span> int</span> scattered; export</span> Ray scatteredRay; export</span> vector</span> attenuation; const</span> Ray ray; const</span> Hit hit)</span> </span>{ vector</span> randomPos; vector</span> target; randomPos = sample_sphere_uniform(set</span>(nrandom(), nrandom(), nrandom())); target = hit.pos + hit.normal + randomPos; attenuation = primuv(GEOS_INPUT_IDX, ALBEDO_ATTRIB_NAME, hit.prim, hit.uvw); scatteredRay = Ray(hit.pos, normalize(target - hit.pos)); scattered = 1</span>; } void</span> evalMetallicMaterial</span>(export</span> int</span> scattered; export</span> Ray scatteredRay; export</span> vector</span> attenuation; const</span> Ray ray; const</span> Hit hit)</span> </span>{ vector</span> randomPos; float</span> fuzziness; randomPos = sample_sphere_uniform(set</span>(nrandom(), nrandom(), nrandom())); fuzziness = min( primuv(GEOS_INPUT_IDX, FUZZINESS_ATTRIB_NAME, hit.prim, hit.uvw), 1.0</span>); attenuation = primuv(GEOS_INPUT_IDX, ALBEDO_ATTRIB_NAME, hit.prim, hit.uvw); scatteredRay = Ray( hit.pos, reflect(ray.direction, hit.normal) + randomPos * fuzziness); scattered = dot(scatteredRay.direction, hit.normal) > 0</span>; } void</span> evalDielectricMaterial</span>(export</span> int</span> scattered; export</span> Ray scatteredRay; export</span> vector</span> attenuation; const</span> Ray ray; const</span> Hit hit)</span> </span>{ float</span> iDotN; float</span> ior; float</span> iorRatio; vector</span> outNormal; float</span> cosine; float</span> reflectedAmount; float</span> refractedAmount; attenuation = {1.0</span>, 1.0</span>, 1.0</span>}; scattered = 1</span>; iDotN = dot(ray.direction, hit.normal); ior = ior = primuv(GEOS_INPUT_IDX, IOR_ATTRIB_NAME, hit.prim, hit.uvw); if</span> (iDotN < 0</span>) { // The ray comes from outside the surface.</span> iorRatio = 1.0</span> / ior; outNormal = hit.normal; cosine = -iDotN / length(ray.direction); } else</span> { // The ray comes from inside the surface.</span> iorRatio = ior; outNormal = -hit.normal; cosine = ior * iDotN / length(ray.direction); } fresnel( ray.direction, outNormal, iorRatio, reflectedAmount, refractedAmount); if</span> (nrandom() < reflectedAmount) { scatteredRay = Ray(hit.pos, reflect(ray.direction, hit.normal)); return</span>; } scatteredRay = Ray(hit.pos, refract(ray.direction, outNormal, iorRatio)); } void</span> getColor</span>(export</span> vector</span> color; const</span> Ray ray)</span> </span>{ int</span> i; Ray stack</span>[]; vector</span> accumulator[]; int</span> hitten; Hit hit; i = 0</span>; push(stack</span>, ray); while</span> (len(stack</span>) > 0</span>) { Ray currentRay; currentRay = pop(stack</span>); trace(hitten, hit, currentRay); if</span> (hitten && i < MAX_BOUNCES) { int</span> material; int</span> scattered; Ray scatteredRay; vector</span> attenuation; material = prim(GEOS_INPUT_IDX, MATERIAL_ATTRIB_NAME, hit.prim); if</span> (material == MATERIAL_LAMBERT) { evalLambertianMaterial( scattered, scatteredRay, attenuation, currentRay, hit); } else</span> if</span> (material == MATERIAL_METAL) { evalMetallicMaterial( scattered, scatteredRay, attenuation, currentRay, hit); } else</span> if</span> (material == MATERIAL_DIELECTRIC) { evalDielectricMaterial( scattered, scatteredRay, attenuation, currentRay, hit); } else</span> { warning("unsupported material"</span>); push(accumulator, {1.0</span>, 0.078</span>, 0.576</span>}); break</span>; } if</span> (scattered) { push(accumulator, attenuation); push(stack</span>, scatteredRay); } else</span> { push(accumulator, {0.0</span>, 0.0</span>, 0.0</span>}); } ++i; } else</span> { float</span> v; v = dot(normalize(set</span>( currentRay.direction.x, 0.0</span>, currentRay.direction.z)), currentRay.direction); v = currentRay.direction.y < 0</span> ? 0.0</span> : 1.0</span> - v; push(accumulator, chramp(SKY_RAMP_NAME, v)); } } color = {1.0</span>, 1.0</span>, 1.0</span>}; for</span> (i = 0</span>; i < len(accumulator); ++i) { color = accumulator[i]; } } void</span> getCameraRay</span>(export</span> Ray ray; const</span> vector</span> throughPos; const</span> vector</span> pos; const</span> vector</span> u; const</span> vector</span> v; const</span> float</span> aperture)</span> </span>{ vector2 randomPos; vector</span> origin; randomPos = sample_circle_uniform(set</span>(nrandom(), nrandom())); randomPos = aperture * 0.5</span>; origin = pos + u * randomPos.x + v * randomPos.y; ray = Ray(origin, normalize(throughPos - origin)); } cvex main</span>(export</span> vector</span> Cd = {0.0</span>, 0.0</span>, 0.0</span>}; const</span> vector</span> P = {0.0</span>, 0.0</span>, 0.0</span>}; const</span> vector</span> cameraPos = {0.0</span>, 0.0</span>, 0.0</span>}; const</span> vector</span> cameraU = {1.0</span>, 0.0</span>, 0.0</span>}; const</span> vector</span> cameraV = {0.0</span>, 1.0</span>, 0.0</span>}; const</span> float</span> cameraAperture = 1.0</span>)</span> </span>{ Ray ray; Cd = {0.0</span>, 0.0</span>, 0.0</span>}; getCameraRay(ray, P, cameraPos, cameraU, cameraV, cameraAperture); getColor(Cd, ray); } </code></pre> Download</h2> </span> ray-tracer-01 v2</strong></a></p> This file contains a scene created with SideFX</a>’s Houdini 16.5 as well as any required asset.</p> </div> Footnotes</h2>Anatolii Iudanov</a>, Matt Ebb</a>, and others.↩</span></a></li> Also available as “pay what you want” PDFs: https://twitter.com/Peter_shirley/status/985561344555417600</a>↩</span></a></li></ol></aside> Houdini: Wind Tunnel 2018-04-04T12:00:00Z Computer graphics can help making impossible things become reality—so how about having a heavy metallic bull sculpture being pushed away by a mere 15 m/s breeze coming from within a wind tunnel? Definitely something worth making happen!</p> </span>Watch on Vimeo</span></a></span></p> Smoke Flows Breakdown</h2> The primary objective is to manage having the flows of smoke to look as continuous as possible.</p> To this purpose, the idea here is to have each flow sourced on the left side of the container from a Tube SOP</em> whose length depends on the wind speed per simulation step rounded to the nearest voxel unit.</p> coefficient = fps * substeps * voxel size</span> wind</span> speed</span> per step</span> in</span> voxels = round</span>(wind</span> speed</span> / coefficient) adjusted wind</span> speed</span> = wind</span> speed</span> per step</span> in</span> voxels * coefficient tube length = wind</span> speed</span> per step</span> in</span> voxels * voxel size</span> </code></pre> Then, the Smoke Solver DOP</em> needs to “push” the density field towards the right to leave just enough room for some more smoke to be sourced on the left side during the next simulation step.</p> This is done by having the velocity field of the simulation to approximately match the adjusted wind speed at all times around the left side of the container. The Smoke Object DOP</em>’s Wind Tunnel Direction</em> parameter helps to do precisely that but I ended up using a custom setup instead because it seems to provide slightly better results and there’s more to learn this way, heh!</p> Nothing too fancy in this setup anyway—the container is initialized with the wind’s velocity and then some more velocity is added at each step in the left side. The continuous pumping of fresh new velocity is required because the advection of the velocity field by itself at each simulation step causes a loss of velocity in the sourcing area that needs to be compensated.</p> By this point, and with the collision source plugged in, the flows look alright but some small discontinuities are still visible in the density field. Fortunately these are minor enough to be disregarded—they are bound to disappear altogether once rendered with motion blur.</p> </span>density field—some discontinuities are visible</span></span></p> </span>velocity field—losing a bit of steam on the front</span></span></p> To give a more interesting look, the linear shape of the flows is broken by adding a tiny bit of noise to the velocity source, as well as a Gas Vortex Confinement DOP</em> to boost the swirls, and a Gas Turbulence DOP</em> around the collision area.</p> </span>density field after breaking its linearity</span></span></p> Finally the simulation substeps are set to 2 simply because it brings a more interesting motion.</p> Dust Breakdown</h2> Since a bull sculpture sliding in these conditions doesn’t make any sense anyway, I decided to furthermore pursue in this direction by adding a dust effect as if some dirt were, somehow, laying on the ground.[1]</a></sup> Yup.</p> To emit dust whenever the bull is sliding, a volume is first generated around the bull’s feet, near the ground, with an added pinch of noise here and there. It is then multiplied by the surrounding velocity of the bull, thus nullifying its density as the bull comes to a standstill.</p> The rest is even more straightforward—the volume and the points scattered from it are both advected by the velocity from the smoke flows to respectively simulate the dust particles and the dust smoke.</p> </span>dust sources</span></span></p> </span>dust advection</span></span></p> At render time, the dust particles and smoke are set to be mostly transparent to not distract from the main effect: the smoke flows.</p> Download</h2> </span> wind-tunnel-01 v2</strong></a></p> This file contains a scene created with SideFX</a>’s Houdini 16.5 as well as any required asset.</p> </div> References</h2> https://www.youtube.com/watch?v=E9ZSAX56m0E</a></li> </ul> Credits</h2> The bull model and its texture maps were created and shared under the CC Attribution-ShareAlike license</a> by Zafio via Sketchfab</a>.</p> Footnotes</h2>It’s a good exercise anyhow.↩</span></a></li></ol></aside> Zero: A Bunch of Single-File Libraries for C/C++ 2018-05-26T12:00:00Z For the needs of a project I’m working on, I had to write an aligned</strong> allocator on top of malloc()/realloc()/free()</code> and a simple logger featuring different log levels and basic colouring. Nothing too fancy here.</p> It was obvious that the code had nothing specific to that project and was in fact a good fit for a more general-purpose library.</p> So I decided to jump into the single-file, header-only, libraries bandwagon started by Sean Barrett and his popular stb</a> project by releasing my own: Zero</a>.</p> View on GitHub</span></a></span></p> While developing Zero, I was influenced by the Physical Design of The Machinery</a> and chose not to have any #include</code> dependency within the library headers. That’s right. Not even standard headers. [1]</a></sup> Why’s that? Because standard headers contain thousands</em> of lines of code when counting their own dependencies and I do not want to slow down compilation times by burdening projects that include my headers into their own headers. At least, not without a good reason. Are fixed integer types or size_t</code> a good enough reason? Not even.</p> Most projects target common platforms (Windows, Linux, macOS) and hence use either the ILP32, LP64, or LLP64 data models. All of these data models guarantee the char</code> type to be 8 bits, short</code> to be 16 bits, int</code> to be 32 bits, and long long</code> to be 64 bits. For people using more exotic platforms, Zero can fallback to using <stdint.h></code> if the macro ZR_USE_STD_FIXED_TYPES</code> is defined. Even better, each type can be overridden individually through macros such as ZR_INT32</code>.</p> The same goes for size_t</code>—on almost all platforms the size of size_t</code> equals the targetted architecture, that is either 32 or 64 bits. Here again, there is a fallback macro with ZR_USE_STD_BASIC_TYPES</code> that includes <stddef.h></code>, and a more granular one ZR_SIZE_TYPE</code> to directly set the size type to be used.</p> Note that these custom types are only used in the public interface defined within the headers. The implementation side of things is free to include whatever file is needed, which is fine since these dependencies are to remain within a single translation unit rather than spreading all over the place through the #include</code> mechanism.</p> As always, it’s all on GitHub</a>, so go get it!</p> Footnotes</h2>Alright, there is a single exception with <stdarg.h></code> and that’s because one function uses va_list</code> as a parameter. But in my defense, <stdarg.h></code> has no other dependency (on my platform, at least) and is fairly short (~100 LOC).↩</span></a></li></ol></aside> New Look and a Brand New Static Site Generator 2017-10-04T13:00:00Z It seems that whenever I’m looking forward to turn a page in my life, there’s a little—but insisting</em>—voice inside calling me to update my website. Not being a huge fan of web development, it’s something that I truly</em> dread but then it makes me feel somehow freshened once it’s done. And boy, does releasing this new version has been rewarding for me!</p> I threw away all the PHP, SQL, JavaSript, and basically anything that could slow down page loadings on the client side, including analytics. I also stopped relying on CMS</abbr> solutions and wrote the back-end myself, that is a static site generator called Eddi. All this for the sake of having full</em> control over the complete process.</p> View demo</span></a>eddi’s default theme</span></span></p> I ended up spending waaay</em> more time than I hoped to so towards the end I started cutting some corners with the code which translates into some small bits here and there being not so well implemented. But it’s not too shabby for a first go, overall I’m fairly happy with the end result—it’s now much easier to maintain my blog and I see the overall structure of the generator to be a solid base that I could build upon again in the future.[1]</a></sup></p> What This Update Means for You</h2> Design</dt> I somehow managed to make the design even simpler than the previous edition while also making all the content easily accessible. Gone are the days where you had to click, load, scroll down, and all over again 10+ times to see older articles. Well, no one ever bothered doing that anyways.</dd> Speed</dt> The server doesn’t have anymore to dynamically generate each page that the visitor is requesting, which can take a bit of time when querying databases and such. All the assets are now static which means that the HTML pages already exist and only have to be served as-is.</dd> Privacy</dt> No more Google Analytics, Google Fonts, or embedded videos from third-party services such as Vimeo. All the pages and resources are now served directly from my host, which means no tracking whatsoever from the tech giants.[2]</a></sup></dd> Comments</dt> They are gone. This is a side-effect of having a static site and not wanting to rely on third-party services. Which is a bit sad</em>. I counted 149 comments in total (48 of them being written by myself) making it a great place to interact with you. I truly appreciated reading all the kind words, debates, critics, and whatnot, so thank you</strong>. At the end of the day, emails are well-suited for discussions, so you know what to do!</dd> </dl> I hope you guys like it!</p> Can I Has the Static Site Generator?</h2> Yes, you can. Eddi and its default theme are free and open-source so nothing’s stopping you from using it to build your own site. Except that this is not</em> so accessible nor user-friendly. You’d need to be fairly tech-savvy and even then I skipped writing any sort of documentation for now so it’s a bit rough.[3]</a></sup></p> You can find the source in eddi’s repository on GitHub</a> and you’ll also need Node.js</a>.</p> If you still feel like giving it a spin and are hitting walls, do get in touch!</p> Footnotes</h2>The content (articles) for the site are just a git</abbr></a> repository with Markdown</abbr></a> files that I can rsync</abbr></a> to the remote server.↩</span></a></li> You might want to check Replacing Disqus with Github Comments</a> for an example of what to expect when you are visiting websites using such services. And while we’re there, have a look at privacytools.io</a>.↩</span></a></li> And I probably will never write any documentation for this project because it would take me a lot of time and I don’t foresee many people interested in using Eddi.↩</span></a></li></ol></aside> Hienoi: A 2D Particle Playground 2017-10-01T13:00:00Z I initially started this project with the goal of providing a visual programming framework to introduce my friend to coding in a fun</strong> way. I could have used other existing projects such as Processing</a> instead but then I thought it’d be a good experience for me to write my own.</p> So these were my 2 objectives. Making something educational that is fun to use, and honing my own skills.</p> I quickly reached a working prototype but then, it happened</em>. Hey, you know what?</q>... How about putting the GUI and simulation modules into their own processes? And using OpenGL instead of the software renderer? And using NumPy under the hood to speed things up while preserving a user-friendly API? And allowing users to add new attributes to particles?</q> And, and, and... and I kept going like that for a while, even writing a helper library in the process, Nani</a>.</p> </span>particle trail</span></span></p> I’m still not satisfied with the amount of functionalities provided but hey, for a toy</em> project, this is not that bad and it has already fulfilled its main objectives. I think.</p> Have a go at it, grab Hienoi on GitHub</a>!</p> Release All the Things! 2017-10-01T13:00:00Z It’s been a while since I last coded anything and it’s been itching me ever since. So I paused whatever I was up to and got back onto coding a few things here and there.</p> </span>does not represent the time spent working on these libraries</span></span></p> Despite the small size of these 4 libraries, I’ve put a lot of efforts into trying to release quality products by designing the code to the higher standard permitted by my—humble</em>—knowledge, but also by covering most of the code with tests, polishing the documentations as much as I possibly could, and even providing benchmarks where it made sense. And for once</em>, I’m quite happy with the results!</p> The libraries that I have entirely rewritten are Gorilla</a>, a convenient approach to monkey patching, and Bana</a>, a set of extensions for Autodesk Maya’s Python API.</p> As for the the new ones, there is Revl</a>, which helps to benchmark code for Autodesk Maya, and Nani</a>, an alternative approach to defining and viewing NumPy’s arrays.</p> It’s been a great exercise to improve my skills in designing, building, and shipping libraries, and I hope that these projects will also serve as good examples to others or simply be useful at all.</p> More should be coming soon but for now... get them all</strong>!</p> myXKCD: Sensational Bullshit 2017-10-01T13:00:00Z </span></span></p> Nested Initializer Lists for Multidimensional Arrays 2017-10-01T13:00:00Z With the release of the template metaprogramming library m3ta</a>, I’ve included in the documentation</a> a few examples on how some utilities might prove useful.</p> I find one example particularly worth sharing here because I’ve been stuck on it for some times and thought that it might be useful to someone else. That’s the nested initializers trick.</p> But what exactly are those initializer thingies?</p> Initializer lists are a way to initialise objects using a curly braces syntax {}</code> that encloses a list of values such as {4, 9, 8, 5}</code>. Their nested version allows for more structured syntaxes like {{4, 9}, {8, 5}}</code>.</p> Since they are well suited to define arrays, let’s see how they could be used in the context of a custom multidimensional array class that would mimic the curly braces initialization properties of the built-in arrays of C/C++.</p> The Built-In Curly Braces Syntax</h2> The C & C++ languages have always provided a special curly braces syntax for the built-in arrays that allowed to define all their elements at once.</p> // Single curly braces syntax.</span> int</span> array[3</span>][2</span>] = { 0</span>, 1</span>, 2</span>, 3</span>, 4</span>, 5</span> }; </code></pre> On top of initialising the content of the array with the values passed, this syntax also comes with two neat features for the corner cases. Firstly, any element in excess is signalled with an error at compile time, and secondly, the end of the array is filled with zeroes if less values than expected are provided.</p> The nested flavour of this syntax allows to write as many levels of nested curly braces as there are of dimensions defined by the array.</p> // Nested curly braces syntax.</span> // 2-dimensional array -> 2 levels of braces</span> int</span> array[3</span>][2</span>] = { {0</span>, 1</span>}, {2</span>, 3</span>}, {4</span>, 5</span>} }; </code></pre> The difference is not only aesthetic. This last version helps localising the behaviour of the “neat features”. Namely, it provides an error message with the precise</em> location of any set of braces defining elements in excess, and likewise fills with zeroes the inner</em> sets of braces that have some values missing.</p> Otherwise, and if provided with the expected number of values, both syntaxes produce the exact same content.</p> Curly Braces Initializers for All!</h2> Now that the behaviours that needs to be reproduced are known, let’s get onto it—but not so fast! If you are not using C++11 or above, you are doomed.</p> </span></span></p> Indeed, until C++11 this convenient syntax wasn’t available for user-defined types. It’s the addition of std::initializer_list</code></a> that changed the deal.</p> If you are part of the cool kids, enabling the curly braces initializers for a type is done by simply defining a constructor taking a std::initializer_list</code> argument.</p> In the case of the single curly braces syntax, the implementation of the constructor can actually be quite concise.</p> template</span><typename</span> T, std::size_t</span> ... T_dimensions> class</span> MultidimensionalArray</span> {</span> public</span>: MultidimensionalArray</span>(std::initializer_list<T> values) { std::copy</span>(values.begin</span>(), values.end</span>(), _data.begin</span>()); } private</span>: std::array<T, size()> _data; }; </code></pre> This implementation wouldn’t take care of the corner cases though—what if the user writes 2 or 4 values when only 3 are expected?</p> What I previously called the “neat features” that are shipped with the built-in arrays are not a big deal to be implemented here.</p> template</span><typename</span> T, std::size_t</span> ... T_dimensions> class</span> MultidimensionalArray</span> {</span> static_assert</span></span>(sizeof</span> ... (T_dimensions) > 0</span>, "At least one dimension needs to be defined."</span>); public</span>: static</span> constexpr</span> std::size_t</span> size</span>()</span> </span>{ return</span> m3ta::product</span>(T_dimensions ...); } MultidimensionalArray</span>(std::initializer_list<T> values) { if</span> (values.size</span>() > size</span>()) { std::ostringstream message; message << "Elements in excess: "</span> << "expected "</span> << size</span>() << ", "</span> << "got "</span> << values.size</span>() << "."</span>; throw</span> std::invalid_argument</span>(message.str</span>()); } std::copy</span>(values.begin</span>(), values.end</span>(), _data.begin</span>()); if</span> (values.size</span>() < size</span>()) { std::size_t</span> count = std::min</span>(size</span>(), values.size</span>()); std::uninitialized_fill</span>( _data.begin</span>() + count, _data.end</span>(), static_cast</span><T>(0</span>) ); } } using</span> Iterator = typename</span> std::array<T, size</span>()>::iterator; private</span>: std::array<T, size()> _data; }; </code></pre> Once again, only the single curly braces syntax is defined here, but otherwise the same “neat features” as the built-in arrays are provided.</p> MultidimensionalArray<float</span>, 3</span>, 2</span>> array = { 0</span>, 1</span>, 2</span>, 3</span>, 4</span>, 5</span> }; </code></pre> Implementing the nested curly braces variant is slightly more involved.</p> Firstly, a new constructor needs to be defined to accept nested initializer lists, that is for example a std::initializer_list<std::initializer_list<float>></code> in the case of a 2-dimensional array.</p> Creating a such type in a generic fashion isn’t a problem, as demonstrated with the m3ta::NestedInitializerLists</code></a> trait.</p> But one thing to know is that it isn’t possible to directly iterate over all the values held within nested std::initializer_list</code>s—pointers to the next deeper nested level are returned until the very last level is reached, at which point the values can finally be accessed.</p> m3ta::NestedInitializerListsT<float</span>, 3</span>> values = { { {0</span>, 1</span>}, {2</span>, 3</span>} }, { {4</span>, 5</span>}, {6</span>, 7</span>} } }; for</span> (auto</span> secondLevel : values) { for</span> (auto</span> thirdLevel : secondLevel) { for</span> (auto</span> value : thirdLevel) { // Do something with the value.</span> } } } </code></pre> Nesting as many for-loops as there are of levels is not something that can be done generically.</p> Iterating over Nested Initializer Lists</h2> I initially tried to either flatten the nested lists into a linear sequence of elements or to find a trick based on std::array</code> to automatically inherit its properties, but nothing gave me both the exact same syntax as the built-in arrays with the “neat features” that I wanted.</p> The solution had to pass by a recursive approach.</p> The values to recurse over are the number of elements per level of the nested initializer lists—that is, its shape</em>.</p> The idea kinda goes like this: from the first level, check if the number of elements is as expected, recurse over the second level, then fill the missing elements with zeroes, and repeat until the last level is reached. At this point, do something with the values.</p> template</span><typename</span> T, std::size_t</span> ... T_shape> struct</span> NestedInitializerListsProcessor</span>;</span> // Recursive part.</span> template</span><typename</span> T, std::size_t</span> T_first, std::size_t</span> ... T_others> struct</span> NestedInitializerListsProcessor</span><</span>T, T_first, T_others ...> { using</span> NestedInitializerLists = m3ta::NestedInitializerListsT<T, 1</span> + sizeof</span> ... (T_others)>; template</span><typename</span> T_Function> static</span> void</span> process</span>(NestedInitializerLists values, T_Function function)</span> </span>{ if</span> (values.size</span>() > T_first) { throw</span> std::invalid_argument</span>( "Elements in excess within the initilizer list."</span> ); } for</span> (auto</span> nested : values) { NestedInitializerListsProcessor<T, T_others ...>:: process</span>(nested, function); } if</span> (values.size</span>() < T_first) { std::size_t</span> count = m3ta::Product<std::size_t</span>, T_others ...>::value * (T_first - values.size</span>()); while</span> (count-- > 0</span>) { function</span>(static_cast</span><T>(0</span>)); } } } }; // Last level.</span> template</span><typename</span> T, std::size_t</span> T_last> struct</span> NestedInitializerListsProcessor</span><</span>T, T_last> { using</span> InitializerList = m3ta::NestedInitializerListsT<T, 1</span>>; template</span><typename</span> T_Function> static</span> void</span> process</span>(InitializerList values, T_Function function)</span> </span>{ if</span> (values.size</span>() > T_last) { std::ostringstream message; message << "Elements in excess: "</span> << "expected "</span> << T_last << ", "</span> << "got "</span> << values.size</span>() << "."</span>; throw</span> std::invalid_argument</span>(message.str</span>()); } std::for_each(values.begin</span>(), values.end</span>(), function); if</span> (values.size</span>() < T_last) { std::size_t</span> count = T_last - values.size</span>(); while</span> (count-- > 0</span>) { function</span>(static_cast</span><T>(0</span>)); } } } }; </code></pre> For more genericity, this NestedInitializerListsProcessor</code> helper takes a function that it applies on each element iterated over. This way, the caller—the MultidimensionalArray</code> constructors here—can decide what to do with those values.</p> The first template specialisation is the recursive part while the one with the T_last</code> parameter is the equivalent of what was previously implemented within the MultidimensionalArray</code> constructor for the single curly braces case.</p> Putting All the Things into the Multidimensional Array Class</h2> Now that accessing the values of nested initializer lists is dealt with, the MultidimensionalArray</code> class can define the constructor for the nested curly braces.</p> template<typename T, std::size_t ... T_dimensions> class MultidimensionalArray { static_assert(sizeof ... (T_dimensions) > 0, "At least one dimension needs to be defined."); public: static constexpr std::size_t size() { return m3ta::product(T_dimensions ...); } // Single curly braces syntax. MultidimensionalArray(m3ta::NestedInitializerListsT<T, 1> values) { initialize<size()>(values); } using NestedInitializerLists = m3ta::NestedInitializerListsT<T, sizeof ... (T_dimensions)>; // Nested curly braces syntax. MultidimensionalArray(NestedInitializerLists values) { initialize<T_dimensions ...>(values); } private: template<std::size_t ... T_shape, typename T_NestedInitializerLists> void initialize(T_NestedInitializerLists values) { auto iterator = _data.begin(); NestedInitializerListsProcessor<T, T_shape ...>:: process( values, [&iterator](T value) { (iterator++) = value; } ); } std::array<T, size()> _data; }; </code></pre> The private method initialize()</code> defines a new template parameter T_shape</code> which refers to the shape to expect from the initializer lists to iterate over—that is the number of values in the case of the single curly braces syntax, and the dimensions of the array for the nested syntax.</p> It then defines a lambda function which simply copies each value onto the _data</code> member.</p> The MultidimensionalArray</code> class is now almost good to go—the nested curly braces constructor needs to be disabled when the array contains a single dimension to avoid ambiguous calls, and a pair of begin()/end()</code> methods need to be added to at least allow a sort of iteration. I’ll leave these as an exercise for the reader—if there is any reader left at this point? Or you can simply get the full code on this Gist</a>.</p> Additional Notes</h2> Admittedly the error messages could be improved but will hardly get nearly as good as what the compilers can generate for the built-in arrays.</p> Also, the conditions for these error messages are checked at run-time when, according to this question of mine on StackOverflow</a>, it should have been possible to retrieve the size of a std::initializer_list</code> at compile time and turn the whole check + exception combo into a simple static_assert</code>. Maybe an oversight from the C++ committee?</p> Don’t be shy and follow me on GitHub</a> if you want to check out the latest code that I’m sharing—it won’t always make it into a blog post.</p> m3ta: A Template Metaprogramming Library 2017-10-01T13:00:00Z For the needs of a personal C++ project heavily relying on templates, I found myself coding more and more template metaprogramming</a> utilities to the point where I wrote more lines of these than of the actual project itself. The time was for a refactoring—these utilities deserved their own dedicated library.</p> I thought that the process would take me only a couple of days—how naive</em> of me. Extracting some utilities that work well within a specific project and turning them into something more bulletproof with the help of an extensive set of unit tests is... quite some work. Not even talking of the documentation entirely written manually in reStructuredText</a>, without much help from Sphinx</a> on the C++ front.</p> Nonetheless, it’s now all good to go and I am pleased to introduce you m3ta</a>!</p> I’ve made the source code available on GitHub</a>. Note that this library relies on features from C++11.</p> What Sphinx helped me for though is to make the documentation</a> compatible with the beautifully themed readthedocs.org</a> website.</p> Curious About Metaprogramming?</h2> If you’re new to template metaprogramming but not to C++, I encourage you to check the examples from the documentation, the source code, or even better, to research the subject on the Internet like I did.</p> Not only could it potentially expand your way of thinking and your overall programming skills (template metaprogramming can give a small preview of what functional programming</a> is), but it would also open the doors to a whole</em> new set of tools for solving some problems more efficiently.</p> myXKCD: Christmas 2017-10-01T13:00:00Z </span></span></p> Flying Things: A Rigging Showreel 2017-10-01T13:00:00Z Here’s a proof that I’ve not been doing nothing during my last 4 years of work.</p> </span>Watch on Vimeo</span></a>character rigging showreel from 2014</span></span></p> Needless to say that I’ve done the rigs of the canisters and of the bouncing ball in full. For the rest you can check the shot breakdown</a>.</p> Modern Rigging Workflow: The Modular Approach 2017-10-01T13:00:00Z Providing solid (character) rigs that fit animators’ requirements is only a good start for a rigger aspiring to become proficient. Efficiency is the other equally important aspect so let’s discuss some leads to get there.</p> As a beginner I struggled to create a big picture of what could be a good rigging workflow. My only focus back then was on making my rigs robust and friendly for the animators. As soon as my object hierarchies and logic made sense, then it all sounded good enough to me.</p> The more I had to make some changes to the rigs I had built, the more I started to get a hint that something was wrong with my approach.</p> Since I would build them manually, it wasn’t straightforward to operate complex modifications on the structure. Clearly, numerous mistakes could make their way through during an update or another. I couldn’t even guarantee that the left arm of a character was the exact same as its right arm. As for propagating the changes to multiple characters, it would probably have been really</em> challenging.</p> Dismembering the Rigs into Modules</h2> Looking back at it now, the object hierarchy of my first rigs were quite a chaotic place—an arm here, a leg there, both most likely directly parented under the spine, while the controllers were mixed with rigging objects, deformers, previs geometries, and so on. The only neat part was the final geometry which was in its own hierarchy...</p> </span></span></p> From there, the first move was to encapsulate each logical part of a rig (spine, arm, leg, ...) into its own object hierarchy, without any external element sneaking in, and to make sure that each could work in a standalone fashion. Let’s call those logical parts rig modules</strong>.</p> Back at Action Synthèse, we implemented this approach by saving separately a scene containing the rig for each module. A module could then be imported, fit onto a specific character, and connected to the other modules.</p> </span></span></p> The fitting part was a bit sketchy—adapting a static</em> rig existing in a scene onto different characters might require to break some constraints, expressions, and hierarchies, and to recreate them only when the sizes and posing were adjusted. We added a layer of script to help with that but this whole approach is an added complexity which is highly error prone and makes it easy to break everything apart when making changes to the rig.</p> Bring on the Structure</h2> What a rig really is, is just the internals made of pistons and cogs that connect the interface given to the animators with the final deformed geometry given to the lighting department. It is only a part of a bigger picture from which we need to differentiate multiple assembly stages.</p> Now there’s not just one structure possible but many of them, interchangeable depending on the needs of each studio. A common and simple variation would include those units: rig, armature, and geometry.</p> </span></span></p> The dependencies here works only in one direction—the rig drives the armature, which in turn drives the geometry.</p> The armature is made of anything required to drive the deformations of the final geometry contained in the last unit. It acts like a buffer layer that usually includes a representation of the skeleton as well as any animated attribute that might end up driving shapes and other deformations.</p> However this structural approach is being implemented, this concept is a central piece to an efficient rigging workflow. It lays out a solid global structure for the rigs and opens the doors to much flexibility. The other building blocks just flow naturally from there.</p> Ideas to Make a Good Use of the Structure</h2> A direct benefit of splitting the structure this way is that the final geometry now only requires to be driven by the armature unit. If the animation on the armature gets baked, it is then possible to provide the lighters with a lightweight asset, stripped out from the rig unit, that they can render.</p> In the cases where complex muscle or cloth simulations are involved, baking the final geometry for the lighters is the only viable option. But a simulation unit could well be wrapped with the armature before being sent for computation on a render farm for example. No need for the full rig here neither.</p> If the geometry unit prevents the animators from having a real-time feedback, an idea could be to add a new previs unit containing only “puppet” geometries to speed it all up. It could either replace entirely the geometry unit or work alongside with it by providing a visibility toggle.</p> </span></span></p> Is the rig part of a motion capture pipeline? Insert a new motion capture unit that drives the controllers.</p> Interface and Implementation</h2> To really emphasize the idea of a rig being a glue between the interface for the animators and the final deformed geometry, it is possible—and recommended—to split the animation controllers from the rigging logic. The programming equivalent is to separate the data from the implementation—a core design principle.</p> </span></span></p> To perform this separation properly, it becomes important to fully grasp the logic of each rig module—what they require as input, how they process that data, and what they output.</p> The first advantage is that it’s easier to maintain both the interfaces and the rigs, especially when picking them up after a while or when someone else gets onto it. Indeed, like with programming, there’s more chances to understand small chunks of code, each encapsulated into routines getting a specific task done, rather than gigantic monolithic code snippets. Check out for example the idea behind the separations of concerns</a> design principle if you’re not convinced.</p> Even more importantly, it promotes reusability by allowing to swap either a rig and/or an interface independently from the other—a same spine rig module can for example be used for a neck or a small tail, and thus by simply providing different interfaces adapted to each scenario. This could as well become convenient for when a specific shot would require to manipulate the rig in a non-conventional way.</p> This separation of interface and implementation doesn’t mean that any rigging system should be prohibited from within the interface. In the contrary, it’s sometimes required to build some small mechanisms to enhance the behavior of the controllers.</p> Adding Some More Granularity</h2> To build more upon this separation of concerns, it’s possible to break each rig module in even smaller logical, self-contained parts. Let’s call them rig chunks</strong>.</p> Those allow creating some small structures that can be reused or swapped to change the behavior of a rig.</p> As with the rig modules forming the global structure, the chunks defining a rig module need to flow in a simple and predictable fashion.</p> Figuring out the right level of granularity is never easy. Starting off by turning every couple of nodes into a rig chunk under the pretext that it could possibly be reused somewhere else is definitely not the way to go and will only end up in a total clusterfuck</em> on top of being a waste of time.</p> </span>credit: xkcd</a> (CC BY-NC 2.5</a>)</span></span></p> Instead, a solid argument to turn a piece of rig into a reusable chunk would be to build everything as usual until a same pattern shows up again—maybe in a different rig—, in which case a refactorisation is beneficial.</p> As for the other good argument, it’s simple—if adding/removing a part from a rig allows to add/remove features such as the stretch system for a spine, then it is more likely to be a good contender for a chunkisation</em>.</p> The Point So Far</h2> Remember how I said that the implementation of the rig modules was sketchy and complex because of the way we did it? As nice as those rig chunks might look on the paper, they won’t fare any better if implemented in the same way.</p> Obviously, relying on static pieces of rig to implement those dynamic concepts is quite limitative here. The fundamentals needs to be revised before being able to encompass all the current and possible future requirements.</p> Following the Flow, Coding It All</h2> Each time that a concept is being isolated into a unit structure, a rig module, or a rig chunk, it really is the equivalent of creating a new function.</p> As such, the next step is to entirely</em> generate the rigs through scripts. Does it freak you out? Then forget about working at Weta Digital</a> as a rigger. Just kidding, keep reading.</p> Everyone there, ranging from junior to senior positions, picked it up easily enough. It is really intuitive and fast to use once all there is left to do is to type a few lines to import, configure and connect the rig modules together.</p> It is more involved when it comes to the lower level of creating the actual logic of each rig module and chunks, but it is for the good cause. This enforces a different approach to rigging—the encapsulation of each concept tends to be even more well-defined and modular, leading to positive restructurations of the rig elements and to a cleaner code.</p> Over time, it reaches a point where it becomes much more straightforward to read and understand the linear sequence of instructions from a well written code than a complex dependency graph with a ton of connections to follow, which is a specialty of Maya and the likes.</p> That’s only the icing on the cake but the real deal is all about being finally able to dynamically build any rig on the fly without any hack as well as being freely able to define the granularity as wished. If the code is well layed out and modular enough, this allows to create whole new variations of a rig by simply overriding a few functions.</p> Even better is the chance it gives to provide a flexible rig builder to the riggers. No more predefined object names, orientation orders, controllers shapes, etc. Everything becomes fully customizable to the point of also being able to define different behaviors for a same rig—should this spine be stretchable or not? Should there be 8 or 10 joints?</p> Note that this won’t stop anyone from creating utterly crap</em> rigs and code if the good practices are not followed.</p> The Real Deal</h2> The time for trials and errors is now over. In my opinion everything converge towards coding somehow most of the rigging workflow, but the truth being that it’s really an unnecessary pain to do this for softwares such as Maya.</p> Think about it. What’s happening there is that we’re creating an intermediary and unnecessary stage where we need to translate the rig logic (mathematical operations) into rig nodes specific to a 3D software.</p> This can quickly become a daunting task to have to create a network of interconnected nodes only to perform a few vector/matrice operations, especially since the code required for creating and connecting each node can be... substantial</em>.</p> On top of that, this can cause a great performance hit. Often, transformation nodes solely exist in rigging to hold onto rotation or translation values to then drive a constraint. Such nodes still require to have their full transformation and properties to be defined and computed, and contribute to an useless clustering of the dependency graph. That’s a lot of waste of memory and processing time.</p> So why coding a bunch of rig nodes to process the data, when it is possible to create a much more suited piece of code that would directly process that same data optimally? Well, because we couldn’t do that easily until now—maybe with the exception of VEX from Houdini</a>.</p> What’s Next?</h2> The future is all about using the right frameworks to implement our rigging logic the way we choose to. But that wouldn’t be a good reason enough to do the switch without bringing more speed to the rigs and a good portability for the long-term run.</p> That’s where frameworks such as Fabric Engine</a> kick in. With their DCC-agnostic ultra-optimized dependency graph and KL language, all the tools that we need and even more are provided.</p> Seeing the modularity of the workflow described in this article, I strongly believe that it’s shouting to be implemented as a nodal graph with the right level of granularity.</p> If you want to stay cutting edge on the rigging front, you know in which direction to head to.</p> Credits</h2> Thanks to Frédéric Bonometti, Raffaele Fragapane and Andrea Interguglielmi, for all having influenced me at some point my approach to rigging.</p> Getting Started with OpenGL in C++ 2017-10-01T13:00:00Z Learning OpenGL has been on my to-do list for as long as I can remember, but before getting too crazy on it, I wanted to start slowly by focusing on a simple project.</p> I hence began by laying out the structure of the project. I wanted to have the core to deal only with OpenGL, while having hooks with GUI toolkits—such as Qt</a> and GLFW</a>—being built on top of it in separate modules.</p> For testing purposes, I figured that the core OpenGL library could be as simple as a single class containing the required methods to setup and cleanup the OpenGL context, with a draw()</code> method for the main rendering loop.</p> // core/openglrenderer.h</span> #include</span> <GLXW/glxw.h></span></span> class</span> OpenGLRenderer</span> {</span> public</span>: OpenGLRenderer</span>(); void</span> setup</span>()</span></span>; void</span> draw</span>()</span></span>; void</span> cleanup</span>()</span></span>; private</span>: bool</span> _setup; GLuint _program; }; </code></pre> Note that GLXW</a> is one of the many OpenGL loader available. There is no special reason why I picked this one over another one, they are all similar enough.</p> The Qt 5 Struggle</h2> With this class prototype in place and a simple call to glClearBufferfv()</code></a> within the draw()</code> method, I was ready to give a go at hooking up Qt 5.</p> // qt5/openglsurface.h</span> #include</span> <QtGui/QWindow></span></span> class</span> QOpenGLContext</span>;</span> class</span> OpenGLRenderer</span>;</span> class</span> OpenGLSurface</span> :</span> public</span> QWindow { Q_OBJECT public</span>: OpenGLSurface</span>(QScreen screen = 0</span>); OpenGLSurface</span>(QWindow parent); ~OpenGLSurface</span>(); void</span> render</span>()</span></span>; private</span>: QOpenGLContext _context; OpenGLRenderer _renderer; }; </code></pre> This is a simplification of the actual class but that’s basically the idea behind it. The render()</code> method gets triggered by the event system of Qt and its role is to ensure that an OpenGL context exists before calling the appropriate methods from the OpenGLRenderer</code> class.</p> I’ve implemented the full class by thoroughly following an official example from Qt</a> but it decided not to compile.</p> That’s not due to the tutorial itself but more with the way of how Qt deals with OpenGL.</p> The C++ source file implementing the OpenGLSurface</code>’s Qt class includes the <core/openglrenderer.h></code> header, which implicity also includes the GLXW header—that’s when Qt starts screaming.</p> Without going into the details, the QtOpenGL</code> module (from Qt 5.2) doesn’t like mixing with external OpenGL loading libraries such as GLXW, GLEW and others.</p> I came to realize anyways that exposing the <GLXW/glxw.h></code> file into a public header from the OpenGL core I was writing meant that any project linking to that library also had an extra compile-time dependency towards GLXW to take care of. That’s not only annoying but it also isn’t required—that dependency should be kept internal to the core library.</p> Pimpling It Up</h2> The idea was to break this extra dependency by making any reference to GLXW and OpenGL invisible to the public. A true</em> abstraction.</p> The easy solutions is to replace any reference to OpenGL typdefs such as GLuint</code> for their actual standard types. But even though it would be fine in most cases, it could potentially break the portability of OpenGL and is largely</a> not recommended</a> by the Internet</a>.</p> That’s where the pimpl idiom</a>—also called opaque or d pointer, and widely used in Qt—comes to the rescue.</p> The public interface of the OpenGLRenderer</code> was already good to go as it was, but the GLuint _program</code> private member was at fault—as well as the others to come.</p> The pimpl idiom is all about replacing the current private members of a class by pointing to a new class where the members have been moved to.</p> // core/openglrenderer.h</span> //#include "openglrenderer.h" < Not required anymore!</span> class</span> OpenGLRenderer</span> {</span> public</span>: OpenGLRenderer</span>(); void</span> setup</span>()</span></span>; void</span> draw</span>()</span></span>; void</span> cleanup</span>()</span></span>; private</span>: class</span> Impl</span>;</span> Impl _d; }; // core/openglrenderer_impl.h</span> #include</span> <GLXW/glxw.h></span></span> #include</span> "openglrenderer.h"</span></span> class</span> OpenGLRenderer</span>:</span>:Impl { public</span>: bool</span> setup; GLuint_program; }; </code></pre> On top of removing dependencies, the pimpl idiom also provides the convenience of having a cleaner public API, faster compilation times, and helps preserving binary compatibility.</p> A more advanced definition and usage is available in 2 parts on Sutter’s Mill website: Compilation Firewalls</a>, part 2</a>.</p> GLSL Shaders</h2> Happy with the implementation of my OpenGL core with Qt 5 and even GLFW, I coud move onto going through the great OpenGL SuperBible</a> to learn some basics.</p> After writing a couple of GLSL shaders the way they show it in the first chapters, I already couldn’t take it anymore.</p> How could I possibly go through the entire book by wrapping each</em> line of the shaders within double quotes while making sure they all end with a newline \n</code> character?</p> static</span> const</span> GLchar vertexShaderSource[] = { "#version 430 core\n"</span> "void main(void)\n"</span> "{\n"</span> " const vec4 vertices[3] = vec4[3](\n"</span> " vec4( 0.25, -0.25, 0.5, 1.0),\n"</span> " vec4(-0.25, -0.25, 0.5, 1.0),\n"</span> " vec4( 0.25, 0.25, 0.5, 1.0)\n"</span> " );\n"</span> " \n"</span> " gl_Position = vertices[gl_VertexID];\n"</span> "}\n"</span> }; </code></pre> Frankly I couldn’t imagine the pros writing their shaders like this either. I had to find a solution, one involving having each of my GLSL shaders in a separate file and loading them somehow in OpenGL.</p> The Dynamic Approach</h2> The only OpenGL function available to set the source code of a shader is glShaderSource()</code></a> and it expects the source to be given as a const GLchar </code>.</p> The obvious first move was to open a shader file and convert its content into a character buffer at runtime.</p> It’s an easy task and the web crawls with examples to do just that.</p> void</span> setShaderSourceFromFile</span>(GLuint shader, const</span> GLchar filename)</span> </span>{ std::ifstream file</span>(filename)</span></span>; if</span> (!file.is_open</span>()) { std::cerr << "Unable to open file "</span> << filename << std::endl; return</span>; } std::stringstream stream; stream << file.rdbuf</span>(); file.close</span>(); std::string string = stream.str</span>(); const</span> char</span> code = string.c_str</span>(); glShaderSource</span>(shader, 1</span>, (GLchar )&code, 0</span>); } </code></pre> One thing to keep in mind is that if a relative filename is passed to the std::ifstream()</code> constructor—which will most likely be the case—and that the application is started from a shell, then this can lead to problems.</p> Paths are defined relatively to the shell’s current directory rather than to the location of the binary, so it’s important that the shaders can be found from where the application is being started.</p> That’s probably one of the reasons of why there’s so many launchers out there that initialize a working environment before firing the actual application—finding resources at runtime.</p> The Static Approach</h2> How about using an #include</code> statement to make the shader available into the C++ code at compile-time?</p> The idea here is to automagically convert the content of each shader file into a multiline string literal, like the ones showcased in the OpenGL SuperBible.</p> That’s a parsing job simple enough for CMake and it can be wrapped in a custom target.</p> add_custom_target</span>( shaders COMMAND</span> ${CMAKE_COMMAND}</span> -DSOURCE_DIR=${CMAKE_CURRENT_SOURCE_DIR}</span> -DDESTINATION_DIR=/path/to/formatted/shaders -DFILES="${shaders_files}"</span> -P /path/to/shaders.cmake COMMENT "Creating the files to include the GLSL shaders"</span> ) </code></pre> The command defined in shaders.cmake</code> is where the main logic happens:</p> separate_arguments</span>(FILES) foreach</span> (file</span> ${FILES}</span>) set</span>(filename ${SOURCE_DIR}</span>/${file}</span>) get_filename_component</span>(name ${filename}</span> NAME_WE) set</span>(source ""</span>) file</span>(STRINGS ${filename}</span> lines) foreach</span> (line ${lines}</span>) set</span>(source "${source} \"${line}\\n\"\n"</span>) endforeach</span>() file</span>( WRITE ${DESTINATION_DIR}</span>/${file}</span> "static const GLchar ${name}ShaderSource[] = {\n"</span> "${source}"</span> "};\n"</span> ) endforeach</span>() </code></pre> For each shader file found, CMake will create a new C++ file in the destination directory containing a single GLchar *</code> variable that can be directly passed to the glShaderSource()</code> function.</p> Bootstrapping It All</h2> At this stage everything was ready for me to get started on OpenGL for good—I could write my OpenGL code and GLSL shaders independently from anything and then preview the result within the GUI toolkit of my choice.</p> I’ve decided to save a checkpoint of this progression by wrapping everything in a bootstrap that I could reuse later on as a starting point for any project. It can be found on GitHub</a>.</p> Since I couldn’t decide which method to use for loading the GLSL shaders, and that it after all depends on the needs of each, I’ve added in the bootstrap an option for the user to switch between the dynamic and the static approach.</p> Support for both GLFW and Qt 5 (with or without the QtWidgets module) is also provided out of the box.</p> I’ve tested it only on Mac OS X so far but porting it to either Linux or Windows shouldn’t be a problem, if it’s not working already.</p> Time to get those pixels moving!</p> Why I’m Not Using the MEL and Python Command Layers of Maya 2017-10-01T13:00:00Z There’s a large amount of things that frustrate me in Maya. The MEL and the Python command layers being two of those that I’d rather not have to ever use again.</p> But first, here’s a disclaimer. My sole objective here is to genuinely</em> share my—hopefully objective—point of view and experience in the hope that it’ll get some to think about it. I’m not saying that this is the one and only valid approach, I’m just explaining why I’ve chosen this one. Good on you if you manage to create some bulletproof and awesome scripts using the MEL or the Python command layer.</p> Preface</h2> To draw a quick parallel, both a command layer and an API are also available in Softimage. The question of which one to use has never been asked but by the beginners just getting started.</p> The API has always been the obvious choice. The command layer has its use but mostly for the artists out there who want to automatize a task by copying the log from the script editor that results from their interactions with the UI.</p> Funnily, I must be one of the rare living soul to use the Python API of Maya for daily tasks.[1]</a></sup> But does being alone against all necessarily mean that I’m doing it the wrong way? I hope</em> not.</p> Introducing the MEL Command Layer</h2> Back then, there only was 2 options to code within Maya: MEL or the C++ API. The latter is largely overkilled for most of the tasks of a TD and is also harder to access and iterate. Logically, everyone turned to MEL. But what is MEL?</p> </span></span></p> The official documentation of Maya tells us that MEL is derived from a UNIX shell language. Hence why it is called a command layer. It exposes a bunch of global commands like the ones that we would type into a shell to list the content of the current directory or to move onto another directory. ls -la</code>, cd ./path/to/other/directory</code> and the likes. Hey wait, there’s even a ls()</code> command in MEL too!</p> I’ve been baffled more than once by the quality of the MEL code that I was seeing. It was written with incredibly terrible coding practices to the point that I was wondering if the persons knew anything about coding at all. Now I finally understand why it was the case. They’re not to blame. That’s MEL’s fault.</p> My own theory is that MEL has been created with the sole purpose of describing ASCII Maya scenes. It probably wasn’t intented to be used as a scripting language with which one could write any serious code with. It just happened to be the case because the community was lacking of options.</p> Of course I know that you’ve all made awesome scripts that can do this and that. I wrote some myself, maybe not that</em> awesome. But it’s like trying to sprint with ice skates.</p> Look at it, all we’ve got is that jungle of nonsensical global commands, each spammed with a ton of confusing flags that are often incompatible with each other. Good luck at figuring out a logic there.</p> It gets better over time, but not because it</em> starts to make sense. Only because we</em>’re getting used to it. That said, even today I’m still never sure which command from getAttr()</code>, attributeInfo()</code>, and attributeQuery()</code> I should be using when needing to retrieve some information about an attribute. Any hint?</p> The point being that those commands are not made to make sense as a whole. They all achieve something specific but don’t always play well as part of a team. It’s as if the program to write was a huge puzzle and that we were constantly looking for pieces that might hopefully cover the surface without necessarily fitting into the neighbour pieces.</p> Once again this becomes almost anecdotal over time so let’s move on to something more important. Knowing how complex the dependency graph in Maya is, how can referring to a node in a scene solely by its name can be a robust approach at all?</p> Strings Are Not Sexy</h2> To put things back into context, I’m a rigger. I’m spending a lot of time dealing with hierarchies and I like writing modular rigs.</p> Modular rigs makes it more than likely to have a same hierarchy of nodes being reused in a same scene. Instead of prefixing the name of each of my nodes with a hundredth of characters worth of different information to ensure that their names are unique within the scene, I prefer to stay simple and call them ‘root’, ‘spine’, ‘arm’, ‘whatever’, and so on.</p> From there, let’s consider a first example.</p> from</span> maya import</span> cmds root = cmds.group(name='character'</span>, empty=True</span>) l_arm = cmds.group(name='l_arm'</span>, parent=root, empty=True</span>) r_arm = cmds.group(name='r_arm'</span>, parent=root, empty=True</span>) l_node = cmds.group(name='node'</span>, parent=l_arm, empty=True</span>) r_node = cmds.group(name='node'</span>, parent=r_arm, empty=True</span>) l_child = cmds.group(name='child'</span>, parent=l_node, empty=True</span>) r_child = cmds.group(name='child'</span>, parent=r_node, empty=True</span>) </code></pre> See the problem here? The variable l_node</code> is pointing to a node named node</em> but can suddenly become invalid simply because another node has been created in the scene, and thus even though the node pointed by l_node</code> hasn’t been modified in any way.</p> Of course this snippet of code reflects a terribly poor coding practice and the issue could be avoided much easily.</p> But the point here is to show a weakness in referring to nodes by their names. As bad as this snippet can be, it is still made of a valid serie of calls and should work in any decent API. It should not</em> require the developer to know how the internals of the API works to workaround an issue that shouldn’t require any workaround.</p> Ok, let’s move on with another example.</p> from</span> maya import</span> cmds def</span> toFullPathName</span>(node</span>):</span> return</span> cmds.ls(node, long=True</span>)[0</span>] root = cmds.group(name='character'</span>, empty=True</span>) for</span> arm_name in</span> ['l_arm'</span>, 'r_arm'</span>]: arm = toFullPathName(cmds.group(name=arm_name, parent=root, empty=True</span>)) node = toFullPathName(cmds.group(name='node'</span>, parent=arm, empty=True</span>)) child = toFullPathName(cmds.group(name='child'</span>, parent=node, empty=True</span>)) </code></pre> This snippet solves the previous issue by introducing a loop statement.</p> Also, this time each node is stored by using its full path name instead of its partial path name to ensure a false impression of robustness that will be highlighted by the next example to come.</p> Note here the lack of consistency within the command layer: the group()</code> command doesn’t have any flag to retrieve the full path name when many other commands have it. Funnily this flag can sometimes be accessible in other commands but under different names such as long</code>, longName</code> or fullPath</code>, probably depending on the personal preferences of the coder at that time.</p> As a result, we don’t know what we’ll get as a return value from the group()</code> command: a name or a partial path name? It’s like magic and depends on the content of the scene. Yet another thing to take into consideration when coding.</p> If we want to consistently deal with full path names then we’re left with calling a quite ugly workaround using the ls()</code> command.</p> Now, and even though the flaws listed so far are not excusable, there’s still nothing that we can’t get used to with a bit of time.</p> The straw that broke the camel’s back is that, as a rigger being, I often have to insert objects within a hierarchy, reparent nodes, and so on. It would for example be common for me to add a parent to each node from a hierarchy to set their local transformations to identity in a post-process pass.</p> A naive approach of such an operation would look like this:</p> from</span> maya import</span> cmds def</span> toFullPathName</span>(node</span>):</span> return</span> cmds.ls(node, long=True</span>)[0</span>] nodes = [] root = cmds.group(name='character'</span>, empty=True</span>) for</span> arm_name in</span> ['l_arm'</span>, 'r_arm'</span>]: arm = toFullPathName(cmds.group(name=arm_name, parent=root, empty=True</span>)) node = toFullPathName(cmds.group(name='node'</span>, parent=arm, empty=True</span>)) child = toFullPathName(cmds.group(name='child'</span>, parent=node, empty=True</span>)) nodes.extend([node, child]) for</span> node in</span> nodes: parent = cmds.listRelatives(node, parent=True</span>, fullPath=True</span>)[0</span>] buffer = toFullPathName(cmds.group(name='buffer'</span>, parent=parent, empty=True</span>)) cmds.parent(node, buffer) </code></pre> Without knowing the API and simply by reading the code from this snippet, the result seems fairly predictable. Except it’s not. This code errors out due to trying to retrieve an object from a full path name that is not valid anymore because of the changes made to the hierarchy. You thought you that had a solid reference to your node? You don’t</em>. You simply can’t with strings.</p> Some possible workarounds to this one are quite funny actually. Either we could do our parenting pass after having sorted the list of nodes from the one at the bottom of the hiearchy to the one at the top, or we could store them in a temporary set to make sure that we keep a solid reference to them.</p> In both cases we would still end up with invalid references if we had to use these nodes again later on in our code. The exception being if we reassign the variables each time with their updated full path name. Quite error-prone.</p> So What?</h2> Those are only 2 basic examples that I can remember despite not having used Maya in over 1 year. Believe me, I banged my head in frustration a whole lot more than that.</p> So how do I feel about this command layer? Pretty insecure I have to say. Why would I be keen in using a scripting interface that exposes so many inconsistencies and flaws?</p> Yes it’s usable and works well if one knows all the corner cases and take care of them. But it’s not something that I want to waste my energy dealing with only to end up in a state in which I would never have the confidence that a certain variable still points to the node I’d expect it to. And that sucks. Heaps.</p> Those are facts that most of you probably already know and have accepted dealing with. I didn’t.</p> Once again, I fully respect any approach and believe they are valid as soon as the code produced is robust. I chose the Maya API back in 2010 because it was simpler for me to write such code, that’s all.</p> Now if you expect me to praise the Maya API, this won’t happen neither. I actually understand why not so many people dare to adventure in there—it goes straight in the lower end of the user-friendliness scale, especially its Frankenstein-like Python version, and has its own pitfalls.</p> But at least it has a sort of organization with its object-oriented approach and most importantly: we can reference nodes as nodes.</p> In other words, I chose it because my priority was to write robust</em> code and it felt like the less worse option at that point in time. Also I was keen to invest some of my time to make it more usable on a daily basis by developing some extensions through monkey patching</a>.</p> Footnotes</h2>If not, please raise your hands, it’ll make me feel less lonely.↩</span></a></li></ol></aside> From Monkey Patching the Maya Python API to Gorilla and Bananas 2017-10-01T13:00:00Z Or how I went from patching the Autodesk’s Maya Python API to creating a more generic solution for extending any library in Python.</p> </span>credit: Matt Reinbold</a> (CC BY-SA 2.0</a>)</span></span></p> Coming from Softimage and having had previous experiences with various libraries, it was a shock</em> when I first came face-to-face with the API of Maya.</p> Many like to think of it as being flexible but I mainly see it as a pain</em> to use. It’s clunky and inconsistent at best, and lacks basic methods that would make everyone’s life easier.</p> Fortunately, I don’t even have the words to describe its port to Python but I thought more than once about hanging the one who believed that using the MScriptUtil</code> abomination to retrieve values such as the scale of a MFnTransform</code> object would be a good idea.</p> As a result I quickly started to hate my job until I thought that I needed to find a way to make this thing more usable. It ended up becoming the perfect playground for experimenting some monkey patching techniques in Python.</p> Extending the Maya API?</h2> In C++, if we want to extend an external object-oriented library such as the Maya API, there’s often no much choices offered to us. Because of the static nature of the language we’ve got no way to directly modify the built-in classes. All we can do is add some patches on the side rather than in-between.</p> Patching on the side equals here in extending the classes through inheritance. This approach wouldn’t play so well in our case. Indeed, we would have many castings to do from the original types to our own derived types, and we would end up losing the object-oriented benefits anyways: each method that we would add to a certain class would only be available in the scope of that class and won’t be inherited by any of the built-in classes.</p> For an analogy, imagine that you have a system of pipes that you want to modify to provide hot water. All you can do is to derivate from what’s already out there without being able to link your extensions back onto the original system. Only your new system will have hot water, not the existing one.</p> </span>still no hot water on the right side!</span></span></p> If the API doesn’t provide a way to insert new methods into the existing classes at runtime, then what are our options?</p> We’re left with creating global functions taking as first argument a pointer or a reference to the class we want to extend. It does the job, but it’s not so object-oriented anymore even though it preserves polymorphism. Wrapping the original API into a new one could be another solution but a colossal and hard to maintain work too.</p> But that’s C++ and we want to use Python.</p> Python to the Rescue</h2> Unlike with C++, everything in Python is an object</a>. Even classes, functions and numbers are objects. We can assign those objects to variables, they most likely have attributes, and we can inspect and modify them at runtime.</p> This concept is at the same time both incredibly powerful and</em> dangerous.</p> In our case, it gives us the chance to improve the Maya Python API on the surface by allowing us to sneakily insert new methods but it also makes it easy to fuck up everything if we’re not so wise. Welcome to the monkey patching world.</p> Monkey Patching ABC</h2> Let’s check out the basics of the technique with a serie of examples.</p> from</span> maya import</span> OpenMaya dummy = OpenMaya.MObject() print</span>(dummy.apiTypeStr()) print</span>(dummy.isNull()) </code></pre> Here we initialize a dummy</code> variable containing an instance of the class MObject</code>. As it is right now, this dummy</code> variable doesn’t hold any valid Maya object internally but that’s enough for us to play around and have access to the methods defined within the MObject</code> class.</p> You’d better off checking the Maya documentation to know what methods are available to call but we can also list them at runtime with a Python’s built-in function: dir()</code></a>.</p> from</span> maya import</span> OpenMaya print</span>(dir</span>(OpenMaya.MObject)) </code></pre> As per Python’s documentation, the dir()</code> function tries to list all the attributes of an object. Simply put, this will print here a whole bunch of names that correspond to the methods and data variables defined for the class MObject</code>. The ones surrounded with double underscores are the internal “magic” attributes mostly generated by Python that we’re not supposed to touch—for now.</p> Since we said that everything in Python is an object, nothing stops us from getting the value assigned to those attributes listed previously. There’s another function built-in in Python to do just that: getattr()</code></a>.</p> from</span> maya import</span> OpenMaya for</span> attribute in</span> dir</span>(OpenMaya.MObject): print</span>('%s: %s'</span> % (attribute, getattr</span>(OpenMaya.MObject, attribute))) </code></pre> The attribute apiTypeStr</code> for example is assigned with an unbound method object. That unbound method object is a legacy from Python 2 to represent methods that haven’t been called from a class instance. But this is just an unimportant detail for this scope.</p> What matters is that we can indeed retrieve those attributes at runtime, and that if there’s a getattr()</code> function, then there must be a setattr()</code></a> one.</p> setattr()</code> allows us to assign new values to existing attributes but also to define new ones if they don’t exist yet. That’s precisely what we need to insert a new awesome method directly within the MObject</code> class.</p> from</span> maya import</span> OpenMaya def</span> awesomeFn</span>(self</span>):</span> return</span> "Everything is awesome! Even this %s thing."</span> % self.apiTypeStr() setattr</span>(OpenMaya.MObject, 'awesome'</span>, awesomeFn) dummy = OpenMaya.MObject() print</span>(dummy.awesome()) </code></pre> That’s all it takes. Thanks to this one liner, we now have access to the awesome()</code> method as if it has always been part of the MObject</code> class.</p> But that’s also where the danger is. By inadvertance—or madness</em>—, you could replace an existing method. This is allowed in Python since once again it is considered as a simple reassignment of a variable with another object. Of course you’ve changed the expected behavior of that method, causing a subtle bug showing up only late in the production. Congratulations, you’ve broken everything and are about to get fired.</p> A first option would be to prefix all your own methods with something unlikely to be ever used by the developer team of Maya. The method awesome()</code> could for example be called bnnAwesome()</code>.[1]</a></sup></p> Secondly, you could check if a method already exists, just to make sure. And if it does, then just give up. It’s better to preserve the original behavior rather than inserting your broken method that you couldn’t even figure out how to name properly.</p> Quizz on how to check if a method already exists? The global function hasattr()</code></a>.</p> Now, there’s a last option if really, really</em>, you have a good reason, you know what you’re doing at 2000%, and you don’t mind getting fired. Should I say that it’s highly unrecommended? Well, it is. Use at your own risks. You’ve been warned.</p> That last option consists in storing the existing method under a new name such as _original_awesome()</code>. This way, the overidden method remains callable within our code if we wanted to preserve its original behavior as we should.</p> Inheritance</h2> Since we’re inserting methods into an existing class hierarchy, this means that inheritance is automagically preserved.</p> </span>inheritance diagram for the MFnTransform class</span></span></p> In other words, if we insert a method bnnAwesome()</code> in MFnTransform</code>, then it will also be available in the all the classes defined on the right of MFnTransform</code> from the graph above.</p> from</span> maya import</span> OpenMaya, OpenMayaAnim def</span> awesomeFn</span>(self</span>):</span> return</span> "Everything is awesome!"</span> # Patch the `MFnTransform` class.</span> setattr</span>(OpenMaya.MFnTransform, 'awesome'</span>, awesomeFn) # Use the method in the `MFnIkJoint` class.</span> dummy = OpenMayaAnim.MFnIkJoint() print</span>(dummy.awesome()) </code></pre> And that’s awesome.</p> A Naive Implementation</h2> As effective as this code can be, this won’t take us every far and it would quickly become cumbersome if we had to manually repeat this process for each method that we’d like to patch.</p> The original approach that I used in production was to create a bunch of Python modules, each named as per the OpenMaya class that I wanted to patch, and each containing a list of functions to insert.</p> A function could be inserted either as a normal method, a class method, or a static method depending if self</code>, cls</code> or nothing was defined as first keyword.</p> It’s been really easy to use but it felt a bit hacky.</p> That’s why I recently came up with the idea of building a library to provide a convenient—and flexible—approach to monkey patching.</p> The Real Deal: Gorilla</h2> With the library Gorilla</a>, you can patch anything as soon as it makes sense.</p> Marking our awesome method as being an extension for the target class OpenMaya.MFnTransform</code> becomes as easy as:</p> import</span> gorilla from</span> maya import</span> OpenMaya @gorilla.patch(OpenMaya.MFnTransform</span>)</span> def</span> bnnAwesome</span>(self</span>):</span> return</span> "Everything is awesome!"</span> </code></pre> If many methods are to be patched into a same target class, it can be quicker to define them into a class and mark that class as an extension itself.</p> import</span> gorilla from</span> maya import</span> OpenMaya @gorilla.patch(OpenMaya</span>)</span> class</span> MFnTransform</span>(object</span></span>):</span> def</span> bnnAwesome</span>(self</span>):</span> return</span> "Everything is awesome!"</span> def</span> bnnMoreAwesome</span>(self</span>):</span> return</span> "Everything is even more awesome!"</span> </code></pre> Our MFnTransform</code> class is here to be directly patched into the module OpenMaya</code>. Since a class with that name already exists in the target module, it’s each method of our class that are going to be individually inserted into the OpenMaya.MFnTransform</code> class while preserving the ones built-in.</p> To apply the actual patching, a function is provided to recursively look into all the modules from a given package for any extension marked with the gorilla.patch()</code> decorator. The extensions found are then applied.</p> Properties, class methods, static methods, and whatsoever are also supported as extensions. Other features include the possibility to define what needs to be patched at runtime and how. But really, the documentation of Gorilla</a> does explain all the details more nicely.</p> The best in all that? The code is relatively straightforward and works for both Python 2.6+ and 3.3+. Have a look by yourself, get the source on GitHub</a>.</p> A Banana for Maya</h2> As a proof of concept for the library Gorilla, I’ve made a set of extensions for the Maya Python API v1.0.</p> In its current state, it’s not very furnished but it still provides a good starting point with a set of methods to easily retrieve and iterate through the nodes of a scene.</p> It’s—logically?—called Bana and can also be found on GitHub</a>. Here again, I’ve put some decent efforts in the documentation</a> if you’re curious.</p> Final Note</h2> When I decided to adopt this approach, it was back in 2010 and I had my own—not necessarily valid—reasons to do so. PyMEL</a> wasn’t shipped with Maya and I refused to use the Python command layer of Maya which is a simple 1:1 of the atrocity</em> that MEL is.[2]</a></sup></p> Even today I would most probably go the same way as it served me quite well and made me proud of successfully taking on the challenge of using that Maya Python API in production.</p> Now, by publishing this article, I do not intend to say that monkey patching the Maya Python API is the way to go. There’s other alternatives out there that are probably better suited for the vast majority of the use cases and that won’t require any extra work on your end.</p> Whatever path you choose, do it because you feel comfortable using it on a daily basis and make sure that you can get your things done efficiently.</p> Having the monkey patching technique in hands simply gives you the bonus option of being able to extend any Python library to your wishing if you need to, and as a last resort kind of things.</p> Use it wisely.</p> Footnotes</h2>bnn</em> like banana.↩</span></a></li> You can read more in Why I’m Not Using the MEL and Python Command Layers of Maya</a>.↩</span></a></li></ol></aside> A Taiwanese Monk at the Salar de Uyuni, Bolivia 2017-10-01T13:00:00Z The Salar de Uyuni, one of these surreal places that I had in mind at the time when I bought my camera only to realize that a simple Photoshop gradient would have got me the same result. Minus the Taiwanese monk.</p> Mid-June is the dry season in Bolivia but it’s also winter time. It can get relatively</em> cold at an elevation of 3,500 m, and it gets even colder when you’ve got a salt flat covering a surface of 10,500 km² nearby.</p> Since the freezing nights in the non-heated rooms of an hostel in Uyuni were not enough, I decided to go for the next level—waking up at 3 a.m. to make it for some night shoot of the stars and most importantly for the sunrise over the Salar de Uyuni.</p> There were 5 crazy of us in the group to volunteer for a hypothermia experience: 3 Japaneses, a Vietnamese, and the usual French. We all got a bit disappointed when our guide Ricardo drove us to the spot only to tell us that it won’t be possible to shoot the stars this time since the light of the full moon was polluting the sky. We had to wait for another 2 hours before sunrise.</p> The car was heated and felt like our last rampart between us and the cold out there. The few rapid excursions to get some snaps got us frozen within seconds. When the fingers reached the point of not being able to press the shutter button anymore, it was time to get back into the car to warm up until the next attempt.</p> View on Flickr</span></a>before sunrise</span></span></p> The results of our brave efforts ended up looking pale in comparison to when the light finally showed up. The 5 minutes during which the sky turned pinkish/blue while being perfectly mirrored on a thin layer of water was simply speechless. And disturbing of simplicity too. It couldn’t look any more fake.</p> </span>a (Photoshopped?) French</span></span></p> View on Flickr</span></a></span></p> That sunrise over the Salar de Uyuni was just for us. We were the only 5—plus Ricardo—to dare adventuring over there at that time. We felt privileged and took the usual touristic photos.</p> </span>the Daltons</span></span></p> After such a beautiful experience, I was craving for some more. I didn’t make all the way to Uyuni, especially after coming close to death around 10 time on the way from Sucre</a>, for only one sunrise. I signed up for a 1-day tour the day after. I wanted to see the dried and cracked parts of the salt flat.</p> This time I definitely wasn’t one of the few to have had that idea. The dozen of tour agencies in Uyuni were fully booked and soon we reached our first target—the train cemetery—accompanied by a good hundredth of other tourists.</p> There I was, back into a tourist trap</strong>. After one had the idea of climbing a train to get a new Facebook profile picture, they were all onto it, proudly posing on top of those metallic carcases. Fortunately they didn’t spot the one sneakily tagging his name on a train further away or they might all have done the same.</p> Needless to say that taking a photo without anyone on it was close to a miracle. Panoramics were of course out of question.</p> </span>that’s life</span></span></p> We were only allowed 15 min on each spot to do our things before heading to the next destination. The exception was the popular Isla of Incahuasi. It was our lunch spot.</p> After filling our rumen, we had 1.5 hours of free time to enjoy ourselves. Actually there wasn’t much to do. The only 2 choices were to either take photos using the immense surrounding desert as a playground or to visit the island (and its toilets) for 30 BOB. It all seemed like a well planned invitation for us to play our roles of milk cow.</p> Was it worth it so far? I don’t know. But fortunately a not so usual event made that day more interesting. A Taiwanese monk happened to also visit the Salar de Uyuni and was luckily sharing our car.</p> Ariano talks many languages, is full of energy, has his approach to peace, and likes to take photos of the road with his tablet while sitting in the passenger seat. A great man.</p> View on Flickr</span></a></span></p> When reaching an hostel/museum entirely made of salt, we’ve been reminded of the recent Dakar rally raid</a> that took place here in 2014. I firstly thought of the possible negative impact that such a race might have on the environment but then... well, I enjoy racing myself and selfishly couldn’t help thinking how fun it would be to rally drive on Uyuni’s salt flat.</p> Our driver for the day seemed to know more than me on the subject and told me that joining the Dakar was mainly a matter of having a lot of money to spend. The salar will host another race during the wet season of 2015. Maybe another time?</p> View on Flickr</span></a>the Dakar passed by here</span></span></p> The wet season is the recommended time to visit the salar. The temperatures are warmer, the entire surface of the salt flat is covered with water and there are chances to have the sky made of awesomeness: menacing gigantic clouds forming a beautiful ambiance for photography.</p> We didn’t have all that but we could still comfort ourselves with the highlight of the day—spending the sunset on the small area still covered by water. For the clouds, I’ll have to come back later.</p> View on Flickr</span></a></span></p> myXKCD: CPU benchmark 2017-10-01T13:00:00Z </span>100% viable</span></span></p> ccRig: A Rig for Softimage Back from the Dead 2017-10-01T13:00:00Z Having the limbs producing nice curvatures at any stretch value while being configurable and robust? Those were my goals for a rig prototype that I wanted to get done. It was back in 2006. It had a good run and it’s now live again. Sort of.</p> The Apogee</h2> One of my very first gig as a character TD was a pitch for The Stupid Invaders</cite>, a cartoony movie. The characters had thin arms that could be highly</em> stretchable and bendable. The rigs were working mostly great and my job back then was to fix any eventual issue happening on a per shot basis.</p> That’s when I thought that I should challenge myself with a prototype of my own. It had to be able to stretch limbs without any limit and still always produce nice curvatures that are easy to control. And of course, it had to be robust—no more popping. Ever</em>.</p> A couple of years later, in 2008, I’ve been showcasing this rig in my first rigging showreel</a>. We could already see stretching and bending of limbs in every showreel, but I knew there was something different to this approach.</p> I decided to share my researches for educational purposes and released the rig for free at the same time than my showreel.</p> </span></span></p> I didn’t except such a response from the community. Overwhelmed would be an understatement. Coming out from the unknown and having my work showcased on the front pages of various community websites was just unthinkable.</p> It helped me to gain a bit in confidence but that’s also when I understood that “success” had a price. I had to pay for the 930 GB of extra bandwith that I’ve been using for the previous 2 weeks. That was an excess of 4750%</strong> of the quota that my web host was providing.</p> Back on Track</h2> In November last year, with the release of my brand new website, I thought that it was about time to flush out all the old resources and start over from scrach. Who could be using this rig anyways? I mean... that rig was created with Softimage\|XSI 6.5, you know!</p> Turns out I was wrong. The traffic logs were consistently showing requests to the old ccRig resource page that now leads to a 404 error. Maybe some naive animators thinking they’ll find the rig of their life in there. They too couldn’t be more wrong. But that’s not my problem—you want it, you got it. You can now download</a> it and do your things.</p> I’ll repeat it though. This rig was only built for educational</em> purposes. Not that I will prevent you from doing any showreel, commercial work or whatsoever with it—no, the truth is that it is simply not suited for proper animation work.</p> From an animation point of view, its spine is terrible to the point of being broken and it lacks any facial rig. Now, if you’re of the stubborn/masochist type, or if you simply like challenges, I’d still love to see what you can manage to do with it.</p> From a more technical aspect, the rig itself is highly outdated in the way it is being layed out and won’t serve as a good reference.</p> I still believe that there’s some value to the logic behind the stretchy/curvy system of the limbs though, which is why I put it back online—for the rigging beginners out there to selectively learn some bits from that logic. And only that. Nothing else for your own sake. Don’t come complain to me afterwards if you get fired because you’re rigging like in the 60’s.</p> Download</h2> </span> ccRig v0.11</strong></a></p> Note that the rig is provided as it was back then. I don’t even know if it opens in the latest versions of Softimage.</s> Thanks to Eric Thivierge, the rig apparently survived to the Autodesk era and made it through to the final version of Softimage! I can be proud of my weed.</p> </div> Softimage Has Been Killed, the Future of CG Softwares Is Now in TD’s Hands 2017-10-01T13:00:00Z Softimage did shine in more than one’s heart until it met its fate with Autodesk. Our dear software is now dead but not our experience nor our vision. It’s now up to us to make the future brighter.</p> </span></span></p> Softimage the Great</h2> When I started to learn 3D on my own as a teenager, I used to play around with Maya 2.5. It looked complicated and unintuitive, which paradoxically excited</em> me. Everyone within the online community that I was frequenting found it hard</em> to use. I liked the challenge. And the splashscreen too.</p> I kept reading good reviews about the recently released Softimage\|XSI and decided to try it out one day. I gave up 30 minutes after opening it. I didn’t like the default shortcuts, I didn’t like the UI. I didn’t give it a chance.</p> It’s only when I got in touch with Action Synthèse in 2005 that I got back into it. I had no other choice if I wanted to land an internship anyways. For that reason I took the time to setup my own shortcuts, to get used to the UI, and to get some sensations going.</p> It didn’t take long, it was a blast</em>. I realized how stupid</em> I was to give up so easily before.</p> My goal was to learn rigging and it was the best tool for that. There was nothing preventing me from applying my ideas—Softimage had a fast learning curve, it was intuitive, and made perfect sense. Thanks to that in no time</em> I felt comfortable to get some rigs going.</p> I never wrote any line of code before then but I thought it would be a good idea to also learn how to develop. That’s how I started to use the Softimage SDK. I struggled quite a bit at understanding how to write my code in the first place but the API itself was no problem. Here again, everything</em> made sense, even for a total beginner like me, and I quickly got my first scatter tool going.</p> Some softwares are simple to use but don’t get you very far. It wasn’t the case with Softimage. Thanks to its well-thought architecture, it never got on the way when complex work was required.</p> On top of the quality of the software itself, both the developers and the community were forming a great symbiosis. That was a bunch of active, friendly, helpful, and innovative souls. Softimage was driven by its users. Everyone was involved.</p> With the implementation of the nodal graph ICE in July 2008, things quickly became out of control. More power at the reach of every artist. Everyone had a blast</em> using it, countless of inspiring demonstrations of the tool kept emerging on the Internet. It also quickly became indispensable.</p> </span>a Softimage ICE compound</span>credit: Benjamin Paschke</a> (with permission)</span></span></p> The Struggles</h2> Eventually Autodesk felt the threat coming and perceived Softimage as a strong competitor to Maya and 3DSMax. Four months after the public release of ICE, Autodesk bought Softimage from Avid. A that point, they owned the 3 major all-rounded 3D softwares on the market. No more competition on this front.</p> As soon as the deal got rumored, things started to change. The community grew concerned and unsecure about the future of its software. The Softimage public mailing-list became the place of numerous heated</em> debates on the subject.</p> But the community was stronger. It regained optimism when seeing the work accomplished by its users. Two of them mainly ended up doing the show and managed to open the eyes of those living on the planet Maya. They both developed plugins for ICE: Eric Mootz</a> with his Mootzoid nodes and Thiago Costa</a> with Lagoa Multiphysics</a>.</p> </span>test of emTopolizer2</span>credit: Tim Borgmann</a> (with permission)</span></span></p> We were proud to be Softimage users even though we started to feel more and more abandoned by Autodesk after each new release. Softimage was marketed as a plug-in for Maya</strong>, had less features implemented, the developers eventually moved to the Maya team, and always more debates were being fired up on the list.</p> Meanwhile I was dealing with my own struggle in parallel.</p> I landed a job at Weta Digital</a> and had to learn Maya. I tried hard to approach this transition from an open-minded pespective and there was no big issue in transferring my rigging skill set. The concepts in rigging are pretty much the same everywhere. What dumbstrucked me was the process to get to that same result.</p> I felt like I was back to stone age. I found many of Maya’s daily tasks and the design of its API to be retarded</em>. I spent my first weeks (months?) asking my teammates how they could possibly work with a such software. Even now, I still refuse to do in Maya a task as simple as painting some skin weights. It drives me crazy</em>.</p> My colleagues wouldn’t understand my frustration. All they knew was Maya, they couldn’t compare it to anything else. I was being just annoying to them. I sometimes wished to be ignorant too—it would have helped with my zen.</p> But at the end of the day, let’s face it. As good as Softimage could be, it was a battle lost in advance. They’ve been trapped</em>.</p> The Proprietary Do-It-All Trap</h2> One size doesn’t fit all. All-rounded 3D softwares cannot please the specific requirements of each studio and each user, and that’s fair enough.</p> Keeping a such package up-to-date is not guaranteed neither. Developers cannot afford to focus actively and simultaneously on each area covered by this kind of software. The large codebase, the deep dependencies between each internal module, and the unique core architecture and data structures trying to accomodate each discipline are all not helping much here.</p> Specialized softwares are more likely to remain competitive by implementing the latest technologies in their field and even define new standards themselves. But then those all-rounded 3D packages allows for a smooth pipeline out of the box. For a company just starting its business and not having much resources yet to invest in RnD to connect the dots of a more flexible pipeline, this has always been an attractive feature.</p> I believe this was especially a game changer back in the 90’s when anything must have been a struggle. If a unified pipeline with a single software could make the life of its users a bit simpler, then what could be wrong</em> with that?</p> That’s how most studios ended up buying a single package and decided to fill the holes by developing in-house tools. This task was furthermore eased with the developers not having to worry about implementing math, geometric and other complex libraries. It was already all there, available directly within the APIs built-in into the softwares. Developers could focus on getting their tools to work within their tight deadlines.</p> But that’s also where the bottleneck lies. Using those APIs meant that all the code being written would be gravitating around a proprietary software, creating deep</em> dependencies with it.</p> Once a studio has invested years in developing tools, workflows, and a pipeline for a specific package, it becomes difficult to change ship. They’re stuck with it, for the best and for the worst.</p> In this context, there’s no point for a studio to move from one package to another, especially if it is to end up in the same situation a few years later. Since Maya has always been on top of the film industry market, there was no hope for Softimage to gain much more seats from the large studios.</p> Hence the decision of Autodesk to discontinue it.</p> That’s life but I can’t help thinking that they’ve planned it all since the begin because it kinda make sense from a business point of view: buy Softimage to get rid of the competition, move its features to Maya who’s leading the market, and kiss goodbye to everyone</em> relying on it for their living because Autodesk can’t afford maintaining its development.</p> Nice hypocrital move after repeating years after years that they wouldn’t kill it.</p> The Modularization Has Already Started</h2> Some studios grew tired of having their invested development being so closely tied to the unknown</em> future of a software that they didn’t own.</p> They started to cut their bounds and to regain some control by creating their own file formats or using standardized ones. The main idea being to store their data in a generic way to make it easily transferable onto any software. The native software’s file formats were only to be used by the artists to save their work in progress before publishing.</p> With this in place, it was then possible to split the pipeline into logical chunks. Each department could work on the software(s) of their choice as long as they could output the data in the expected format. I’ve even seen 3 different softwares being used in the FX department on a same</em> show. The right tool for the right job.</p> The way to write tools itself has also changed to be done in a more modular and portable fashion. If you’ve spent years to develop a full-on muscle system but made it highly dependant on Maya’s API, then you’ve exposed yourself to rewrite pretty much the whole thing if you decided one day to port it onto another software. Instead, the goal here is to split the core with its gateway connecting it to the target software. Got a new software? You’ve only got to write a new gateway to plug the core in.</p> To take full control over the destiny of a tool, some of the largest studios went for the next level. They developped stand-alone fully-featured applications. It is a tremendous work in terms of development and maintenance but in a world of closed-source softwares this is after all the only</em> viable solution to ensure a long-term vision with an active development focused on the specific requirements of a studio.</p> That was it</em>. Some pioneers did their first steps towards independance.</p> TDs Can Now Shape the Future</h2> Ideally each studio should have adopted a such modular approach to tools development. The trend being to implement deformers, simulation nodes, rigs and other involved developments into an in-house stand-alone nodal graph platform to then glue its content with different softwares.</p> Of course, not everyone could push for that. Not until now</em>.</p> That’s where new solutions such as Fabric Engine</a> come in.</p> </span></span></p> Fabric Engine shines at abstracting the complexity of writing portable code. It allows any developer, including TDs, to write their tools in a stand-alone nodal graph and to painlessly make them usable in every software. Code it once, use it everywhere. All this with maximum performances out of the box.</p> Now, imagine the talented community of TDs and developers joining their forces to build a library of tools and making them accessible to everyone on an App Store-like platform.</p> Tools such as Gator, Lagoa Multiphysics, emPolygonizer, Unfold 3D, and more, would be available to everyone on every package. And ICE? Well, that’s already part of Fabric Engine 2.0.</p> If that library of tools managed to encompass the needs in each area of CG, then the one requirement left to buy a software would be to have a hosting environment for Fabric Engine. It would become used simply as a shell where the main selling argument would be a good UI/UX to perform efficiently daily tasks.</p> With Fabric Engine also providing a set of extendable modules to assist building applications, including a powerful real-time renderer and a set of extandable Python UI widgets such as an OpenGL viewport, an animation timeline, and so on, another choice would be for the users to assemble themselves their own hosting application.</p> How much more powerful and dynamic would our toolset become if it was directly driven by its community, if we were all contributing to shape the future of CG softwares?</p> If the entire userbase started to break its dependencies with today’s softwares, Autodesk would lose the control of the market and it would be our turn to kiss them</em> goodbye.</p> I’d say it’s the way to go anyways. Theorically it opens the doors to a longer-term vision and its team is made of a good bunch of passionate souls. It’s worth giving it a go, let’s just hope that Autodesk won’t buy them out.</p> myXKCD: Painter TD 2017-10-01T13:00:00Z </span>I had to work hard to get there</span></span></p> How I Got to Work in the Visual Effects Industry 2017-10-01T13:00:00Z I am not sharing this story to show-off anything whatsoever. Hell, in fact I consider career achievements as fairly meaningless in one (hu)man’s life. But if we gotta do a job every day, then it’s still better to do one we like, right? So all I’m hoping to achieve here is to bring a bit of hope to the ones still seeking for that cool job. Because I’ve been there before, and it didn’t look so promising.</p> </span>a truly unexpected journey</span></span></p> The (Failed) Beginnings</h2> It all started back when I was a kid with my parents often shopping at the same hypermarket. It had a shelf with many computers on display that we could try out and that’s exactly what I would do. Trying them out, every</em> single time.</p> I did spend many sessions like that, trying to figure out the purpose of the files found on C:\</code> or to beat the Solitaire and other Minesweeper games.</p> My interest not fading away over the years, I eventually got my first own personal</em> computer at 14.</p> At that time, I was away in the beautiful backcountry of France for the summer break while my brand new computer was awaiting for me back home. But I was already proactive, I was getting ready for it.</p> Surrounded with cows, sheep, chickens, and the mixed smell of their excrement—which I now associate with the great feeling of being in the nature—, I read a book on how to use Windows 95 like a pro.</p> The computer bug, I had it. I knew that’s what I wanted to do for a living with the exception of being a developer because it looked boring.[1]</a></sup></p> As for the visual effects part, I was fascinated with what I was watching on TV and knew that it was all made on computers, somehow.</p> Soon after finally meeting with my computer, I started to mess around with 3D softwares and immediately thought that it would be the dream job for me.</p> However I was way behind those guys sharing their work on Internet forums. They were good, really good. But most of them didn’t have any job, so how would I?</p> I decided to not give up just yet. After graduating from high school, I applied for a 3D school in Paris. I travelled there, took part to the entry test, and... failed it. It wasn’t even a school with much recognition. No, it was a very accessible one, an easy bet. And I had failed its entry test nonetheless...</p> I felt miserable</strong>. At this point, I thought it was game over.</p> The Spark</h2> So I went for the kind of job that you do when you don’t know what else to do with your life. It was so terrible</em> that it was almost scary. I was wasting my time, I was getting more stupid by the day, everything seemed to be pointless and I was being dragged down.</p> But it was exactly</em> what I needed.</p> It opened my eyes, it gave me a kick in the butt. I didn’t want to spend the rest of my life like this. I didn’t want to give up on my objective without even fighting for it.</p> I got back into teaching myself some more modelling, texturing and rendering until the day where I stumbled upon an article on the French online magazine 3DVF</a>. It was an interview of the makers of The Magic Roundabout</cite> movie and I knew one of those guys: Frédéric Bonometti.</p> 6 years earlier, he very kindly taught me by email how to animate a bouncing ball and we did lose contact after that. But he was now an animation and rigging supervisor working back in my hometown Marseille!</p> I emailed him and he remembered me. As a true passionate, he once again did a very kind gesture, this time by inviting me to his work to give me a sneak peek in person of the behind the scenes.</p> I couldn’t refuse that opportunity. The moment when he showed me how he could move a cartoony dog around with the controllers that he created was probably the most fascinating thing that I’ve ever seen back then. I finally found my vocation, I wanted to become a character rigger!</p> </span></span></p> After a couple of weeks spent home trying to redo what I just witnessed, Frédéric sent me a rigging exercise that I quickly resolved.</p> Without knowing it, it was an entry test that would lead me to step into the film industry as an intern in his company Action Synthèse.</p> I was 19. I had no diplomas nor any experience to help me landing a job in the industry. I already almost gave up on pursuing this carreer because of the difficulty to get in. And I didn’t know if such an opportunity would ever show up again. This was my chance, my one shot. I had to give it all, I was utterly motivated!</p> The Breakout</h2> </span>CRT monitors, you said?</span></span></p> Breaking one of their computers during my first week there didn’t stop them from all being a truly awesome bunch of people with me.</p> Unlike many companies that are exploiting their interns, they made it clear since the beginning that I was there solely to learn</em>, not to work on their projects for free. They kept their words.</p> Driven by their passion and their good will, they shared all their knowledge with me. Always with a smile, a great attitude and encouraging words, while never expecting anything back from me. I learned a lot</em>. They became my best friends too.</p> Still today, I keep thinking that I have no idea what I would be doing if I hadn’t met Frédéric and those guys. I’m feeling immensely grateful and lucky</em>.</p> But I also worked hard</strong>.</p> I’m never satisfied. I need to continuously extend my knowledge. I always question the status quo—especially regarding my own work. I need to go beyond what’s already existing, I want to improve things, I want to keep exploring and experimenting new ideas.</p> In other words, I need</em> challenge. And if I don’t know how to tackle one of them, that’s when the fun starts. I’ll research how to get there, learning tons of interesting satellite concepts in the process. A bit like when you can’t help yourself clicking on every link found on Wikipedia to answer a question that you already forgot.</p> There’s no need for a school to learn or to reach your objectives. A big pool of resources like the Internet and knowledgeable people to help you getting unstuck are plenty enough.</p> This whole attitude eventually got me hired at Action Synthèse as a character rigger and developer for a TV series.</p> After a few years spent working there plus a short experience in Paris, and despite of all my hard work, I still felt unconfident about my skill set.</p> I couldn’t help thinking of the cutting edge companies out there that were redefining the standards, pushing the limits further away, bringing always more life into each pixel. They had</em> to be filled with godlike superhumans. It had to be out of reach for someone like me.</p> But I wanted to travel a bit and decided to try my luck anyways.</p> Thanks to our great education system in France, most of us still can’t converse in English even after 7 years of learning at school. I was one of them when I landed my first job interview ever. It was on the phone with Animal Logic</a>, at 6 a.m.—time difference oblige—, I was sick as hell, and it was of course in English.</p> I’ve never been as stressed out as I was that time but it worked out somehow and that’s how I ended up working on the other side of the world, in Sydney, Australia.</p> Less than 2 years later, after finally building up a bit of confidence, I decided to go once again for the impossible and it went pretty well too. At 26 years old, I was fulfilling my initial objective to work with those guys who made movies such as Lord of the Rings</cite>, King Kong</cite>, and Avatar</cite> possible. I was working at Weta Digital</a> in Wellington, New Zealand.</p> </span>where is Charlie?</span>credit: Julian Butler</a> (with permission)</span></span></p> Conclusion</h2> I’m not so much of an artist myself but I can now proudly say that I’ve started from nothing to end up working with the most talented artists in the industry. Something that no one</em>—especially not myself—would have thought possible only a few years before, when I was lost.</p> My grandfather often told me when I was a kid: when you have something in the head, you don’t have it in the ass</q>. Another way of saying it is that I am stubborn and persistent. I wanted to work on those blockbusters, so I grabbed my chance when it came up and kept going from there.</p> I’m not any more special than you. At the end of the day we’re all good at doing what we enjoy doing. Your dream job is just one step away from there. Motivation, persistence, and patience are all you need.</p> Do it</strong>.</p> Footnotes</h2>Funnily enough, programming is now one of my top interest.↩</span></a></li></ol></aside> How Not to Climb the Volcano Acatenango, Guatemala 2017-10-01T13:00:00Z I love</em> physical and mental challenges. I knew that hiking Acatenango’s 3,976 m summit would be difficult but the more different persons would tell me how hard it actually was and how cold it got, the more I was getting all fired up. If they could do it, there’s no reasons why I wouldnt’t.</p> But a sprained ankle and other sickness convinced me to hold on for a bit. It sounded wise until I got a cold with a sore throat but couldn’t wait any longer. My flight was the day after, it was now or never.</p> My Italian friend climbed it the week before and recommended me to directly contact the guide without going through the usual agencies. Those agencies are the ones pocketing most of the money, while the guides doing the actual hard work get the leftovers.</p> My Spanish not allowing it yet, the receptionist at my hostel kindly accepted to give me a hand with the phone call. All got arranged quickly and the guy would come picking me up that same night at 11 p.m.</p> I had the whole day to prepare myself and started it with getting myself a good lunch. A bit of proteins here but mainly loads of carbohydrates there to build a reserve of energy that I could use during the climb. Then, I had to buy the mandatory banana bread from a shop in Antigua that I could use for a boost of energy during the effort. And finally I planned to buy the chocolate to go with it, as well as to drink some rice with milk for dinner, but first... a small nap. I would see the rest later.</p> I got into bed a 2.30 p.m. and got awaken an hour later by the receptionist. The guide was here and was waiting for me. The result of a misunderstanding—the receptionist herself also seemed surprised.</p> I packed my bag in a lightning strike and started to follow my guide, Jaime. He had no car so he did all the way from Acatenango by chicken bus, especially for me. I followed him to the bus station of Antigua and we arrived 1 hour later in his small village, at the foot of the volcano.</p> The sun was setting and it started to get cold. He offered me a spare room with a bed and a small dinner to eat before sleeping for a few hours.</p> </span></span></p> With the night, the dogs seemed to have become different beasts. I had one dog growling at me earlier, but now they were all constantly growling at each others to defend their territory and sometimes got into fights. One of them sounded especially violent and scary.</p> Despite of wearing 3 layers of merino, a down jacket and being covered deep under 2 blankets, I was shaking</em> from the cold out there. I wanted to be on the move already to get warmer.</p> At 10 p.m., the roasters from all over the village decided to announce the... the... well, the I don’t know what</em>. There was still 8 hours to go before the sunrise. But whatever they announced, they did it well. With a good endurance.</p> Needless to say that I didn’t sleep much when I heard Jaime getting ready at 1.15 a.m. But so was I, ready and more excited than ever! I just needed to walk out like a ninja to not raise any attention from the dogs.</p> No warm up, the path directly started with a fair slope which was mainly made of sand. Like at the beach, each step required a good amount of effort for little reward. I tried to focus on becoming more efficient. Small steps without sliding backwards. But the technique of the guide made the difference and he slowly but surely distanced me.</p> In such low temperatures, wearing wet clothes is forbidden to prevent possible future hypotermias when cooling down. But I was already sweating from the effort and decided after 15 min to have a quick first stop to remove my down jacket.</p> After the sandy ground, we were welcomed with a slippery one. Here again he distanced me with his daily experience of the field, but thanks to my energetic brute force I would quickly catch up with him when some charitable souls were once kind enough to plant some pieces of wood to serve as stairs.</p> We were back on a more practicable—but even steeper—terrain when we reached the first checkpoint with a bench to sit. He slightly slowed down to check if I would head for it. But no, I already stopped once and it was enough. This hike was my come back challenge after almost 2 years of not doing any serious sport, and I wanted to take it up like a boss.</p> So we kept going and he took the lead by sitting on the next bench, even though I wasn’t behind this time. I got proud. He stopped. Ok, he was probably being thoughtful of me, but it was good for the moral nonetheless. Even more so since my cardio, my breathing and my legs were all doing pretty well.</p> A few stops and 3 hours of walk later, I was still at the top of my form. I even found a way to heat my hands by leaving them in my pockets, against my boiling hot legs.</p> But then, I suddenly started to feel a cramp in each leg.</p> I knew that it would most probably only get worse but I didn’t say anything and kept going anyways. Two years earlier I ran 28 km with proper cramps during the last 15 km on top of a painful knee—who ended up preventing me from running ever since then.</p> I thought that if I could run in these conditions, then I could certainly walk with a couple of cramps. And I was sure that it wouldn’t have stopped Mike Horn</a> from continuing either.</p> Despite me drinking even more water, eating bananas, giving myself deep tissue massages and stretching out, it quickly reached the point where both of my legs were literally tetanised. I couldn’t stand up anymore. So I sat, put back my down jacket, fitted some toe warmers in my shoes to help the blood flowing, kept drinking, got a lolipop for a quick energy rush, and was hoping to wait a bit to see if it would get any better.[1]</a></sup> But time was playing against us.</p> Our headlamps were reflecting on a sea of ice crystals dropped off on the ground. The temperature was glacial</em>. Staying put for only five minutes was enough to get us frozen to the bones. Staying longer would have meant taking the risk to get into an hypotermic state. And so we had to give up on the summit, only 1 hour away, and turned around. I hated it but it was the only wise decision to take.</p> I tried to leave aside my frustration and focused on moving the chopsticks that I had in place of my legs. It became a question of survival.</p> It just happens that despite of my level of fitness and my relatively healthy style of life, I’ve always had those kind of muscular problems since I’m a teenager. I love pushing my limits and it’s hard to accept when my body sometimes decide to fail so easily where everyone else wouldn’t have had any problem in an identical scenario. After having worked hard towards resolving these issues without any success, I’ve had to come to the evidence that we’re not equal towards our body.</p> But as a friend told me, for some it’s indeed way harder than for others, but it doesn’t prevent disabled persons to realize apparently impossible challenges.</p> All this to say that I’m quite shameful to share this experience with you, but I want to take you as witnesses here: one day, things will</em> be different.</p> </span></span></p> Footnotes</h2>I suffer from Raynaud’s syndrome, which makes it even more vital for me to not let my fingers and toes drop in temperature.↩</span></a></li></ol></aside> Guatemala: A Journey Full of Journeys 2021-10-09T13:00:00Z </span></span></p> Proudly, I can say that I’ve started my Latin American trip without any plan and without doing any research neither on the Internet nor in any guide. My whole idea was to show up in a place, meet with the locals and with other travellers, and decide what to do on the spot.</p> Less proudly, communicating with the locals turned out being harder than I hoped for—reaching level 8 in Spanish at Duolinguo</a> and adding a touch of French-nish didn’t cut it.</p> Antigua</h2> I needed to start my trip from somewhere. That was an easy one, an Italian friend decided to hit Guatemala for 2 weeks during Christmas, so would I. Antigua was the meeting point.</p> 17 December 2013</h3> The plane flew over Guatemala City just when the sun was setting. Quite a beautiful introduction to the volcanoes scenery all around. But it also meant that I had to reach Antigua by night.</p> I still remember the day when I was in the plane in direction to Australia for the first time. It was on the 9th of February 2009. There was a French girl sitting next to me who was returning to Australia. I’m not sure what was her reason but she did her best to try to freak me out. Beware of the deadly spiders, they like to hide under the toilet seats because they fancy humidity</q>. They also like hiding in the grass so don’t walk barefoot</q>. Always double–check your bed and your shoes before getting in</q>. There’s ton of shark attacks happening, don’t swim</q>. I’m not even talking about the many lethal jellyfishes</q>. And the list went on and on.</p> Many couldn’t help themselves at telling me similar stuff about Guatemala but regarding violence this time. Don’t travel in chicken buses</q>—the local transport system—and Don’t go out by night</q> were in the top 2 of the list.</p> To leave them the benefit of the doubt, and because I was exhausted after this long travel, I thought that I’d play it safe for my first move. As I was about to grab a minibus to Antigua for 80 quetzals—the local currency—, which is about 8 € or $10 USD, a Dutch girl sitting next to me in the plane offered me to jump in her private shuttle for free. Her mum already organized and paid for it in advance because she was scared that her daughter would take a chicken bus instead. It made me a bit uncomfortable not to pay anything and so I decided to give her 100 quetzals to thank her. I didn’t have any smaller change anyways, and she didn’t neither.</p> When the driver dropped me after leaving the girl at her hostel, he stared at me insistently. He raised his hand, the palm slightly facing up. I hastened myself to grab it and shook it while thanking him with a warm ¡Muchas gracias!</q>. For some reasons it didn’t seem to be enough for him to stop staring at me weirdly.</p> Only then I understood that he was expecting a small tip. Without any idea of the actual value of the currency, I gave him 50 quetzals. Only later I realized that with an average Guatemalan wage of 80 quetzals per day, I’ve been more than kind. But more importantly, I’ve beautifully played the role of a naive</em> tourist and this had to change.</p> Before the conclusion of this fiasco, I agreed on a dinner with the Dutch girl to a place recommended by our shuttle driver. I decided to pick her up at her hostel to make sure that she wouldn’t get into troubles because of the don’t get out by night</q> thing.</p> The receptionist at my hostel kindly gave me a map and drawed the direction. It was only a few blocks away and would be quite straightforward if only she had pointed me to the correct</em> destination.</p> Instead I’ve been turning around for 30 min and ended up getting lost in a totally different area with either non–existant street names or names that wouldn’t match with the ones on the map.</p> This first exploration of Antigua by night left me sceptical. There was no much light in the streets, making them quite dark. Not many pedestrians were walking neither. At an almost regular interval, cars were driving by at a much reduced speed because of the paved road. And all those cars had their windows covered with a black tint to the windows.[1]</a></sup></p> All this plus some extra loud firecrackers banging here and there in the streets—due to pre–Christmas celebrations that sounded more like Bagdad to me—left me with a slightly sketchy feeling.</p> I finally managed to find my way back to my hostel, looked myself at the address of her hostel on Internet, and made it there in no time.</p> 20 December 2013</h3> I met a lovely French couple the day before and signed in with them for a trip to the volcano Pacaya. The goal was to get to the summit for sunset.</p> We left at around 2 p.m., drove for about 1.5 hour and started our gentle climb. Because we were allowed to stay up there for only a short period of time, our guide made us climb slowly to make sure that we would arrive at the right moment.</p> Despite having our entire group refusing to climb with one of the many horses offered at the start, a few of them followed us anyways. Just in case someone changed their mind or wanted to give up. You know, a bit like a broom wagon.</p> When the last ascent of the summit was at our reach, we had to stop there. Climbing to the top was forbidden due to the volcano being currently active. Indeed it was continuously smoking and rumbling every 3–4 minutes.</p> So we just sat down there, with a nice view over other volcanoes around, and waited for the sunset. It was beautiful</em>.</p> View on Flickr</span></a></span></p> But it wasn’t enough for our guide. He got disappointed because he hoped that we would see the red color of the lava from the volcano vent when the dark set, which didn’t happen.</p> We had to go back down in the dark, with a few headlamps helping with the bumpy ground. I didn’t feel the need for turning on mine, until I figured out that it wouldn’t be the best timing to injure myself just before my Italian friend would arrive in town.</p> So I turned on my light for the time of a very small run downhill, for the fun of it, and that’s when a deep crack</em> sound rang out from my right ankle. Done</em>.</p> When we almost returned to our starting point, our guide stopped us and pointed back at the volcano. It was red. We could see rocks erupting from it.</p> 22 December 2013</h3> So far my frustration of not speaking Spanish was already quite high. I mean, what’s the point of going into a country if we can’t even speak with the locals? But something that I’ve never been looking forward to is heading back to any sort of school. This has just never been a good fit for me. I’m more of the type to learn things by myself. I hoped to catch up over time.</p> I was fortunate enough to have been assisted in this regard by the French couple for the previous few days, who both have a great level of Spanish, and I would now be able to rely on my Italian friend who just arrived and who is perfectly fluent.</p> San Pedro La Laguna</h2> 24 December 2013</h3> We booked the day before one of the only place available to us on HostelWorld. Not a good idea. The hostel was rather expensive for the average price and it didn’t rhyme with better quality.</p> When walking in the streets, we’ve asked some guys staying at a Spanish school if they knew any better accomodation around. We’ve been pointed towards one named Hotel Peneleu.</p> We went to check it out. It was way cheaper, way cleaner, and the view was quite something so we booked it for the next night. Note to self: do not solely rely on the Internet.</p> View on Flickr</span></a></span></p> On the way to that hostel, we’ve found a group of kids playing in the street. They were having a lot of fun, and they doubled up in energy and excitement when we’ve asked them if we could take them in photo. Such a great moment. They loved the photos so much that they went on for another round.</p> View on Flickr</span></a></span></p> Then their mum showed up to give them some piece of advices by telling them to accept being taken in photos only in exchange of money.</p> The time was for Christmas celebrations. With many selling weed and mushrooms in the streets, and all those gringos—foreigners—buying them only to end up wandering in the streets completely stoned, we thought that there would be some sort of party happening.</p> After scanning the streets, we ended up stumbling upon where all the locals were gathering: on the place in front of the church. Not really our cup of tea.</p> So we kept searching and we found a nice hostel where this time all the tourists were regrouped. Not really what we were looking for neither but in lack of a better choice, we stayed.</p> The music was there even though not in its best form. The general dynamism wasn’t at its best neither. And to be a real party pooper, I chose to be wise and not to dance much due to my sprained ankle.</p> But faith decided otherwise. The DJ set a track of Daft Punk, Get Lucky</cite>. If there’s one thing I like to dance on, it has to be Daft Punk tracks. And so I went full on in the centre of the dance floor, battling with other guys.</p> I was on fire. So much that it took me a few tracks to realize that I only manage to worsen the condition of my ankle.</p> 25 December 2013</h3> On the other side of the lake is the Indian Nose. A small mountain whose silouhette looks like a profile of looking upwards. Our destination for today. We thought that we would try it on our own without going through a tour or a guide.</p> So we first jumped in the boat, direction San Marcos. From there we had a small lunch in one of the very few places available, and we looked for a tuk–tuk. We knew that we could drive up to a place named Santa Clara, and from there only 40 min of climb would be separating us from the viewpoint.</p> We looked for a tuk—tuk, tried to negotiate the price to what we’ve previously been told by the restaurant owner, and... it didn’t work out. The old man was camping on his position and so were we. So we took a ride to San Pablo instead in the hope to find better deals over there.</p> When arrived, the negotiation started again with the old man but didn’t go any further until a younger and more intrepid tuk–tuk driver accosted us with his vehicle. He got us a better deal, we changed ship.</p> That driver was definitely more sporty too. The not so stable–looking 3–wheeled machine and the bumpy, steep and curvy mountain road seemed to be like just another video game to him. And for us too, it was fun! Especially since we made it in one piece to our destination.</p> There a guy ran out of his house to stop us. He couldn’t help himself from smiling when he was talking, like if he could smell the good deal. He told us that he was a sort of custom for the Indian Nose land, that we had to pay a fee to get there, and that he would have to come with us. We’ve heard about the 150 quetzals fee so it sounded fine.</p> We went on with the plan, started a walk towards a first lookout, and from there he tried to convince us to not go to the summit because it wouldn’t be worth it. The view would be the same. We insisted to keep going. He left us and finished walking the way up with our tuk—tuk driver who felt like joining us.</p> View on Flickr</span></a>our tuk–tuk driver, a cool dude</span></span></p> Arrived at the summit, there was a group of other gringos waiting for their guides to come back with some extra gear. Their tour included a camping overnight. And there were also some locals trying to get more money from us. I could barely understand half of what they were saying, which was enough to make me unhappy about the situation. But I couldn’t reply to them, my friend had to do all the job.</p> It wasn’t so much a matter of money, they were asking only 25 quetzals per person, or around $3 USD. It was more a question of principles. We already paid an entry fee and didn’t want to pay every single person asking us for money. Especially without any document supporting their arguments. The situation got worse, they became more agressive and threatened us to call the police while letting us know that we would run into troubles on the way back. Or something like that.</p> View on Flickr</span></a></span></p> Our tuk–tuk driver started to wonder why the hell he followed us up there and begged us to pay the fee to avoid any problem. But instead we decided to wait until the guides of the other group came back from their extra climb. That’s how we learned that we actually were on a private land. A different one from the previous lookout. And that yes, they require visitors to pay. Well, only gringos have to pay, not the locals.</p> After a quick evaluation between taking a risk—as low as it might have been, if we consider that they were hopefully bluffing—of losing our gear and whatnot versus spending $3 USD, we opted for the latter.[2]</a></sup> And here we were, in for another epic tuk—tuk ride. Downhill this time.</p> Actually the ride wasn’t sensational enough to finish the day. The driver—should I say pilot</em>?—did a quick stop in San Pablo to pick up a friend of his and to let him drive all the way to San Pedro. He was around 8 years old. Eight freakin</em> years old! At his age, I wasn’t even playing at Colin McRae Rally</cite> yet.</p> </span>a way too young tuk-tuk driver practising</span></span></p> Semuc Champey</h2> 26 December 2013</h3> With that previous experience, I thought that we would be immunized against any sort of ride. I was wrong.</p> It all started normally. We got in the shuttle at 7 a.m., direction Antigua for a lunch stop. We took the opportunity to rush back towards our favorite lunch place, where not many gringos dare going to eat: the market place! Most cheap, authentic</em> and possibly yummy food!</p> We couldn’t pass by Antigua without stopping to our second addiction in town: the banana bread shop. The delicious flavour of bananas can already be smelled from the street. When you’re around, there’s no stopping the urge of buying some. Best. Banana bread. Ever!</strong></p> Of course, they did things well by being located next door from the chocolate museum. A banana bread sandwich with a row of 80% salty chocolate equals to pure awesomeness.</p> </span></span></p> Back on track! Two shuttles left at 2 p.m. in direction of Semuc Champey. Somewhere half–way our shuttle decided to stop and turn around. The other one had a mechanical issue so we ran to the rescue. And ran again after picking up some cooling liquid.</p> View on Flickr</span></a>killing some time</span></span></p> Apparently every Guatemalan driver is also a mechanic. I found the front seats unmounted to allow them to dig through the layers of the engine. It took some time but eventually they got it sorted and we were back on track.</p> At 1 a.m. we arrived at a place named Lanquín and for some yet unknown reasons we changed vehicles. From almost comfortable and warm seats, we’ve been thrown into the back of a truck with no rooftop or whatsoever and no other way to sit than a single thin wood board. But sitting wasn’t our best bet.</p> We immediately rushed into the jungle in a fashion very similar to water rafting. Sitting down on that board would have only resulted in a good petrissage of our bum. The one viable option was to stand up and and hold on tight to the metallic armature surrounding the truck. It was either that or being ejected out in the jungle. And it started to rain. Lightly but consistently.</p> An hour later, we finally made it to our hostel and went on to sleep straight into our huts. They had a rooftop but no walls, it was a bit like sleeping in the outdoors. It felt great!</p> 27 December 2013</h3> After a short night, we went on with the main reason of our stay: a tour going through a viewpoint, the natural pools, and the exploration of a cave with a candle.</p> But before heading for the tour, our guide has been pushing hard for everyone to order their lunch meal straight away so they would be ready for when we’d come back. We were not really attracted by the menu and the prices but since we had no idea of the surroundings—arriving at 2 a.m. didn’t help—, and since he’s been so insistent, we followed the mass and ordered ours.</p> Getting to the viewpoint required a little climb. It was written difícil</em>, but it wasn’t. What’s sure is that the view was worth it.</p> View on Flickr</span></a></span></p> And then onto the river and the pools. Not carrying any swimsuit with me, I had to borrow one from a local. It was actually a thick sport short. The water was clear, and us, gringos, were mostly invading the place. I felt bad for the locals living around there.</p> View on Flickr</span></a></span></p> This and a serie of small activities in the pools took us the entire morning. When heading back to the place we were staying at, which is also where the tour operates, we realized that there were actually plenty of locals selling real, authentic looking, food.</p> Anger grew in me. I already didn’t like this guide for some reasons but now I truly had a grudge against him. He deliberately hid this information from us. Instead of distributing our money to the poor locals in the need, we had to spend it in his stupid company. But now we knew.</p> The lunch with its ridiculously terrible (quantity × quality) / price</code> ratio finished, we had to get rid of all our gear and clothes. Only the swimming suit and the flip–flops had to remain. Flip–what? Alright, my minimalist gear didn’t include any of these. I was the only one. Barefoot it would be then.</p> Here I was, walking like a penguin for about 5 minutes on a relatively painful ground. Fortunately my feet are slightly trained with a small barefoot running experience and other “shaolin-like” trainings on sharp rocks that I happened to do once because I’ve got such stupid ideas sometimes.</p> The barefoot community grew when they all been asked to leave their flip–flops at the entrance of the cave. There, we’ve been given a candle each. A bit like the Olympic Games torch, my goal was to get it through without it shutting off. I’ll save you from any sort of uncontrollable suspense by letting you know that I’ve miserably failed on the way back.</p> The cave exploration was not so interesting for its sight. It was rather ugly. The cool side had more to do with its adventurous aspect. We had to go through a few fun obstacles and endure walking or swimming in the dark knowing that at some point we’ll hit an underwater sharp rock that will cut our skin. I definitely didn’t fail that bit, it happened.</p> Flores</h2> 28 December 2013</h3> Departing at 7 a.m. from Semuc Champey back to Lanquín, I couldn’t wait to add some brand new bruises by banging again the armature at the back of the truck. My wish has been fullfiled with the help of a new driver, very keen to overtake all the other trucks in his path.</p> Of course, it was just the begin of the journey. We jumped in a shuttle in direction to Coban where we had to pick up some new passengers. The issue? The shuttle was overbooked. No worries, I though, this is the kind of non–issue for a group of adventurous travellers anyways. Right? Except that it ended up being one.</p> The shuttle dropped us all at a McDonald’s—do they think that we exclusively eat in shit places or that we want to contribute to them?—and then drove away. At its return, the 3 new passengers were finally sitting in the then empty shuttle after having waited for 2 hours outside.</p> Coincidentally, they were a group of 1 Peruvian and 2 Guatemalans brothers that we previously met in an other shuttle from Antigua to Lanquín. We had the occasion to discuss quite a bit with them, especially when we all had to wait for the cooling system of a shuttle to be fixed during the previous trip.</p> My friend and I happily greeted them. As for the others, they welcomed them in their own way: Why did they take our seats?</q>, We were there before</q>, We’re tourists and they’re Guatemalans</q>, and so on. Except that they were humans like us, they were tourists like us, they paid like us, and they’ve been told to seat there. A long infantile battle started.</p> Being the last one to enter into the shuttle, I could only see the final outcome. The 3 of them were stacked on top of each others in the most uncomfortable way possible. All this when there was an empty space on the floor at the front of the bus. I wondered how could we have lost any value of solidarity and become so selfish in our “developed” countries of gringos. So I went for that spot on the floor and gave away my seat. It made me feel pretty happy.</p> A few hours later, a Brazilian girl had requested a stop for an urgent need. For some reasons the driver didn’t stop where there were signs of civilization and possible toilets around but ended up pulling somewhere with not much around. So she went for it anyways and came back crying. She had been bitten by a dog while doing her thing.</p> I picked up my SAS Survival Guide Handbook</cite> and checked for any hint of what to do in this scenario. We requested for another stop next to some habitations. I told her to thouroughly wash her wound to remove any trace of saliva, then I gave her an antiseptic to apply.</p> On her way back from the restrooms, she called me. I asked her how deep the wound was and how it went. The bite being at the back of the leg, she couldn’t do much and asked me to apply the antiseptic. So I executed myself and did it without thinking. Then I let her know about the small probability of rabies and told her to check with a doctor within the next few days.</p> For the next hour, I hated</em> myself. I’m not a doctor but I have been through a 2–day outdoor first–aid course in New Zealand the year before. I should have known better. I kept thinking of what I should have done instead. Wash my hands, not get in direct contact with the blood of the victim, clean her wound, apply a compress and a strap to avoid infection. I pretty much did it all wrong. I was fairly relaxed and collected but I simply didn’t activate any of my brain cells. How could I forget all these basic steps when it finally mattered? This was unacceptable.</p> I’m not even talking of the probability of contracting rabies myself by applying some antiseptic on one of my own wound after having been in contact with her blood and not having washed my hands inbetween. I guess it would have been a good lesson.</p> To you, Brazilian girl: even though you haven’t been so nice with my 3 friends, I sincerely hope that you’ve recovered well.</p> View on Flickr</span></a></span></p> 29 December 2013</h3> Sleeping is overrated. We woke up at 2 a.m. to get into a tour that would take us to the Tikal Mayan ruins just in time for sunset. Of course the shuttle showed up 30 min late but we arrived on time and started our walk through the ruins in the dark.</p> Our sunset spot was a tall pyramid overlooking the jungle. Before climbing it, our guide gave us a quick briefing, asking us to respect the silence once at the top so everyone could enjoy the melody of the jungle.</p> It did work. Almost. Nobody was talking, only the crowd of cameras were frenetically making noises.</p> I sometimes wish that digital cameras had a newbie</em> detection algorithm. Maybe they could signal to their owner things like: No magic here, if it looks bad with your own eyes, it won’t look any better on a photo</q>, Nope, that small bird still won’t stand out from the tree in a photo</q>, or Don’t mistake my flash with Superman’s laser beams, I won’t light up your subject at 5 km away</q>.</p> On our watch the sun was supposed to be there but the thick layer of clouds decided otherwise. It didn’t stop the howler monkeys to shine in the surrounding jungle through their impressively loud voice. Surreal atmosphere.</p> </span>nope, we didn’t climb that one</span></span></p> Rio Dulce</h2> 30 December 2013</h3> To not change with the good habits, the night was yet another time short. We woke up at 4.15 a.m., skipped any sort of breakfast and reached the bus terminal in Santa Elena with our Peruvian and Guatemalan friends.</p> After spending my last 7 quetzals into a bottle of orange juice, we jumped into the coach that didn’t seem to be of the latest generation. Most of its windows have been hit by rock impacts, probably during a street manifestation that didn’t turn so well.</p> But we were happy, the coach wasn’t as crowded as we thought it would be and we could easily secure ourselves a seat each. It even was comfortable and the 4 hour drive to Rio Dulce for only 65 quetzals sounded like a great deal.</p> This was until the coach stopped to get more passengers. Over and over again. Quickly all the seats were taken and the unlucky ones had to stand up in the middle row with their alive chicken and other marchandises.</p> It reached a point where there really wasn’t any space left. I could feel the leg of someone compressed against my shoulder. I couldn’t take it anymore when he started to rub his willy against me. After a few minutes, I sighed. Loudly. He giggled and gave me a break by stepping back.</p> Against any logic, the density of people didn’t seem to be enough to dissuade the coach manager to always take more passengers in. When the persons standing up couldn’t figure out anymore how to free up some space, the manager walked to the back and started to place each person himself in a way that made them stacked up like tetris blocks. The coach did become a real tin box of sardines. With the sweat juice that comes with it.</p> To make it always more challenging, someone decided to showcase all the tracks that he had on his phone. Some sort of music from the 70s with the exact same rythmn played by an accordeon on each single of his tracks. I started to get a pretty badass headache.</p> Meanwhile some chicks escaped from their box and were partying a bit everywhere in the bus while singing a cute pew pew</em> song.</p> I thought that I would finally breathe when we reached our destination but I was wrong. The loud truck engines and the dense traffic honking like if they were playing a contest of the most annoying driver only managed to make me regret my dear coach.</p> My first proper intake of food and sugar of the day didn’t help to get rid of my growing headache. I had to skip the tour planned to a castle in the middle of the lake and say goodbye to my new friends.</p> </span></span></p> When I reached my hostel by boat, in the middle of some sort of jungle, I realized that what was a simple headache turned into an illness. It was around 2 p.m. when I felt asleep, covering myself in many layers to sweat the shit out of me. When I woke up a few hours later, I was still too weak but a honey bear crawling in the hostel cheered me with his presence.</p> Livingston</h2> 31 December 2013</h3> Wait, did we change continent? Livingston is only accessible by boat, and when we reached the quay the first impression was that black Africans took control of the place.</p> It was supposed to be the place where to spend New Year Eve but we did struggle once again at finding any partying going on. We gathered with a few other gringos and went on a mission but for the first time in my life, I missed the countdown. Not that I care much anyways.</p> It’s only later that we finally found some African sound with a few guests dancing in a very... sexual manner.</p> View on Flickr</span></a>throwing some more firecrackers...</span></span></p> Antigua, the Return of the Vengeance</h2> 2 January 2014</h3> Back to Antigua to close the loop.</p> The most terrible thing so far has been for me to not be able to directly interact with the locals. I’ve only been a mere passive spectactor when my Italian friend did speak to them. This has been beyond frustration to the point that I decided to overcome my hate for school and take Spanish classes in Antigua. I decided not to leave until I could communicate properly. It would be worthless to keep travelling like this anyways.</p> View on Flickr</span></a></span></p> Banana bread, how I’ve missed you!</p> Random Facts</h2> going into local places where no many gringos usually go is quite an experience. It sums up to dozen of people staring and amically laughing at you, while wondering what the fuck you’re doing there.</li> the toilet paper? Please don’t throw it in the toilets but in the bin. It might block the toilets and you reallly</em> don’t want that.</li> clothes don’t dry in a humid environment</li> Guatemalans love showing-off the same 3–bit Christmas song everywhere. My ears bled. A lot.</li> the pre–Christmas banging firecrackers celebrations actually never ended. They did survive to both Christmas and New Year Eve, to the days and the nights.</li> did you ever see a place where the toilet paper is only available before entering the toilets? I did. Hopefully you’re not on diarrhea, otherwise good luck at anticipating the amount of paper that you’ll need without wasting any.</li> I’m sure that a kid has more chances of being shot dead at his school in the USA than ending up injured at all in Guatemala.</li> </ul> Footnotes</h2>Only later have I been told that the omnipresent black tint on the cars is there to prevent thieves from seeing their content.↩</span></a></li> The road between San Pedro and Santa Clara has the reputation to be a good spot for thieves to target foreigners.↩</span></a></li></ol></aside> Let It Begin 2017-10-01T13:00:00Z A Taste of Freedom</h2> In France we’ve got what’s called a CDI, which is a permanent work contract. In such a difficult economic context, it is seen as the Holy Grail, providing their holders with security of employment.</p> Not being stressed out, carrying no responsibilities, having no constraints, being able to meet with friends anytime, anywhere, benefiting from having the freedom to do what we like, including relaxing, this is what I call a VDI.</p> VDI stands for Vacances à Durée Indéterminée</em>, which translates to Open-Ended Holidays</em>. It has been my status for the last 6 months already, and needless to say that it has been great.</p> But it‘s now time to move on, to go for the real</em> deal. I’ve decided to add a glimpse of adventure to my dear VDI. Here I am, now starting an unrestricted</em> trip to Latin America!</p> Paris</h2> But first things first. Living in the South of France, Paris was the first stop on my way.</p> Paris and I have always been into a love–hate relationship.</p> When I was a kid, I always thought that the weather forecasts were just lies. I still kinda believe that but back then I couldn’t get myself around the fact that they consistently predicted either a cloudy or a rainy weather in Paris when it was mostly sunny in the South. How could these people possibly endure living without the sun for so long, right?</p> </span></span></p> Then I started to work there for 2 months. Trying to find my way in the streets of Paris with my hugely and heavily unoptimized backpack lacerating my shoulders wasn’t enough, I also had to be welcomed with a cold rain that soaked me up within minutes.</p> I didn’t see any single pixel of blue sky during my first week, let alone the sun rays. When I finally met with the sun again, I got blinded by the intense</em> ambient luminosity, I just couldn’t stand all that natural light anymore. Fortunately it only</em> lasted for 15 minutes.</p> Not only the sky was grey but the city itself with its buildings felt quite colorless too. Even its inhabitants were dressed in a shade of grey, like if they were enjoying themselves in this moody and monotone atmosphere.</p> It hit the nail on the head when a pizza maker one day told me that I didn’t seem to come from Paris. I was surprised, how could he possibly figure this out? I don’t have that much of a pronounced Southerner accent, nor was I wearing anything that could betray me, so I asked the man. His answer? Well, you’re smiling!</q> Alright... I had failed the Parisian test.</p> All in all, I’ve first seen Paris like a very noisy, confined, polluted and oppressing city with no much space for nature, and where their inhabitants looked like a bunch of soulless zombies living solely for their work.</p> For the city known as the most romantic city in the world, I surely was disappointed. It all looked too cold. Cold and grey.</p> But I based that judgement on day time only. I then realized that by night, Paris and its people are a whole different beast.</p> The city paradoxically becomes quieter but more alive. The show starts with an unecological but beautiful set of lights illuminating those Haussmanian buildings and other monuments, while the inhabitant’s souls seem to be regaining possession of their bodies.[1]</a></sup></p> With their stressful work behind, Parisians go out to enjoy the innumerable local bands, restaurants and bars available to them. The choice of food is large and potentially good but expensive.[2]</a></sup> Even the simplest cocktail can get sometimes ridiculously expensive but it doesn’t matter anymore. Life is good again.</p> A trip in the city with the Velib’—the self–service bike system— finished to convince me of that chilled and magical ambiance of Paris by night. Such a pleasure for the eyes.</p> Toronto</h2> I knew that Paris wouldn’t be cold enough to my liking so I thought Why not visiting a friend in Toronto and see a bit of Canada for the first time?</q></p> Having never experienced negative temperatures before, I wasn’t sure if neither my gear nor my body would pass the test. But it didn’t go toooo</em> bad.</p> With my layered approach—long sleeve merino base layer, merino t–shirt, merino long sleeve light vest, ultralight down feather jacket, and Gore–Tex hard shell jacket!—, I’ve proudly managed to survive to a temperature of -10°C that apparently felt like -16°C with the extra wind. Of course my merino underwear also helped.</p> But still, it was freezing cold. So cold that we had to adopt a walk’n’hide strategy. We regularly interrupted our outdoors walks to find refuge in shops or public transports to allow us to unfreeze and build a bit of heat before stepping back outside again.</p> And it wasn’t even winter at its best.</p> Temperatures aside, in the short 4 days that I’ve spent there, I found the city to be heartwarming. Maybe is it partly due to the Poutine dishes burrowed from their neighbors in Quebec, but mostly everyone seemed to be kind and friendly.</p> </span></span></p> OK, being a fan of healthy</em> cuisine from the entire world, I had quite some difficulties with the Poutine but I loved the markets there—bonus points here because they sell French cheese!—and the different communities having each their own suburb as the always present Chinatown swarming with Vietnamese, Japanese and other dim sum places. Yum. Not sure if I’ll ever be able to live again in a city without good Asian restaurants.</p> My only disappointment after having been teased with it for days by my local friend is to not have found any place selling the famous beaver tails—not the actual tail of beavers but their pastry equivalent, a specialty around here. We tried hard though! We even went as far as to the Niagara Falls only to find out that the shop was closed.</p> Another thing that I kept hearing was to come back in summer for a better experience of the city. I can only be looking forward to do so!</p> San Francisco</h2> Don’t tell the customs but my main goal was to gear up a bit in electronics for the needs of my trip. I had to leave my film cameras back home and opt for a more portable solution, which is why I picked a Fuji X100S. I never had the chance to try one before so I solely had to trust the online reviews and cross my fingers.</p> But San Francisco was also a chance to visit another city in the USA. After having been not really pleased with both Honolulu and Los Angeles, I was told that SF could leave me with a better impression.</p> And this time, I indeed wouldn’t be disappointed. Instead of the ridiculous Muscle Beach and other never ending boulevards lacking of any interest, I found myself walking in streets that had a nice vibe to them, packed with tons of cool little places to eat, and went through suburbs that each had their own identity.</p> I happily went on to climb all these famous roller coaster streets. Fortunately I enjoy walking uphill because I realized that a simple map is not enough in SF to deduce the most optimized route. It’s in those situations that having a good knowledge of Grand Theft Auto</cite> can become handy.</p> </span></span></p> I’ve been impressed by how much the nearby Silicon Valley had an impact on the number of entrepreneurs trying their luck with various projects. Or maybe is it the other way around?</p> What’s sure is that either in the train or in coffee shops, many had their laptop open and were discussing about their startup, their ideas, the designs they were working on, or the softwares they were developing.</p> That’s a lot of creativity going on within that tech–savvy bubble. No wonder why the few managing to emerge out of that fierce competition end up ruling over the world.</p> On the other side were the ones wandering in the streets and calling them “home”. They were far from being only a few, it actually seemed more like an entire and vast community living in a parallel world where any interaction between both worlds were rare. A truly saddening sight.</p> As of Now...</h2> I’ve just arrived in Antigua, Guatemala. I’ve got a cold and a sprained ankle.</p> </span></span></p> Footnotes</h2>By night, even the Eiffel Tower looks nice.↩</span></a></li> Being renowned as a one of the countries with great food, it’s surprisingly much easier to find terrible and pricy restaurants than honest ones with good food.↩</span></a></li></ol></aside>

Christopher Crouzet

NVIDIA’s Warp for Houdini

2022-05-30T12:00:00Z

I’ve only found out about NVIDIA’s Warp</a> recently and I really like how it makes writing performant CUDA kernels accessible to Python developers, without anything being in the way to getting started quickly.

After having spent the past 3 years at work developing HDAs, tools, and workflows for Houdini</a>, the first thing that popped into my mind was to check whether a marriage between both apps would be possible. I thought it’d be neat to expose Warp to Houdini users, through the SOP context.

It turns out that it was quite simple to get a Warp kernel updating some point positions</a> but that wasn’t quite enough to be satisfying.

Indeed, that solution was all fairly hard-coded to my specific test case so the next itch was to figure out whether I could build an HDA that would allow reading and writing from/to any geometry attribute.

Additionally, I wanted to take this exercise as an opportunity to share how I personally like to author HDAs in Houdini. But I’ll leave this for another blog post, coming up shortly!

The (Lack Of) Process</h2>
Long story short, it was all fairly straightforward to put in place a working solution.

One trick was to use a Solver SOP node to support simulations and the caching of frames, so that we can scrub through the timeline without needing to recompute everything.
As for the rest, it was mostly a matter of converting the data back and forth between both APIs, while... uh... not making silly mistakes that would cause the node to segfault when the input topology would change? Ahem.
The HDA’s interface is somewhat similar to an Attrib Wrangle SOP node mixed with a Solver SOP, with an additional set of parameters allowing to define the inputs and outputs attributes that are to be passed to the kernel.

There is also a button that allows generating the code of the kernel function, based on the parameter values from the attributes tab.
To validate the HDA and help documenting its usage, I worked on a couple of examples which aim at keeping things as simple as possible to allow users diving in and understanding what’s required to get started, instead of trying to generate quality results. So if these results look cheap and imperfect (they do!), you can blame me, not the tools.
Example: Ripple Deformer</h2>
The first example that I built for my tests was a simple ripple deformer. In itself, it bypasses the simulation mechanism since it builds upon the same initial point positions stored into the rest attribute, instead of reading the point positions from the previous step.
The objective here was to make sure that it was possible to change parameter values while the solver is running, even when it involves retopologizing the input mesh.
</video>look ma, I can even change its topology and scrub through the timeline!
# -- coding: utf-8 -- import warp as wp @wp.kernel def run( P_array: wp.array(dtype=wp.vec3), count_array: wp.array(dtype=wp.int32), amplitude_array: wp.array(dtype=wp.float32), frequency_array: wp.array(dtype=wp.float32), rest_array: wp.array(dtype=wp.vec3), time: wp.float32, time_step: wp.float32, ): tid = wp.tid() # Detail attributes. count = count_array[0] amplitude = amplitude_array[0] frequency = frequency_array[0] # Point attributes. P = P_array[tid] rest = rest_array[tid] # Compute the ripple deformation. d = wp.length(P) h = sin(-d * frequency + time) * amplitude P = wp.vec3(rest[0], rest[1] + h, rest[2]) # Write out the point attributes. P_array[tid] = P # Keep track of how many kernels have been run. count_array[0] = count + 1 </code></pre>
Example: Bouncing Ball</h2>
This time, I wanted to try out a real simulation. Something that builds up upon the values computed in the previous step. So, uh... a bouncing ball, anyone?
</video>
# -- coding: utf-8 -- import warp as wp @wp.kernel def run( P_array: wp.array(dtype=wp.vec3), v_array: wp.array(dtype=wp.vec3), pscale_array: wp.array(dtype=wp.float32), bounce_array: wp.array(dtype=wp.float32), drag_array: wp.array(dtype=wp.float32), time: wp.float32, time_step: wp.float32, ): tid = wp.tid() # Point attributes. P = P_array[tid] v = v_array[tid] pscale = pscale_array[tid] bounce = bounce_array[tid] drag = drag_array[tid] radius = pscale * 0.5 # Apply the drag force. v = v * (1.0 - drag * time_step) # Bounce the particle if it went under the ground. if P[1] < radius: P = wp.vec3(P[0], radius, P[2]) v = wp.vec3(v[0], -v[1] * bounce, v[2]) # Apply the gravitational force. v = v + wp.vec3(0.0, -9.81 * time_step, 0.0) # Solve the position. P = P + v * time_step # Write out the point attributes. P_array[tid] = P v_array[tid] = v </code></pre>
Closing Notes</h2>
This HDA is quite experimental and has not been thoroughly tested, so use at your own risk!
Oh, and it’s Python 3 only, so you might need at least Houdini 19.
If you scrolled all the way down just to find where to get the HDA, here is the link on GitHub</a>!

Seamless and Collaborative Generation of Infinite Worlds

2022-04-26T12:00:00Z

I am worried about what some of the tech giants truly envision when it comes to the concepts of metaverse and of web 3.0, but if there is one thing that I like in these conversations, it’s the idea of having some sort of open worlds available to connect us with other people.
In 1999, we had this virtual world in France named Le Deuxième Monde (The Second World), and I remember finding it to be a wonderful and captivating experience. I met some lovely people there with whom I’m still connected to this day, and others who even helped me getting started in 3D, which eventually kickstarted my career in the animation and VFX film industry.
Wouldn’t it be cool if we had some interactive experiences like that today, in worlds that would be authored by their users, and where we could somehow satisfy our innate desires to explore an unknown land and to form communities?[1]</a>[2]</a>
Design Objectives</h2>
One thing that I learned during my time as a technical artist, it’s that you usually don’t want to take away control from the users by fully automatizing some systems. Every tool, every feature, should always allow users to override their behaviour and to drive the result in whichever direction they like.
That’s also true for such open worlds. Yes, we might want to be able to generate them to some extent, but how cool would it be if users could also author their little piece of land however they’d like?
So that’s what I decided to tackle during the 4 days of the Easter break!
The goal was to build a quick proof of concept in Houdini where an infinite world can be created based on a set of tiles that are provided, and where users can focus on getting their own tile to look good in a standalone fashion, while having the confidence that they would seamlessly blend with the rest of the world.
terrain
To keep the scope of this experiment small, the result shall not be expected to represent the final look of the terrain. Instead, the intention is to use it as an intermediate step, on top of which more procedural work can be applied, such as adding hard edges depending on the curvature, running an erosion pass, adding roads and rivers, and whatnot.
SDF All the Things!</h2> The Signed Distance Function</a> (SDF) is one of these techniques that is just too good to ignore.
Knowing the distance to a surface for cheap makes it well suited for algorithms involving collision detection, such as ray marching, and many fluid and rigid body solvers used in the film industry when making VFXs.
Not only that but it’s also a prime choice for procedural modeling where it makes organically combining multiple arbitrary shapes a walk in the park.
In other words, I’m a big fan of SDFs. And so are the masterminds behind Shadertoy</a>, Dreams</a>, and Clayxels</a>.
The more I thought about it, the more the smooth blending property that comes with SDFs seemed like a must-have to address the needs of seamlessly connecting adjacent tiles.
</video>smooth blending using SDFs
The smooth blending formula can be found on Inigo Quilez’s excellent website</a> where it is described as a function named smin()</code>.
Porting that to Houdini was fairly straighforward.
SDF smooth blending setup in Houdini
Tiling</h2> To divide the world up into equal areas, I decided to use hexagonal tiles—it seemed like a good opportunity for me to experiment with these, but they also look much more organic while remaining simple enough to build grids with. Generating the grid was done in two steps. First, I created a bunch of points that would represent the center of each tile, and then I instantiated one hexagon on each of these points. There’s probably a formal definition for that approach somewhere but I found out through some lucky experimentations that, to generate these instance points, I could use... more hexagons! For the first layer, I’d create an hexagon with a single division per edge. Then another hexagon for the second layer, this time with 2 divisions per edge, and so on. hexagonal grid with instance points The only trick being to know by how much to scale the hexagons for each layer but, after some empirical measurements, I figured it out to be equal to the expression where is a 0-based index representing the current layer. hexagonal grid generation Safe Area</h2> One immediate drawback of smooth blending in the context of connecting adjacent tiles is that it actually modifies the tile’s geometry up to a specific number of voxels deep, with the actual amount of voxels directly depending on the value k</code> used in the smooth blending formula. So we need a sort of “safe area” to inform users that within it anything they do will be preserved as-is. However, outside of that safe zone, in a thin band near the boundaries of the tile, the terrain might change a little bit to accomodate for the smooth blending operation, and hence some edits like placing buildings and other structures might not be permitted in there—but others like roads and rivers might be alright. Not only that but if we were to blend 2 adjacent tiles that are in direct contact, then the transition might be a bit... crude? So we need to allow for a bit of padding between the tiles in order for the blending to generate a smoother transition. And there we have it, tiles being seamlessly connected to each other in an organic fashion while preserving their features within the safe areas. blending of 3 adjacent tilesAd Infinitum</h2> If we only had a fixed numbers of tiles as input that would never change, then we could go ahead and generate the whole terrain in one go through this approach. However, remember that we’re after an infinite world here, so we need to be able to keep connecting new tiles to the already existing world as soon as they are being authored by the users. For that, we need to be able to generate the seams on the go. The approach that I went for was to subdivide the hexagonal grid to obtain another grid made of triangles, where each triangle is centered at the intersection of 3 tiles. cell grid What this means is that, to generate the geometry for a single triangle cell, this solution requires the 3 surrounding tiles to be readily available. And to generate the geometry for a single hexagonal tile, with its seams, all the surrounding cells are required to be known. blending of all the cells overlapping a single tile The advantage of dividing each tile with these triangular cells is that their edge boundaries should pretty much line up, regardless of how much terrain sculpting was done in these areas by the users, which should make it straighforward to stitch them back together. To be honest, I’m not too sure how to explain this assumption with words but I can see pretty pictures in my mind telling me that it should be viable. Or not? The geometry for these cells can be generated on a server as soon as new tiles are being added to the world, or they could also be generated on demand, just before a user is about to explore a new tile for the very first time. streaming of new cells Either way, the result is the same... a world whose boundaries can stretch to infinity and beyond! infinite world (kindof) What’s Next</h2> As mentioned before, this technique only aims at generating an intermediate representation of the terrain, so additional work would need to be done to give it a more interesting and polished look. And by no mean is this proof of concept devoid of issues. For example, connecting adjacent tiles with the smooth function tends to create a bulge in the middle. That being said, I don’t foresee any of these issues to be a showstopper—they should all be addressable, and it should be possible to turn this approach into a reliable product. Alas, I ran out of time to take this experiment further and need to refocus on my others, already too numerous, personal projects. But maybe you’ll be the one to do something cool with it? If so, please share the result! Footnotes</h2>Yes, I’m aware that some games and platforms already provide similar experiences.↩</a></li> Albeit with proper handling over the trolls and toxic behaviours. Hint: nicknames can be used but IDs should be required to be stored privately so that offenders can be held accountable for their action instead of letting them join back the world over and over again using different accounts.↩</a></li></ol></aside>
Optimizing Pixar’s USD Compile Time 2022-04-23T12:00:00Z It’s been a long while since I’ve been wondering how I could possibly contribute to bringing a positive environmental impact to life by using my dev skills. The opportunity finally showed up while doing some work on Pixar USD’s—I noticed that its codebase took around 90 minutes to compile on my laptop (Intel i7-7700HQ, Ubuntu 20.04) using a single thread. It seemed huge. Even though this might not have the greatest impact in reducing energy waste, it was still an actionable item and could prove somewhat useful. After all, USD is becoming mainstream across several industries now and with the amount of developers around the world working on improving its core, and the number of CI servers compiling the codebase over and over again before running tests, I thought... why not giving this a go? If all it does is to help with iteration times for all these developers, it’d still be a win! Definitely Not Zero Cost Abstractions</h2> I know it, you know it, we all know it—C++’s “zero cost abstractions” do in fact have a non-negligible cost, both in increased maintenance complexity but also in compile times. Right? But still... how could a codebase possibly take 90 minutes to compile!? I was intrigued. I fired up Aras Pranckevičius’s awesome compiler profiler</a> and immediately got a clear picture of the problem. *** Expensive headers: 972063 ms: /opt/boost/1.70.0/include/boost/preprocessor/iteration/detail/iter/forward1.hpp (included 13959 times, avg 69 ms), included via: wrapTimestamp.cpp.o pyUtils.h pyInterpreter.h object.hpp object_core.hpp call.hpp arg_to_python.hpp function_handle.hpp caller.hpp (320 ms) ... 904090 ms: build/usd/include/pxr/usd/usd/prim.h (included 369 times, avg 2450 ms), included via: modelAPI.cpp.o modelAPI.h apiSchemaBase.h schemaBase.h (3114 ms) ... 887681 ms: build/usd/include/pxr/base/tf/pyObjWrapper.h (included 993 times, avg 893 ms), included via: aov.cpp.o aov.h types.h value.h (1567 ms) ... 838714 ms: build/usd/include/pxr/usd/usd/object.h (included 374 times, avg 2242 ms), included via: wrapUtils.cpp.o wrapUtils.h (3054 ms) ... 835586 ms: build/usd/include/pxr/base/vt/value.h (included 894 times, avg 934 ms), included via: aov.cpp.o aov.h types.h (1702 ms) ... </code></pre> Yes, that’s right. Over 900,000 ms were spent on compiling some of these headers! That’s more than 15 minutes per header because they are being recompiled over and over again in hundreds, if not thousands, of compilation units. It’s just nuts that C++ encourages this. Remember that C++ is based on C, and that C was designed to only have simple interfaces exposed in the header files (.h</code>), while source files (.c</code>) are reserved for their implementation. Header files were never meant to include actual implementation logic, and yet it’s exactly what C++ pushed for with templates. Take a few header files that include other header files that involve the STL, and there we have it—our definitely non-zero cost abstraction. Tackling the Issue at Its Source</h2> We now know that C++’s design is promoting long compile times, but what would it take then for developers to workaround this pitfall? Well, if we’re fortunate enough to start a new C++ project from scratch, let’s just use headers how they were meant to be used in the first place, duh? Seriously, it’s absolutely feasible to: write headers that define C-like interfaces as much as possible—ban STL data types, use raw pointers, and avoid templates unless strictly necessary.</li> have headers that do not include other headers (with a few, rare, exceptions).</li> and... that’s it!</li> </ul> Yes, it does require a certain paradigm shift but it’s not all that unrealistic. In fact it’s exactly how Our Machinery has been doing it for their game engine, as described in their article Physical Design of The Machinery</a>. After reading that article, I also have experimented with that approach in my personal work, such as Zero: A Bunch of Single-File Libraries for C/C++</a> for example, and although my experiments were on projects of a much smaller scale than The Machinery or USD, I still found it fairly challenging to undo my C++ habits at first, but it quickly became a much more natural process afterwards. And if I managed to do it, I’m sure you can too! Tackling the Issue After the Fact</h2> Optimizing compile times on existing C++ projects without making breaking changes to their API is a whole different challenge. A much bigger one than I anticipated when I started to dive head first into doing just that for USD. Strong from the profiling results, I knew what I needed to do: add support for unity builds</a>. This way, instead of having an enormous amount of tiny compilation units, we’d have only a handful of larger ones and we won’t end up having to recompile the same expensive headers as many times. “Easy-peasy”, I thought. I started by modifying the project’s CMake configuration in order to make it create a new .cpp</code> file for each module (e.g.: pxr/base/arch</code>) that’d include all the other source files from the same module, and to make it compile just that one file instead of the other ones. Not So Fast</h2> Of course unity builds only work if all identifiers in the concatenated source files are unique. Which wasn’t the case in USD’s codebase. Another less obvious issue is that some symbol resolution became ambiguous, as demonstrated in the following example: using namespace boost; using namespace std; tuple foo; // is it “boost::tuple” or “std::tuple”? </code></pre> Hence the work required was two-fold: avoid identifiers clashing by wrapping them all in a unique namespace.</li> flatten all the namespaces by removing using</code> statements and referencing each symbol with their full name.</li> </ul> Early Results</h2> I started to do these changes through a lot of search and replace directly within my IDE, sometimes involving some advanced regular expressions, but it quickly became apparent that this wouldn’t cut it. It was both too tedious and error-prone. I still decided to pursue this approach just enough to cover a couple of modules, as to get an idea of whether I was going in the right direction. Many hours later spread over a few weeks, I finally finished converting the pxr/base/arch</code> and pxr/base/tf</code> modules. The result was quite encouraging with a 4x speed up! That was 2 modules done. Cool, now onto finding a more humane approach to refactoring all of the 55 modules, ahem. Using the AST</h2> I had to find a way to somehow automatize the refactoring. Not only that but, unlike a regular expression approach, I wanted the process to be done in a semantically robust fashion as to give me more confidence that the changes done would be valid. Working at the AST level seemed like the obvious choice and I also kinda liked the idea of learning a new API. So I jumped onto the opportunity to get started with Clang’s AST API, yay! “Surely it should be easy to find all the symbols in a codebase and prefix them with a namespace using the AST”, or so I thought. He he he, how naive of me. I know it, you know it, we all know it—C++ is an (unnecessarily) complex language. And it turns out that this complexity is fairly well reflected in Clang’s AST API. I’ll skip the details but it turned out to be a LOT of pain and to be mentally draining. It took me months to iterate on my refactoring tools, with many setbacks, in order to get them as close as possible to the desired result. But, despite my perseverance, I just could not figure out how to make the refactoring process 100% automatic. There were always some bits of code that needed to be manually patched here and there after running the tools. In fact, Clang’s AST API operates after the C++ preprocessor pass has finished evaluating, meaning that any code wrapped into #if</code>/#ifdef</code> statements might be discarded and left untouched by the refactoring tools. As a result, since I’ve run these tools using an Ubuntu environment, some code paths specific to Windows, macOS, Metal, and others, are required to be manually patched. Final Results</h2> Despite all the adversity, I still managed to refactor the whole USD codebase and to make it compile using an unity build approach. Did the early results carry over? Yeah, mostly! I mean, look at this sexy graph! You’ll note that the timings for g++ 11.1.0 (unity=ON) with 8 threads are only an estimate, and that’s because my laptop runs out of memory for that one. Overall, that’s still a speed-up of 2.7-3.5 times on my laptop. The compilation that took 90 minutes on a single thread now finishes in 26 minutes. Which is admittedly still a lot but it’s a start. Still Want to Know More?</h2> You might find what you’re looking for in this pull request on GitHub</a>. As for the refactoring tools, they’re available on a GitHub repository</a>. What’s Next?</h2> You know what would be fun? Optimizing the compile times of the LLVM project... tee-hee! Rexo: A Unit Testing Framework in C (Part 2) 2021-10-15T13:00:00Z I revamped my C89/C++ unit testing framework around the end of 2019 but I never really shared what’s cool about it... let’s finally address this! View on GitHub</a> When I implemented Rexo</a>’s first iteration in 2018, which I already wrote about here</a>, I mostly set out to understand why the majority of the unit testing frameworks for C required so much boilerplate in comparison to the ones offered in C++. The short answer is that the C standard doesn’t offer any portable way to implement automatic registration of tests. I ended up going ahead with the usual approach but, for someone who prides himself with always aiming at providing the best user experience possible, I wasn’t happy at all with my own implementation and wanted to address it somehow. Automatic Test Registration</h2> The C frameworks NovaProva</a> and Criterion</a> workaround C’s limitation by respectively reading the DWARF debug information generated during a debug compilation, and by parsing the ELF (Unix), Mach-O (macOS), and PE (Windows) executable file formats to read their data sections. This might just be my lack of knowledge but I found both implementations to be so involved that I couldn’t fully make sense of their fine details. I was hoping for a much simpler solution. The data section approach used by Criterion is pretty neat because it allows storing some data initialized at the file scope and then retrieve it later on, which is exactly what we were missing. Although data sections are not part of the C/C++ standards, it turns our that they are so important to low-level system programming that each compiler expose them in a way or another. So I looked into this direction and... tada! I got a fairly straightforward implementation working with support for the GNU-like compilers (GCC, clang, ICC) and MSVC[1]</a>, which is pretty much the same coverage as Criterion’s, and can also be extended as needed. #include <stdio.h> /* Example of automatic test registration. This approach uses a data section ‘bar’ to store multiple static instances of type ‘foo’. These objects are first statically instantiated at the file scope and a pointer is then stored in the data section, between some given ‘start’ and ‘end’ locations. Objects stored this way can then be retrieved at runtime by iterating over all the pointers found between these ‘start’ and ‘end’ locations. */ struct foo { int value; }; /* Implementation Details */ /* -------------------------------------------------------------------------- */ #if defined(_MSC_VER) __pragma(section("bar$a", read)) __pragma(section("bar$b", read)) __pragma(section("bar$c", read)) __declspec(allocate("bar$a")) extern const struct foo * const bar_begin = NULL; __declspec(allocate("bar$c")) extern const struct foo * const bar_end = NULL; #define DEFINE_SECTION \ __declspec(allocate("bar$b")) #elif defined(__APPLE__) extern const struct foo * const __start_bar __asm("section$start$__DATA$bar"); extern const struct foo * const __stop_bar __asm("section$end$__DATA$bar"); #define DEFINE_SECTION \ __attribute__((used,section("__DATA,bar"))) DEFINE_SECTION extern const struct foo * const dummy = NULL; #elif defined(__unix__) extern const struct foo * const __start_bar; extern const struct foo * const __stop_bar; #define DEFINE_SECTION \ __attribute__((used,section("bar"))) DEFINE_SECTION extern const struct foo * const dummy = NULL; #endif /* Public API */ /* -------------------------------------------------------------------------- */ #if defined(_MSC_VER) #define SECTION_BEGIN \ (&bar_begin + 1) #define SECTION_END \ (&bar_end) #elif defined(__unix__) || defined(__APPLE__) #define SECTION_BEGIN \ (&__start_bar) #define SECTION_END \ (&__stop_bar) #endif #define REGISTER_FOO(id, value) \ static const struct foo id = { value }; \ DEFINE_SECTION \ extern const struct foo * const id##_ptr = &id; /* Usage */ /* -------------------------------------------------------------------------- */ REGISTER_FOO(b, 234); REGISTER_FOO(a, 123); REGISTER_FOO(c, 345); int main( void ) { const struct foo * const *it; for (it = SECTION_BEGIN; it < SECTION_END; ++it) { if (*it != NULL) { printf("%d\n", (*it)->value); } } return 0; } </code></pre> And... that’s it! I think that’s fairly sweet and short, at least in comparison to what I’ve seen in NovaProva and Criterion. Rexo makes use of this automatic registration feature through the macros RX_TEST_CASE</code> and RX_TEST_SUITE</code>, as shown in this minimal example</a> from the documentation. Designated Initializer-like Syntax With Cascading Configuration</h2> C99, and later C++20, introduced designated initializers which is a neat feature to default initialize a struct to zero while letting users set the value of hand-picked fields, similarly to default named function parameters for other languages. struct my_struct { const char *foo; int bar; double baz; }; /* Only setting the bar field leaves foo and baz to 0. */ struct my_struct inst = {.bar = 123}; </code></pre> This kind of syntax is something that I’ve been looking forward to implement in Rexo to configure the test cases, suites, and fixtures. Not only because it’s a nice syntactic sugar but also because it would allow me to extend the configuration options as needed without breaking the API and requiring users to update their code. It turns out that here again Criterion got this one sorted out. Almost. From my understanding, Criterion allows to configure all the tests in a suite at once by setting configuration values on the suite itself. That’s great! On top of that, it’s still possible to override these values for each individual test case. However, this overriding operation works by replacing the whole set of configuration values instead of inheriting the ones from the parent suite and only updating the values passed to the test cases. TEST_SUITE(my_suite, .foo = "hello", .baz = 1.23); TEST_CASE(my_suite, my_case, .foo = "world") { // Expectation : {foo = "hello", bar = 0, baz = 1.23} // Criterion : {foo = "world", bar = 0, baz = 0.0} } </code></pre> Not happy with that, I decided to try taking Criterion’s approach to the next level while still supporting C89 and all C++ versions. It took me some time to figure it out but the solution is quite simple in the end! We just need to close our eyes on all these redundant macros required to support C89 and its lack of variadic arguments. #include <stdio.h> #include <string.h> /* Macros */ /* -------------------------------------------------------------------------- */ #define UNUSED(x) (void)(x) #define EXPAND(x) x #define CONCAT_(a, b) a##b #define CONCAT(a, b) CONCAT_(a, b) #define STRUCT_SET_MEMBER(x) (*obj) x; #define STRUCT_UPDATE_0() #define STRUCT_UPDATE_1(_0) \ STRUCT_SET_MEMBER(_0) #define STRUCT_UPDATE_2(_0, _1) \ STRUCT_SET_MEMBER(_0) \ STRUCT_UPDATE_1(_1) #define STRUCT_UPDATE_3(_0, _1, _2) \ STRUCT_SET_MEMBER(_0) \ STRUCT_UPDATE_2(_1, _2) #define STRUCT_UPDATE_4(_0, _1, _2, _3) \ STRUCT_SET_MEMBER(_0) \ STRUCT_UPDATE_3(_1, _2, _3) #define STRUCT_UPDATE_5(_0, _1, _2, _3, _4) \ STRUCT_SET_MEMBER(_0) \ STRUCT_UPDATE_4(_1, _2, _3, _4) #define STRUCT_UPDATE_6(_0, _1, _2, _3, _4, _5) \ STRUCT_SET_MEMBER(_0) \ STRUCT_UPDATE_5(_1, _2, _3, _4, _5) #define STRUCT_UPDATE_7(_0, _1, _2, _3, _4, _5, _6) \ STRUCT_SET_MEMBER(_0) \ STRUCT_UPDATE_6(_1, _2, _3, _4, _5, _6) #define STRUCT_UPDATE_8(_0, _1, _2, _3, _4, _5, _6, _7) \ STRUCT_SET_MEMBER(_0) \ STRUCT_UPDATE_7(_1, _2, _3, _4, _5, _6, _7) #define STRUCT_DEFINE_UPDATE_FN(id, type, arg_count, args) \ static void \ id(type *obj) \ { \ UNUSED(obj); \ EXPAND(CONCAT(STRUCT_UPDATE_, arg_count) args) \ } /* Config */ /* -------------------------------------------------------------------------- */ struct config { const char *foo; int bar; double baz; }; typedef void (*config_update_fn)( struct config * ); struct config_desc { const config_update_fn update; }; #define CONFIG(id, arg_count, args) \ STRUCT_DEFINE_UPDATE_FN( \ id##_config_update_fn, \ struct config, \ arg_count, \ args) \ \ static const struct config_desc \ id##_config_desc = {id##_config_update_fn} /* Test Suite */ /* -------------------------------------------------------------------------- */ struct test_suite_desc { const char *name; const struct config_desc *config_desc; }; #define TEST_SUITE_(id, arg_count, args) \ CONFIG(id, arg_count, args) \ /* Test suite registration and declaration goes here. */ #define TEST_SUITE_1(id, _0) \ TEST_SUITE_(id, 1, (_0)) #define TEST_SUITE_2(id, _0, _1) \ TEST_SUITE_(id, 2, (_0, _1)) /* Test Case */ /* -------------------------------------------------------------------------- */ struct test_case_desc { const char *suite_name; const char *name; const struct config_desc *config_desc; }; #define TEST_CASE_(suite_id, id, arg_count, args) \ CONFIG(suite_id##_##id, arg_count, args) \ /* Test case registration and declaration goes here. */ #define TEST_CASE_1(suite_id, id, _0) \ TEST_CASE_(suite_id, id, 1, (_0)) #define TEST_CASE_2(suite_id, id, _0, _1) \ TEST_CASE_(suite_id, id, 2, (_0, _1)) /* Usage */ /* -------------------------------------------------------------------------- */ TEST_SUITE_2(my_suite, .foo = "hello", .baz = 1.23); TEST_CASE_1(my_suite, my_case, .foo = "world"); int main( void ) { struct config config; memset(&config, 0, sizeof config); my_suite_config_desc.update(&config); my_suite_my_case_config_desc.update(&config); printf("foo: %s\n", config.foo); printf("bar: %d\n", config.bar); printf("baz: %f\n", config.baz); return 0; } </code></pre> The trick basically consists in defining a function which contains the necessary logic to update an existing configuration instance with the given field values. Maybe it’ll be clearer after expanding the two macros calls from the usage section above. /* TEST_SUITE_2(my_suite, .foo="hello", .baz=1.23) */ /* -------------------------------------------------------------------------- */ static void my_suite_config_update_fn( struct config *obj ) { (void)(obj); (*obj).foo = "hello"; (*obj).baz = 1.23; } static const struct config_desc my_suite_config_desc = {my_suite_config_update_fn}; /* TEST_CASE_1(my_suite, my_case, .foo="world") */ /* -------------------------------------------------------------------------- */ static void my_suite_my_case_config_update_fn( struct config *obj ) { (void)(obj); (*obj).foo = "world"; } static const struct config_desc my_suite_my_case_config_desc = {my_suite_my_case_config_update_fn}; /* -------------------------------------------------------------------------- */ int main( void ) { struct config config; memset(&config, 0, sizeof config); my_suite_config_desc.update(&config); my_suite_my_case_config_desc.update(&config); printf("foo: %s\n", config.foo); printf("bar: %d\n", config.bar); printf("baz: %f\n", config.baz); return 0; } </code></pre> Straighforward, right? If you’re curious to see how it looks like in action in Rexo, check out this concrete example</a> from the documentation. Closing Notes</h2> I’m fairly happy with the current state of Rexo although there would still be some more work needed to be done in order to implement more assertion macros, to output the report summaries in different standard formats (e.g.: jUnit XML), and to provide more visual diagnostic messages, amongst other things. But it’s still plenty enough for me to rely on it for my other projects, and maybe it would be satisfactory for yours as well? If it’s something that you’d be interested in exploring, maybe a good place to start would be to have a peek at its comprehensive documentation</a>. Or you can always head straight to its GitHub repository</a> otherwise. If you end up using it, please let me know how it goes! Footnotes</h2>Thanks to Marco Giordano for finding an issue with MSVC discarding the section items when compiling in C++ mode, and to Sy Brand for providing a solution!↩</a></li></ol></aside> Wadu: Again and Again 2020-09-14T12:00:00Z View on GitHub</a> March 2020, me and my ≈1,500 colleagues from Weta Digital</a> were being sent home to work remotely due to the COVID-19 pandemic. This also meant no more gym and the need to find a way to do some exercises somewhat regularly. Surely, this sounded like a good pretext to build a terminal-based app that would remind me of doing specific exercises at specific times, right? And, surely, setting up reminders that are to be triggered every day at a given time is no big deal, right? But wait. How about reminders that occur only once every 2 weeks? Or only during the first week of each month? It quickly became apparent that some more thinking needed to take place and that’s when I stumbled upon the iCalendar (RFC 5545)</a> specification that describes recurrence rule objects, amongst other things. I even found a popular Python package named dateutil</a> that implements these recurrence rules, however... ... it wouldn’t be fun if it was too easy, or so I thought. And while skimming through the implementation of dateutil, I found some of its bits to be fairly difficult to decypher. So, “y’know what, bud?”, I asked myself, “the best way to learn about something is to do it yourself”. But that wasn’t all. The naïve person that I was decided that this wasn't challenging enough: “while y’er at it, make a simpler implementation. And why not a moar optimised one, too. And with a data-oriented approach, y’know?”. At that time, I had no idea what I was getting into. I simply dived head first into the rabbit hole of recurring date events and what started as a fun exercise quickly turned into hell. Hell</h2> In retrospective, I can say this probably was the most challenging programming project that I’ve ever worked on. Not due to the code complexity, mind you. It’s all fairly straightforward. No, no, what made it truly difficult was making sense of that RFC 5545 specification. Trying to implement the specification one piece at a time, without fully grasping the whole picture, was a truly inefficient approach but, at the same time, it also was the only way to build the required knowledge to move forward. Whenever I’d end up successfully implementing one bit, I’d move onto the next one only to realize that my understanding of the specification felt apart and that my whole approach was thus wrong. Which led me to needing to rethink everything from the beginning. Every. Single. Time. It really felt hopeless. How many times did I begin seeing the light at the end of the tunnel only to see it collapse right in front of me, forcing me to go all the way back to the starting point? I lost count. Did I really have to be my usual stubborn masochist self and implement something that no one will ever care about, when I could have spent my time working on cool projects instead? Wadu</h2> The one thing that finally came to my rescue was stumbling upon the JSCalendar draft from IETF</a>. At last a specification that is clear, well articulated and, most importantly, that doesn’t leave space for ambiguities like the RFC 5545 does. Because of these ambiguities, different libraries such as dateutil</a>, libical</a>, lib-recur</a>, and others, all advertise themselves to be RFC 5545 compliant—and rightfully so—while at the same time returning inconsistent results depending on how the specification is being interpreted. So here I stand. With the only open source implementation that I’m aware of that is fully compliant with the JSCalendar draft while covering all the edge cases that I could find, and boasting a relatively straightforward-ish implementation. I called it wadu and the source code is on GitHub</a>, as always! Hell, it’s even on pypi</a> so you could go ahead and install it by running pip install wadu</code> if you too would like to get to play with these sexy curves: # The 1st Friday of each month, for 10 occurrences. rule = RecurrenceRule(MONTHLY, on_week_days=(FRIDAY(1),), count=10) for dttm in rule: print(dttm) # Every other year on January and February, starting on a given date. rule = RecurrenceRule(YEARLY, interval=2, on_months=(JANUARY, FEBRUARY), count=10) start = datetime(1997, 3, 10, hour=9) for dttm in rule.iterate_from(start): print(dttm) </code></pre> Final Notes</h2> If you’re wondering whether I got to implement the terminal-based app that I initially intended to write: of course not ¯\_(ツ)_/¯ And I didn’t end up doing any exercise neither. ― Jesus Fucking Christ. What did we learn, Palmer? ― I don’t know sir. ― I don’t fucking know either. I guess we learned not to do it again. I’m fucked if I know what we did. </blockquote> Forget About Anti-Cheats, Here's How You Do It 2019-12-22T13:00:00Z These things that are plaguing most online multiplayer games—cheating and toxicity? I think that we could address them better. I never cheated, I swear! Bottlenecks</h2> In my opinion, there are two main areas that are preventing much improvement to the current situation: the detection process and offense handling. Detection Process</h3> Anti-cheat software solutions have some major drawbacks: burdening for the developers: anti-cheats can not only be complicated[1]</a> but they're also costly to maintain since resources need to be continuously invested into researching how to block new cheats as they arise.</li> burdening for the players: client-side anti-cheats can possibly affect the performance and cause issues (e.g.: freezes and crashes) to the whole player base only to fight a minority of players. This is like using a big hammer to kill a fly—legitimate players shouldn't have to pay that price due to a minority of troublemakers.</li> unreliable: the truth is that no sort of anti-cheat is fully reliable. It's a relentless battle against cheat developers (cheat-making is a big business[2]</a>[3]</a>) and it simply is technically impossible to develop a perfect anti-cheat. Worse, they can produce false positives and end up banning legitimate players.</li> </ul> Which seems to me like a lot of negatives only for suboptimal results? Offense Handling</h3> Even more importantly than the detection process is how the offences are being handled. Banning a game account is NOT enough when players can simply get back into the game through another account. It's like being put in jail only to be let free if you pay a small fine of $30—why even bother? It's not as if this amounts to anything when most cheaters are probably rich kids and the monthly subscription for these cheats can be more expensive than the game itself. As long as this issue won't be tackled properly, any effort going into fighting toxic players and cheaters will just end up being a waste of time, resources, energy, and trust. Suggestion</h2> What I'm trying to say here is that we might be tackling these problems the wrong way around. Empower Humans Over Softwares</h3> Anti-cheat softwares are burdening and unreliable. Humans are much more reliable towards detecting cheats and don't have any negative impact on game performance and whatnot. So how would a game developer go about building a detection process based around humans? It's simple, really—make better use of the community and reward them for their positive contributions! When a player reports someone who is then confirmed by the game developer's staff to be a cheater, then the player receives some contribution points. When a given number of points is reached, the player gets some nice, exclusive, skins or whatnot. To prevent abuse of the system, any report targeted at legitimate players results in a loss of points—so you'd better get it right. Reports can then be automatically prioritized to help the staff to first assess the reports that are more likely to be positives, while comforting the players that their valuable reports will be assessed sooner than later if, and only if, they have a good track record. The priority formula could be as simple as the Python snippet that is to be found at the end of this post</a>. The result of this formula, ran over a small data set, looks like this: positive reports</th> total reports</th> priority</th> </tr> </thead> 6</td> 93</td> -0.861</td> </tr> 1</td> 25</td> -0.793</td> </tr> 3</td> 8</td> -0.098</td> </tr> 0</td> 2</td> -0.038</td> </tr> 0</td> 1</td> -0.010</td> </tr> 0</td> 0</td> +0.000</td> </tr> 1</td> 1</td> +0.010</td> </tr> 2</td> 2</td> +0.038</td> </tr> 7</td> 12</td> +0.098</td> </tr> 7</td> 7</td> +0.329</td> </tr> 25</td> 27</td> +0.749</td> </tr> 47</td> 52</td> +0.779</td> </tr> 52</td> 53</td> +0.929</td> </tr> </tbody> </table></div> As you can see, both the number of reports and their accuracy are being taken into account to provide a priority metric that makes sense—the more meaningful someone's contribution is, the higher priority their reports will have, and vice versa. From there, client-side anti-cheats could be removed altogether, or at least be made less disruptive. This doesn't mean that there is no place for software detection at all. It'd always be helpful for a game developer to be able to find cheaters without requiring any assistance from the community—this can be implemented by flagging users with a high K/D ratio or win rate, or why not by adding a server-side deep learning system^{[4]</a> that would learn from the ingame behaviour of players that were reported.} It is important to note that any detection software should NOT have an authoritative decision. It should never directly ban a player, only flag them for human review. I might be biased but this seems like a bulletproof detection system to me—I bet that any community would be happy to contribute if they'd be rewarded accordingly, as long as they'd be guaranteed that their efforts won't go to waste by getting the offenders banned for good. Keeping the Offenders Out, For Good</h3> If I was developing an online multiplayer game, I probably wouldn't bother too much about crafting complicated anti-cheats. But the caveat would be: if you get caught, you're out of my game, for good. How'd you do that? How'd you uniquely identify each player regarding on which game account they might be using? Not with an IP address, not with an HWID, but with an actual proof of identity and/or physical address. For example, such a verification system could require either one or a combination of the following: providing a scan of an official document from the government (national ID, passport, driving license, ...).</li> entering a verification code that was sent by the game developer through post mail to a given physical address.</li> taking a selfie next to a verification code that is displayed either on a phone or printed out on a piece of paper.</li> </ul> Of course you shouldn't have to provide a proof of identity only to play a game online. But I bet that the part of the community that truly cares about playing in a good, safe, environment, which I'm hoping is the majority of us, would understand the benefits of providing such a proof of identity and would be fine complying with it? It could even be handled through an external, independent, platform, and be made available to all games, so you'd have to go through the verification process only once. Such a system would be optional. You could decide not to opt-in and have access to the ‘normal’ matchmaking queues, or you could opt-in and also gain access the ‘verified’ queues. Once a verified offender would get caught, it means that not only their game account would be banned but also their actual physical identity would be blacklisted. It wouldn't be possible for that person to join a ‘verified’ queue ever again, thus ensuring that these queues become safer and safer over time. How Does That Sound?</h2> I know for one that I'd be happy to be part of a community where we'd fight toxicity and cheating all together, hands in hands with game developers, to provide the best possible online multiplayer gaming experience. Hell, the concept could probably be extended to other type of online communities. Would you be willing to join the fight against cheating and toxicity if such a concept were to be implemented? Priority Formula Code</h2> Here is the Python snippet used to compute the priority table from above: #! /usr/bin/env python # -*- coding: utf-8 -*- """Formula to compute a priority value according to the reports received. The priority number fits in the range [-1.0, 1.0]. Everyone starts at 0, synonym to a neutral priority level. """ _DATA_SET = ( (0, 0), (0, 1), (0, 2), (1, 1), (2, 2), (1, 25), (3, 8), (6, 93), (7, 7), (7, 12), (25, 27), (47, 52), (52, 53), ) # Magic number—the higher, the more weight will be given to the ratio # `positive_count / total_count` as the number of reports increase. _THRESHOLD = 10 def _compute_priority(positive_count, total_count): if total_count == 0: return 0 x = float(total_count) / _THRESHOLD weight = 1 - 1 / (x * x + 1) ratio = (float(positive_count) / total_count) * 2 - 1 return ratio * weight def _print_results(results): print("+---------------------------------------------+") print("| positive reports | total reports | priority |") print("+------------------+---------------+----------+") for priority, (positive_count, total_count) in results: print("| {:16d} | {:13d} | {:+8.3f} |".format( positive_count, total_count, priority)) print("+---------------------------------------------+") def main(): results = sorted((_compute_priority(*x), x) for x in _DATA_SET) _print_results(results) if __name__ == '__main__': main() </code></pre> Footnotes</h2>Riot's Approach to Anti-Cheat</a>.↩</a></li> Hacks! An investigation into the million-dollar business of video game cheating</a>↩</a></li> Feeling the Cheat: The Game Hack Sellers Working Under the Radar</a>↩</a></li> GDC 2018: John McDonald (Valve) - Using Deep Learning to Combat Cheating in CSGO</a>↩</a></li></ol></aside> Houdini: Flame 2018-06-13T12:00:00Z A while ago I did simulate a flame in Houdini based on a video reference that had a lot of character to it (see below), to the point where it almost produced a stroboscopic effect. I was happy with the result that I obtained but alas I could not share the scene because I lost the definition of some custom digital assets that I was using. Rejoy as I have recreated it from scratch! Watch on Vimeo</a> The effect is pretty simple to achieve. The only tricks are to provide a pulsatile temperature source but also to find a good balance between the pyro solver's shredding, which brings some of the character out but shorten the flame's height, and the buoyancy plus temperature multiplier combo. Too much of shredding and the motion becomes too frenetic, and not enough temperature/buoyancy and the flame becomes too short. Download</h2> flame-01 v1</a> This file contains a scene created with SideFX</a>’s Houdini 16.5 as well as any required asset. </div> References</h2> https://www.youtube.com/watch?v=aCpBT3sIPc4&t=80</a></li> </ul> Rexo: A Unit Testing Framework in C 2018-06-11T12:00:00Z In the serie of reinventing the wheel for the sake of learning, let me introduce you to the unit testing framework! Update A full redesign of Rexo has since been released, see Rexo: A Unit Testing Framework in C (Part 2)</a>. </div> View on GitHub</a> Test Registration</h2> While looking around for unit testing frameworks written in C, I noticed that the vast majority were fairly verbose and didn’t provide any sort of automatic test registration like most of their C++ counterparts do. There had to be some sort of additional constraints inheritent to C, but which ones? In an effort to learn more about the C language, I set out to answer this question by writing my own unit testing framework from scratch, in C89. The reason why automatic test registration is not available in C quickly became obvious. C++ frameworks like Google Test use some clever static initialization trickery that registers each test to a global factory class with the help of some macros to nicely hide the registration logic away from the user[1]</a>. But no function, not even static, can be called at the file scope in C. All that is allowed is defining simple constant values and functions, so no such trickery allowed here. As an example, the simple code snippet below works perfectly fine in C++ but triggers a compilation error in C. #include <stdio.h> static int foo() { return 123; } static const int bar = foo(); int main() { printf("bar is %d\n", bar); return 0; } </code></pre> Some C frameworks such as NovaProva</a> workaround this limitation by reading the DWARF debug information</a> generated during a debug compilation while Criterion</a> parses the generated executable file formats to read the contents of specific data sections. I wasn’t ready to dig into such involved approaches so I picked the more standard route with this first iteration of Rexo and went for the manual registration choice with all the verbosity that it comes with. API Design</h2> Rexo provides both a diagonal API for ease of use and an orthogonal one for maximum customizability. The diagonal API is just one function, rxRun()</code>. It takes the suites as parameter and run them. The orthogonal API is made of all the smaller logical parts that rxRun()</code> uses to get the job done, that is rxInitializeTestCaseReport()</code>, rxTerminateTestCaseReport()</code>, rxRunTestCase()</code>, and rxPrintTestCaseRunSummary()</code>. If you go down this path, it means that you need to write your own function to run the tests, and it’s also up to you to use the provided orthogonal functions or here again to write your own variants... but at this point, you’re probably better off writing your own framework from scratch. Simple Usage</h2> Here’s a basic example on how to use Rexo, with a fixture and a display of a few of the available assertion macros, which are declined in CHECK</code> and REQUIRE</code> variants, respectively for nonfatal and fatal failures. #define RX_DEBUG_LOGGING_LEVEL #include <rexo/rexo.h> #include <stddef.h> #include <stdio.h> #define PI 3.14159265358979323846 struct Fixture { int zero; unsigned int one; }; enum RxStatus setUp(void **ppFixture) { struct Fixture *pData; pData = (struct Fixture *)malloc(sizeof *pData); if (pData == NULL) { return RX_ERROR_ALLOCATION; } pData->zero = 0; pData->one = 1; *ppFixture = (void *)pData; return RX_SUCCESS; } void tearDown(void *pFixture) { free(pFixture); } RX_TEST_CASE(testBasics) { struct Fixture *pData; pData = (struct Fixture *)RX_FIXTURE; RX_CHECK_INT_EQUAL(pData->zero, 0); RX_CHECK_UINT_EQUAL(pData->one, 1); RX_CHECK_FP_ALMOST_EQUAL(sin(PI), 0.0, 1.0e-6); RX_CHECK_FP_ALMOST_EQUAL(sin(PI * 0.5), 1.0, 1.0e-6); RX_CHECK_STRING_EQUAL_NO_CASE("abc", "ABC"); } RX_TEST_CASE(testFailure) { struct Fixture *pData; pData = (struct Fixture *)RX_FIXTURE; RX_CHECK_INT_EQUAL(pData->zero, 1); } static const struct RxTestCase cases[] = {{"basics", testBasics}, {"failure", testFailure}}; static const struct RxTestSuite suites[] = {{"example", sizeof cases / sizeof cases[0], cases, setUp, tearDown}}; int main(int argc, const char **ppArgv) { rxRun(sizeof suites / sizeof suites[0], suites, argc, ppArgv); return 0; } </code></pre> Which results in the output: [PASSED] "example" / "basics" (0.009188 ms) [FAILED] "example" / "failure" (0.010063 ms) ./rexo/tests/example.c:57: nonfatal test failure: ‘pData->zero’ is expected to be equal to ‘1’ 0 == 1 </code></pre> Where Is It?</h2> On GitHub</a>, as always! Footnotes</h2>See this condensed example on Stackoverflow</a>.↩</a></li></ol></aside> Zero: Dynamic Arrays 2018-05-26T12:00:00Z Dynamic arrays stand for arrays that can grow and shrink in size. They are conceptualized in C++ through the std::vector</code> class, but no such facility is available out of the box in C, leading to countless different implementations by countless different developers. This is my contribution to it! A trendy, minimalist, implementation comes from Sean Barrett’s stretchy buffer</a> but I decided to go for a slightly more involved approach. View on GitHub</a> Inspired by C++ templates, the library provides a ZR_MAKE_DYNAMIC_ARRAY()</code> macro that generates all the functions needed to manipulate a dynamic array for a given type. The library’s code is slightly abominable but it’s pretty neat on the user’s end, with all the type checking you’d get with the usual function signatures. One cool feature, as shared by Zero’s allocator library</a> and Sean Barrett’s stretchy buffers, is that these arrays are not wrapped into any sort of structure to make them work—all the bookkeeping required is instead stored in a header invisible to the user, so you can still pass your arrays around as if they were plain C arrays. For the manipulation side of things, three main families of functions provide facilities to add new elements into an array: extend</code>: adds new uninitialized element(s) at a given position and returns a pointer to the first element added</li> insert</code>: adds new element(s) at a given position and initializes them by copying the given input values</li> push</code>: adds a new element at a given position and initializes it by copying the given input value</li> </ul> And a single one is dedicated to removing elements: trim</code>. Each of these 4 functions come in different flavours. While the base one offers an explicit control over where the modification needs to occur, two variants exist as a shortcut to focus on the front and back ends of the arrays. Here’s a usage example, with error checking omitted for brevity: #define ZR_DEFINE_IMPLEMENTATION #include <zero/dynamicarray.h> ZR_MAKE_DYNAMIC_ARRAY(IntArray, int) int main(void) { int *pArray; int *pSlice; int values[2]; zrCreateIntArray(&pArray, 2); pArray[0] = 1; pArray[1] = 2; /* pArray: {1, 2} */ zrResizeIntArray(&pArray, 4); pArray[2] = 7; pArray[3] = 8; /* pArray: {1, 2, 7, 8} */ zrExtendIntArray(&pSlice, &pArray, 2, 2); pSlice[0] = 3; pSlice[1] = 6; /* pArray: {1, 2, 3, 6, 7, 8} */ values[0] = 4; values[1] = 5; zrInsertIntArray(&pArray, 3, sizeof values / sizeof values[0], values); /* pArray: {1, 2, 3, 4, 5, 6, 7, 8} */ zrPushIntArrayFront(&pArray, 0); zrPushIntArrayBack(&pArray, 9); /* pArray: {0, 1, 2, 3, 4, 5, 6, 7, 8, 9} */ zrDestroyIntArray(pArray); return 0; } </code></pre> I’m not sure what the drawbacks of this approach are (if any) but that’s exactly why I decided to experiment with it! If you have some feedback, please do share! The implementation is available on GitHub</a>. Houdini: Ray Tracer in VEX 2018-05-23T12:00:00Z I’ve seen many people sharing fun ray tracers experiments with Houdini’s VEX in the past,[1]</a> and it just happens that I’ve had many ~10 min bursts of time to spare due to waiting for simulation computations, so I grabbed a copy of Peter Shirley’s mini book Ray Tracing in One Weekend</cite></a>[2]</a> and gave it a go. Watch on Vimeo</a> I’ve used Houdini facilities when possible, such as various SOP nodes to build the scene and the built-in VEX functions like intersect()</code>, fresnel()</code>, reflect()</code>, refract()</code>, and others, which allowed me to take a few shortcuts. Hence it’s more of an adaptation rather than a 100% faithful implementation of the book, but the results are fairly similar. Still, it’s been plenty enough to give a good introduction to ray tracing and I’m happy with that! Performance-wise though... it’s not there yet. Probably a good contender for an implementation using an OpenCL SOP node? The scene is available in the download link below, but I’ll also throw the VEX code here for quick reference: #define MAX_BOUNCES 8 #define NEAR_DISTANCE 1.0e-3 #define FAR_DISTANCE 1.0e3 #define MATERIAL_LAMBERT 0 #define MATERIAL_METAL 1 #define MATERIAL_DIELECTRIC 2 #define GEOS_INPUT_IDX 1 #define SKY_RAMP_NAME "sky" #define ALBEDO_ATTRIB_NAME "Cd" #define NORMAL_ATTRIB_NAME "N" #define MATERIAL_ATTRIB_NAME "material" #define FUZZINESS_ATTRIB_NAME "fuzziness" #define IOR_ATTRIB_NAME "ior" struct Ray { vector origin; vector direction; }; struct Hit { int prim; vector uvw; vector pos; vector normal; }; void trace(export int hitten; export Hit hit; const Ray ray) { vector pos; vector uvw; int prim; prim = intersect( GEOS_INPUT_IDX, ray.origin + ray.direction * {NEAR_DISTANCE, NEAR_DISTANCE, NEAR_DISTANCE}, ray.direction * {FAR_DISTANCE, FAR_DISTANCE, FAR_DISTANCE}, pos, uvw); hitten = prim > -1; if (hitten) { hit.prim = prim; hit.uvw = uvw; hit.pos = pos; hit.normal = primuv( GEOS_INPUT_IDX, NORMAL_ATTRIB_NAME, hit.prim, hit.uvw); } } void evalLambertianMaterial(export int scattered; export Ray scatteredRay; export vector attenuation; const Ray ray; const Hit hit) { vector randomPos; vector target; randomPos = sample_sphere_uniform(set(nrandom(), nrandom(), nrandom())); target = hit.pos + hit.normal + randomPos; attenuation = primuv(GEOS_INPUT_IDX, ALBEDO_ATTRIB_NAME, hit.prim, hit.uvw); scatteredRay = Ray(hit.pos, normalize(target - hit.pos)); scattered = 1; } void evalMetallicMaterial(export int scattered; export Ray scatteredRay; export vector attenuation; const Ray ray; const Hit hit) { vector randomPos; float fuzziness; randomPos = sample_sphere_uniform(set(nrandom(), nrandom(), nrandom())); fuzziness = min( primuv(GEOS_INPUT_IDX, FUZZINESS_ATTRIB_NAME, hit.prim, hit.uvw), 1.0); attenuation = primuv(GEOS_INPUT_IDX, ALBEDO_ATTRIB_NAME, hit.prim, hit.uvw); scatteredRay = Ray( hit.pos, reflect(ray.direction, hit.normal) + randomPos * fuzziness); scattered = dot(scatteredRay.direction, hit.normal) > 0; } void evalDielectricMaterial(export int scattered; export Ray scatteredRay; export vector attenuation; const Ray ray; const Hit hit) { float iDotN; float ior; float iorRatio; vector outNormal; float cosine; float reflectedAmount; float refractedAmount; attenuation = {1.0, 1.0, 1.0}; scattered = 1; iDotN = dot(ray.direction, hit.normal); ior = ior = primuv(GEOS_INPUT_IDX, IOR_ATTRIB_NAME, hit.prim, hit.uvw); if (iDotN < 0) { // The ray comes from outside the surface. iorRatio = 1.0 / ior; outNormal = hit.normal; cosine = -iDotN / length(ray.direction); } else { // The ray comes from inside the surface. iorRatio = ior; outNormal = -hit.normal; cosine = ior * iDotN / length(ray.direction); } fresnel( ray.direction, outNormal, iorRatio, reflectedAmount, refractedAmount); if (nrandom() < reflectedAmount) { scatteredRay = Ray(hit.pos, reflect(ray.direction, hit.normal)); return; } scatteredRay = Ray(hit.pos, refract(ray.direction, outNormal, iorRatio)); } void getColor(export vector color; const Ray ray) { int i; Ray stack[]; vector accumulator[]; int hitten; Hit hit; i = 0; push(stack, ray); while (len(stack) > 0) { Ray currentRay; currentRay = pop(stack); trace(hitten, hit, currentRay); if (hitten && i < MAX_BOUNCES) { int material; int scattered; Ray scatteredRay; vector attenuation; material = prim(GEOS_INPUT_IDX, MATERIAL_ATTRIB_NAME, hit.prim); if (material == MATERIAL_LAMBERT) { evalLambertianMaterial( scattered, scatteredRay, attenuation, currentRay, hit); } else if (material == MATERIAL_METAL) { evalMetallicMaterial( scattered, scatteredRay, attenuation, currentRay, hit); } else if (material == MATERIAL_DIELECTRIC) { evalDielectricMaterial( scattered, scatteredRay, attenuation, currentRay, hit); } else { warning("unsupported material"); push(accumulator, {1.0, 0.078, 0.576}); break; } if (scattered) { push(accumulator, attenuation); push(stack, scatteredRay); } else { push(accumulator, {0.0, 0.0, 0.0}); } ++i; } else { float v; v = dot(normalize(set( currentRay.direction.x, 0.0, currentRay.direction.z)), currentRay.direction); v = currentRay.direction.y < 0 ? 0.0 : 1.0 - v; push(accumulator, chramp(SKY_RAMP_NAME, v)); } } color = {1.0, 1.0, 1.0}; for (i = 0; i < len(accumulator); ++i) { color *= accumulator[i]; } } void getCameraRay(export Ray ray; const vector throughPos; const vector pos; const vector u; const vector v; const float aperture) { vector2 randomPos; vector origin; randomPos = sample_circle_uniform(set(nrandom(), nrandom())); randomPos *= aperture * 0.5; origin = pos + u * randomPos.x + v * randomPos.y; ray = Ray(origin, normalize(throughPos - origin)); } cvex main(export vector Cd = {0.0, 0.0, 0.0}; const vector P = {0.0, 0.0, 0.0}; const vector cameraPos = {0.0, 0.0, 0.0}; const vector cameraU = {1.0, 0.0, 0.0}; const vector cameraV = {0.0, 1.0, 0.0}; const float cameraAperture = 1.0) { Ray ray; Cd = {0.0, 0.0, 0.0}; getCameraRay(ray, P, cameraPos, cameraU, cameraV, cameraAperture); getColor(Cd, ray); } </code></pre> Download</h2> ray-tracer-01 v2</a> This file contains a scene created with SideFX</a>’s Houdini 16.5 as well as any required asset. </div> Footnotes</h2>Anatolii Iudanov</a>, Matt Ebb</a>, and others.↩</a></li> Also available as “pay what you want” PDFs: https://twitter.com/Peter_shirley/status/985561344555417600</a>↩</a></li></ol></aside> Houdini: Wind Tunnel 2018-04-04T12:00:00Z Computer graphics can help making impossible things become reality—so how about having a heavy metallic bull sculpture being pushed away by a mere 15 m/s breeze coming from within a wind tunnel? Definitely something worth making happen! Watch on Vimeo</a> Smoke Flows Breakdown</h2> The primary objective is to manage having the flows of smoke to look as continuous as possible. To this purpose, the idea here is to have each flow sourced on the left side of the container from a Tube SOP whose length depends on the wind speed per simulation step rounded to the nearest voxel unit. coefficient = fps * substeps * voxel size wind speed per step in voxels = round(wind speed / coefficient) adjusted wind speed = wind speed per step in voxels * coefficient tube length = wind speed per step in voxels * voxel size </code></pre> Then, the Smoke Solver DOP needs to “push” the density field towards the right to leave just enough room for some more smoke to be sourced on the left side during the next simulation step. This is done by having the velocity field of the simulation to approximately match the adjusted wind speed at all times around the left side of the container. The Smoke Object DOP’s Wind Tunnel Direction parameter helps to do precisely that but I ended up using a custom setup instead because it seems to provide slightly better results and there’s more to learn this way, heh! Nothing too fancy in this setup anyway—the container is initialized with the wind’s velocity and then some more velocity is added at each step in the left side. The continuous pumping of fresh new velocity is required because the advection of the velocity field by itself at each simulation step causes a loss of velocity in the sourcing area that needs to be compensated. By this point, and with the collision source plugged in, the flows look alright but some small discontinuities are still visible in the density field. Fortunately these are minor enough to be disregarded—they are bound to disappear altogether once rendered with motion blur. density field—some discontinuities are visible velocity field—losing a bit of steam on the front To give a more interesting look, the linear shape of the flows is broken by adding a tiny bit of noise to the velocity source, as well as a Gas Vortex Confinement DOP to boost the swirls, and a Gas Turbulence DOP around the collision area. density field after breaking its linearity Finally the simulation substeps are set to 2 simply because it brings a more interesting motion. Dust Breakdown</h2> Since a bull sculpture sliding in these conditions doesn’t make any sense anyway, I decided to furthermore pursue in this direction by adding a dust effect as if some dirt were, somehow, laying on the ground.[1]</a> Yup. To emit dust whenever the bull is sliding, a volume is first generated around the bull’s feet, near the ground, with an added pinch of noise here and there. It is then multiplied by the surrounding velocity of the bull, thus nullifying its density as the bull comes to a standstill. The rest is even more straightforward—the volume and the points scattered from it are both advected by the velocity from the smoke flows to respectively simulate the dust particles and the dust smoke. dust sources dust advection At render time, the dust particles and smoke are set to be mostly transparent to not distract from the main effect: the smoke flows. Download</h2> wind-tunnel-01 v2</a> This file contains a scene created with SideFX</a>’s Houdini 16.5 as well as any required asset. </div> References</h2> https://www.youtube.com/watch?v=E9ZSAX56m0E</a></li> </ul> Credits</h2> The bull model and its texture maps were created and shared under the CC Attribution-ShareAlike license</a> by Zafio via Sketchfab</a>. Footnotes</h2>It’s a good exercise anyhow.↩</a></li></ol></aside> Zero: A Bunch of Single-File Libraries for C/C++ 2018-05-26T12:00:00Z For the needs of a project I’m working on, I had to write an aligned allocator on top of malloc()/realloc()/free()</code> and a simple logger featuring different log levels and basic colouring. Nothing too fancy here. It was obvious that the code had nothing specific to that project and was in fact a good fit for a more general-purpose library. So I decided to jump into the single-file, header-only, libraries bandwagon started by Sean Barrett and his popular stb</a> project by releasing my own: Zero</a>. View on GitHub</a> While developing Zero, I was influenced by the Physical Design of The Machinery</a> and chose not to have any #include</code> dependency within the library headers. That’s right. Not even standard headers. [1]</a> Why’s that? Because standard headers contain thousands of lines of code when counting their own dependencies and I do not want to slow down compilation times by burdening projects that include my headers into their own headers. At least, not without a good reason. Are fixed integer types or size_t</code> a good enough reason? Not even. Most projects target common platforms (Windows, Linux, macOS) and hence use either the ILP32, LP64, or LLP64 data models. All of these data models guarantee the char</code> type to be 8 bits, short</code> to be 16 bits, int</code> to be 32 bits, and long long</code> to be 64 bits. For people using more exotic platforms, Zero can fallback to using <stdint.h></code> if the macro ZR_USE_STD_FIXED_TYPES</code> is defined. Even better, each type can be overridden individually through macros such as ZR_INT32</code>. The same goes for size_t</code>—on almost all platforms the size of size_t</code> equals the targetted architecture, that is either 32 or 64 bits. Here again, there is a fallback macro with ZR_USE_STD_BASIC_TYPES</code> that includes <stddef.h></code>, and a more granular one ZR_SIZE_TYPE</code> to directly set the size type to be used. Note that these custom types are only used in the public interface defined within the headers. The implementation side of things is free to include whatever file is needed, which is fine since these dependencies are to remain within a single translation unit rather than spreading all over the place through the #include</code> mechanism. As always, it’s all on GitHub</a>, so go get it! Footnotes</h2>Alright, there is a single exception with <stdarg.h></code> and that’s because one function uses va_list</code> as a parameter. But in my defense, <stdarg.h></code> has no other dependency (on my platform, at least) and is fairly short (~100 LOC).↩</a></li></ol></aside> New Look and a Brand New Static Site Generator 2017-10-04T13:00:00Z It seems that whenever I’m looking forward to turn a page in my life, there’s a little—but insisting—voice inside calling me to update my website. Not being a huge fan of web development, it’s something that I truly dread but then it makes me feel somehow freshened once it’s done. And boy, does releasing this new version has been rewarding for me! I threw away all the PHP, SQL, JavaSript, and basically anything that could slow down page loadings on the client side, including analytics. I also stopped relying on CMS</abbr> solutions and wrote the back-end myself, that is a static site generator called Eddi. All this for the sake of having full control over the complete process. View demo</a>eddi’s default theme I ended up spending waaay more time than I hoped to so towards the end I started cutting some corners with the code which translates into some small bits here and there being not so well implemented. But it’s not too shabby for a first go, overall I’m fairly happy with the end result—it’s now much easier to maintain my blog and I see the overall structure of the generator to be a solid base that I could build upon again in the future.[1]</a> What This Update Means for You</h2> Design</dt> I somehow managed to make the design even simpler than the previous edition while also making all the content easily accessible. Gone are the days where you had to click, load, scroll down, and all over again 10+ times to see older articles. Well, no one ever bothered doing that anyways.</dd> Speed</dt> The server doesn’t have anymore to dynamically generate each page that the visitor is requesting, which can take a bit of time when querying databases and such. All the assets are now static which means that the HTML pages already exist and only have to be served as-is.</dd> Privacy</dt> No more Google Analytics, Google Fonts, or embedded videos from third-party services such as Vimeo. All the pages and resources are now served directly from my host, which means no tracking whatsoever from the tech giants.[2]</a></dd> Comments</dt> They are gone. This is a side-effect of having a static site and not wanting to rely on third-party services. Which is a bit sad. I counted 149 comments in total (48 of them being written by myself) making it a great place to interact with you. I truly appreciated reading all the kind words, debates, critics, and whatnot, so thank you. At the end of the day, emails are well-suited for discussions, so you know what to do!</dd> </dl> I hope you guys like it! Can I Has the Static Site Generator?</h2> Yes, you can. Eddi and its default theme are free and open-source so nothing’s stopping you from using it to build your own site. Except that this is not so accessible nor user-friendly. You’d need to be fairly tech-savvy and even then I skipped writing any sort of documentation for now so it’s a bit rough.[3]</a> You can find the source in eddi’s repository on GitHub</a> and you’ll also need Node.js</a>. If you still feel like giving it a spin and are hitting walls, do get in touch! Footnotes</h2>The content (articles) for the site are just a git</abbr></a> repository with Markdown</abbr></a> files that I can rsync</abbr></a> to the remote server.↩</a></li> You might want to check Replacing Disqus with Github Comments</a> for an example of what to expect when you are visiting websites using such services. And while we’re there, have a look at privacytools.io</a>.↩</a></li> And I probably will never write any documentation for this project because it would take me a lot of time and I don’t foresee many people interested in using Eddi.↩</a></li></ol></aside> Hienoi: A 2D Particle Playground 2017-10-01T13:00:00Z I initially started this project with the goal of providing a visual programming framework to introduce my friend to coding in a fun way. I could have used other existing projects such as Processing</a> instead but then I thought it’d be a good experience for me to write my own. So these were my 2 objectives. Making something educational that is fun to use, and honing my own skills. I quickly reached a working prototype but then, it happened. Hey, you know what?</q>... How about putting the GUI and simulation modules into their own processes? And using OpenGL instead of the software renderer? And using NumPy under the hood to speed things up while preserving a user-friendly API? And allowing users to add new attributes to particles?</q> And, and, and... and I kept going like that for a while, even writing a helper library in the process, Nani</a>. particle trail I’m still not satisfied with the amount of functionalities provided but hey, for a toy project, this is not that bad and it has already fulfilled its main objectives. I think. Have a go at it, grab Hienoi on GitHub</a>! Release All the Things! 2017-10-01T13:00:00Z It’s been a while since I last coded anything and it’s been itching me ever since. So I paused whatever I was up to and got back onto coding a few things here and there. does not represent the time spent working on these libraries Despite the small size of these 4 libraries, I’ve put a lot of efforts into trying to release quality products by designing the code to the higher standard permitted by my—humble—knowledge, but also by covering most of the code with tests, polishing the documentations as much as I possibly could, and even providing benchmarks where it made sense. And for once, I’m quite happy with the results! The libraries that I have entirely rewritten are Gorilla</a>, a convenient approach to monkey patching, and Bana</a>, a set of extensions for Autodesk Maya’s Python API. As for the the new ones, there is Revl</a>, which helps to benchmark code for Autodesk Maya, and Nani</a>, an alternative approach to defining and viewing NumPy’s arrays. It’s been a great exercise to improve my skills in designing, building, and shipping libraries, and I hope that these projects will also serve as good examples to others or simply be useful at all. More should be coming soon but for now... get them all! myXKCD: Sensational Bullshit 2017-10-01T13:00:00Z Nested Initializer Lists for Multidimensional Arrays 2017-10-01T13:00:00Z With the release of the template metaprogramming library m3ta</a>, I’ve included in the documentation</a> a few examples on how some utilities might prove useful. I find one example particularly worth sharing here because I’ve been stuck on it for some times and thought that it might be useful to someone else. That’s the nested initializers trick. But what exactly are those initializer thingies? Initializer lists are a way to initialise objects using a curly braces syntax {}</code> that encloses a list of values such as {4, 9, 8, 5}</code>. Their nested version allows for more structured syntaxes like {{4, 9}, {8, 5}}</code>. Since they are well suited to define arrays, let’s see how they could be used in the context of a custom multidimensional array class that would mimic the curly braces initialization properties of the built-in arrays of C/C++. The Built-In Curly Braces Syntax</h2> The C & C++ languages have always provided a special curly braces syntax for the built-in arrays that allowed to define all their elements at once. // Single curly braces syntax. int array[3][2] = { 0, 1, 2, 3, 4, 5 }; </code></pre> On top of initialising the content of the array with the values passed, this syntax also comes with two neat features for the corner cases. Firstly, any element in excess is signalled with an error at compile time, and secondly, the end of the array is filled with zeroes if less values than expected are provided. The nested flavour of this syntax allows to write as many levels of nested curly braces as there are of dimensions defined by the array. // Nested curly braces syntax. // 2-dimensional array -> 2 levels of braces int array[3][2] = { {0, 1}, {2, 3}, {4, 5} }; </code></pre> The difference is not only aesthetic. This last version helps localising the behaviour of the “neat features”. Namely, it provides an error message with the precise location of any set of braces defining elements in excess, and likewise fills with zeroes the inner sets of braces that have some values missing. Otherwise, and if provided with the expected number of values, both syntaxes produce the exact same content. Curly Braces Initializers for All!</h2> Now that the behaviours that needs to be reproduced are known, let’s get onto it—but not so fast! If you are not using C++11 or above, you are doomed. Indeed, until C++11 this convenient syntax wasn’t available for user-defined types. It’s the addition of std::initializer_list</code></a> that changed the deal. If you are part of the cool kids, enabling the curly braces initializers for a type is done by simply defining a constructor taking a std::initializer_list</code> argument. In the case of the single curly braces syntax, the implementation of the constructor can actually be quite concise. template<typename T, std::size_t ... T_dimensions> class MultidimensionalArray { public: MultidimensionalArray(std::initializer_list<T> values) { std::copy(values.begin(), values.end(), _data.begin()); } private: std::array<T, size()> _data; }; </code></pre> This implementation wouldn’t take care of the corner cases though—what if the user writes 2 or 4 values when only 3 are expected? What I previously called the “neat features” that are shipped with the built-in arrays are not a big deal to be implemented here. template<typename T, std::size_t ... T_dimensions> class MultidimensionalArray { static_assert(sizeof ... (T_dimensions) > 0, "At least one dimension needs to be defined."); public: static constexpr std::size_t size() { return m3ta::product(T_dimensions ...); } MultidimensionalArray(std::initializer_list<T> values) { if (values.size() > size()) { std::ostringstream message; message << "Elements in excess: " << "expected " << size() << ", " << "got " << values.size() << "."; throw std::invalid_argument(message.str()); } std::copy(values.begin(), values.end(), _data.begin()); if (values.size() < size()) { std::size_t count = std::min(size(), values.size()); std::uninitialized_fill( _data.begin() + count, _data.end(), static_cast<T>(0) ); } } using Iterator = typename std::array<T, size()>::iterator; private: std::array<T, size()> _data; }; </code></pre> Once again, only the single curly braces syntax is defined here, but otherwise the same “neat features” as the built-in arrays are provided. MultidimensionalArray<float, 3, 2> array = { 0, 1, 2, 3, 4, 5 }; </code></pre> Implementing the nested curly braces variant is slightly more involved. Firstly, a new constructor needs to be defined to accept nested initializer lists, that is for example a std::initializer_list<std::initializer_list<float>></code> in the case of a 2-dimensional array. Creating a such type in a generic fashion isn’t a problem, as demonstrated with the m3ta::NestedInitializerLists</code></a> trait. But one thing to know is that it isn’t possible to directly iterate over all the values held within nested std::initializer_list</code>s—pointers to the next deeper nested level are returned until the very last level is reached, at which point the values can finally be accessed. m3ta::NestedInitializerListsT<float, 3> values = { { {0, 1}, {2, 3} }, { {4, 5}, {6, 7} } }; for (auto secondLevel : values) { for (auto thirdLevel : secondLevel) { for (auto value : thirdLevel) { // Do something with the value. } } } </code></pre> Nesting as many for-loops as there are of levels is not something that can be done generically. Iterating over Nested Initializer Lists</h2> I initially tried to either flatten the nested lists into a linear sequence of elements or to find a trick based on std::array</code> to automatically inherit its properties, but nothing gave me both the exact same syntax as the built-in arrays with the “neat features” that I wanted. The solution had to pass by a recursive approach. The values to recurse over are the number of elements per level of the nested initializer lists—that is, its shape. The idea kinda goes like this: from the first level, check if the number of elements is as expected, recurse over the second level, then fill the missing elements with zeroes, and repeat until the last level is reached. At this point, do something with the values. template<typename T, std::size_t ... T_shape> struct NestedInitializerListsProcessor; // Recursive part. template<typename T, std::size_t T_first, std::size_t ... T_others> struct NestedInitializerListsProcessor<T, T_first, T_others ...> { using NestedInitializerLists = m3ta::NestedInitializerListsT<T, 1 + sizeof ... (T_others)>; template<typename T_Function> static void process(NestedInitializerLists values, T_Function function) { if (values.size() > T_first) { throw std::invalid_argument( "Elements in excess within the initilizer list." ); } for (auto nested : values) { NestedInitializerListsProcessor<T, T_others ...>:: process(nested, function); } if (values.size() < T_first) { std::size_t count = m3ta::Product<std::size_t, T_others ...>::value * (T_first - values.size()); while (count-- > 0) { function(static_cast<T>(0)); } } } }; // Last level. template<typename T, std::size_t T_last> struct NestedInitializerListsProcessor<T, T_last> { using InitializerList = m3ta::NestedInitializerListsT<T, 1>; template<typename T_Function> static void process(InitializerList values, T_Function function) { if (values.size() > T_last) { std::ostringstream message; message << "Elements in excess: " << "expected " << T_last << ", " << "got " << values.size() << "."; throw std::invalid_argument(message.str()); } std::for_each(values.begin(), values.end(), function); if (values.size() < T_last) { std::size_t count = T_last - values.size(); while (count-- > 0) { function(static_cast<T>(0)); } } } }; </code></pre> For more genericity, this NestedInitializerListsProcessor</code> helper takes a function that it applies on each element iterated over. This way, the caller—the MultidimensionalArray</code> constructors here—can decide what to do with those values. The first template specialisation is the recursive part while the one with the T_last</code> parameter is the equivalent of what was previously implemented within the MultidimensionalArray</code> constructor for the single curly braces case. Putting All the Things into the Multidimensional Array Class</h2> Now that accessing the values of nested initializer lists is dealt with, the MultidimensionalArray</code> class can define the constructor for the nested curly braces. template<typename T, std::size_t ... T_dimensions> class MultidimensionalArray { static_assert(sizeof ... (T_dimensions) > 0, "At least one dimension needs to be defined."); public: static constexpr std::size_t size() { return m3ta::product(T_dimensions ...); } // Single curly braces syntax. MultidimensionalArray(m3ta::NestedInitializerListsT<T, 1> values) { initialize<size()>(values); } using NestedInitializerLists = m3ta::NestedInitializerListsT<T, sizeof ... (T_dimensions)>; // Nested curly braces syntax. MultidimensionalArray(NestedInitializerLists values) { initialize<T_dimensions ...>(values); } private: template<std::size_t ... T_shape, typename T_NestedInitializerLists> void initialize(T_NestedInitializerLists values) { auto iterator = _data.begin(); NestedInitializerListsProcessor<T, T_shape ...>:: process( values, [&iterator](T value) { *(iterator++) = value; } ); } std::array<T, size()> _data; }; </code></pre> The private method initialize()</code> defines a new template parameter T_shape</code> which refers to the shape to expect from the initializer lists to iterate over—that is the number of values in the case of the single curly braces syntax, and the dimensions of the array for the nested syntax. It then defines a lambda function which simply copies each value onto the _data</code> member. The MultidimensionalArray</code> class is now almost good to go—the nested curly braces constructor needs to be disabled when the array contains a single dimension to avoid ambiguous calls, and a pair of begin()/end()</code> methods need to be added to at least allow a sort of iteration. I’ll leave these as an exercise for the reader—if there is any reader left at this point? Or you can simply get the full code on this Gist</a>. Additional Notes</h2> Admittedly the error messages could be improved but will hardly get nearly as good as what the compilers can generate for the built-in arrays. Also, the conditions for these error messages are checked at run-time when, according to this question of mine on StackOverflow</a>, it should have been possible to retrieve the size of a std::initializer_list</code> at compile time and turn the whole check + exception combo into a simple static_assert</code>. Maybe an oversight from the C++ committee? Don’t be shy and follow me on GitHub</a> if you want to check out the latest code that I’m sharing—it won’t always make it into a blog post. m3ta: A Template Metaprogramming Library 2017-10-01T13:00:00Z For the needs of a personal C++ project heavily relying on templates, I found myself coding more and more template metaprogramming</a> utilities to the point where I wrote more lines of these than of the actual project itself. The time was for a refactoring—these utilities deserved their own dedicated library. I thought that the process would take me only a couple of days—how naive of me. Extracting some utilities that work well within a specific project and turning them into something more bulletproof with the help of an extensive set of unit tests is... quite some work. Not even talking of the documentation entirely written manually in reStructuredText</a>, without much help from Sphinx</a> on the C++ front. Nonetheless, it’s now all good to go and I am pleased to introduce you m3ta</a>! I’ve made the source code available on GitHub</a>. Note that this library relies on features from C++11. What Sphinx helped me for though is to make the documentation</a> compatible with the beautifully themed readthedocs.org</a> website. Curious About Metaprogramming?</h2> If you’re new to template metaprogramming but not to C++, I encourage you to check the examples from the documentation, the source code, or even better, to research the subject on the Internet like I did. Not only could it potentially expand your way of thinking and your overall programming skills (template metaprogramming can give a small preview of what functional programming</a> is), but it would also open the doors to a whole new set of tools for solving some problems more efficiently. myXKCD: Christmas 2017-10-01T13:00:00Z Flying Things: A Rigging Showreel 2017-10-01T13:00:00Z Here’s a proof that I’ve not been doing nothing during my last 4 years of work. Watch on Vimeo</a>character rigging showreel from 2014 Needless to say that I’ve done the rigs of the canisters and of the bouncing ball in full. For the rest you can check the shot breakdown</a>. Modern Rigging Workflow: The Modular Approach 2017-10-01T13:00:00Z Providing solid (character) rigs that fit animators’ requirements is only a good start for a rigger aspiring to become proficient. Efficiency is the other equally important aspect so let’s discuss some leads to get there. As a beginner I struggled to create a big picture of what could be a good rigging workflow. My only focus back then was on making my rigs robust and friendly for the animators. As soon as my object hierarchies and logic made sense, then it all sounded good enough to me. The more I had to make some changes to the rigs I had built, the more I started to get a hint that something was wrong with my approach. Since I would build them manually, it wasn’t straightforward to operate complex modifications on the structure. Clearly, numerous mistakes could make their way through during an update or another. I couldn’t even guarantee that the left arm of a character was the exact same as its right arm. As for propagating the changes to multiple characters, it would probably have been really challenging. Dismembering the Rigs into Modules</h2> Looking back at it now, the object hierarchy of my first rigs were quite a chaotic place—an arm here, a leg there, both most likely directly parented under the spine, while the controllers were mixed with rigging objects, deformers, previs geometries, and so on. The only neat part was the final geometry which was in its own hierarchy... From there, the first move was to encapsulate each logical part of a rig (spine, arm, leg, ...) into its own object hierarchy, without any external element sneaking in, and to make sure that each could work in a standalone fashion. Let’s call those logical parts rig modules. Back at Action Synthèse, we implemented this approach by saving separately a scene containing the rig for each module. A module could then be imported, fit onto a specific character, and connected to the other modules. The fitting part was a bit sketchy—adapting a static rig existing in a scene onto different characters might require to break some constraints, expressions, and hierarchies, and to recreate them only when the sizes and posing were adjusted. We added a layer of script to help with that but this whole approach is an added complexity which is highly error prone and makes it easy to break everything apart when making changes to the rig. Bring on the Structure</h2> What a rig really is, is just the internals made of pistons and cogs that connect the interface given to the animators with the final deformed geometry given to the lighting department. It is only a part of a bigger picture from which we need to differentiate multiple assembly stages. Now there’s not just one structure possible but many of them, interchangeable depending on the needs of each studio. A common and simple variation would include those units: rig, armature, and geometry. The dependencies here works only in one direction—the rig drives the armature, which in turn drives the geometry. The armature is made of anything required to drive the deformations of the final geometry contained in the last unit. It acts like a buffer layer that usually includes a representation of the skeleton as well as any animated attribute that might end up driving shapes and other deformations. However this structural approach is being implemented, this concept is a central piece to an efficient rigging workflow. It lays out a solid global structure for the rigs and opens the doors to much flexibility. The other building blocks just flow naturally from there. Ideas to Make a Good Use of the Structure</h2> A direct benefit of splitting the structure this way is that the final geometry now only requires to be driven by the armature unit. If the animation on the armature gets baked, it is then possible to provide the lighters with a lightweight asset, stripped out from the rig unit, that they can render. In the cases where complex muscle or cloth simulations are involved, baking the final geometry for the lighters is the only viable option. But a simulation unit could well be wrapped with the armature before being sent for computation on a render farm for example. No need for the full rig here neither. If the geometry unit prevents the animators from having a real-time feedback, an idea could be to add a new previs unit containing only “puppet” geometries to speed it all up. It could either replace entirely the geometry unit or work alongside with it by providing a visibility toggle. Is the rig part of a motion capture pipeline? Insert a new motion capture unit that drives the controllers. Interface and Implementation</h2> To really emphasize the idea of a rig being a glue between the interface for the animators and the final deformed geometry, it is possible—and recommended—to split the animation controllers from the rigging logic. The programming equivalent is to separate the data from the implementation—a core design principle. To perform this separation properly, it becomes important to fully grasp the logic of each rig module—what they require as input, how they process that data, and what they output. The first advantage is that it’s easier to maintain both the interfaces and the rigs, especially when picking them up after a while or when someone else gets onto it. Indeed, like with programming, there’s more chances to understand small chunks of code, each encapsulated into routines getting a specific task done, rather than gigantic monolithic code snippets. Check out for example the idea behind the separations of concerns</a> design principle if you’re not convinced. Even more importantly, it promotes reusability by allowing to swap either a rig and/or an interface independently from the other—a same spine rig module can for example be used for a neck or a small tail, and thus by simply providing different interfaces adapted to each scenario. This could as well become convenient for when a specific shot would require to manipulate the rig in a non-conventional way. This separation of interface and implementation doesn’t mean that any rigging system should be prohibited from within the interface. In the contrary, it’s sometimes required to build some small mechanisms to enhance the behavior of the controllers. Adding Some More Granularity</h2> To build more upon this separation of concerns, it’s possible to break each rig module in even smaller logical, self-contained parts. Let’s call them rig chunks. Those allow creating some small structures that can be reused or swapped to change the behavior of a rig. As with the rig modules forming the global structure, the chunks defining a rig module need to flow in a simple and predictable fashion. Figuring out the right level of granularity is never easy. Starting off by turning every couple of nodes into a rig chunk under the pretext that it could possibly be reused somewhere else is definitely not the way to go and will only end up in a total clusterfuck on top of being a waste of time. credit: xkcd</a> (CC BY-NC 2.5</a>) Instead, a solid argument to turn a piece of rig into a reusable chunk would be to build everything as usual until a same pattern shows up again—maybe in a different rig—, in which case a refactorisation is beneficial. As for the other good argument, it’s simple—if adding/removing a part from a rig allows to add/remove features such as the stretch system for a spine, then it is more likely to be a good contender for a chunkisation. The Point So Far</h2> Remember how I said that the implementation of the rig modules was sketchy and complex because of the way we did it? As nice as those rig chunks might look on the paper, they won’t fare any better if implemented in the same way. Obviously, relying on static pieces of rig to implement those dynamic concepts is quite limitative here. The fundamentals needs to be revised before being able to encompass all the current and possible future requirements. Following the Flow, Coding It All</h2> Each time that a concept is being isolated into a unit structure, a rig module, or a rig chunk, it really is the equivalent of creating a new function. As such, the next step is to entirely generate the rigs through scripts. Does it freak you out? Then forget about working at Weta Digital</a> as a rigger. Just kidding, keep reading. Everyone there, ranging from junior to senior positions, picked it up easily enough. It is really intuitive and fast to use once all there is left to do is to type a few lines to import, configure and connect the rig modules together. It is more involved when it comes to the lower level of creating the actual logic of each rig module and chunks, but it is for the good cause. This enforces a different approach to rigging—the encapsulation of each concept tends to be even more well-defined and modular, leading to positive restructurations of the rig elements and to a cleaner code. Over time, it reaches a point where it becomes much more straightforward to read and understand the linear sequence of instructions from a well written code than a complex dependency graph with a ton of connections to follow, which is a specialty of Maya and the likes. That’s only the icing on the cake but the real deal is all about being finally able to dynamically build any rig on the fly without any hack as well as being freely able to define the granularity as wished. If the code is well layed out and modular enough, this allows to create whole new variations of a rig by simply overriding a few functions. Even better is the chance it gives to provide a flexible rig builder to the riggers. No more predefined object names, orientation orders, controllers shapes, etc. Everything becomes fully customizable to the point of also being able to define different behaviors for a same rig—should this spine be stretchable or not? Should there be 8 or 10 joints? Note that this won’t stop anyone from creating utterly crap rigs and code if the good practices are not followed. The Real Deal</h2> The time for trials and errors is now over. In my opinion everything converge towards coding somehow most of the rigging workflow, but the truth being that it’s really an unnecessary pain to do this for softwares such as Maya. Think about it. What’s happening there is that we’re creating an intermediary and unnecessary stage where we need to translate the rig logic (mathematical operations) into rig nodes specific to a 3D software. This can quickly become a daunting task to have to create a network of interconnected nodes only to perform a few vector/matrice operations, especially since the code required for creating and connecting each node can be... substantial. On top of that, this can cause a great performance hit. Often, transformation nodes solely exist in rigging to hold onto rotation or translation values to then drive a constraint. Such nodes still require to have their full transformation and properties to be defined and computed, and contribute to an useless clustering of the dependency graph. That’s a lot of waste of memory and processing time. So why coding a bunch of rig nodes to process the data, when it is possible to create a much more suited piece of code that would directly process that same data optimally? Well, because we couldn’t do that easily until now—maybe with the exception of VEX from Houdini</a>. What’s Next?</h2> The future is all about using the right frameworks to implement our rigging logic the way we choose to. But that wouldn’t be a good reason enough to do the switch without bringing more speed to the rigs and a good portability for the long-term run. That’s where frameworks such as Fabric Engine</a> kick in. With their DCC-agnostic ultra-optimized dependency graph and KL language, all the tools that we need and even more are provided. Seeing the modularity of the workflow described in this article, I strongly believe that it’s shouting to be implemented as a nodal graph with the right level of granularity. If you want to stay cutting edge on the rigging front, you know in which direction to head to. Credits</h2> Thanks to Frédéric Bonometti, Raffaele Fragapane and Andrea Interguglielmi, for all having influenced me at some point my approach to rigging. Getting Started with OpenGL in C++ 2017-10-01T13:00:00Z Learning OpenGL has been on my to-do list for as long as I can remember, but before getting too crazy on it, I wanted to start slowly by focusing on a simple project. I hence began by laying out the structure of the project. I wanted to have the core to deal only with OpenGL, while having hooks with GUI toolkits—such as Qt</a> and GLFW</a>—being built on top of it in separate modules. For testing purposes, I figured that the core OpenGL library could be as simple as a single class containing the required methods to setup and cleanup the OpenGL context, with a draw()</code> method for the main rendering loop. // core/openglrenderer.h #include <GLXW/glxw.h> class OpenGLRenderer { public: OpenGLRenderer(); void setup(); void draw(); void cleanup(); private: bool _setup; GLuint _program; }; </code></pre> Note that GLXW</a> is one of the many OpenGL loader available. There is no special reason why I picked this one over another one, they are all similar enough. The Qt 5 Struggle</h2> With this class prototype in place and a simple call to glClearBufferfv()</code></a> within the draw()</code> method, I was ready to give a go at hooking up Qt 5. // qt5/openglsurface.h #include <QtGui/QWindow> class QOpenGLContext; class OpenGLRenderer; class OpenGLSurface : public QWindow { Q_OBJECT public: OpenGLSurface(QScreen *screen = 0); OpenGLSurface(QWindow *parent); ~OpenGLSurface(); void render(); private: QOpenGLContext *_context; OpenGLRenderer *_renderer; }; </code></pre> This is a simplification of the actual class but that’s basically the idea behind it. The render()</code> method gets triggered by the event system of Qt and its role is to ensure that an OpenGL context exists before calling the appropriate methods from the OpenGLRenderer</code> class. I’ve implemented the full class by thoroughly following an official example from Qt</a> but it decided not to compile. That’s not due to the tutorial itself but more with the way of how Qt deals with OpenGL. The C++ source file implementing the OpenGLSurface</code>’s Qt class includes the <core/openglrenderer.h></code> header, which implicity also includes the GLXW header—that’s when Qt starts screaming. Without going into the details, the QtOpenGL</code> module (from Qt 5.2) doesn’t like mixing with external OpenGL loading libraries such as GLXW, GLEW and others. I came to realize anyways that exposing the <GLXW/glxw.h></code> file into a public header from the OpenGL core I was writing meant that any project linking to that library also had an extra compile-time dependency towards GLXW to take care of. That’s not only annoying but it also isn’t required—that dependency should be kept internal to the core library. Pimpling It Up</h2> The idea was to break this extra dependency by making any reference to GLXW and OpenGL invisible to the public. A true abstraction. The easy solutions is to replace any reference to OpenGL typdefs such as GLuint</code> for their actual standard types. But even though it would be fine in most cases, it could potentially break the portability of OpenGL and is largely</a> not recommended</a> by the Internet</a>. That’s where the pimpl idiom</a>—also called opaque or d pointer, and widely used in Qt—comes to the rescue. The public interface of the OpenGLRenderer</code> was already good to go as it was, but the GLuint _program</code> private member was at fault—as well as the others to come. The pimpl idiom is all about replacing the current private members of a class by pointing to a new class where the members have been moved to. // core/openglrenderer.h //#include "openglrenderer.h" < Not required anymore! class OpenGLRenderer { public: OpenGLRenderer(); void setup(); void draw(); void cleanup(); private: class Impl; Impl *_d; }; // core/openglrenderer_impl.h #include <GLXW/glxw.h> #include "openglrenderer.h" class OpenGLRenderer::Impl { public: bool setup; GLuint_program; }; </code></pre> On top of removing dependencies, the pimpl idiom also provides the convenience of having a cleaner public API, faster compilation times, and helps preserving binary compatibility. A more advanced definition and usage is available in 2 parts on Sutter’s Mill website: Compilation Firewalls</a>, part 2</a>. GLSL Shaders</h2> Happy with the implementation of my OpenGL core with Qt 5 and even GLFW, I coud move onto going through the great OpenGL SuperBible</a> to learn some basics. After writing a couple of GLSL shaders the way they show it in the first chapters, I already couldn’t take it anymore. How could I possibly go through the entire book by wrapping each line of the shaders within double quotes while making sure they all end with a newline \n</code> character? static const GLchar *vertexShaderSource[] = { "#version 430 core\n" "void main(void)\n" "{\n" " const vec4 vertices[3] = vec4[3](\n" " vec4( 0.25, -0.25, 0.5, 1.0),\n" " vec4(-0.25, -0.25, 0.5, 1.0),\n" " vec4( 0.25, 0.25, 0.5, 1.0)\n" " );\n" " \n" " gl_Position = vertices[gl_VertexID];\n" "}\n" }; </code></pre> Frankly I couldn’t imagine the pros writing their shaders like this either. I had to find a solution, one involving having each of my GLSL shaders in a separate file and loading them somehow in OpenGL. The Dynamic Approach</h2> The only OpenGL function available to set the source code of a shader is glShaderSource()</code></a> and it expects the source to be given as a const GLchar **</code>. The obvious first move was to open a shader file and convert its content into a character buffer at runtime. It’s an easy task and the web crawls with examples to do just that. void setShaderSourceFromFile(GLuint shader, const GLchar *filename) { std::ifstream file(filename); if (!file.is_open()) { std::cerr << "Unable to open file " << filename << std::endl; return; } std::stringstream stream; stream << file.rdbuf(); file.close(); std::string string = stream.str(); const char *code = string.c_str(); glShaderSource(shader, 1, (GLchar **)&code, 0); } </code></pre> One thing to keep in mind is that if a relative filename is passed to the std::ifstream()</code> constructor—which will most likely be the case—and that the application is started from a shell, then this can lead to problems. Paths are defined relatively to the shell’s current directory rather than to the location of the binary, so it’s important that the shaders can be found from where the application is being started. That’s probably one of the reasons of why there’s so many launchers out there that initialize a working environment before firing the actual application—finding resources at runtime. The Static Approach</h2> How about using an #include</code> statement to make the shader available into the C++ code at compile-time? The idea here is to automagically convert the content of each shader file into a multiline string literal, like the ones showcased in the OpenGL SuperBible. That’s a parsing job simple enough for CMake and it can be wrapped in a custom target. add_custom_target( shaders COMMAND ${CMAKE_COMMAND} -DSOURCE_DIR=${CMAKE_CURRENT_SOURCE_DIR} -DDESTINATION_DIR=/path/to/formatted/shaders -DFILES="${shaders_files}" -P /path/to/shaders.cmake COMMENT "Creating the files to include the GLSL shaders" ) </code></pre> The command defined in shaders.cmake</code> is where the main logic happens: separate_arguments(FILES) foreach (file ${FILES}) set(filename ${SOURCE_DIR}/${file}) get_filename_component(name ${filename} NAME_WE) set(source "") file(STRINGS ${filename} lines) foreach (line ${lines}) set(source "${source} \"${line}\\n\"\n") endforeach() file( WRITE ${DESTINATION_DIR}/${file} "static const GLchar *${name}ShaderSource[] = {\n" "${source}" "};\n" ) endforeach() </code></pre> For each shader file found, CMake will create a new C++ file in the destination directory containing a single GLchar *</code> variable that can be directly passed to the glShaderSource()</code> function. Bootstrapping It All</h2> At this stage everything was ready for me to get started on OpenGL for good—I could write my OpenGL code and GLSL shaders independently from anything and then preview the result within the GUI toolkit of my choice. I’ve decided to save a checkpoint of this progression by wrapping everything in a bootstrap that I could reuse later on as a starting point for any project. It can be found on GitHub</a>. Since I couldn’t decide which method to use for loading the GLSL shaders, and that it after all depends on the needs of each, I’ve added in the bootstrap an option for the user to switch between the dynamic and the static approach. Support for both GLFW and Qt 5 (with or without the QtWidgets module) is also provided out of the box. I’ve tested it only on Mac OS X so far but porting it to either Linux or Windows shouldn’t be a problem, if it’s not working already. Time to get those pixels moving! Why I’m Not Using the MEL and Python Command Layers of Maya 2017-10-01T13:00:00Z There’s a large amount of things that frustrate me in Maya. The MEL and the Python command layers being two of those that I’d rather not have to ever use again. But first, here’s a disclaimer. My sole objective here is to genuinely share my—hopefully objective—point of view and experience in the hope that it’ll get some to think about it. I’m not saying that this is the one and only valid approach, I’m just explaining why I’ve chosen this one. Good on you if you manage to create some bulletproof and awesome scripts using the MEL or the Python command layer. Preface</h2> To draw a quick parallel, both a command layer and an API are also available in Softimage. The question of which one to use has never been asked but by the beginners just getting started. The API has always been the obvious choice. The command layer has its use but mostly for the artists out there who want to automatize a task by copying the log from the script editor that results from their interactions with the UI. Funnily, I must be one of the rare living soul to use the Python API of Maya for daily tasks.[1]</a> But does being alone against all necessarily mean that I’m doing it the wrong way? I hope not. Introducing the MEL Command Layer</h2> Back then, there only was 2 options to code within Maya: MEL or the C++ API. The latter is largely overkilled for most of the tasks of a TD and is also harder to access and iterate. Logically, everyone turned to MEL. But what is MEL? The official documentation of Maya tells us that MEL is derived from a UNIX shell language. Hence why it is called a command layer. It exposes a bunch of global commands like the ones that we would type into a shell to list the content of the current directory or to move onto another directory. ls -la</code>, cd ./path/to/other/directory</code> and the likes. Hey wait, there’s even a ls()</code> command in MEL too! I’ve been baffled more than once by the quality of the MEL code that I was seeing. It was written with incredibly terrible coding practices to the point that I was wondering if the persons knew anything about coding at all. Now I finally understand why it was the case. They’re not to blame. That’s MEL’s fault. My own theory is that MEL has been created with the sole purpose of describing ASCII Maya scenes. It probably wasn’t intented to be used as a scripting language with which one could write any serious code with. It just happened to be the case because the community was lacking of options. Of course I know that you’ve all made awesome scripts that can do this and that. I wrote some myself, maybe not that awesome. But it’s like trying to sprint with ice skates. Look at it, all we’ve got is that jungle of nonsensical global commands, each spammed with a ton of confusing flags that are often incompatible with each other. Good luck at figuring out a logic there. It gets better over time, but not because it starts to make sense. Only because we’re getting used to it. That said, even today I’m still never sure which command from getAttr()</code>, attributeInfo()</code>, and attributeQuery()</code> I should be using when needing to retrieve some information about an attribute. Any hint? The point being that those commands are not made to make sense as a whole. They all achieve something specific but don’t always play well as part of a team. It’s as if the program to write was a huge puzzle and that we were constantly looking for pieces that might hopefully cover the surface without necessarily fitting into the neighbour pieces. Once again this becomes almost anecdotal over time so let’s move on to something more important. Knowing how complex the dependency graph in Maya is, how can referring to a node in a scene solely by its name can be a robust approach at all? Strings Are Not Sexy</h2> To put things back into context, I’m a rigger. I’m spending a lot of time dealing with hierarchies and I like writing modular rigs. Modular rigs makes it more than likely to have a same hierarchy of nodes being reused in a same scene. Instead of prefixing the name of each of my nodes with a hundredth of characters worth of different information to ensure that their names are unique within the scene, I prefer to stay simple and call them ‘root’, ‘spine’, ‘arm’, ‘whatever’, and so on. From there, let’s consider a first example. from maya import cmds root = cmds.group(name='character', empty=True) l_arm = cmds.group(name='l_arm', parent=root, empty=True) r_arm = cmds.group(name='r_arm', parent=root, empty=True) l_node = cmds.group(name='node', parent=l_arm, empty=True) r_node = cmds.group(name='node', parent=r_arm, empty=True) l_child = cmds.group(name='child', parent=l_node, empty=True) r_child = cmds.group(name='child', parent=r_node, empty=True) </code></pre> See the problem here? The variable l_node</code> is pointing to a node named node but can suddenly become invalid simply because another node has been created in the scene, and thus even though the node pointed by l_node</code> hasn’t been modified in any way. Of course this snippet of code reflects a terribly poor coding practice and the issue could be avoided much easily. But the point here is to show a weakness in referring to nodes by their names. As bad as this snippet can be, it is still made of a valid serie of calls and should work in any decent API. It should not require the developer to know how the internals of the API works to workaround an issue that shouldn’t require any workaround. Ok, let’s move on with another example. from maya import cmds def toFullPathName(node): return cmds.ls(node, long=True)[0] root = cmds.group(name='character', empty=True) for arm_name in ['l_arm', 'r_arm']: arm = toFullPathName(cmds.group(name=arm_name, parent=root, empty=True)) node = toFullPathName(cmds.group(name='node', parent=arm, empty=True)) child = toFullPathName(cmds.group(name='child', parent=node, empty=True)) </code></pre> This snippet solves the previous issue by introducing a loop statement. Also, this time each node is stored by using its full path name instead of its partial path name to ensure a false impression of robustness that will be highlighted by the next example to come. Note here the lack of consistency within the command layer: the group()</code> command doesn’t have any flag to retrieve the full path name when many other commands have it. Funnily this flag can sometimes be accessible in other commands but under different names such as long</code>, longName</code> or fullPath</code>, probably depending on the personal preferences of the coder at that time. As a result, we don’t know what we’ll get as a return value from the group()</code> command: a name or a partial path name? It’s like magic and depends on the content of the scene. Yet another thing to take into consideration when coding. If we want to consistently deal with full path names then we’re left with calling a quite ugly workaround using the ls()</code> command. Now, and even though the flaws listed so far are not excusable, there’s still nothing that we can’t get used to with a bit of time. The straw that broke the camel’s back is that, as a rigger being, I often have to insert objects within a hierarchy, reparent nodes, and so on. It would for example be common for me to add a parent to each node from a hierarchy to set their local transformations to identity in a post-process pass. A naive approach of such an operation would look like this: from maya import cmds def toFullPathName(node): return cmds.ls(node, long=True)[0] nodes = [] root = cmds.group(name='character', empty=True) for arm_name in ['l_arm', 'r_arm']: arm = toFullPathName(cmds.group(name=arm_name, parent=root, empty=True)) node = toFullPathName(cmds.group(name='node', parent=arm, empty=True)) child = toFullPathName(cmds.group(name='child', parent=node, empty=True)) nodes.extend([node, child]) for node in nodes: parent = cmds.listRelatives(node, parent=True, fullPath=True)[0] buffer = toFullPathName(cmds.group(name='buffer', parent=parent, empty=True)) cmds.parent(node, buffer) </code></pre> Without knowing the API and simply by reading the code from this snippet, the result seems fairly predictable. Except it’s not. This code errors out due to trying to retrieve an object from a full path name that is not valid anymore because of the changes made to the hierarchy. You thought you that had a solid reference to your node? You don’t. You simply can’t with strings. Some possible workarounds to this one are quite funny actually. Either we could do our parenting pass after having sorted the list of nodes from the one at the bottom of the hiearchy to the one at the top, or we could store them in a temporary set to make sure that we keep a solid reference to them. In both cases we would still end up with invalid references if we had to use these nodes again later on in our code. The exception being if we reassign the variables each time with their updated full path name. Quite error-prone. So What?</h2> Those are only 2 basic examples that I can remember despite not having used Maya in over 1 year. Believe me, I banged my head in frustration a whole lot more than that. So how do I feel about this command layer? Pretty insecure I have to say. Why would I be keen in using a scripting interface that exposes so many inconsistencies and flaws? Yes it’s usable and works well if one knows all the corner cases and take care of them. But it’s not something that I want to waste my energy dealing with only to end up in a state in which I would never have the confidence that a certain variable still points to the node I’d expect it to. And that sucks. Heaps. Those are facts that most of you probably already know and have accepted dealing with. I didn’t. Once again, I fully respect any approach and believe they are valid as soon as the code produced is robust. I chose the Maya API back in 2010 because it was simpler for me to write such code, that’s all. Now if you expect me to praise the Maya API, this won’t happen neither. I actually understand why not so many people dare to adventure in there—it goes straight in the lower end of the user-friendliness scale, especially its Frankenstein-like Python version, and has its own pitfalls. But at least it has a sort of organization with its object-oriented approach and most importantly: we can reference nodes as nodes. In other words, I chose it because my priority was to write robust code and it felt like the less worse option at that point in time. Also I was keen to invest some of my time to make it more usable on a daily basis by developing some extensions through monkey patching</a>. Footnotes</h2>If not, please raise your hands, it’ll make me feel less lonely.↩</a></li></ol></aside> From Monkey Patching the Maya Python API to Gorilla and Bananas 2017-10-01T13:00:00Z Or how I went from patching the Autodesk’s Maya Python API to creating a more generic solution for extending any library in Python. credit: Matt Reinbold</a> (CC BY-SA 2.0</a>) Coming from Softimage and having had previous experiences with various libraries, it was a shock when I first came face-to-face with the API of Maya. Many like to think of it as being flexible but I mainly see it as a pain to use. It’s clunky and inconsistent at best, and lacks basic methods that would make everyone’s life easier. Fortunately, I don’t even have the words to describe its port to Python but I thought more than once about hanging the one who believed that using the MScriptUtil</code> abomination to retrieve values such as the scale of a MFnTransform</code> object would be a good idea. As a result I quickly started to hate my job until I thought that I needed to find a way to make this thing more usable. It ended up becoming the perfect playground for experimenting some monkey patching techniques in Python. Extending the Maya API?</h2> In C++, if we want to extend an external object-oriented library such as the Maya API, there’s often no much choices offered to us. Because of the static nature of the language we’ve got no way to directly modify the built-in classes. All we can do is add some patches on the side rather than in-between. Patching on the side equals here in extending the classes through inheritance. This approach wouldn’t play so well in our case. Indeed, we would have many castings to do from the original types to our own derived types, and we would end up losing the object-oriented benefits anyways: each method that we would add to a certain class would only be available in the scope of that class and won’t be inherited by any of the built-in classes. For an analogy, imagine that you have a system of pipes that you want to modify to provide hot water. All you can do is to derivate from what’s already out there without being able to link your extensions back onto the original system. Only your new system will have hot water, not the existing one. still no hot water on the right side! If the API doesn’t provide a way to insert new methods into the existing classes at runtime, then what are our options? We’re left with creating global functions taking as first argument a pointer or a reference to the class we want to extend. It does the job, but it’s not so object-oriented anymore even though it preserves polymorphism. Wrapping the original API into a new one could be another solution but a colossal and hard to maintain work too. But that’s C++ and we want to use Python. Python to the Rescue</h2> Unlike with C++, everything in Python is an object</a>. Even classes, functions and numbers are objects. We can assign those objects to variables, they most likely have attributes, and we can inspect and modify them at runtime. This concept is at the same time both incredibly powerful and dangerous. In our case, it gives us the chance to improve the Maya Python API on the surface by allowing us to sneakily insert new methods but it also makes it easy to fuck up everything if we’re not so wise. Welcome to the monkey patching world. Monkey Patching ABC</h2> Let’s check out the basics of the technique with a serie of examples. from maya import OpenMaya dummy = OpenMaya.MObject() print(dummy.apiTypeStr()) print(dummy.isNull()) </code></pre> Here we initialize a dummy</code> variable containing an instance of the class MObject</code>. As it is right now, this dummy</code> variable doesn’t hold any valid Maya object internally but that’s enough for us to play around and have access to the methods defined within the MObject</code> class. You’d better off checking the Maya documentation to know what methods are available to call but we can also list them at runtime with a Python’s built-in function: dir()</code></a>. from maya import OpenMaya print(dir(OpenMaya.MObject)) </code></pre> As per Python’s documentation, the dir()</code> function tries to list all the attributes of an object. Simply put, this will print here a whole bunch of names that correspond to the methods and data variables defined for the class MObject</code>. The ones surrounded with double underscores are the internal “magic” attributes mostly generated by Python that we’re not supposed to touch—for now. Since we said that everything in Python is an object, nothing stops us from getting the value assigned to those attributes listed previously. There’s another function built-in in Python to do just that: getattr()</code></a>. from maya import OpenMaya for attribute in dir(OpenMaya.MObject): print('%s: %s' % (attribute, getattr(OpenMaya.MObject, attribute))) </code></pre> The attribute apiTypeStr</code> for example is assigned with an unbound method object. That unbound method object is a legacy from Python 2 to represent methods that haven’t been called from a class instance. But this is just an unimportant detail for this scope. What matters is that we can indeed retrieve those attributes at runtime, and that if there’s a getattr()</code> function, then there must be a setattr()</code></a> one. setattr()</code> allows us to assign new values to existing attributes but also to define new ones if they don’t exist yet. That’s precisely what we need to insert a new awesome method directly within the MObject</code> class. from maya import OpenMaya def awesomeFn(self): return "Everything is awesome! Even this %s thing." % self.apiTypeStr() setattr(OpenMaya.MObject, 'awesome', awesomeFn) dummy = OpenMaya.MObject() print(dummy.awesome()) </code></pre> That’s all it takes. Thanks to this one liner, we now have access to the awesome()</code> method as if it has always been part of the MObject</code> class. But that’s also where the danger is. By inadvertance—or madness—, you could replace an existing method. This is allowed in Python since once again it is considered as a simple reassignment of a variable with another object. Of course you’ve changed the expected behavior of that method, causing a subtle bug showing up only late in the production. Congratulations, you’ve broken everything and are about to get fired. A first option would be to prefix all your own methods with something unlikely to be ever used by the developer team of Maya. The method awesome()</code> could for example be called bnnAwesome()</code>.[1]</a> Secondly, you could check if a method already exists, just to make sure. And if it does, then just give up. It’s better to preserve the original behavior rather than inserting your broken method that you couldn’t even figure out how to name properly. Quizz on how to check if a method already exists? The global function hasattr()</code></a>. Now, there’s a last option if really, really, you have a good reason, you know what you’re doing at 2000%, and you don’t mind getting fired. Should I say that it’s highly unrecommended? Well, it is. Use at your own risks. You’ve been warned. That last option consists in storing the existing method under a new name such as _original_awesome()</code>. This way, the overidden method remains callable within our code if we wanted to preserve its original behavior as we should. Inheritance</h2> Since we’re inserting methods into an existing class hierarchy, this means that inheritance is automagically preserved. inheritance diagram for the MFnTransform class In other words, if we insert a method bnnAwesome()</code> in MFnTransform</code>, then it will also be available in the all the classes defined on the right of MFnTransform</code> from the graph above. from maya import OpenMaya, OpenMayaAnim def awesomeFn(self): return "Everything is awesome!" # Patch the `MFnTransform` class. setattr(OpenMaya.MFnTransform, 'awesome', awesomeFn) # Use the method in the `MFnIkJoint` class. dummy = OpenMayaAnim.MFnIkJoint() print(dummy.awesome()) </code></pre> And that’s awesome. A Naive Implementation</h2> As effective as this code can be, this won’t take us every far and it would quickly become cumbersome if we had to manually repeat this process for each method that we’d like to patch. The original approach that I used in production was to create a bunch of Python modules, each named as per the OpenMaya class that I wanted to patch, and each containing a list of functions to insert. A function could be inserted either as a normal method, a class method, or a static method depending if self</code>, cls</code> or nothing was defined as first keyword. It’s been really easy to use but it felt a bit hacky. That’s why I recently came up with the idea of building a library to provide a convenient—and flexible—approach to monkey patching. The Real Deal: Gorilla</h2> With the library Gorilla</a>, you can patch anything as soon as it makes sense. Marking our awesome method as being an extension for the target class OpenMaya.MFnTransform</code> becomes as easy as: import gorilla from maya import OpenMaya @gorilla.patch(OpenMaya.MFnTransform) def bnnAwesome(self): return "Everything is awesome!" </code></pre> If many methods are to be patched into a same target class, it can be quicker to define them into a class and mark that class as an extension itself. import gorilla from maya import OpenMaya @gorilla.patch(OpenMaya) class MFnTransform(object): def bnnAwesome(self): return "Everything is awesome!" def bnnMoreAwesome(self): return "Everything is even more awesome!" </code></pre> Our MFnTransform</code> class is here to be directly patched into the module OpenMaya</code>. Since a class with that name already exists in the target module, it’s each method of our class that are going to be individually inserted into the OpenMaya.MFnTransform</code> class while preserving the ones built-in. To apply the actual patching, a function is provided to recursively look into all the modules from a given package for any extension marked with the gorilla.patch()</code> decorator. The extensions found are then applied. Properties, class methods, static methods, and whatsoever are also supported as extensions. Other features include the possibility to define what needs to be patched at runtime and how. But really, the documentation of Gorilla</a> does explain all the details more nicely. The best in all that? The code is relatively straightforward and works for both Python 2.6+ and 3.3+. Have a look by yourself, get the source on GitHub</a>. A Banana for Maya</h2> As a proof of concept for the library Gorilla, I’ve made a set of extensions for the Maya Python API v1.0. In its current state, it’s not very furnished but it still provides a good starting point with a set of methods to easily retrieve and iterate through the nodes of a scene. It’s—logically?—called Bana and can also be found on GitHub</a>. Here again, I’ve put some decent efforts in the documentation</a> if you’re curious. Final Note</h2> When I decided to adopt this approach, it was back in 2010 and I had my own—not necessarily valid—reasons to do so. PyMEL</a> wasn’t shipped with Maya and I refused to use the Python command layer of Maya which is a simple 1:1 of the atrocity that MEL is.[2]</a> Even today I would most probably go the same way as it served me quite well and made me proud of successfully taking on the challenge of using that Maya Python API in production. Now, by publishing this article, I do not intend to say that monkey patching the Maya Python API is the way to go. There’s other alternatives out there that are probably better suited for the vast majority of the use cases and that won’t require any extra work on your end. Whatever path you choose, do it because you feel comfortable using it on a daily basis and make sure that you can get your things done efficiently. Having the monkey patching technique in hands simply gives you the bonus option of being able to extend any Python library to your wishing if you need to, and as a last resort kind of things. Use it wisely. Footnotes</h2>bnn like banana.↩</a></li> You can read more in Why I’m Not Using the MEL and Python Command Layers of Maya</a>.↩</a></li></ol></aside> A Taiwanese Monk at the Salar de Uyuni, Bolivia 2017-10-01T13:00:00Z The Salar de Uyuni, one of these surreal places that I had in mind at the time when I bought my camera only to realize that a simple Photoshop gradient would have got me the same result. Minus the Taiwanese monk. Mid-June is the dry season in Bolivia but it’s also winter time. It can get relatively cold at an elevation of 3,500 m, and it gets even colder when you’ve got a salt flat covering a surface of 10,500 km² nearby. Since the freezing nights in the non-heated rooms of an hostel in Uyuni were not enough, I decided to go for the next level—waking up at 3 a.m. to make it for some night shoot of the stars and most importantly for the sunrise over the Salar de Uyuni. There were 5 crazy of us in the group to volunteer for a hypothermia experience: 3 Japaneses, a Vietnamese, and the usual French. We all got a bit disappointed when our guide Ricardo drove us to the spot only to tell us that it won’t be possible to shoot the stars this time since the light of the full moon was polluting the sky. We had to wait for another 2 hours before sunrise. The car was heated and felt like our last rampart between us and the cold out there. The few rapid excursions to get some snaps got us frozen within seconds. When the fingers reached the point of not being able to press the shutter button anymore, it was time to get back into the car to warm up until the next attempt. View on Flickr</a>before sunrise The results of our brave efforts ended up looking pale in comparison to when the light finally showed up. The 5 minutes during which the sky turned pinkish/blue while being perfectly mirrored on a thin layer of water was simply speechless. And disturbing of simplicity too. It couldn’t look any more fake. a (Photoshopped?) French View on Flickr</a> That sunrise over the Salar de Uyuni was just for us. We were the only 5—plus Ricardo—to dare adventuring over there at that time. We felt privileged and took the usual touristic photos. the Daltons After such a beautiful experience, I was craving for some more. I didn’t make all the way to Uyuni, especially after coming close to death around 10 time on the way from Sucre</a>, for only one sunrise. I signed up for a 1-day tour the day after. I wanted to see the dried and cracked parts of the salt flat. This time I definitely wasn’t one of the few to have had that idea. The dozen of tour agencies in Uyuni were fully booked and soon we reached our first target—the train cemetery—accompanied by a good hundredth of other tourists. There I was, back into a tourist trap. After one had the idea of climbing a train to get a new Facebook profile picture, they were all onto it, proudly posing on top of those metallic carcases. Fortunately they didn’t spot the one sneakily tagging his name on a train further away or they might all have done the same. Needless to say that taking a photo without anyone on it was close to a miracle. Panoramics were of course out of question. that’s life We were only allowed 15 min on each spot to do our things before heading to the next destination. The exception was the popular Isla of Incahuasi. It was our lunch spot. After filling our rumen, we had 1.5 hours of free time to enjoy ourselves. Actually there wasn’t much to do. The only 2 choices were to either take photos using the immense surrounding desert as a playground or to visit the island (and its toilets) for 30 BOB. It all seemed like a well planned invitation for us to play our roles of milk cow. Was it worth it so far? I don’t know. But fortunately a not so usual event made that day more interesting. A Taiwanese monk happened to also visit the Salar de Uyuni and was luckily sharing our car. Ariano talks many languages, is full of energy, has his approach to peace, and likes to take photos of the road with his tablet while sitting in the passenger seat. A great man. View on Flickr</a> When reaching an hostel/museum entirely made of salt, we’ve been reminded of the recent Dakar rally raid</a> that took place here in 2014. I firstly thought of the possible negative impact that such a race might have on the environment but then... well, I enjoy racing myself and selfishly couldn’t help thinking how fun it would be to rally drive on Uyuni’s salt flat. Our driver for the day seemed to know more than me on the subject and told me that joining the Dakar was mainly a matter of having a lot of money to spend. The salar will host another race during the wet season of 2015. Maybe another time? View on Flickr</a>the Dakar passed by here The wet season is the recommended time to visit the salar. The temperatures are warmer, the entire surface of the salt flat is covered with water and there are chances to have the sky made of awesomeness: menacing gigantic clouds forming a beautiful ambiance for photography. We didn’t have all that but we could still comfort ourselves with the highlight of the day—spending the sunset on the small area still covered by water. For the clouds, I’ll have to come back later. View on Flickr</a> myXKCD: CPU benchmark 2017-10-01T13:00:00Z 100% viable ccRig: A Rig for Softimage Back from the Dead 2017-10-01T13:00:00Z Having the limbs producing nice curvatures at any stretch value while being configurable and robust? Those were my goals for a rig prototype that I wanted to get done. It was back in 2006. It had a good run and it’s now live again. Sort of. The Apogee</h2> One of my very first gig as a character TD was a pitch for The Stupid Invaders</cite>, a cartoony movie. The characters had thin arms that could be highly stretchable and bendable. The rigs were working mostly great and my job back then was to fix any eventual issue happening on a per shot basis. That’s when I thought that I should challenge myself with a prototype of my own. It had to be able to stretch limbs without any limit and still always produce nice curvatures that are easy to control. And of course, it had to be robust—no more popping. Ever. A couple of years later, in 2008, I’ve been showcasing this rig in my first rigging showreel</a>. We could already see stretching and bending of limbs in every showreel, but I knew there was something different to this approach. I decided to share my researches for educational purposes and released the rig for free at the same time than my showreel. I didn’t except such a response from the community. Overwhelmed would be an understatement. Coming out from the unknown and having my work showcased on the front pages of various community websites was just unthinkable. It helped me to gain a bit in confidence but that’s also when I understood that “success” had a price. I had to pay for the 930 GB of extra bandwith that I’ve been using for the previous 2 weeks. That was an excess of 4750% of the quota that my web host was providing. Back on Track</h2> In November last year, with the release of my brand new website, I thought that it was about time to flush out all the old resources and start over from scrach. Who could be using this rig anyways? I mean... that rig was created with Softimage|XSI 6.5, you know! Turns out I was wrong. The traffic logs were consistently showing requests to the old ccRig resource page that now leads to a 404 error. Maybe some naive animators thinking they’ll find the rig of their life in there. They too couldn’t be more wrong. But that’s not my problem—you want it, you got it. You can now download</a> it and do your things. I’ll repeat it though. This rig was only built for educational purposes. Not that I will prevent you from doing any showreel, commercial work or whatsoever with it—no, the truth is that it is simply not suited for proper animation work. From an animation point of view, its spine is terrible to the point of being broken and it lacks any facial rig. Now, if you’re of the stubborn/masochist type, or if you simply like challenges, I’d still love to see what you can manage to do with it. From a more technical aspect, the rig itself is highly outdated in the way it is being layed out and won’t serve as a good reference. I still believe that there’s some value to the logic behind the stretchy/curvy system of the limbs though, which is why I put it back online—for the rigging beginners out there to selectively learn some bits from that logic. And only that. Nothing else for your own sake. Don’t come complain to me afterwards if you get fired because you’re rigging like in the 60’s. Download</h2> ccRig v0.11</a> Note that the rig is provided as it was back then. I don’t even know if it opens in the latest versions of Softimage.</s> Thanks to Eric Thivierge, the rig apparently survived to the Autodesk era and made it through to the final version of Softimage! I can be proud of my weed. </div> Softimage Has Been Killed, the Future of CG Softwares Is Now in TD’s Hands 2017-10-01T13:00:00Z Softimage did shine in more than one’s heart until it met its fate with Autodesk. Our dear software is now dead but not our experience nor our vision. It’s now up to us to make the future brighter. Softimage the Great</h2> When I started to learn 3D on my own as a teenager, I used to play around with Maya 2.5. It looked complicated and unintuitive, which paradoxically excited me. Everyone within the online community that I was frequenting found it hard to use. I liked the challenge. And the splashscreen too. I kept reading good reviews about the recently released Softimage|XSI and decided to try it out one day. I gave up 30 minutes after opening it. I didn’t like the default shortcuts, I didn’t like the UI. I didn’t give it a chance. It’s only when I got in touch with Action Synthèse in 2005 that I got back into it. I had no other choice if I wanted to land an internship anyways. For that reason I took the time to setup my own shortcuts, to get used to the UI, and to get some sensations going. It didn’t take long, it was a blast. I realized how stupid I was to give up so easily before. My goal was to learn rigging and it was the best tool for that. There was nothing preventing me from applying my ideas—Softimage had a fast learning curve, it was intuitive, and made perfect sense. Thanks to that in no time I felt comfortable to get some rigs going. I never wrote any line of code before then but I thought it would be a good idea to also learn how to develop. That’s how I started to use the Softimage SDK. I struggled quite a bit at understanding how to write my code in the first place but the API itself was no problem. Here again, everything made sense, even for a total beginner like me, and I quickly got my first scatter tool going. Some softwares are simple to use but don’t get you very far. It wasn’t the case with Softimage. Thanks to its well-thought architecture, it never got on the way when complex work was required. On top of the quality of the software itself, both the developers and the community were forming a great symbiosis. That was a bunch of active, friendly, helpful, and innovative souls. Softimage was driven by its users. Everyone was involved. With the implementation of the nodal graph ICE in July 2008, things quickly became out of control. More power at the reach of every artist. Everyone had a blast using it, countless of inspiring demonstrations of the tool kept emerging on the Internet. It also quickly became indispensable. a Softimage ICE compoundcredit: Benjamin Paschke</a> (with permission) The Struggles</h2> Eventually Autodesk felt the threat coming and perceived Softimage as a strong competitor to Maya and 3DSMax. Four months after the public release of ICE, Autodesk bought Softimage from Avid. A that point, they owned the 3 major all-rounded 3D softwares on the market. No more competition on this front. As soon as the deal got rumored, things started to change. The community grew concerned and unsecure about the future of its software. The Softimage public mailing-list became the place of numerous heated debates on the subject. But the community was stronger. It regained optimism when seeing the work accomplished by its users. Two of them mainly ended up doing the show and managed to open the eyes of those living on the planet Maya. They both developed plugins for ICE: Eric Mootz</a> with his Mootzoid nodes and Thiago Costa</a> with Lagoa Multiphysics</a>. test of emTopolizer2credit: Tim Borgmann</a> (with permission) We were proud to be Softimage users even though we started to feel more and more abandoned by Autodesk after each new release. Softimage was marketed as a plug-in for Maya, had less features implemented, the developers eventually moved to the Maya team, and always more debates were being fired up on the list. Meanwhile I was dealing with my own struggle in parallel. I landed a job at Weta Digital</a> and had to learn Maya. I tried hard to approach this transition from an open-minded pespective and there was no big issue in transferring my rigging skill set. The concepts in rigging are pretty much the same everywhere. What dumbstrucked me was the process to get to that same result. I felt like I was back to stone age. I found many of Maya’s daily tasks and the design of its API to be retarded. I spent my first weeks (months?) asking my teammates how they could possibly work with a such software. Even now, I still refuse to do in Maya a task as simple as painting some skin weights. It drives me crazy. My colleagues wouldn’t understand my frustration. All they knew was Maya, they couldn’t compare it to anything else. I was being just annoying to them. I sometimes wished to be ignorant too—it would have helped with my zen. But at the end of the day, let’s face it. As good as Softimage could be, it was a battle lost in advance. They’ve been trapped. The Proprietary Do-It-All Trap</h2> One size doesn’t fit all. All-rounded 3D softwares cannot please the specific requirements of each studio and each user, and that’s fair enough. Keeping a such package up-to-date is not guaranteed neither. Developers cannot afford to focus actively and simultaneously on each area covered by this kind of software. The large codebase, the deep dependencies between each internal module, and the unique core architecture and data structures trying to accomodate each discipline are all not helping much here. Specialized softwares are more likely to remain competitive by implementing the latest technologies in their field and even define new standards themselves. But then those all-rounded 3D packages allows for a smooth pipeline out of the box. For a company just starting its business and not having much resources yet to invest in RnD to connect the dots of a more flexible pipeline, this has always been an attractive feature. I believe this was especially a game changer back in the 90’s when anything must have been a struggle. If a unified pipeline with a single software could make the life of its users a bit simpler, then what could be wrong with that? That’s how most studios ended up buying a single package and decided to fill the holes by developing in-house tools. This task was furthermore eased with the developers not having to worry about implementing math, geometric and other complex libraries. It was already all there, available directly within the APIs built-in into the softwares. Developers could focus on getting their tools to work within their tight deadlines. But that’s also where the bottleneck lies. Using those APIs meant that all the code being written would be gravitating around a proprietary software, creating deep dependencies with it. Once a studio has invested years in developing tools, workflows, and a pipeline for a specific package, it becomes difficult to change ship. They’re stuck with it, for the best and for the worst. In this context, there’s no point for a studio to move from one package to another, especially if it is to end up in the same situation a few years later. Since Maya has always been on top of the film industry market, there was no hope for Softimage to gain much more seats from the large studios. Hence the decision of Autodesk to discontinue it. That’s life but I can’t help thinking that they’ve planned it all since the begin because it kinda make sense from a business point of view: buy Softimage to get rid of the competition, move its features to Maya who’s leading the market, and kiss goodbye to everyone relying on it for their living because Autodesk can’t afford maintaining its development. Nice hypocrital move after repeating years after years that they wouldn’t kill it. The Modularization Has Already Started</h2> Some studios grew tired of having their invested development being so closely tied to the unknown future of a software that they didn’t own. They started to cut their bounds and to regain some control by creating their own file formats or using standardized ones. The main idea being to store their data in a generic way to make it easily transferable onto any software. The native software’s file formats were only to be used by the artists to save their work in progress before publishing. With this in place, it was then possible to split the pipeline into logical chunks. Each department could work on the software(s) of their choice as long as they could output the data in the expected format. I’ve even seen 3 different softwares being used in the FX department on a same show. The right tool for the right job. The way to write tools itself has also changed to be done in a more modular and portable fashion. If you’ve spent years to develop a full-on muscle system but made it highly dependant on Maya’s API, then you’ve exposed yourself to rewrite pretty much the whole thing if you decided one day to port it onto another software. Instead, the goal here is to split the core with its gateway connecting it to the target software. Got a new software? You’ve only got to write a new gateway to plug the core in. To take full control over the destiny of a tool, some of the largest studios went for the next level. They developped stand-alone fully-featured applications. It is a tremendous work in terms of development and maintenance but in a world of closed-source softwares this is after all the only viable solution to ensure a long-term vision with an active development focused on the specific requirements of a studio. That was it. Some pioneers did their first steps towards independance. TDs Can Now Shape the Future</h2> Ideally each studio should have adopted a such modular approach to tools development. The trend being to implement deformers, simulation nodes, rigs and other involved developments into an in-house stand-alone nodal graph platform to then glue its content with different softwares. Of course, not everyone could push for that. Not until now. That’s where new solutions such as Fabric Engine</a> come in. Fabric Engine shines at abstracting the complexity of writing portable code. It allows any developer, including TDs, to write their tools in a stand-alone nodal graph and to painlessly make them usable in every software. Code it once, use it everywhere. All this with maximum performances out of the box. Now, imagine the talented community of TDs and developers joining their forces to build a library of tools and making them accessible to everyone on an App Store-like platform. Tools such as Gator, Lagoa Multiphysics, emPolygonizer, Unfold 3D, and more, would be available to everyone on every package. And ICE? Well, that’s already part of Fabric Engine 2.0. If that library of tools managed to encompass the needs in each area of CG, then the one requirement left to buy a software would be to have a hosting environment for Fabric Engine. It would become used simply as a shell where the main selling argument would be a good UI/UX to perform efficiently daily tasks. With Fabric Engine also providing a set of extendable modules to assist building applications, including a powerful real-time renderer and a set of extandable Python UI widgets such as an OpenGL viewport, an animation timeline, and so on, another choice would be for the users to assemble themselves their own hosting application. How much more powerful and dynamic would our toolset become if it was directly driven by its community, if we were all contributing to shape the future of CG softwares? If the entire userbase started to break its dependencies with today’s softwares, Autodesk would lose the control of the market and it would be our turn to kiss them goodbye. I’d say it’s the way to go anyways. Theorically it opens the doors to a longer-term vision and its team is made of a good bunch of passionate souls. It’s worth giving it a go, let’s just hope that Autodesk won’t buy them out. myXKCD: Painter TD 2017-10-01T13:00:00Z I had to work hard to get there How I Got to Work in the Visual Effects Industry 2017-10-01T13:00:00Z I am not sharing this story to show-off anything whatsoever. Hell, in fact I consider career achievements as fairly meaningless in one (hu)man’s life. But if we gotta do a job every day, then it’s still better to do one we like, right? So all I’m hoping to achieve here is to bring a bit of hope to the ones still seeking for that cool job. Because I’ve been there before, and it didn’t look so promising. a truly unexpected journey The (Failed) Beginnings</h2> It all started back when I was a kid with my parents often shopping at the same hypermarket. It had a shelf with many computers on display that we could try out and that’s exactly what I would do. Trying them out, every single time. I did spend many sessions like that, trying to figure out the purpose of the files found on C:\</code> or to beat the Solitaire and other Minesweeper games. My interest not fading away over the years, I eventually got my first own personal computer at 14. At that time, I was away in the beautiful backcountry of France for the summer break while my brand new computer was awaiting for me back home. But I was already proactive, I was getting ready for it. Surrounded with cows, sheep, chickens, and the mixed smell of their excrement—which I now associate with the great feeling of being in the nature—, I read a book on how to use Windows 95 like a pro. The computer bug, I had it. I knew that’s what I wanted to do for a living with the exception of being a developer because it looked boring.[1]</a> As for the visual effects part, I was fascinated with what I was watching on TV and knew that it was all made on computers, somehow. Soon after finally meeting with my computer, I started to mess around with 3D softwares and immediately thought that it would be the dream job for me. However I was way behind those guys sharing their work on Internet forums. They were good, really good. But most of them didn’t have any job, so how would I? I decided to not give up just yet. After graduating from high school, I applied for a 3D school in Paris. I travelled there, took part to the entry test, and... failed it. It wasn’t even a school with much recognition. No, it was a very accessible one, an easy bet. And I had failed its entry test nonetheless... I felt miserable. At this point, I thought it was game over. The Spark</h2> So I went for the kind of job that you do when you don’t know what else to do with your life. It was so terrible that it was almost scary. I was wasting my time, I was getting more stupid by the day, everything seemed to be pointless and I was being dragged down. But it was exactly what I needed. It opened my eyes, it gave me a kick in the butt. I didn’t want to spend the rest of my life like this. I didn’t want to give up on my objective without even fighting for it. I got back into teaching myself some more modelling, texturing and rendering until the day where I stumbled upon an article on the French online magazine 3DVF</a>. It was an interview of the makers of The Magic Roundabout</cite> movie and I knew one of those guys: Frédéric Bonometti. 6 years earlier, he very kindly taught me by email how to animate a bouncing ball and we did lose contact after that. But he was now an animation and rigging supervisor working back in my hometown Marseille! I emailed him and he remembered me. As a true passionate, he once again did a very kind gesture, this time by inviting me to his work to give me a sneak peek in person of the behind the scenes. I couldn’t refuse that opportunity. The moment when he showed me how he could move a cartoony dog around with the controllers that he created was probably the most fascinating thing that I’ve ever seen back then. I finally found my vocation, I wanted to become a character rigger! After a couple of weeks spent home trying to redo what I just witnessed, Frédéric sent me a rigging exercise that I quickly resolved. Without knowing it, it was an entry test that would lead me to step into the film industry as an intern in his company Action Synthèse. I was 19. I had no diplomas nor any experience to help me landing a job in the industry. I already almost gave up on pursuing this carreer because of the difficulty to get in. And I didn’t know if such an opportunity would ever show up again. This was my chance, my one shot. I had to give it all, I was utterly motivated! The Breakout</h2> CRT monitors, you said? Breaking one of their computers during my first week there didn’t stop them from all being a truly awesome bunch of people with me. Unlike many companies that are exploiting their interns, they made it clear since the beginning that I was there solely to learn, not to work on their projects for free. They kept their words. Driven by their passion and their good will, they shared all their knowledge with me. Always with a smile, a great attitude and encouraging words, while never expecting anything back from me. I learned a lot. They became my best friends too. Still today, I keep thinking that I have no idea what I would be doing if I hadn’t met Frédéric and those guys. I’m feeling immensely grateful and lucky. But I also worked hard. I’m never satisfied. I need to continuously extend my knowledge. I always question the status quo—especially regarding my own work. I need to go beyond what’s already existing, I want to improve things, I want to keep exploring and experimenting new ideas. In other words, I need challenge. And if I don’t know how to tackle one of them, that’s when the fun starts. I’ll research how to get there, learning tons of interesting satellite concepts in the process. A bit like when you can’t help yourself clicking on every link found on Wikipedia to answer a question that you already forgot. There’s no need for a school to learn or to reach your objectives. A big pool of resources like the Internet and knowledgeable people to help you getting unstuck are plenty enough. This whole attitude eventually got me hired at Action Synthèse as a character rigger and developer for a TV series. After a few years spent working there plus a short experience in Paris, and despite of all my hard work, I still felt unconfident about my skill set. I couldn’t help thinking of the cutting edge companies out there that were redefining the standards, pushing the limits further away, bringing always more life into each pixel. They had to be filled with godlike superhumans. It had to be out of reach for someone like me. But I wanted to travel a bit and decided to try my luck anyways. Thanks to our great education system in France, most of us still can’t converse in English even after 7 years of learning at school. I was one of them when I landed my first job interview ever. It was on the phone with Animal Logic</a>, at 6 a.m.—time difference oblige—, I was sick as hell, and it was of course in English. I’ve never been as stressed out as I was that time but it worked out somehow and that’s how I ended up working on the other side of the world, in Sydney, Australia. Less than 2 years later, after finally building up a bit of confidence, I decided to go once again for the impossible and it went pretty well too. At 26 years old, I was fulfilling my initial objective to work with those guys who made movies such as Lord of the Rings</cite>, King Kong</cite>, and Avatar</cite> possible. I was working at Weta Digital</a> in Wellington, New Zealand. where is Charlie?credit: Julian Butler</a> (with permission) Conclusion</h2> I’m not so much of an artist myself but I can now proudly say that I’ve started from nothing to end up working with the most talented artists in the industry. Something that no one—especially not myself—would have thought possible only a few years before, when I was lost. My grandfather often told me when I was a kid: when you have something in the head, you don’t have it in the ass</q>. Another way of saying it is that I am stubborn and persistent. I wanted to work on those blockbusters, so I grabbed my chance when it came up and kept going from there. I’m not any more special than you. At the end of the day we’re all good at doing what we enjoy doing. Your dream job is just one step away from there. Motivation, persistence, and patience are all you need. Do it. Footnotes</h2>Funnily enough, programming is now one of my top interest.↩</a></li></ol></aside> How Not to Climb the Volcano Acatenango, Guatemala 2017-10-01T13:00:00Z I love physical and mental challenges. I knew that hiking Acatenango’s 3,976 m summit would be difficult but the more different persons would tell me how hard it actually was and how cold it got, the more I was getting all fired up. If they could do it, there’s no reasons why I wouldnt’t. But a sprained ankle and other sickness convinced me to hold on for a bit. It sounded wise until I got a cold with a sore throat but couldn’t wait any longer. My flight was the day after, it was now or never. My Italian friend climbed it the week before and recommended me to directly contact the guide without going through the usual agencies. Those agencies are the ones pocketing most of the money, while the guides doing the actual hard work get the leftovers. My Spanish not allowing it yet, the receptionist at my hostel kindly accepted to give me a hand with the phone call. All got arranged quickly and the guy would come picking me up that same night at 11 p.m. I had the whole day to prepare myself and started it with getting myself a good lunch. A bit of proteins here but mainly loads of carbohydrates there to build a reserve of energy that I could use during the climb. Then, I had to buy the mandatory banana bread from a shop in Antigua that I could use for a boost of energy during the effort. And finally I planned to buy the chocolate to go with it, as well as to drink some rice with milk for dinner, but first... a small nap. I would see the rest later. I got into bed a 2.30 p.m. and got awaken an hour later by the receptionist. The guide was here and was waiting for me. The result of a misunderstanding—the receptionist herself also seemed surprised. I packed my bag in a lightning strike and started to follow my guide, Jaime. He had no car so he did all the way from Acatenango by chicken bus, especially for me. I followed him to the bus station of Antigua and we arrived 1 hour later in his small village, at the foot of the volcano. The sun was setting and it started to get cold. He offered me a spare room with a bed and a small dinner to eat before sleeping for a few hours. With the night, the dogs seemed to have become different beasts. I had one dog growling at me earlier, but now they were all constantly growling at each others to defend their territory and sometimes got into fights. One of them sounded especially violent and scary. Despite of wearing 3 layers of merino, a down jacket and being covered deep under 2 blankets, I was shaking from the cold out there. I wanted to be on the move already to get warmer. At 10 p.m., the roasters from all over the village decided to announce the... the... well, the I don’t know what. There was still 8 hours to go before the sunrise. But whatever they announced, they did it well. With a good endurance. Needless to say that I didn’t sleep much when I heard Jaime getting ready at 1.15 a.m. But so was I, ready and more excited than ever! I just needed to walk out like a ninja to not raise any attention from the dogs. No warm up, the path directly started with a fair slope which was mainly made of sand. Like at the beach, each step required a good amount of effort for little reward. I tried to focus on becoming more efficient. Small steps without sliding backwards. But the technique of the guide made the difference and he slowly but surely distanced me. In such low temperatures, wearing wet clothes is forbidden to prevent possible future hypotermias when cooling down. But I was already sweating from the effort and decided after 15 min to have a quick first stop to remove my down jacket. After the sandy ground, we were welcomed with a slippery one. Here again he distanced me with his daily experience of the field, but thanks to my energetic brute force I would quickly catch up with him when some charitable souls were once kind enough to plant some pieces of wood to serve as stairs. We were back on a more practicable—but even steeper—terrain when we reached the first checkpoint with a bench to sit. He slightly slowed down to check if I would head for it. But no, I already stopped once and it was enough. This hike was my come back challenge after almost 2 years of not doing any serious sport, and I wanted to take it up like a boss. So we kept going and he took the lead by sitting on the next bench, even though I wasn’t behind this time. I got proud. He stopped. Ok, he was probably being thoughtful of me, but it was good for the moral nonetheless. Even more so since my cardio, my breathing and my legs were all doing pretty well. A few stops and 3 hours of walk later, I was still at the top of my form. I even found a way to heat my hands by leaving them in my pockets, against my boiling hot legs. But then, I suddenly started to feel a cramp in each leg. I knew that it would most probably only get worse but I didn’t say anything and kept going anyways. Two years earlier I ran 28 km with proper cramps during the last 15 km on top of a painful knee—who ended up preventing me from running ever since then. I thought that if I could run in these conditions, then I could certainly walk with a couple of cramps. And I was sure that it wouldn’t have stopped Mike Horn</a> from continuing either. Despite me drinking even more water, eating bananas, giving myself deep tissue massages and stretching out, it quickly reached the point where both of my legs were literally tetanised. I couldn’t stand up anymore. So I sat, put back my down jacket, fitted some toe warmers in my shoes to help the blood flowing, kept drinking, got a lolipop for a quick energy rush, and was hoping to wait a bit to see if it would get any better.[1]</a> But time was playing against us. Our headlamps were reflecting on a sea of ice crystals dropped off on the ground. The temperature was glacial. Staying put for only five minutes was enough to get us frozen to the bones. Staying longer would have meant taking the risk to get into an hypotermic state. And so we had to give up on the summit, only 1 hour away, and turned around. I hated it but it was the only wise decision to take. I tried to leave aside my frustration and focused on moving the chopsticks that I had in place of my legs. It became a question of survival. It just happens that despite of my level of fitness and my relatively healthy style of life, I’ve always had those kind of muscular problems since I’m a teenager. I love pushing my limits and it’s hard to accept when my body sometimes decide to fail so easily where everyone else wouldn’t have had any problem in an identical scenario. After having worked hard towards resolving these issues without any success, I’ve had to come to the evidence that we’re not equal towards our body. But as a friend told me, for some it’s indeed way harder than for others, but it doesn’t prevent disabled persons to realize apparently impossible challenges. All this to say that I’m quite shameful to share this experience with you, but I want to take you as witnesses here: one day, things will be different. Footnotes</h2>I suffer from Raynaud’s syndrome, which makes it even more vital for me to not let my fingers and toes drop in temperature.↩</a></li></ol></aside> Guatemala: A Journey Full of Journeys 2021-10-09T13:00:00Z Proudly, I can say that I’ve started my Latin American trip without any plan and without doing any research neither on the Internet nor in any guide. My whole idea was to show up in a place, meet with the locals and with other travellers, and decide what to do on the spot. Less proudly, communicating with the locals turned out being harder than I hoped for—reaching level 8 in Spanish at Duolinguo</a> and adding a touch of French-nish didn’t cut it. Antigua</h2> I needed to start my trip from somewhere. That was an easy one, an Italian friend decided to hit Guatemala for 2 weeks during Christmas, so would I. Antigua was the meeting point. 17 December 2013</h3> The plane flew over Guatemala City just when the sun was setting. Quite a beautiful introduction to the volcanoes scenery all around. But it also meant that I had to reach Antigua by night. I still remember the day when I was in the plane in direction to Australia for the first time. It was on the 9th of February 2009. There was a French girl sitting next to me who was returning to Australia. I’m not sure what was her reason but she did her best to try to freak me out. Beware of the deadly spiders, they like to hide under the toilet seats because they fancy humidity</q>. They also like hiding in the grass so don’t walk barefoot</q>. Always double–check your bed and your shoes before getting in</q>. There’s ton of shark attacks happening, don’t swim</q>. I’m not even talking about the many lethal jellyfishes</q>. And the list went on and on. Many couldn’t help themselves at telling me similar stuff about Guatemala but regarding violence this time. Don’t travel in chicken buses</q>—the local transport system—and Don’t go out by night</q> were in the top 2 of the list. To leave them the benefit of the doubt, and because I was exhausted after this long travel, I thought that I’d play it safe for my first move. As I was about to grab a minibus to Antigua for 80 quetzals—the local currency—, which is about 8 € or $10 USD, a Dutch girl sitting next to me in the plane offered me to jump in her private shuttle for free. Her mum already organized and paid for it in advance because she was scared that her daughter would take a chicken bus instead. It made me a bit uncomfortable not to pay anything and so I decided to give her 100 quetzals to thank her. I didn’t have any smaller change anyways, and she didn’t neither. When the driver dropped me after leaving the girl at her hostel, he stared at me insistently. He raised his hand, the palm slightly facing up. I hastened myself to grab it and shook it while thanking him with a warm ¡Muchas gracias!</q>. For some reasons it didn’t seem to be enough for him to stop staring at me weirdly. Only then I understood that he was expecting a small tip. Without any idea of the actual value of the currency, I gave him 50 quetzals. Only later I realized that with an average Guatemalan wage of 80 quetzals per day, I’ve been more than kind. But more importantly, I’ve beautifully played the role of a naive tourist and this had to change. Before the conclusion of this fiasco, I agreed on a dinner with the Dutch girl to a place recommended by our shuttle driver. I decided to pick her up at her hostel to make sure that she wouldn’t get into troubles because of the don’t get out by night</q> thing. The receptionist at my hostel kindly gave me a map and drawed the direction. It was only a few blocks away and would be quite straightforward if only she had pointed me to the correct destination. Instead I’ve been turning around for 30 min and ended up getting lost in a totally different area with either non–existant street names or names that wouldn’t match with the ones on the map. This first exploration of Antigua by night left me sceptical. There was no much light in the streets, making them quite dark. Not many pedestrians were walking neither. At an almost regular interval, cars were driving by at a much reduced speed because of the paved road. And all those cars had their windows covered with a black tint to the windows.[1]</a> All this plus some extra loud firecrackers banging here and there in the streets—due to pre–Christmas celebrations that sounded more like Bagdad to me—left me with a slightly sketchy feeling. I finally managed to find my way back to my hostel, looked myself at the address of her hostel on Internet, and made it there in no time. 20 December 2013</h3> I met a lovely French couple the day before and signed in with them for a trip to the volcano Pacaya. The goal was to get to the summit for sunset. We left at around 2 p.m., drove for about 1.5 hour and started our gentle climb. Because we were allowed to stay up there for only a short period of time, our guide made us climb slowly to make sure that we would arrive at the right moment. Despite having our entire group refusing to climb with one of the many horses offered at the start, a few of them followed us anyways. Just in case someone changed their mind or wanted to give up. You know, a bit like a broom wagon. When the last ascent of the summit was at our reach, we had to stop there. Climbing to the top was forbidden due to the volcano being currently active. Indeed it was continuously smoking and rumbling every 3–4 minutes. So we just sat down there, with a nice view over other volcanoes around, and waited for the sunset. It was beautiful. View on Flickr</a> But it wasn’t enough for our guide. He got disappointed because he hoped that we would see the red color of the lava from the volcano vent when the dark set, which didn’t happen. We had to go back down in the dark, with a few headlamps helping with the bumpy ground. I didn’t feel the need for turning on mine, until I figured out that it wouldn’t be the best timing to injure myself just before my Italian friend would arrive in town. So I turned on my light for the time of a very small run downhill, for the fun of it, and that’s when a deep crack sound rang out from my right ankle. Done. When we almost returned to our starting point, our guide stopped us and pointed back at the volcano. It was red. We could see rocks erupting from it. 22 December 2013</h3> So far my frustration of not speaking Spanish was already quite high. I mean, what’s the point of going into a country if we can’t even speak with the locals? But something that I’ve never been looking forward to is heading back to any sort of school. This has just never been a good fit for me. I’m more of the type to learn things by myself. I hoped to catch up over time. I was fortunate enough to have been assisted in this regard by the French couple for the previous few days, who both have a great level of Spanish, and I would now be able to rely on my Italian friend who just arrived and who is perfectly fluent. San Pedro La Laguna</h2> 24 December 2013</h3> We booked the day before one of the only place available to us on HostelWorld. Not a good idea. The hostel was rather expensive for the average price and it didn’t rhyme with better quality. When walking in the streets, we’ve asked some guys staying at a Spanish school if they knew any better accomodation around. We’ve been pointed towards one named Hotel Peneleu. We went to check it out. It was way cheaper, way cleaner, and the view was quite something so we booked it for the next night. Note to self: do not solely rely on the Internet. View on Flickr</a> On the way to that hostel, we’ve found a group of kids playing in the street. They were having a lot of fun, and they doubled up in energy and excitement when we’ve asked them if we could take them in photo. Such a great moment. They loved the photos so much that they went on for another round. View on Flickr</a> Then their mum showed up to give them some piece of advices by telling them to accept being taken in photos only in exchange of money. The time was for Christmas celebrations. With many selling weed and mushrooms in the streets, and all those gringos—foreigners—buying them only to end up wandering in the streets completely stoned, we thought that there would be some sort of party happening. After scanning the streets, we ended up stumbling upon where all the locals were gathering: on the place in front of the church. Not really our cup of tea. So we kept searching and we found a nice hostel where this time all the tourists were regrouped. Not really what we were looking for neither but in lack of a better choice, we stayed. The music was there even though not in its best form. The general dynamism wasn’t at its best neither. And to be a real party pooper, I chose to be wise and not to dance much due to my sprained ankle. But faith decided otherwise. The DJ set a track of Daft Punk, Get Lucky</cite>. If there’s one thing I like to dance on, it has to be Daft Punk tracks. And so I went full on in the centre of the dance floor, battling with other guys. I was on fire. So much that it took me a few tracks to realize that I only manage to worsen the condition of my ankle. 25 December 2013</h3> On the other side of the lake is the Indian Nose. A small mountain whose silouhette looks like a profile of looking upwards. Our destination for today. We thought that we would try it on our own without going through a tour or a guide. So we first jumped in the boat, direction San Marcos. From there we had a small lunch in one of the very few places available, and we looked for a tuk–tuk. We knew that we could drive up to a place named Santa Clara, and from there only 40 min of climb would be separating us from the viewpoint. We looked for a tuk—tuk, tried to negotiate the price to what we’ve previously been told by the restaurant owner, and... it didn’t work out. The old man was camping on his position and so were we. So we took a ride to San Pablo instead in the hope to find better deals over there. When arrived, the negotiation started again with the old man but didn’t go any further until a younger and more intrepid tuk–tuk driver accosted us with his vehicle. He got us a better deal, we changed ship. That driver was definitely more sporty too. The not so stable–looking 3–wheeled machine and the bumpy, steep and curvy mountain road seemed to be like just another video game to him. And for us too, it was fun! Especially since we made it in one piece to our destination. There a guy ran out of his house to stop us. He couldn’t help himself from smiling when he was talking, like if he could smell the good deal. He told us that he was a sort of custom for the Indian Nose land, that we had to pay a fee to get there, and that he would have to come with us. We’ve heard about the 150 quetzals fee so it sounded fine. We went on with the plan, started a walk towards a first lookout, and from there he tried to convince us to not go to the summit because it wouldn’t be worth it. The view would be the same. We insisted to keep going. He left us and finished walking the way up with our tuk—tuk driver who felt like joining us. View on Flickr</a>our tuk–tuk driver, a cool dude Arrived at the summit, there was a group of other gringos waiting for their guides to come back with some extra gear. Their tour included a camping overnight. And there were also some locals trying to get more money from us. I could barely understand half of what they were saying, which was enough to make me unhappy about the situation. But I couldn’t reply to them, my friend had to do all the job. It wasn’t so much a matter of money, they were asking only 25 quetzals per person, or around $3 USD. It was more a question of principles. We already paid an entry fee and didn’t want to pay every single person asking us for money. Especially without any document supporting their arguments. The situation got worse, they became more agressive and threatened us to call the police while letting us know that we would run into troubles on the way back. Or something like that. View on Flickr</a> Our tuk–tuk driver started to wonder why the hell he followed us up there and begged us to pay the fee to avoid any problem. But instead we decided to wait until the guides of the other group came back from their extra climb. That’s how we learned that we actually were on a private land. A different one from the previous lookout. And that yes, they require visitors to pay. Well, only gringos have to pay, not the locals. After a quick evaluation between taking a risk—as low as it might have been, if we consider that they were hopefully bluffing—of losing our gear and whatnot versus spending $3 USD, we opted for the latter.[2]</a> And here we were, in for another epic tuk—tuk ride. Downhill this time. Actually the ride wasn’t sensational enough to finish the day. The driver—should I say pilot?—did a quick stop in San Pablo to pick up a friend of his and to let him drive all the way to San Pedro. He was around 8 years old. Eight freakin years old! At his age, I wasn’t even playing at Colin McRae Rally</cite> yet. a way too young tuk-tuk driver practising Semuc Champey</h2> 26 December 2013</h3> With that previous experience, I thought that we would be immunized against any sort of ride. I was wrong. It all started normally. We got in the shuttle at 7 a.m., direction Antigua for a lunch stop. We took the opportunity to rush back towards our favorite lunch place, where not many gringos dare going to eat: the market place! Most cheap, authentic and possibly yummy food! We couldn’t pass by Antigua without stopping to our second addiction in town: the banana bread shop. The delicious flavour of bananas can already be smelled from the street. When you’re around, there’s no stopping the urge of buying some. Best. Banana bread. Ever! Of course, they did things well by being located next door from the chocolate museum. A banana bread sandwich with a row of 80% salty chocolate equals to pure awesomeness. Back on track! Two shuttles left at 2 p.m. in direction of Semuc Champey. Somewhere half–way our shuttle decided to stop and turn around. The other one had a mechanical issue so we ran to the rescue. And ran again after picking up some cooling liquid. View on Flickr</a>killing some time Apparently every Guatemalan driver is also a mechanic. I found the front seats unmounted to allow them to dig through the layers of the engine. It took some time but eventually they got it sorted and we were back on track. At 1 a.m. we arrived at a place named Lanquín and for some yet unknown reasons we changed vehicles. From almost comfortable and warm seats, we’ve been thrown into the back of a truck with no rooftop or whatsoever and no other way to sit than a single thin wood board. But sitting wasn’t our best bet. We immediately rushed into the jungle in a fashion very similar to water rafting. Sitting down on that board would have only resulted in a good petrissage of our bum. The one viable option was to stand up and and hold on tight to the metallic armature surrounding the truck. It was either that or being ejected out in the jungle. And it started to rain. Lightly but consistently. An hour later, we finally made it to our hostel and went on to sleep straight into our huts. They had a rooftop but no walls, it was a bit like sleeping in the outdoors. It felt great! 27 December 2013</h3> After a short night, we went on with the main reason of our stay: a tour going through a viewpoint, the natural pools, and the exploration of a cave with a candle. But before heading for the tour, our guide has been pushing hard for everyone to order their lunch meal straight away so they would be ready for when we’d come back. We were not really attracted by the menu and the prices but since we had no idea of the surroundings—arriving at 2 a.m. didn’t help—, and since he’s been so insistent, we followed the mass and ordered ours. Getting to the viewpoint required a little climb. It was written difícil, but it wasn’t. What’s sure is that the view was worth it. View on Flickr</a> And then onto the river and the pools. Not carrying any swimsuit with me, I had to borrow one from a local. It was actually a thick sport short. The water was clear, and us, gringos, were mostly invading the place. I felt bad for the locals living around there. View on Flickr</a> This and a serie of small activities in the pools took us the entire morning. When heading back to the place we were staying at, which is also where the tour operates, we realized that there were actually plenty of locals selling real, authentic looking, food. Anger grew in me. I already didn’t like this guide for some reasons but now I truly had a grudge against him. He deliberately hid this information from us. Instead of distributing our money to the poor locals in the need, we had to spend it in his stupid company. But now we knew. The lunch with its ridiculously terrible (quantity × quality) / price</code> ratio finished, we had to get rid of all our gear and clothes. Only the swimming suit and the flip–flops had to remain. Flip–what? Alright, my minimalist gear didn’t include any of these. I was the only one. Barefoot it would be then. Here I was, walking like a penguin for about 5 minutes on a relatively painful ground. Fortunately my feet are slightly trained with a small barefoot running experience and other “shaolin-like” trainings on sharp rocks that I happened to do once because I’ve got such stupid ideas sometimes. The barefoot community grew when they all been asked to leave their flip–flops at the entrance of the cave. There, we’ve been given a candle each. A bit like the Olympic Games torch, my goal was to get it through without it shutting off. I’ll save you from any sort of uncontrollable suspense by letting you know that I’ve miserably failed on the way back. The cave exploration was not so interesting for its sight. It was rather ugly. The cool side had more to do with its adventurous aspect. We had to go through a few fun obstacles and endure walking or swimming in the dark knowing that at some point we’ll hit an underwater sharp rock that will cut our skin. I definitely didn’t fail that bit, it happened. Flores</h2> 28 December 2013</h3> Departing at 7 a.m. from Semuc Champey back to Lanquín, I couldn’t wait to add some brand new bruises by banging again the armature at the back of the truck. My wish has been fullfiled with the help of a new driver, very keen to overtake all the other trucks in his path. Of course, it was just the begin of the journey. We jumped in a shuttle in direction to Coban where we had to pick up some new passengers. The issue? The shuttle was overbooked. No worries, I though, this is the kind of non–issue for a group of adventurous travellers anyways. Right? Except that it ended up being one. The shuttle dropped us all at a McDonald’s—do they think that we exclusively eat in shit places or that we want to contribute to them?—and then drove away. At its return, the 3 new passengers were finally sitting in the then empty shuttle after having waited for 2 hours outside. Coincidentally, they were a group of 1 Peruvian and 2 Guatemalans brothers that we previously met in an other shuttle from Antigua to Lanquín. We had the occasion to discuss quite a bit with them, especially when we all had to wait for the cooling system of a shuttle to be fixed during the previous trip. My friend and I happily greeted them. As for the others, they welcomed them in their own way: Why did they take our seats?</q>, We were there before</q>, We’re tourists and they’re Guatemalans</q>, and so on. Except that they were humans like us, they were tourists like us, they paid like us, and they’ve been told to seat there. A long infantile battle started. Being the last one to enter into the shuttle, I could only see the final outcome. The 3 of them were stacked on top of each others in the most uncomfortable way possible. All this when there was an empty space on the floor at the front of the bus. I wondered how could we have lost any value of solidarity and become so selfish in our “developed” countries of gringos. So I went for that spot on the floor and gave away my seat. It made me feel pretty happy. A few hours later, a Brazilian girl had requested a stop for an urgent need. For some reasons the driver didn’t stop where there were signs of civilization and possible toilets around but ended up pulling somewhere with not much around. So she went for it anyways and came back crying. She had been bitten by a dog while doing her thing. I picked up my SAS Survival Guide Handbook</cite> and checked for any hint of what to do in this scenario. We requested for another stop next to some habitations. I told her to thouroughly wash her wound to remove any trace of saliva, then I gave her an antiseptic to apply. On her way back from the restrooms, she called me. I asked her how deep the wound was and how it went. The bite being at the back of the leg, she couldn’t do much and asked me to apply the antiseptic. So I executed myself and did it without thinking. Then I let her know about the small probability of rabies and told her to check with a doctor within the next few days. For the next hour, I hated myself. I’m not a doctor but I have been through a 2–day outdoor first–aid course in New Zealand the year before. I should have known better. I kept thinking of what I should have done instead. Wash my hands, not get in direct contact with the blood of the victim, clean her wound, apply a compress and a strap to avoid infection. I pretty much did it all wrong. I was fairly relaxed and collected but I simply didn’t activate any of my brain cells. How could I forget all these basic steps when it finally mattered? This was unacceptable. I’m not even talking of the probability of contracting rabies myself by applying some antiseptic on one of my own wound after having been in contact with her blood and not having washed my hands inbetween. I guess it would have been a good lesson. To you, Brazilian girl: even though you haven’t been so nice with my 3 friends, I sincerely hope that you’ve recovered well. View on Flickr</a> 29 December 2013</h3> Sleeping is overrated. We woke up at 2 a.m. to get into a tour that would take us to the Tikal Mayan ruins just in time for sunset. Of course the shuttle showed up 30 min late but we arrived on time and started our walk through the ruins in the dark. Our sunset spot was a tall pyramid overlooking the jungle. Before climbing it, our guide gave us a quick briefing, asking us to respect the silence once at the top so everyone could enjoy the melody of the jungle. It did work. Almost. Nobody was talking, only the crowd of cameras were frenetically making noises. I sometimes wish that digital cameras had a newbie detection algorithm. Maybe they could signal to their owner things like: No magic here, if it looks bad with your own eyes, it won’t look any better on a photo</q>, Nope, that small bird still won’t stand out from the tree in a photo</q>, or Don’t mistake my flash with Superman’s laser beams, I won’t light up your subject at 5 km away</q>. On our watch the sun was supposed to be there but the thick layer of clouds decided otherwise. It didn’t stop the howler monkeys to shine in the surrounding jungle through their impressively loud voice. Surreal atmosphere. nope, we didn’t climb that one Rio Dulce</h2> 30 December 2013</h3> To not change with the good habits, the night was yet another time short. We woke up at 4.15 a.m., skipped any sort of breakfast and reached the bus terminal in Santa Elena with our Peruvian and Guatemalan friends. After spending my last 7 quetzals into a bottle of orange juice, we jumped into the coach that didn’t seem to be of the latest generation. Most of its windows have been hit by rock impacts, probably during a street manifestation that didn’t turn so well. But we were happy, the coach wasn’t as crowded as we thought it would be and we could easily secure ourselves a seat each. It even was comfortable and the 4 hour drive to Rio Dulce for only 65 quetzals sounded like a great deal. This was until the coach stopped to get more passengers. Over and over again. Quickly all the seats were taken and the unlucky ones had to stand up in the middle row with their alive chicken and other marchandises. It reached a point where there really wasn’t any space left. I could feel the leg of someone compressed against my shoulder. I couldn’t take it anymore when he started to rub his willy against me. After a few minutes, I sighed. Loudly. He giggled and gave me a break by stepping back. Against any logic, the density of people didn’t seem to be enough to dissuade the coach manager to always take more passengers in. When the persons standing up couldn’t figure out anymore how to free up some space, the manager walked to the back and started to place each person himself in a way that made them stacked up like tetris blocks. The coach did become a real tin box of sardines. With the sweat juice that comes with it. To make it always more challenging, someone decided to showcase all the tracks that he had on his phone. Some sort of music from the 70s with the exact same rythmn played by an accordeon on each single of his tracks. I started to get a pretty badass headache. Meanwhile some chicks escaped from their box and were partying a bit everywhere in the bus while singing a cute pew pew song. I thought that I would finally breathe when we reached our destination but I was wrong. The loud truck engines and the dense traffic honking like if they were playing a contest of the most annoying driver only managed to make me regret my dear coach. My first proper intake of food and sugar of the day didn’t help to get rid of my growing headache. I had to skip the tour planned to a castle in the middle of the lake and say goodbye to my new friends. When I reached my hostel by boat, in the middle of some sort of jungle, I realized that what was a simple headache turned into an illness. It was around 2 p.m. when I felt asleep, covering myself in many layers to sweat the shit out of me. When I woke up a few hours later, I was still too weak but a honey bear crawling in the hostel cheered me with his presence. Livingston</h2> 31 December 2013</h3> Wait, did we change continent? Livingston is only accessible by boat, and when we reached the quay the first impression was that black Africans took control of the place. It was supposed to be the place where to spend New Year Eve but we did struggle once again at finding any partying going on. We gathered with a few other gringos and went on a mission but for the first time in my life, I missed the countdown. Not that I care much anyways. It’s only later that we finally found some African sound with a few guests dancing in a very... sexual manner. View on Flickr</a>throwing some more firecrackers... Antigua, the Return of the Vengeance</h2> 2 January 2014</h3> Back to Antigua to close the loop. The most terrible thing so far has been for me to not be able to directly interact with the locals. I’ve only been a mere passive spectactor when my Italian friend did speak to them. This has been beyond frustration to the point that I decided to overcome my hate for school and take Spanish classes in Antigua. I decided not to leave until I could communicate properly. It would be worthless to keep travelling like this anyways. View on Flickr</a> Banana bread, how I’ve missed you! Random Facts</h2> going into local places where no many gringos usually go is quite an experience. It sums up to dozen of people staring and amically laughing at you, while wondering what the fuck you’re doing there.</li> the toilet paper? Please don’t throw it in the toilets but in the bin. It might block the toilets and you reallly don’t want that.</li> clothes don’t dry in a humid environment</li> Guatemalans love showing-off the same 3–bit Christmas song everywhere. My ears bled. A lot.</li> the pre–Christmas banging firecrackers celebrations actually never ended. They did survive to both Christmas and New Year Eve, to the days and the nights.</li> did you ever see a place where the toilet paper is only available before entering the toilets? I did. Hopefully you’re not on diarrhea, otherwise good luck at anticipating the amount of paper that you’ll need without wasting any.</li> I’m sure that a kid has more chances of being shot dead at his school in the USA than ending up injured at all in Guatemala.</li> </ul> Footnotes</h2>Only later have I been told that the omnipresent black tint on the cars is there to prevent thieves from seeing their content.↩</a></li> The road between San Pedro and Santa Clara has the reputation to be a good spot for thieves to target foreigners.↩</a></li></ol></aside> Let It Begin 2017-10-01T13:00:00Z A Taste of Freedom</h2> In France we’ve got what’s called a CDI, which is a permanent work contract. In such a difficult economic context, it is seen as the Holy Grail, providing their holders with security of employment. Not being stressed out, carrying no responsibilities, having no constraints, being able to meet with friends anytime, anywhere, benefiting from having the freedom to do what we like, including relaxing, this is what I call a VDI. VDI stands for Vacances à Durée Indéterminée, which translates to Open-Ended Holidays. It has been my status for the last 6 months already, and needless to say that it has been great. But it‘s now time to move on, to go for the real deal. I’ve decided to add a glimpse of adventure to my dear VDI. Here I am, now starting an unrestricted trip to Latin America! Paris</h2> But first things first. Living in the South of France, Paris was the first stop on my way. Paris and I have always been into a love–hate relationship. When I was a kid, I always thought that the weather forecasts were just lies. I still kinda believe that but back then I couldn’t get myself around the fact that they consistently predicted either a cloudy or a rainy weather in Paris when it was mostly sunny in the South. How could these people possibly endure living without the sun for so long, right? Then I started to work there for 2 months. Trying to find my way in the streets of Paris with my hugely and heavily unoptimized backpack lacerating my shoulders wasn’t enough, I also had to be welcomed with a cold rain that soaked me up within minutes. I didn’t see any single pixel of blue sky during my first week, let alone the sun rays. When I finally met with the sun again, I got blinded by the intense ambient luminosity, I just couldn’t stand all that natural light anymore. Fortunately it only lasted for 15 minutes. Not only the sky was grey but the city itself with its buildings felt quite colorless too. Even its inhabitants were dressed in a shade of grey, like if they were enjoying themselves in this moody and monotone atmosphere. It hit the nail on the head when a pizza maker one day told me that I didn’t seem to come from Paris. I was surprised, how could he possibly figure this out? I don’t have that much of a pronounced Southerner accent, nor was I wearing anything that could betray me, so I asked the man. His answer? Well, you’re smiling!</q> Alright... I had failed the Parisian test. All in all, I’ve first seen Paris like a very noisy, confined, polluted and oppressing city with no much space for nature, and where their inhabitants looked like a bunch of soulless zombies living solely for their work. For the city known as the most romantic city in the world, I surely was disappointed. It all looked too cold. Cold and grey. But I based that judgement on day time only. I then realized that by night, Paris and its people are a whole different beast. The city paradoxically becomes quieter but more alive. The show starts with an unecological but beautiful set of lights illuminating those Haussmanian buildings and other monuments, while the inhabitant’s souls seem to be regaining possession of their bodies.[1]</a> With their stressful work behind, Parisians go out to enjoy the innumerable local bands, restaurants and bars available to them. The choice of food is large and potentially good but expensive.[2]</a> Even the simplest cocktail can get sometimes ridiculously expensive but it doesn’t matter anymore. Life is good again. A trip in the city with the Velib’—the self–service bike system— finished to convince me of that chilled and magical ambiance of Paris by night. Such a pleasure for the eyes. Toronto</h2> I knew that Paris wouldn’t be cold enough to my liking so I thought Why not visiting a friend in Toronto and see a bit of Canada for the first time?</q> Having never experienced negative temperatures before, I wasn’t sure if neither my gear nor my body would pass the test. But it didn’t go toooo bad. With my layered approach—long sleeve merino base layer, merino t–shirt, merino long sleeve light vest, ultralight down feather jacket, and Gore–Tex hard shell jacket!—, I’ve proudly managed to survive to a temperature of -10°C that apparently felt like -16°C with the extra wind. Of course my merino underwear also helped. But still, it was freezing cold. So cold that we had to adopt a walk’n’hide strategy. We regularly interrupted our outdoors walks to find refuge in shops or public transports to allow us to unfreeze and build a bit of heat before stepping back outside again. And it wasn’t even winter at its best. Temperatures aside, in the short 4 days that I’ve spent there, I found the city to be heartwarming. Maybe is it partly due to the Poutine dishes burrowed from their neighbors in Quebec, but mostly everyone seemed to be kind and friendly. OK, being a fan of healthy cuisine from the entire world, I had quite some difficulties with the Poutine but I loved the markets there—bonus points here because they sell French cheese!—and the different communities having each their own suburb as the always present Chinatown swarming with Vietnamese, Japanese and other dim sum places. Yum. Not sure if I’ll ever be able to live again in a city without good Asian restaurants. My only disappointment after having been teased with it for days by my local friend is to not have found any place selling the famous beaver tails—not the actual tail of beavers but their pastry equivalent, a specialty around here. We tried hard though! We even went as far as to the Niagara Falls only to find out that the shop was closed. Another thing that I kept hearing was to come back in summer for a better experience of the city. I can only be looking forward to do so! San Francisco</h2> Don’t tell the customs but my main goal was to gear up a bit in electronics for the needs of my trip. I had to leave my film cameras back home and opt for a more portable solution, which is why I picked a Fuji X100S. I never had the chance to try one before so I solely had to trust the online reviews and cross my fingers. But San Francisco was also a chance to visit another city in the USA. After having been not really pleased with both Honolulu and Los Angeles, I was told that SF could leave me with a better impression. And this time, I indeed wouldn’t be disappointed. Instead of the ridiculous Muscle Beach and other never ending boulevards lacking of any interest, I found myself walking in streets that had a nice vibe to them, packed with tons of cool little places to eat, and went through suburbs that each had their own identity. I happily went on to climb all these famous roller coaster streets. Fortunately I enjoy walking uphill because I realized that a simple map is not enough in SF to deduce the most optimized route. It’s in those situations that having a good knowledge of Grand Theft Auto</cite> can become handy. I’ve been impressed by how much the nearby Silicon Valley had an impact on the number of entrepreneurs trying their luck with various projects. Or maybe is it the other way around? What’s sure is that either in the train or in coffee shops, many had their laptop open and were discussing about their startup, their ideas, the designs they were working on, or the softwares they were developing. That’s a lot of creativity going on within that tech–savvy bubble. No wonder why the few managing to emerge out of that fierce competition end up ruling over the world. On the other side were the ones wandering in the streets and calling them “home”. They were far from being only a few, it actually seemed more like an entire and vast community living in a parallel world where any interaction between both worlds were rare. A truly saddening sight. As of Now...</h2> I’ve just arrived in Antigua, Guatemala. I’ve got a cold and a sprained ankle. Footnotes</h2>By night, even the Eiffel Tower looks nice.↩</a></li> Being renowned as a one of the countries with great food, it’s surprisingly much easier to find terrible and pricy restaurants than honest ones with good food.↩</a></li></ol></aside>

Christopher Crouzet

NVIDIA’s Warp for Houdini

Example: Bouncing Ball</h2> This time, I wanted to try out a real</em> simulation. Something that builds up upon the values computed in the previous step. So, uh... a bouncing ball, anyone?</p> </video></span></span></p>

Closing Notes</h2> This HDA is quite experimental and has not</strong> been thoroughly tested, so use at your own risk!</p> Oh, and it’s Python 3 only, so you might need at least Houdini 19.</p>

Seamless and Collaborative Generation of Infinite Worlds

Optimizing Pixar’s USD Compile Time

Rexo: A Unit Testing Framework in C (Part 2)

Wadu: Again and Again

Forget About Anti-Cheats, Here's How You Do It

Bottlenecks</h2> In my opinion, there are two main areas that are preventing much improvement to the current situation: the detection process</strong> and offense handling</strong>.</p>

Zero: Dynamic Arrays

Houdini: Ray Tracer in VEX

Houdini: Wind Tunnel

Zero: A Bunch of Single-File Libraries for C/C++

New Look and a Brand New Static Site Generator

Hienoi: A 2D Particle Playground

Release All the Things!

myXKCD: Sensational Bullshit

Nested Initializer Lists for Multidimensional Arrays

m3ta: A Template Metaprogramming Library

myXKCD: Christmas

Flying Things: A Rigging Showreel

Modern Rigging Workflow: The Modular Approach

Following the Flow, Coding It All</h2> Each time that a concept is being isolated into a unit structure, a rig module, or a rig chunk, it really is the equivalent of creating a new function.</p>

Getting Started with OpenGL in C++

Why I’m Not Using the MEL and Python Command Layers of Maya

From Monkey Patching the Maya Python API to Gorilla and Bananas

A Taiwanese Monk at the Salar de Uyuni, Bolivia

myXKCD: CPU benchmark

ccRig: A Rig for Softimage Back from the Dead

Softimage Has Been Killed, the Future of CG Softwares Is Now in TD’s Hands

myXKCD: Painter TD

How I Got to Work in the Visual Effects Industry

How Not to Climb the Volcano Acatenango, Guatemala

Guatemala: A Journey Full of Journeys

San Pedro La Laguna</h2>

Bottlenecks</h2>
In my opinion, there are two main areas that are preventing much improvement to the current situation: the detection process</strong> and offense handling</strong>.</p>