Max Liani

About 3.5 years ago I did some experiment to improve the behavior of microfacet normals at glancing angles. Many surfaces become highly reflective even though having high roughness. Check the discussion in the thread. Here is my implementation reusing equations you already have:

Add Polygon second pass: "predictive snap points" and numerical input to finetune distance and direction of the current point position in respect to previous.

I need to revamp my modeling operators, especially those that require user interaction. Here is first attempt at the Add Polygon operator. It's a first pass; it needs some work, but I feel it's not a bad start.

Alright, I made some further improvements to the tree view, which now draws in constant time (in respect to the scene complexity). Here is a test with 16 million transform nodes viewable in the scroll area. Without screen recording, the whole app renders at 8kHz.

I had to create a flat cache for the line drawn and that lets me jump to the visible band of TreeNode lines I need. I still rely on the nested structure, so it isn't a flat list... but a few hops in the cache reconstruct the nesting context to initialize ImGui::TreePush/TreePop

I played a bit with the UX of interacting with the tree view. The common operations are selection and re-parent. I want to control both with the same gesture. So, if the drag&drop is mostly vertical -> reparent. If it widens to the side, it becomes marquee selection. Yes, no?

The typical implementation requires one to click-drag on empty space to start a selection marquee. Somehow that feels ok for a file explorer window, but I find it annoying and limiting in a scene hiearchy tree view.

I am not sure why I am doing this, but I optimized further the scene tree view as it was getting a bit slow and clunky to operate when I had many nodes expanded. It's not cheap, it's still the most expensive part of the program to draw.

That's a test with 1 million lines in the tree view, which is likely much more than one can reasonably expect to interact with. I am happy my take on multi selection works and feel zippy.

A long time ago in a galaxy far away (circa 2011) I came up with a distant rect light for my lighting crew. I can't remember how I did it, but I am trying to recreate it. Here is a test for the light sample distribution in the hemispherical domain.

It's not a uniform distribution. Well, it is relatively uniform if at least one of the angles is small. It creates 4 singularities when both angles approach π. But that is outside the intended use because there are easier ways to cover the entire hemisphere :D Here is the result in render.

After how many years? I added code for distant area lights. Some call it "directional". The control "scale compensation" is meant to preserve the light power (radiant flux), so as the emissive area increases, the intensity decreases.

What are distant lights good for? Not for the sun, you get much better result with a HDR map. They are good for fill, rim, modeling lights, especially when the characters move around in the sequence and you need to maintain shot-to-shot consistency.

DLSS in workbench. The quality of 1spp rendering is way higher compared to the other built-in denoisers, and for half the cost. The comparison changes at higher spps.

Last weekend I refined the scene tree view in Workbench. I used the drag & drop support in dear imgui to implement DAG reordering and reparenting, plus renaming. Custom behavior and drop region draw to show where the node would be inserted, and display where and why it cannot.

100,000 fuzz iterations. I'd say this part of the system works :)