[RELEASED] AutoProbe - light probe generator and optimizer

Hi! Sorry, I somehow only found your post just now (lots of notifications - best to write me a PM).
Anyway, just added added the function you asked for yesterday, should be in the next Store release: https://github.com/guycalledfrank/b...706#diff-cf9f12906789f98ade01efc4837b6d15R835
You should be able to just call RenderLightProbesButton() and then wait for bakeInProgress to become false.
This script also demonstrates its: https://geom.io/bakery/wiki/index.php?title=Community_extensions#Batch_scene_baker

 

Hello there, been using this product for awhile but just tried using it in 2019.3 with HDRP and I got this error when trying to bake the probes and not sure how to work around it.

Computing lightmaps from script is not available in iterative mode. Please change Lightmapping.giWorkflowMode to GIWorkflowMode.OnDemand.
UnityEditor.Lightmapping:BakeAsync()
ReachableGames.AutoProbe.AutoProbeGUI:OnInspectorGUI() (at Assets/Middleware/ReachableGames/AutoProbe/AutoProbeGUI.cs:311)
UnityEngine.GUIUtilityProcessEvent(Int32, IntPtr)

 

@mostlyhuman Sorry, I just saw this. It's not an error, really, it's informational.

If you are in iterative mode, it should be rebaking the light probes for you continuously already--which you probably don't want. The warning from Unity is telling you that if you try to bake light probes, it won't do anything, because in iterative mode it's already baking anytime things change.

AutoProbe does NOT set this property for you, because it's not for me to say whether you want to click the buttons on the Inspector or if you want Unity to regenerate lighting for you continuously. That's up to you to decide. All I could really do is gray out the button when it's in the wrong mode and have a tooltip that says why it's grayed out.... which I should do.

 

Many thanks! I'll update my asset as soon as possible.

 

Hey everyone!

I finally found time (who knew you could be so busy while sheltering in place?) to update AutoProbe to automatically detect Bakery and switch to use Bakery functions according to a build flag (Thanks @guycalledfrank for adding BAKERY_INCLUDED!). So now AutoProbe/Bakery integration is seamless. Look for version 2.2 coming at you soon from the Asset Store team.

Also, thanks to all the folks who participated in the sale over the last two weeks. I hope you get some real value out of the assets you picked up for half price, and if AutoProbe was one of them, look out for the update.

Thanks!

 

I'm having some problems with AutoProbe adding light probes inside geometry, my understanding at least is that the LayerMask setting is supposed to be used to stop this?

 

Hi. First of all, thanks for buying AutoProbe.

The next thing you should check is to make sure that your geometry actually has a collider on it, that the collider is active in the scene and not disabled, and that the layer mask that you have set up for auto probe includes the layer that collider is on. If you are getting probes inside the collision for that object still, you'll have to describe to me what kind of colliders it has. if it is a mesh collider it's possible there are gaps or errors in the way that Ray casts get inside of that object, as mesh colliders are not always watertight That is to be expected. You definitely should not get inside of spheres or capsules cylinders boxes etc.

Send me more details at support@reachablegames.com and I can help you further..

Thanks,
JH

 

Sorry I kind of forgot about my post, I'll email you some details. Otherwise AutoProbe has always worked great for me.

 

I am trying to use your plugin and see if it is feasible for our project. However when creating a quick demo scene myself with two meshes I noticed that the probes on the angled mesh surface can sometimes be black, see:



This of course will create unnecessary artifacts. What can be done against this?

 

Also I noticed that probes within geometry do not get deleted making this tool hard to use in actual game scenes. Is this something that can be added?

 

I've put a fair amount of effort into keeping probes from going inside objects. It works much better if you use the Grid method than Spray, to be honest, due to the way those methods do raycasts, but last I checked, I didn't see this happening anymore against primitives. Against mesh colliders, it's a different story, since they aren't guaranteed to be closed manifolds.

As for deleting probes inside objects, that's a feature I have been wanting to do for a while. Again, with mesh colliders there is no absolutely right way to do it. A cleanup pass for inside/outside detection for probes is a very slow operation if done by raycasts, because you have to do one raycast per object whose bounds overlaps each probe and count how many collisions there are for that ray and if it's an odd number, it's inside and if it's even, it's outside.

