[RELEASED] AutoProbe - light probe generator and optimizer

Update: Version 2.0 is out! Scroll to the end of the thread for details.

Hello Developers!

I'm pleased to announce that AutoProbe is ready to help you get high quality lighting onto your dynamic scene objects quickly an easily. The main features are:

• Automatically generates light probes that conform to your geometry, exploring every nook and cranny.
• You limit the space it explores by placing disabled colliders as children, using familiar tools, so your levels don't need to be water-tight or even have ceilings.
• Custom Inspector has a shortcut button to start and stop light bakes, so it's easy to rapidly iterate and check your work.

And most importantly, what no other similar package has:

• One click will optimize the light probes in a light probe group (even if it's been generated by hand or with a competing package), just add the AutoProbe component to the same object that has the LPG on it. This rigorously detects unnecessary probes and removes them, reducing your data set and removing flicker from dynamic objects indirect lighting. If you want to aapproach AAA quality, you will want this.

Asset: https://www.assetstore.unity3d.com/#!/content/105295

I'm happy to answer questions or add features that would make your day better.

Rock on, game developers!

JH

 

Hi, Im trying this on unity 2018.1-b13, is it supported? doesnt seem to do anything? For example delete probes doesnt remove them I see all the pink lines attaching them, I think they were hand placed by me, I want to see if I can optimise it with this tool.

Would also be cool if you made one for reflection probes, looks like nothing exists

 

I haven't tried it on 2018.1 yet, but will give it a try tomorrow and will send you an update if it's broken for some reason. The easiest way to try it out is load the test scene and click the buttons on the custom inspector provided, since the scene is already set up. One thing to note is Unity has a bug where modifying the light probe set does NOT refresh the pink lines, only the light probe points update. You have to click away and click back on it (I've mentioned it to them). So it might be working, but may look broken due to their debug visualization being a little buggy.

 

Yes, AutoProbe works fine in 2018.1.0b13. I submitted a fresh package for 2018.1.0b13 which will probably come out in a week or so, but nothing had to be changed.

The short answer is, Unity's inspector bug threw you off. You can simply click off the AutoProbe object in the Hierarchy tab, then click back and it will update the display. Sorry for the confusion!

 

Actually it isn't that seemingly, doing that doesn't update it. It's as if the buttons literally do nothing. No idea why though.

 

Sorry, that sounds pretty messed up. Would you be willing to connect on skype and do a screen share, so I can help you get it working? It might something simple. If so, send me an email with your skype id and we can sort it out tonight.

 

Sorry for the confusion. I think I know what's happening. If you just added AutoProbe to an object somewhere and start clicking the buttons, it will throw an assert into the error console telling you it needs some disabled colliders to constrain its raycasts growth. I'm updating the script today so it automatically creates a few for you. Just create a child node, add a box collider, disable the box collider, and size it however you want. Check out the test scene that came with it. It should work fine.

 

Thanks, will try it out and let you know.

 

If you grab the most recent update, it automatically does this work you now. There's also an instructional video to help explain how to use it.

 

Still not working unfortunately, I have noticed it does not create the collider object for me as it does for you in the video. If I make my own then the error goes away about not having one but still the buttons don't do anything. Could it be related to my existing probes, looks like I made a huge network of them at one point. Or maybe my level which is insanely large, already pushes unity to its limits really just trying to look around.

Edit: forgot to say im using real time lights and global illumination.

 

Sorry this has been so troublesome. The fact yours isn't making colliders makes me suspect you are using a previous version. Can you can check the readme.txt file and make sure it's v1.3? The video was published along with a new release. If you can grab the latest version, it should make the colliders for you when the component is added. So you might need to remove the component, and re-add it, perhaps. Also, have you tried opening the testScene.scene that comes in my package? It's very basic, but at least there you can see how all the knobs work so you know what to expect.

I really want to make this work for you. I'm also happy to jump on skype and watch what you're doing.

 

Readme says "
Thanks for your patronage!
Jason Hughes

Release 1.2:
* Added disabled colliders as spatial constraints for ray marching.
* Fixed issues with the custom inspector. It was throwing errors that came up in 2017.3."

I tried to get again but it says I have latest already. Thanks for the skype offer, I will take you up on that once I get a minute The test scene works good (just tried it). I copied the autoprobe obj from there into my scene and resized the cube and hit generate and its working now I think!.. Going to take a while but will let you know how I get on! Thanks!

"

 

Works until I hit optimise probes then unity dies, scene has around 50k probes.

Not sure if this is the exact stacktrace u need?


========== OUTPUTTING STACK TRACE ==================

0x0000000142AC3557 (Unity) memcpy
0x000000014189CD39 (Unity) Marshalling::ArrayOutMarshaller<Vector3__,Vector3__>::UnmarshalTempArray<Vector3f>
0x00000001422C08F1 (Unity) Lightmapping_CUSTOM_TetrahedralizeInternal
0x000000000DEE95AB (Mono JIT Code) (wrapper managed-to-native) UnityEditor.Lightmapping:TetrahedralizeInternal (UnityEngine.Vector3[],int[],UnityEngine.Vector3[])
0x000000000DEE9493 (Mono JIT Code) [C:\buildslave\unity\build\Editor\Mono\GI\Lightmapping.bindings.cs:302] UnityEditor.Lightmapping:Tetrahedralize (UnityEngine.Vector3[],int[]&,UnityEngine.Vector3[]&)
0x000000000DEE581D (Mono JIT Code) [Z:\GDV16\GD\Assets\ReachableGames\AutoProbe\AutoProbe.cs:175] ReachableGames.AutoProbe:OptimizeProbes ()
0x000000000DEE4FB1 (Mono JIT Code) [Z:\GDV16\GD\Assets\ReachableGames\AutoProbe\AutoProbeGUI.cs:63] AutoProbeGUI/<OnInspectorGUI>c__AnonStorey0:<>m__1 ()
0x00000000991E3CF3 (Mono JIT Code) [C:\buildslave\unity\build\Editor\Mono\EditorApplication.cs:200] UnityEditor.EditorApplication:Internal_CallDelayFunctions ()
0x000000000D9D11DE (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_void (object,intptr,intptr,intptr)
0x00007FFD4058668F (mono) [c:\buildslave\mono\build\mono\mini\mini.c:4937] mono_jit_runtime_invoke
0x00007FFD404D8A95 (mono) [c:\buildslave\mono\build\mono\metadata\object.c:2623] mono_runtime_invoke
0x0000000140BE5AC7 (Unity) CallStaticMonoMethod
0x0000000140BE584E (Unity) CallStaticMonoMethod
0x000000014142AC66 (Unity) Application::TickTimer
0x00000001415C80E5 (Unity) MainMessageLoop
0x00000001415CA468 (Unity) WinMain
0x00000001423F953A (Unity) __scrt_common_main_seh
0x00007FFD79081FE4 (KERNEL32) BaseThreadInitThunk
0x00007FFD7BC0F061 (ntdll) RtlUserThreadStart

========== END OF STACKTRACE ===========

 

Hmm. I haven't seen that before. I have run with 350k probes one time and it was fine, so there's something angry about something specific in your geometry, perhaps. Tetrahedralize is a Unity function, so if it's failing, it's because somehow garbage went in (or they have a bug). Can you send me your static scene geometry and autoprobe object? If you put it up on google drive or dropbox send send me an email (support@reachablegames.com) with the details, I will open it up tonight.

For what it's worth, if you are getting up to 50k probes, that's probably too many in a single go. There's no reason you can't have multiple probe sets with different settings covering different parts of your scene, or start with higher probe distances to get a smaller initial probe set. You can always re-run with the probes you've found as starting points after tweaking settings, too.

 

My scene is too large to really send, unless there is a way to export the whole thing as an fbx or something (theres one big level mesh but its populated by any many more meshes, trees, buildings, npcs etc, which I assume may be causing the issues), the project is complex and about 200 gigs.I increased the auto probe settings dramatically (grid size 50, min collision 15) to reduce the number of probes. But optimise still crashed it. So not sure how to proceed for now.

 

Thinking about it, all I really need is the probe set. If you can save a scene with everything else deleted, just send that to me.

 

Will do thanks.

 

you should be able to grab the scene here https://www.dropbox.com/s/gwquz638fii0flz/autoprobescene.unity?dl=0

 

Hello Game Developers! A new version has been submitted with some pretty great performance improvements. The Unity QA folks are usually pretty quick on the turnaround, so expect it to land in a few days. The major advance is in the optimizer, which now runs about 4x faster than it already did. The probe generator also has a faster algorithm for rejecting points, which scales much better to really large scenes. And some tweaks to the UI to make it easier to understand how it works and what you're supposed to do. I hope you all enjoy it!

 

Welcome to version 1.6! I am really pleased to announce that I've just submitted a new version to the store and expect it'll be popping up in the next week or so. Lots of improvements went in over the last few months.

The biggest request was a way to generate probes near the ground level of meshes, so that's in there! It works for Terrain objects and ordinary MeshFilter objects (normal meshes). On Terrain, I use 10,000 samples at ground level and 10,000 more directly above at a user-specified height, so you get the high and low values. For meshes, I generate one probe per vertex and one at user-specified height above the vertex. Then, it fills in the remaining space with either Spray or Grid methods of raycasting, and automatically rejects any points that are too high or outside the overall scene constraint colliders.

Here's a better explanation:

I've also updated the tutorial scenes and have made it easier to navigate as well as understand what is baked and what is not. Check it out:

I also made the custom Inspector much easier to use, easier to see things, more tooltips, and a cleaner look.

Finally, there's another small new feature where you can throw a little script ForceLightProbeHere.cs that will place a small cluster of probes around an object that won't be removed by AutoProbe. This might be useful if you really want to ensure some probes exist at points in space if you're fully baking lights, for instance, so every light has a probe right on it. Or any other reason.

One unfortunate note is that Unity broke an important function in 2018.2, which the Optimizer needs to do its job. So, if you plan to use AutoProbe, make sure you can work in 2018.1.x or earlier until they get this sorted out.

I hope you all are enjoying the asset and it's making your lives easier. If not, let me know! I'm happy to hear your feedback.

Best regards,
JH

 

This is very neat. I see optimize is still broken in 2018.2.3. Thankfully, my scenes are simple and I don't need optimize quite yet. Hopefully Unity will deliver a fix soon.

 

I got excited when I saw 2018.2.4 was released. Sadly, this has not resolved the Optimize crash.

 

Small update: Yes, I checked 2018.2.4 the day it came out, and it's not fixed there. Unity QA has reached out to me and said specifically it is fixed in 2018.3, although it's not clear exactly in which version of 2018.2 the fix will arrive. Going forward, I hope to find time to build my own tetrahedralizer that runs a little faster than theirs and I can stop depending on their function entirely. As long as the quality is about the same, it'll be an improvement.

 

The response is appreciated. It's frustrating when something that you think is a core function, and should be QAed before release, is broken. My game stopped working entirely because 2018.2 broke triggers generated at runtime until it was finally fixed in 2018.2.3.

 

I'm working with the probe groups in an automated system and it would be useful if auto-probe could use the bounds constraints and the mesh constraints simultaneously. Right now, I just trim them after they are generated.

 

They kind of do, in the sense that the probes are initially spawned at two elevations on the mesh, then are expanded within the constraints. Do you think it's useful to also constrain the initial spawning to the bounding volumes? I figured constraining to the mesh was more restrictive and the bounding volumes were not generally going to be used in that case, say when terrain is being used. What is your use case like?

 

Mine is probably atypical and pretty easy to work around since I can just trim to the volume after they're generated. I have little vignette scenes where my characters are only moving on a very narrow plane in the foreground. Even though my terrain meshes are quite large, I really only need probes to be constrained to the foreground area.

I'll have better feedback once Unity fixes 2018.2 and I can use all the features. Ideally, I'd like to completely automate probe generation by automatically creating my bounds, detecting all the static meshes in it, generating probes so that they're not inside meshes or on the wrong side of the ground plane, and then optimizing. I'm trying to spare my artists some headache since there are hundreds of these vignettes in the game.

 

Well, I'm not against it. I was rushing to make sure I could get out 1.6 while I had time to work on it, and I realized it a little odd that the spawner doesn't obey the constraint volumes, personally, but getting the release out was more important. It would be easy to do, and feels like the right thing to do. Either the constraint volume should not matter at all when mesh spawning, or it should constrain the generation as well. It's more flexible to let you use the constraint volumes to do exactly what you want with them. So I'll do that. Just give me a little bit to find time to work on it again and push the change to the store. I'm pretty slammed at the moment. :-/

 

There is no hurry. I wrote my own spawner that suits my game's purposes. With 2018.3 in Beta, I'm looking forward to being able to use the optimization function eventually.

 

Yay! Great news! The new 2018.2.11f1 version of Unity has the fix for the Tetrahedralize function that AutoProbe needs to perform probe optimization. If you've been waiting for this, now you can update and expect it to work. Very sorry for the delay in getting full value out of AutoProbe, as I had no control over this, but I'm really happy it's fixed.

As always, let me know if you guys have feature requests or other needs.

Best,
JH

 

A new version is going to come out very soon. It's been a while, and I've had a few feature requests, so I took a few minutes to spruce things up a bit. Here's a rundown of what you can expect:

• Multi-select editing of AutoProbe objects.
• Better reporting of interesting data (new light probes generated, total removed via optimization, total probes remaining, elapsed time) on the optimize and generation runs, especially now that you can run several together in one click.
• A slight cleanup with the probe generation now takes constraint colliders AND mesh generators into consideration when creating light probes. So you can combine boxes with meshes and generate points only on or above the meshes, but only inside the colliders as well, in case you want to break up a large mesh (or level) into lots of separate rooms or zones.
• Correct multi-object Undo handling. This is surprisingly hard to get right in Unity.

I'm pretty excited to get this out to you all, so I can get back to work on my newest asset: I have a major undertaking in the works--a complete runtime light probe replacement system for Unity's that works with additive scene loading and can be independently lit and dynamically placed at runtime. Anybody interested in something like that?

Time to hammer out some more bits,
JH

 

Hi, when I optimize I always get 4 light probes.
even in testSceneInterior.
I am using unity 2018.3, is this the problem?

 

Hi Alejandro,

Once you generate probes, you must bake lighting before optimizing (that's why I put the button right there in the inspector). If you did that and ended up with only four probes, something new is broken in 2018.3 that I haven't seen. Did you bake lights first?

Thanks,
JH

 

Hello game developers!

I'm pleased to announce v1.8 of AutoProbe is up for existing customers to download, or new users to buy and save time and runtime memory with optimized light probe sets!

This version contains some small bug fixes for mathematical precision in Grid point generation mode, I did an optimization pass on the optimizer (I saw up to a 10% performance improvement, depending on the probe set), fixes for the Inspector in dark mode, and most importantly, brand new documentation. Which, by the way, if you want to check out the .PDF doc, it's hosted on the website so you can check out the asset pretty thoroughly before you buy it. It's all right here https://reachablegames.com/unity-assets-autoprobe/

Have a great one!

 

Hey, I'm not sure if what I'm about to ask is even possible, but can you execute this code at runtime to have the tool populate the scene with lightprobes after the game starts? I'm trying to do some procedural generated levels that I would like to have lightmaps baked from, but some items that will be placed in the levels to make them look more dynamic wont have lightmaps baked, so i was hoping after my level populates with level geometry i could launch a light probe tool to fill the scene with enough lightprobes that you cant tell some parts are not light mapped.

 

Two issues with this. First, which can be solved, is the tetrahedralizer function that I use is built into the Unity editor not the runtime...however I did read they were moving it to runtime in one of the newer versions, not certain which. So, if you were planning to use 2019+ then it's possible to generate new light probes. That said, the speed of generating new probes isn't a problem, but it does have to be done in main thread because it needs access to colliders and Physics raycasts. The optimization would take a lot longer though, and probably cause unavoidable hitching. In other words, part of AutoProbe might help you generate probes.

Second, is that you would necessarily need to merge all the probe sets from different areas yourself, as Unity only handles one probe set total and merges them on export, not runtime. This isn't impossible, but it does mean writing some code to grab all the points from everywhere currently loaded and tetrahedralizing the whole set. Not just spawning a few points and it just works.

A final word, which may or may not be a problem is that the probes would be completely empty until some dynamic light mapper generated new data for them. I honestly haven't played with that too much me have no idea if any of them will relight probes at runtime. If they do, you have a shot. If they don't, well.... Better to find out with a quick test before you charge down that route.

Hope this helps!

 

I should also mention that light probes will only affect dynamic objects, not static geo. If you are planning on using large models as dynamic objects (terrain, or large level chunks) that would span light probe tetrahedrons, you will want to look at using light probe proxy volumes, which essentially allow you to light a model with multiple probes. It will not look as good as lightmaps but should be softly lit.

 

Hi, I'm having issues with light probes and would happily pick up your asset if it will resolve my issue. I have no lights in the scene except an HDRI skybox and light probe values appear to be way off.

[I've posted details here: https://forum.unity.com/threads/light-probes-giving-unpredictable-results.759980/ ]

Does your asset simply deal with placing probes (which I think I've got handled) or will it also make other tweaks which might help me?

 

A lot of people find the placement mechanisms of AutoProbe to be handy/better/easier than other packages or by doing that work by hand. Looking at your other thread, it looks like you might have a method that you have written to do something you *think* is appropriate. The problem with explicit placement, and in general where AutoProbe shines, is you really can't be sure where a light probe ought to go unless you can visualize the lighting directly in space (which you really can't). Light has an exponential falloff, and light probes have a linear interpolation, so it's incredibly difficult for you (or a tool, even) to place probes at meaningful places.

This is why a dense mesh of probes tends to do better at capturing lighting data. However, the denser mesh of probes has dramatically increased memory/storage requirements, and also might be so dense that the lighting flickers if your objects are significantly larger than the probe tetrahedrons and lighting changes rapidly between probes. Flickering can also occur when you have very long, very thin tetrahedrons that are interpolating across long distances with high delta values (from black to very bright, or different colored lighting, etc).

AutoProbe's unique feature is it will take your dense mesh of light probes and discover the probes that are mathematically redundant and remove them. This brings down the total memory requirements for representing the lighting, but also helps you visualize where your lighting changes. Based on the lights you are trying to bake, you can take direct lighting and bake it in some areas, or take just indirect bounce lights in other areas, and AutoProbe will figure out where lighting is linear or non-linear automatically, and retain more points where it's non-linear. So in areas where the direct lights have a falloff, there'll be more probes and in indirect lighting where the contribution is softer and less extreme, there will be less probes.

Will it fix your problem? No way to tell for certain. But it could be very helpful in isolating where your lighting is too extreme and retain points where it needs them to help represent the lighting you do have.

Addressing your question in the other thread, baking your lighting should happen at relatively low detail until you're really sure it is doing what you want, then you re-bake with higher detail for a final pass. If the lights haven't changed, and your lightmap settings are the same, if the only change is light probes, the bake process should short circuit and jump straight to that step. Be aware that changing light probes does require a bake step for them to repopulate the LightingData.asset (where the actual lighting data lives, not in your scene), so anytime you modify your probe positions, remember to re-bake lighting. It should be very fast. If it's not, something is changing your lights or lightmaps.

Hope this helps,
JH

 

Does it support HDRP?

 

I don't know that HDRP light probes are different from any other ones. AutoProbe optimizes the positions of light probes in the editor based on the values in the spherical harmonics in the baked lighting. It should not matter what kind of render pipeline you use at runtime, unless somehow the data stored in probes changes. To my knowledge, they are all the same.

As I said, as far as I know, the answer is yes, it should.

Best,
JH

 

Version 1.9 is hot off the presses!

The new version includes:

• A bug with grid generation is now fixed that could cause waaay more points to be generated than desired
• Bakery integration, as has been requested by many users. I'll explain below what this means.
• New test scene with examples on how to use Bakery and AutoProbe
• Added display to the inspector that shows # of light probes selected and also the size of the runtime light probe data. This clarifies when the optimizer has been used correctly, and the runtime data gets smaller, not just the scene probe count (they aren't the same thing).
• Split "Bake Lightmaps" and "Bake Probes" into two different buttons, so you can run them independently. Light probes depend on lightmaps being baked, but you can generate them many times without re-lighting the scene. Plus, Bakery doesn't do both at once, so separate buttons for this make iteration easier.
• Updated screenshots/artwork

Bakery integration requires either uncommenting one #define in AutoBuilderGUI.cs code, or adding a symbol to the scripting definitions in the Player settings. Super easy. AutoProbe will detect that Bakery is installed for you and give you an alert that you should. What this does is change the Render Lightmaps button launches Bakery rather than Unity to do the lighting calculations, as similarly with the Render Lightprobes button.

The example scene tries hard to mimic the Unity light baking features. Fully baked light probes work flawlessly, where there are no shadows, and all the lighting is static but lights dynamic objects well. I ended up using Distance Shadowmaps to get mixed mode lightprobes working, where you get dynamic shadows, realtime lights winking on and off, and high quality indirect lighting in light probes only. Had some trouble getting lightmaps to bake with color on surfaces without also getting direct light in light probes, which is NOT how Unity works in Mixed mode. Typical Mixed workflow is that light probes only get indirect light, but Bakery's lightprobe generator seems to consider lights too (it probably shouldn't).

PS. @guycalledfrank If you wanted to make my integration cleaner, would you mind making a ftRenderLightmap.RenderLightprobes() function similar to ftRenderLightmap.RenderButton() ? I had to write some nasty reflection code to dig into private variables and manage the editor coroutines myself, which may break with any future Bakery release that changes it. Pretty please?

Hope everyone enjoys this release!
Best regards,
JH

 

Version 2.0 is here!

So many improvements, so little time to explain. Here's the rundown of what happened:

• Fixed a bug with probe generation checking the collider before checking ray cast collisions, so sometimes if you had tight bounds on floors or ceilings, the last light probe should have been on the floors or ceilings, but would be skipped. So that works, finally.
• Added CIE76 color metric function to check perceptual differences rather than straight RGB differences in SH colors. That means the optimizer will prefer to remove probes that don't matter, better.
• Changed the error tolerance system to be a Probe Budget rather than some random value you would have to tune. Now, you specify how many probes you want to stick around. Much more straightforward workflow, and much much faster optimization. (Remember, you can use Undo to quickly get the unoptimized probe set back, change the probe budget, and re-optimize really quickly, until you have what you want.)
• Improved the speed of probe generation dramatically. I was casting more rays from geometry collisions than necessary, and in fact, this was >50% of the time spent in some scenes, and rarely produced new probe points.
• Fixed probes going into geometry most of the time. It still can happen if you have interpenetrating geometry or almost-intersecting objects, but it's a lot less likely now. The fairly common completely-black light probes should be fairly rare now.
• Fixed probes digging through geometry and going into backsides of geometry.
• Fixed the documentation to reflect current UI and workflow.

Overall, a lot of work went into getting AutoProbe into a state where I think it's worthy of a 2.0 release. Enjoy! And please leave good reviews if you find it helps you make great games.

Best regards,
JH

 

i think you made a great asset, am thinking of buying it..

one of things i dislike in unity's Universal pipeline, is the lack of shadow mask.. the old way of showing real shadows near camera no longer possible on the new low-end pipelines.. unity wants us to use light probes around dark/shadow areas so dynamic objects/characters start going dark inside whenever a characters moves inside dark areas to give the illusion of receiving shadows.. but the issue it requires unbelievable amount of labor work..

you asset also reminded me of a nice talk years ago:

they managed to make GI effects using probes only.. in runtime as well.. it's too complex for me, but this video might be useful for you for future updates/ideas..

 

That's some clever work right there! He definitely did it the sneaky way, but got a nice result. I had planned at some point to build a full replacement for the light probe system in Unity that let you store probe groups with each prefab or game object (dynamically generated static set pieces, essentially, not dynamic moving objects), and just sample them at runtime as you move in and out of influences, and feed shaders the SH data manually rather than use Unity's light probe system at all. There are hooks to do this, but I haven't seen anyone try using it. Still would require a lighting pass to come up with SH values per light probe position, but this guy gives a reasonable algorithm for doing so. I'd planned on doing it at runtime over many frames, prioritizing the zone closest to the camera (much like the progressive lightmapper).

It's a lot of work to do, and not likely worth the time, so I set it aside. :-/ There's some great stuff early in this talk, though, and it gives me some ideas about improving AutoProbe. Thanks!

 

Hi, using Auto probe with Bakery, attempting to generate lightprobes for a large scene. Thank you for your asset.

A couple questions:

1. Is it possible to optimize probes before baking the probes? So Bake lightmaps > optimiize probes > bake probes. Even if it just removed probes which weren't near geometry. My reason for this is because to get the detail we want, we need tons of probes, but before optimization baking the probes takes way to long.

2. Upon restarting the project, committing changes on git, etc. all light probe data is lost. Not sure if this is Unity, Bakery, or an Auto probe issue. When the project is re opened all probes are completely black and I have to rebake the probes.

Thanks!

 

First off, thanks for buying AutoProbe. I appreciate it.

To your questions,
1) you can't optimize until the probes have been lit, otherwise they are all black and will optimize away entirely. However, you may find that your settings are not ideal for generating probes in your space. You can actually change the grid method (which is much faster to generate and will not place probes too close together, so it won't generate so many). If you need more resolution than that, you can also run multiple passes of the generator, first with very large spacing, then run again with finer spacing, which will start with the probes you generated in the first pass and continue from that point forward. It's an option, but most likely you'll be better off segmenting your probe data into separate regions where you need higher fidelity and lower fidelity... say very large outdoor areas and very detailed indoor areas. Split them into different AutoProbe objects and give them separate constraints, then give them appropriate configuration settings per area that match the detail they need.

2) Your light probes losing data sounds like a file is being thrown away that shouldn't be. I don't recall if Bakery stores the data in a different place than Unity's lighting solution, but they are definitely just stored in files. Normally it's in the LightingData.asset underneath the scene in a folder with the same name as the scene. Check to see if that folder is being ignored or deleted somehow. I know I've been able to retain light probe information across project close/opens.

Let me know if I can help further, and good luck!

 

hi, i've been trying the tool today and so far the tool is great!

i really appreciate the optimization function that reduce my probes from thousands to hundreds..
but am having a small issue with probes lighting/distribution.. see next screens.

the character gets too dark when he is close to the dark room doors in the structure..


this is the result of 100 budget probes in scene, but i increased it to 300 to see if it makes any difference, it didn't .. i also increase baking quality drastically for the scene.. the results improved a bit.. but still gets too dark (almost if character inside the dark room)..

this next two images shows generated vs optimized results..


i noticed that on generation, the tool algorithm prioritize that curvey terrain mesh area overly too much over the structure next it.. i can only think for one reason, is the tool distribute probes based on mesh vertices?
because the structure has very simple boxy shape (( large faces)).. am wondering whats the best resolution for this??.. i can in fact increase structure mesh density, but it's totally not needed in my project needs..

if it is indeed the case (probes applied by vertices locations) i would recommend some sort of away to add probes in-between along mesh large face.. or allow me to set a minimum amount of numbers to allow per mesh maybe?

here is how few remaining probes after optimization on simple shapes.

 

Hi! Glad you are finding it useful. I hope we can solve some of your issues here and get you what you need too.

The reason the characters gets too dark is there is a light probe in that area that is dark and is closer than the light probes in that area that are lit Usually, this is because a probe is buried under ground or directly on the other side of a wall. I plan to add code to detect when they are inside geometry in the future. Generally, if you tighten the constraint boxes so it does not extend around the whole level, but instead is sampling the areas you actually want characters to traverse, this problem either lessens or goes away. Sampling inside geometry is not as common, but still happens occasionally with complex geometry.

Depending on how much space you're sampling, and how many different areas have different lighting environments, you may find that the number of probes is far too small to capture the subtlety of an entire scene. If it's just indirect lighting you're baking, 100 may be ok, but it looks like you're using full baking, because your character is turning black (indirect lighting is only additive). Fully baking lights takes many more probes to capture entering/exiting shadows at good fidelity, especially as light falloff is non-linear and the interpolation between probes is linear.

One thing to keep in mind is light probes are used to improve the lighting of dynamic objects. If they cannot go underneath that archway, you don't really want to sample there. AutoProbe generates points differently depending on what your settings are. The simplest method is to use a grid or spray. That does not really care about the geometry's vertices, but instead samples according to raycasts. The step size of those raycasts are relatively easy to control, but for highly curvy environments where the lighting is not very complicated but the geometry is complicated, you may find Grid method more likely to produce even results. The Spray method will give you many more samples around your geometry, and explore all the nooks and crannies better, but because there are more points where there are collisions with curved geometry, it tends to oversample those areas.

If you are making a mostly walking game, you can get better results by generating probes via Mesh Generators instead. It will automatically create a light probe at the vertices of the mesh and use it as the floor, then generate probes at a distance higher than the floor (you set this height), and will treat that as the probe volume that it explores. Multiple meshes can be specified at once. No probes will be generated that are NOT over the mesh generators, so it acts as a constraint as well.

What you may find useful is breaking up the scene into several sections that you control exactly. For instance, if you have flying/crawling creatures that can use the air around your walkable sections, you might try using mesh generators in one AutoProbe object just for players, then use a different AutoProbe object to generate light probes for the whole scene at a different resolution. They all get merged together in the end anyway. You can be clever with this.

Finally, the way the optimizer works is by removing light probes in order based on how similar they are from their neighboring probes. In the case of the archway with all the light probes underneath, that is the most complicated lighting in your scene, so that's where the majority of the probes are retained. You will want to boost the number of probes until it captures the rest of the scene appropriately, break up the scene into different probe sets, or change the sampling method so undersample that area in favor of other areas. The optimizer doesn't explicitly know about how light probes are generated, it is strictly looking at which probe contributes more to the light complexity of the scene. In places where you have curvy geometry and non-linear light falloff striking those curves, you tend to generate a lot of complexity. AutoProbe doesn't have any way to differentiate between "important" geometry or "unimportant" geometry in the optimization phase. That should be handled in the generation phase instead.

Does that make sense? Hope this helps.

 

Version 2.1 is coming as soon as it's approved by the store admins. It's not a huge change, but does avoid a call stack or two that can be thrown in the case your probeBudget is set really really low (nearly 0). Just a note, in case anyone's run into it already and was confused about the behavior.