Max Liani

🙏 I am doing better, thank you. My energy envelope is still tight, so I take it easy and rebuild.

Reading your post, if I didn’t know about the subject I may have thought that stratified samples cannot be progressive on their own, while there are stratified samples sequences that already have those properties and more (I.e. pmj02).
The main part of the post is cool nonetheless.

That will break any stratification and the intersection of the 1d and 2d samples will result in white noise.

In general I tend to stay clear about using 1d samples. Nowadays lots of things are evaluated stochastically. Using a 1d sequence to sample something that will sample over some other dimension (i.e. use a 1d sequence to pick a light to sample, than use a 2d sequence to sample the light area),

Most stratified sample sequences are “toroidal” in nature, but some may have some constraint about what is optimal, for example some work best if the starting point is at increments of 4…

Stratified sampling can make a set or a sequence. A set requires all samples to deliver the desired quality, while sequences deliver a progressively good result, similarly to your golden ratio test.
Maybe I missed it, as I am surprised you don’t write about the difference between set and sequences.

The way I understand that is that Lin’s paper introduces a fast GPU builder for the light tree… but I may be wrong.
My current implementation is a simpler and less capable version of that where I mostly figured out from first principles the math to compute the correct PDFs for MIS with brdf sampling

First rather naive implementation of Stochastic Light Cuts. Here comparing uniform sampling vs SLC with 1spp over 16,000 lights.

Thank you so much! I am getting there.

It’s been a long break away from my projects. Work deadlines + sickness + low energy slow recovery…
I think I’ll try to make some progress on light transport, at least for a bit. Workbench doesn’t handle many lights (not gracefully at least).

This is really cool, I like the frame composition too.

I see first public mentions of some of the advanced techniques I implemented while I was there. Like quantized quaternions for OBB ray traversal, variable bit rate encoding, deduplication, among other stuff.

How did you manage to keep the browser open for that long without running out of memory?

Histogram Stratification for Spatio-Temporal Reservoir Sampling

Corentin Salaün, Martin Bálint, Laurent Belcour, Eric Heitz, Gurprit Singh and Karol Myszkowski

(Max Planck Institute for Informatics, Germany & Intel, France)

iribis.github.io/publication/...

So, highlights have to be faked to show consistent positioning between left and right eye, and not break the illusion.

That said, often in animation the eyes are so big that their placement is faked. I mean they are pointing outwards, and the position of the iris between the eyelids makes it look the eyes are parallel, instead of divergent. This gives problems because the highlights would be at different places.

Back when I was in lighting, eyes were heavily treated in comp, to get the look right.
With modern lights (I mean PBR) it’s probably not needed to fake the highlight. One can use a small emitter, not bright enough to affect much the character illumination, but enough to produce a highlight.

I wrote an allocator which sub-allocates from large pages, the “problem” is that the allocated dedicated blocks for large allocation that exceeds the page size and it returns all those fields no matter what.
This is a straight port. I need to implement something better.

I really, really, really dislike year-based software version numbers.

Same, it doesn’t seem to affect anything negatively, so I just leave the transitions there for future reference.

Thanks. The file import section of the programs is the the most neglected… so I can’t easily load much. The modeling system is also too primordial to make anything, one day I’ll need to make a call on what to do about that.

Interesting. The takeaway I got was to not ignore transitions, even though most of them may be no-op in my case.

I sort of do this with everything that is geometry data and xforms, with my own allocator that predates the porting. But I'll have to find a better way to do that, because I allow the allocator to service blocks larger than its own pages, allocating dedicated buffers...

while in beefy desktop GPUs it is more of a sanity check, to make sure you understand when you are reading or writing to frame buffers. But if I am mistaken if likely that I don't understand well enough.

The Vk-CUDA interop was the most nebulous and lest documented... it's the only part I had to debug memory leaks. I'd say the second bit was image layout transitions, which still feel weird. As far as I understand, it is a much more important thing in low-power devices, where packing may change.

Thank you. Just to clarify, the raster renderer is the gray shaded version I toggle to in the renderer, the colored, lit images is the path tracer.

I initialize 1.3, but by no mean I am using all of it. I use some minimal dynamic rendering features, like viewport, scissor, primitive topology, depth test enable, and line width. On two of the pipelines, I have a push constant... but that's it.

The Vulkan porting is complete 🎉 The last missing piece was the primordial raster renderer, which I am not sure why I keep around :)
All in all, it wasn't nearly as hard as I thought it would be.

I would need lines, thick lines, points (a few px wide), and triangles. Some degree transparency blending, but not strictly in depth order. Basically, all stuff you expect geometry to be augmented with when modeling.
I believe I’ll get there, it wouldn’t have to be crazy efficient.

I don’t know that. But sharing a texture is the main way you draw an image produced somehow in CUDA.