There are hacky ways that could be done and probably much faster, such as looking for completely black probes that are directly adjacent to non-black probes within a distance, and delete the black probes. That'd probably work 99% of the time, but occasionally would introduce artifacts in dark corners where your walls are thin. Everything comes at a cost.

In the meantime, try Grid placement. Besides being faster, it is simpler code and more likely to not penetrate objects.

 

Hey, I'm using the plugin, and it seems that for some reason, autoprobe doesn't wanna work.

Probe algorithm is set to Grid, Layer mask: Everything, default settings for everything else.
Tried redoing it twice already, no results whatsoever (Screenshot_1 shows how the game looks at runtime, no bounce lights whatsoever).
Unity version 2020.1.8f1

Am I doing something wrong?

 

First, thanks for buying my asset. I appreciate it.

Second, I strongly strongly suggest you follow the instructions in the boring First Steps in the documentation. If you can't get that to work, let's talk.

Most people who have a hard time getting it to generate points jump straight to their (much more complicated) scene and spend a fair amount of time trying to sort through a lot of unrelated settings without first understanding the asset controls.

Check the docs--they are pretty good! If you're beyond that point already, you probably haven't configured the bounding volumes. Which is literally the first step.

Best regards,
JH

 

Thank you JH for your quick reply, I did as you asked, and comparing the results of the two projects, I discovered the probes are indeed working, however the bounce lights are so weak, that they are unoticeable, is the any setting I can tweak to make the probe lights / bounce lights brighter on my project?

 

Cool! You can try using Indirect Multiplier on your lights to increase how much impact they have. Alternatively, you can check that your lightmaps are being lit strongly enough, since that's where the actual probe data comes from.

 

@Zylex Is there a chance you can tell me what your configuration was when you tried the tilted cube? I spent a whole day trying to reproduce the black light probes you mentioned, but could not get a probe to get inside geometry at all.

On the plus side, I added a completely new feature (not yet released) that exhaustively rejects all light probes that have managed somehow to get inside geometry. If this is of importance to you, I can give it to you. Strangely, though, I generated about 2 million probes and didn't have any stray probes. But when I manually put a few inside geometry, this feature worked and removed them.

Soon, I plan to update the videos and make it easier for people to see how things work!

 

I'm afraid I do not have that scene anymore but it was a pretty basic setup if I recall correctly with barely any change of values. The update sounds good, once it is out I will have a look at it again and come back to you on it.

 

Ah, I think I figured it out. The reason none of my scenes showed the problem and yours did is because it depends on the center of the enclosing volume accidentally being inside a collider. Raycasts don't show up as being inside something. When first seeding the volumes, I have to pick some points to grow from, and I pick the centers of the enclosing volumes. It looked like your scene was just a cube and a plane, and by default are pretty centered. So you're likely to have stumbled upon that bug. Does that sound about right?

I'll clean up my code and test it a little more, then push a new version soon.

Thanks!

 

That sounds about right yeah! Glad you found it out and I look forward to the update.

 

Had some time looking in to AutoProbe again but it still seems probes can be placed inside collision. Perhaps it can still happen with mesh colliders? You can see the issues clearly here:

https://gyazo.com/2f9955b23c0c7cb1da5b2661aa0422a0

Could something be done against this?

 

I assume you updated to the latest version before testing? Would you mind sending me that in a dropbox or Google drive? That way I can debug with the settings you have and the colliders you are using. Thanks!

 

I'm currently optimizing my game. One of the things I'm doing is replacing meshColliders with primitives where I can. When I do and try to regenerate light probes, I get the below errors.

If I put the mesh collider back on the mesh, it works again. This seems like it may be some kind of caching issue.

MissingReferenceException: The object of type 'MeshCollider' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
UnityEngine.Collider.ClosestPoint (UnityEngine.Vector3 position) <0x180facc0 + 0x00072> in <f01fe9cc07274016b511aaf01d219ea0>:0
ReachableGames.AutoProbe.AutoProbe.IsInsideCollider (UnityEngine.Vector3 newPos) (at Assets/ReachableGames/AutoProbe/AutoProbe.cs:868)
ReachableGames.AutoProbe.AutoProbe.GenerateProbes () (at Assets/ReachableGames/AutoProbe/AutoProbe.cs:231)
UnityEngine.Debug:LogException(Exception)
ReachableGames.AutoProbe.AutoProbe:GenerateProbes() (at Assets/ReachableGames/AutoProbe/AutoProbe.cs:266)
ReachableGames.AutoProbe.AutoProbeGUI:<OnInspectorGUI>b__35_1() (at Assets/ReachableGames/AutoProbe/AutoProbeGUI.cs:276)
UnityEditor.EditorApplication:Internal_CallDelayFunctions() (at C:/buildslave/unity/build/Editor/Mono/EditorApplication.cs:209)



