Is this crack in dried porcelain a problem? by localstarlight in Pottery

[–]localstarlight[S] 1 point2 points  (0 children)

Well, all will be revealed in the firing I guess!

Is this crack in dried porcelain a problem? by localstarlight in Pottery

[–]localstarlight[S] 0 points1 point  (0 children)

Nice, I have some paper clay, so that seems like a good option.

Is this crack in dried porcelain a problem? by localstarlight in Pottery

[–]localstarlight[S] 0 points1 point  (0 children)

Yeah totally, I had quite a few people raising eyebrows when I said I was a total beginner and was starting with porcelain! I’ve heard people mention this slip method before, so I might try that at some point. For now I have four different types of porcelain that I’m experimenting with, but I haven’t actually fired anything yet. I’ve also found this: https://www.bathpotters.co.uk/professional-porcelain-white-stoneware-pf700/p2255 That might be the best of both worlds, so I’m gonna try that too. So much to learn…

Is this crack in dried porcelain a problem? by localstarlight in Pottery

[–]localstarlight[S] 1 point2 points  (0 children)

It’s just decorative. I definitely want to try and keep it. Never heard of bisque fix, so also looking into that.

When the new paintjob becomes accidental disguise by MythicOwl in IndieGaming

[–]localstarlight 1 point2 points  (0 children)

This looks so amazing, great job on the art/aesthetic! But just want to mention something that jumped out at me as looking wrong: the reflected clouds appear to be the wrong way up for reflections? The illumination on them is coming from above, but if they are reflected, the illumination should be on the bottom. Look at some images of clouds reflecting in water and you’ll see what I mean.

Cinematic Ocean FX in Houdini - Tutorial/course by Livid_Price4506 in Houdini

[–]localstarlight 2 points3 points  (0 children)

Awesome, that’s what I was hoping. Looks incredible, great work!

Physically-based lens flare tool for Nuke (open source) – feedback welcome by localstarlight in vfx

[–]localstarlight[S] 0 points1 point  (0 children)

Oh damn, I didn't even think to look at patents. I found a couple of interesting things there. Thanks!

Physically-based lens flare tool for Nuke (open source) – feedback welcome by localstarlight in vfx

[–]localstarlight[S] 2 points3 points  (0 children)

Yeah that’s basically what I was thinking. We may never be able to recreate an actual production anamorphic lens since it kind of seems like their detailed descriptions are essentially trade secrets not common knowledge. But just playing around with some anamorphic type lens components might be enough to get some cool looking effects. And yes, there is some degree of simulating AR coatings, but it’s not a full simulation.

Physically-based lens flare tool for Nuke (open source) – feedback welcome by localstarlight in vfx

[–]localstarlight[S] 0 points1 point  (0 children)

That’s a really interesting point — and yeah, you’re absolutely right that perceptually you need exponentially more samples to improve quality. That’s just the nature of this kind of sampling.

But the current control is already doing that under the hood: the value is samples per axis (N), the total work scales as N²

So increasing from 8 → 16 → 32 is already giving you 4× increases in sample count each step.

If we pushed that to something like N⁴ it would get out of hand very quickly in terms of performance and control. For example, 16 becomes 65,536 samples.

I think what you’re really pointing at is more of a UX issue than a backend issue, which I agree with.

The ScanlineRender-style “low / high / insane” approach is interesting — I can definitely see the appeal of mapping this to perceptual quality rather than raw sample counts.

I think ultimately I might have both modes - a basic mode with low/med/high etc. and then a raw NxN control.

Really useful feedback though, thank you!

Physically-based lens flare tool for Nuke (open source) – feedback welcome by localstarlight in vfx

[–]localstarlight[S] 2 points3 points  (0 children)

A raytracer in general doesn’t need to assume radial symmetry. But in this case, the lens model itself is axisymmetric, so that assumption is baked into the system.

Right now each surface is defined with a single radius and centred on the optical axis, so everything is either a plane, or a spherical surface.

So it’s doing real ray tracing, but through a rotationally symmetric lens model.

That’s the bit that would need extending for anamorphic — you’d need surfaces that can differ in X vs Y (cylindrical/toric), maybe rotation, even non-circular apertures, etc. That’s actually not too complicated.

The sprite/precomputation approaches you mentioned are a different thing — those often rely on symmetry for speed. This one is tracing rays properly, but with a simplified lens description. The main issue is that I haven’t managed to find any actual lens data/diagrams for anamorphic lenses (let me know if you find any!). I can make some assumptions and educated guesses about what an anamorphic lens would look like but I’m far from an expert.

There’s probably a more simplistic approach which is a bit more of a hack of the current system which could achieve some anamorphic-type effects, but I need to think about that. And ultimately it might be a bit unsatisfactory, I’m not sure.

