URP translucency + GI

[bold basin]

well, we also still want our game to work on weaker devices like switch, using HDRP may make this harder

I understand your idea about using lights, it's interesting as well (not too different from light probes really)

I didn't realize it was possible to modify lightprobes actually, I missed that somehow, but then we could do everything at runtime with light probes if we wanted:
render with custom light probes (not sure how it knows which probes to use though): https://docs.unity3d.com/ScriptReference/LightProbes.CalculateInterpolatedLightAndOcclusionProbes.html
modify light probe data: https://docs.unity3d.com/ScriptReference/LightProbes-bakedProbes.html

Of course that still requires to somehow compute the indirect lighting data at a given location which is the expensive part

[fervent rivet]

Interesting, I didn't think you could truly rebake probes at runtime

I assumed it required lightmapper's raycasting calculations which would be editor only, or at least very expensive

I know you can overwrite them with custom SHs, but moving them would require the Tetrahedralize method

[bold basin]

I don't know if it's possible to do a true rebake, I haven't found a function to recalculate the light probes based on the scene

so indeed I think the raycasting calculations are the part to fill in

[fervent rivet]

So what exactly does CalculateInterpolatedLightAndOcclusionProbes do

[bold basin]

it calculates interpolated light probe values for a given position

since the light probes are basically in a 3d grid, when you move an object through it you need to interpolate the probe values to avoid sudden changes in lighting

[fervent rivet]

Oh, a similar (or the same) process a mesh renderer uses to figure out its own ambient lighting between probes

First was confused why you would need to create another probe group from the first probe group

[bold basin]

did you try assets like Lumina GI ? Any idea if they can work with translucent objects?

or HTrace (well htrace is hdrp only)

[fervent rivet]

That one seems to do, at least in some way
https://youtu.be/mQb3KOv1PSk
The light spreads around behind the tapestries hit by light, but the looks are anywhere between acceptable and bizarre

Judging from videos HTrace is at least not demonstrating light transmission

[bold basin]

yeah that second image is a little odd, but I suppose that could be worked around
also not the worst rendering artifact to have in a game 🤷

[fervent rivet]

Well you can always have worse

[bold basin]

look at the bright side (pun intended)

[fervent rivet]

Unironically if you set the bar for graphical realism or accuracy low, most people will accept that and errors do not stand out

[bold basin]

to me the real-time GI stands out enough to make it acceptable, but it may depend on the game

also possible to make something more stylized of course

[fervent rivet]

It'd be the smart thing to do, if you want to save time and resources

Never worth it to make a perfect asset, because then every asset will have to also be or it'll look like a problem

[bold basin]

I meant something stylized with this kind of GI 🙂
but yes totally
still looking at ideas though

[fervent rivet]

Yeah, I don't know if you're going for photorealism to begin with
But the further you settle from it the easier and quicker it is to design the graphics

In general anyway
Stylization can ramp up the complexity of the workflow as well, a lot

[bold basin]

Yeah, we didn't really decide yet but I told my colleagues that something that approaches realisism is a real time sink

I am interested by HTrace, because from what I understand it's CPU-based, which makes it interesting because it doesn't eat up as much GPU resources

and if we have CPU time to spare, which is the case on PC at least.. why not

[fervent rivet]

If it works in the performance budget, it's no issue

In theory CPUs are orders of magnitude slower at graphics calculations like that than GPUs are though

Compatibility is the only advantage

[bold basin]

in my experience it depends on more factors, like the algorithm and whether you need the data on the CPU for other reasons

[fervent rivet]

Yeah, many different factors pop up in real world scenarios

[bold basin]

I don't think it's nice if the user needs an RTX 4070 to play the game at 60 fps

[fervent rivet]

True, as long as they don't require an equally beefy CPU instead

[bold basin]

yeah

[fervent rivet]

My pipe dream of realtime transmission GI is probably a sidetrack

It'd be a better use of my time to just develop a style / workflow that works without any accurate simulation at all

To be able to do more without having to worry so much about flaws

[bold basin]

GI is cool though, but we're so used to being faked by games on this front