MissingComponentException: There is no 'LightProbeGroup' attached to the "AutoProbe-LargeRoom" game object, but a script is trying to access it.
You probably need to add a LightProbeGroup to the game object "AutoProbe-LargeRoom". Or your script needs to check if the component is attached before using it.
ReachableGames.AutoProbe.AutoProbeGUI.<OnInspectorGUI>b__35_1 () (at Assets/ReachableGames/AutoProbe/AutoProbeGUI.cs:277)
UnityEditor.EditorApplication.Internal_CallDelayFunctions () (at C:/buildslave/unity/build/Editor/Mono/EditorApplication.cs:209)

 

Yes, you're absolutely right. Sorry about that, I missed clearing a hashset of colliders during the GenerateProbes() operation. If you are willing to add the following to AutoProbe.cs at line 777 just inside FindAllStaticColliders(), it will allow you to add and remove colliders at will:

allBlockingColliders.Clear();

I'll get a proper fix out soon. I also have been working on a way to properly handle mesh colliders correctly, so that light probes won't get stuck inside any geometry. The work is only partly done, but should come together quickly.

Thanks for the bug report!

 

No problem. I’ll update the code on my end, thanks for letting me know of an immediate solution.

 

Hi everyone! Version 2.6 just dropped! I'm super excited about this one, because I received a bug report yesterday that actually contained a scene I could dig into and fix the occasional black light probe issue that has been lingering for so long. Tech details at the bottom, if you're interested.

New Feature: AutoProbe lets you set one or more initial starting positions for where it generates probe sets from. All you have to do is create an AutoProbe object, scale the disabled collider to set the volume, then reposition the starting point into some open air space, then click Generate. No more guesswork on my part with placing probes inside meshes by accident. Of course, if you liked the old behavior, just delete the starting points and it does what you're used to.

So, go grab the latest version and give it a whirl! Thanks and best of luck on your projects!

JH
---
Tech details: I am now using SphereCast rather than Raycast. I used to Raycast to a collider then back off a bit according to the collision normal, but sometimes it would back off really close to another collider. That light probe point has to be transformed by a couple of matrices, and would lose precision just enough that it would be 'inside' that other collider and not get lit by the lighting system. Now, the ray is just a slightly thick ray (spherecast) and will hit the other collider and stop there. That was enough to fix all the cases I have been able to identify.

 

Hi importing this for the first time into a new project with 2021 I get this error.

Assets\ReachableGames\AutoProbe\AutoProbeGUI.cs(133,6): error CS0103: The name 'ftRenderLightmap' does not exist in the current context

I don't have Bakery installed. I've ended up commenting out the code as a work-around for the moment.

 

Hi @pinkwerks I don't know what to tell you... that line of code is inside a `#if BAKERY_INCLUDED` so you're compiling as if Bakery is included. If it's not installed, you might want to check here and remove that setting: Edit->ProjectSettings->Player->OtherSettings and uncer the bold `Configuration` heading look at the `Scripting Define Symbols` to see what is being fed into the C# compiler. Most likely you will find BAKERY_INCLUDED in there. AutoProbe uses that to change the interface, and won't work right if the symbol is declared but the code is missing.

Best regards,
JH

 

Hi,
I am using AutoProbe 2.7 on Unity 2021 LTS (2021.3.5f) with URP and GPU progressive light mapper to cover a terrain with lightprobes. But I am getting a lot of "Invalid Cells".

So I tried the testSceneExterior with a clean project using the buildInRender pipeline and Enlighten light mapper (Without toughing anything). And this still results in "Invalid Cells" (See screenshot).
This is the result of the default scene + quickstart steps:

Code (CSharp):