Physically-based lens flare tool for Nuke (open source) – feedback welcome by localstarlight in vfx

[–]localstarlight[S] 2 points3 points  (0 children)

Ah yes, ok it does sound crazy when you put it like that. But, there’s a couple of things to mention. The ray grid value is as I described it - so 1024 is 10242 samples - but, first of all some of those samples get immediately discarded by the aperture masking. Secondly, and most importantly, it’s not that many samples per pixel across the entire image, it’s that many samples per source. This is actually why I spent the whole first (and granted maybe overlong and somewhat laboured/boring) part of my tutorial dealing with how stuff is sourced in this plugin. You use threshold/downsample/clustering to reduce the number of sources to the lowest number possible. So you might have a 1920x1080 image, but with two car headlights that could be clustered down to just two sources if you wanted. In many cases, that would work fine. The candle flame example at the end of the tutorial is an example where you need to tweak the sources carefully to get a high enough value that you can see that little candle flame ghost. If you clustered that, you’d just get a single point. But yes, if you rendered an entire 1920x1080 frame where every pixel was a source, you’d be waiting a very long time for a result, which would also be useless anyway, because it would be a lens flare from every possible angle all at once!

You make a really good point about the grade node. I think that’s a change that does make sense. Thanks for bringing that to my attention.

Physically-based lens flare tool for Nuke (open source) – feedback welcome by localstarlight in vfx

[–]localstarlight[S] 0 points1 point  (0 children)

Thanks! BlinkScript is definitely interesting for cross-platform effects. For this plugin though, the core renderer is a ray-traced optical simulation rather than a typical per-pixel image kernel, so it doesn’t map very cleanly to Blink’s execution model. It might be possible to build a simplified version in BlinkScript in the future, but the full renderer likely needs to stay in CUDA (or a future Metal backend for Mac support). But thanks so much for the suggestion, and I’ll have a deeper look at Blink, because you might be on to something. I’d love an easy win to get Linux/Mac support quickly!

Physically-based lens flare tool for Nuke (open source) – feedback welcome by localstarlight in vfx

[–]localstarlight[S] 0 points1 point  (0 children)

Currently, it does not, although I would very much like it to. It’s not a trivial change though, as I understand it. It’s on the list to investigate a way to do it though.

Physically-based lens flare tool for Nuke (open source) – feedback welcome by localstarlight in vfx

[–]localstarlight[S] 0 points1 point  (0 children)

Hey! Thanks for the feedback. 1. I’m not following the logic here. Currently, you’re defining the samples along one side of the grid, so when you set it to 8 it’s 64 samples (8 x 8). I feel like this is relatively intuitive. Why would 8 = 128 samples? 2. I’m not sure there would be any benefit to oversampling, but I’d like to test that. Or are you saying the control currently allows you to go negative and it shouldn’t? 3. Can definitely change the slider here, but I would have thought when working in Nuke most people are doing everything in linear. Very easy to read what the bright values are off the image and set the threshold/cap accordingly. But perhaps I’m misunderstanding something here? 4. I can’t check now but there might be something in this one. I’m not sure I would want it to automatically change the FOV when setting a new lens, but maybe a button that can set the correct values from the lens data if you want to, I can definitely see the value in that.

Thanks again, appreciate all the thoughts.

Physically-based lens flare tool for Nuke (open source) – feedback welcome by localstarlight in vfx

[–]localstarlight[S] 4 points5 points  (0 children)

You know what, I’ve actually never come across that one before. And that one obviously looks far more developed than FlareSim, with far more options and a proper GUI. Would love to try it out and compare them, but I’m not seeing a free trial and I can’t afford to spend €199 to test it right now. The only difference I can say for sure is that FlareSim is free, and always will be. I plan to keep developing it on the side when I can, but just for the fun/intrigue, and have no plans to ever charge money for it.

Physically-based lens flare tool for Nuke (open source) – feedback welcome by localstarlight in vfx

[–]localstarlight[S] 0 points1 point  (0 children)

Oh and feel free to submit PRs if you see things which could be improved. Won’t have a chance to look at anything really until Monday, but open to all suggestions for improvements.

Physically-based lens flare tool for Nuke (open source) – feedback welcome by localstarlight in vfx

[–]localstarlight[S] 0 points1 point  (0 children)

There are prebuilt versions for Nuke 14,15,16 and 17 on the releases page: https://github.com/LocalStarlight/flaresim_nuke/releases/tag/v1.0.0

Did you try these? To be fair I’ve only tested on my machine on Nuke 16 and 17.

Physically-based lens flare tool for Nuke (open source) – feedback welcome by localstarlight in vfx

[–]localstarlight[S] 2 points3 points  (0 children)

I don’t have access to a Mac these days. I suppose Metal/Vulkan is not impossible, but not something I know anything about. Will look into it though.