1. 6. Click the buttons on AutoProbe in this sequence:
2. a. Delete Probes
3. b. Generate Probes
4. c. Bake Lightmaps
5. d. Render Probes
6. e. Optimize Scene Probes
7. f. Render Probes
8. (this second bake of the probes rewrites the reduced lighting set for the runtime to use)

Looking around on the forums there is not much info about what to do about this situation. The tetrahedrons are too flat maybe...

Is there a way to prevent these 'errors'? Is there a way to correct these 'errors' afterwards?

Thanks

 

Hi Arnold,

If you look, you can skip the optimization step entirely and just visualize what Unity thinks is "invalid", and there will be some extreme tetrahedrons around the edges that are really long and thin. From what I can tell, this is just its way of complaining that the volume is very small compared to the distance between the points. Likely any object going through that tetrahedron will have problems with flickering, as is mentioned in the documentation... long thin tetras are going to come-and-go quickly as objects pass through them. I don't think there's much that can be done about it, honestly. Unity's tetrahedralizer must generate tetrahedrons between all points until a complete convex hull is generated, and as long as the invalid cells are around the exterior, it should not matter since you won't encounter it. If they are in the middle, that'd be more of a cause for concern. You could always increase the budget for points, but if AutoProbe optimizes out interior points, it's because they do not contribute to the lighting equation in a meaningful way. It's not clear to me that marking something as an "invalid cell" is terribly useful, since there isn't much to be done about it except add more light probes to break up the long thin tetrahedrons, but if they are all around the outside, you don't care about them anyway.

From @rasmusn in another thread:
"
When exactly are lightprobe cells considered to be invalid?
Based on my understanding of the Unity source code, a tetrahedron (i.e. "a 4 probe pyramid") is invalid if its volume is very small (approximately less 0.001). This situation can happen if some or all of the involved probes are really close together. Again, this is very much related to the inaccurate nature of small numbers represented with floating point. For example, imagine you are calculating the volume of the tetrahedron spanned by the 4 nearby probes. This involves mathematical computation (multiplication, addition, etc.). Since all these operations become more and more inaccurate for smaller and smaller numbers, that means there must be a given threshold below which the calculation is so inaccurate that it is no longer meaningful. Therefore we must have a limit like this (as long as we are using floating point representation at least).
"

Hope that helps?
JH

 

Thanks for the info. I have not had visual issues during gameplay with the probes, so I guess the red lines just made me overreact. First time using probes, so its all a bit new.

 

I've spent all morning trying to get this generated quicker - it's a scene with a few objects and terrain added to Mesh Generators. I could have nothing added and it's still trying to raymarch between 3 million to 4 million, and takes at least half an hour to process before I have to cancel it.
Optimising Scene Probes is just not happening, as it hangs on 'moving to world space' for at least half an hour.






I can't seem to get this working quick enough to deem it usable over just doing light probes myself.

 

It takes a few seconds to create probes for a small scene, and the same to optimize. I strongly recommend you follow the tutorial after opening the test scene and seeing how it works.

AutoProbe needs to know the density of probes you need, and the bounds in which they should be generated. You gave me no snapshot of your settings or config, only the progress bar (not very easy to help you that way).

 

Hi, we have the Bakery installed but, for quick testing we use the Unity lightmapper.
Auto probes automatically triggers the Bakery instead of Unitys.
Is there a way to control which lightmapper autoprobe triggers?

 

Hi ToastyJ,

AutoProbe is built to auto detect Bakery and the inspector changes slightly to call Bakery functions when iits found. The simplest way is to temporarily uninstall Bakery, but if that's too disruptive, the one thing you can do is go into the project settings to where the compiler definitions are listed and take out the ones that say BAKERY. Just remember to put them back when you're done, or Bakery integration won't work.

Good luck!

 

Ok good to know, thanks!

Does AutoProbe work with the Built-in Pipeline?

 

Yes, it was developed when there was only the built-in pipeline. Although, it's not graphics pipeline specific at all. It should work equally well in URP and HDRP.

 

The asset store link in the first post doesn't lead me to any asset store page just the home. Is AutoProbe the same as Automatic Light Probe Generator https://assetstore.unity.com/packages/tools/integration/automatic-light-probe-generator-156690 ?

 

Several months ago I stopped selling assets on the store. It has not been worth the effort to maintain for me.