Jump to content
  • 0
Sign in to follow this  
AEon

.probe files explained?

Question

I recently added a huge superstructure outside of my main map, a frame of a cube (~3500³u), that looks interesting but not only ups the light compile time significantly but also the size of the .probe file (from 1.7MB to 10MB+)...

 

Running about in the map this does not seem to effect the FPS, as far as I could tell, so I am wondering what exactly the .probe file does.

 

From what I gathered Reflex "places" light probes (more like takes light samples)  in the map at regular intervals (64u spacing in all three dimensions by default), that seem to help the light compile in some way, and I am guessing the info is stored in .probe, to then help create the lightmaps in .light?

 

These console commands seem to be related to it:

r_lm_probe_batch_count <#>  // 128, ???
r_lm_probe_seperation <#>   // 64.0, how far spheres are appart in r_lm_showprobes
r_lm_showprobes <0/1>       // 0, show the light probe spheres in map
  1.  Can the lighting quality, e.g. shadows or lighting detail be improved by using a smaller number in r_lm_probe_seperation <#> ? I.e. by adding more light probes to the map?
  2. Is the .probe file needed after the light compile, i.e. to actually run the light compiled map? If not one could stop distributing it.
  3. Is a large .probe file an issue for the performance of the map? Other than initially increasing the light compile times?

I am presently tending to delete the superstructure to keep the space the map takes up as compact as possible. So it would help to know what is happening here, to perhaps make a better decision.

 

Share this post


Link to post
Share on other sites

10 answers to this question

Recommended Posts

  • 0

I recently added a huge superstructure outside of my main map, a frame of a cube (~3500³u), that looks interesting but not only ups the light compile time significantly but also the size of the .probe file (from 1.7MB to 10MB+)...

 

Running about in the map this does not seem to effect the FPS, as far as I could tell, so I am wondering what exactly the .probe file does.

 

From what I gathered Reflex "places" light probes (more like takes light samples)  in the map at regular intervals (64u spacing in all three dimensions by default), that seem to help the light compile in some way, and I am guessing the info is stored in .probe, to then help create the lightmaps in .light?

 

These console commands seem to be related to it:

r_lm_probe_batch_count <#>  // 128, ???
r_lm_probe_seperation <#>   // 64.0, how far spheres are appart in r_lm_showprobes
r_lm_showprobes <0/1>       // 0, show the light probe spheres in map
  1.  Can the lighting quality, e.g. shadows or lighting detail be improved by using a smaller number in r_lm_probe_seperation <#> ? I.e. by adding more light probes to the map?
  2. Is the .probe file needed after the light compile, i.e. to actually run the light compiled map? If not one could stop distributing it.
  3. Is a large .probe file an issue for the performance of the map? Other than initially increasing the light compile times?

I am presently tending to delete the superstructure to keep the space the map takes up as compact as possible. So it would help to know what is happening here, to perhaps make a better decision.

Aren't they for the dynamic lighting of entities in the levels? I'd imagine a higher res would increase detail but I doubt you'd notice it.

Share this post


Link to post
Share on other sites
  • 0

From my experience a larger probe file doesn't mean less performance.  As you've seen, the probes area scales in order to touch brush faces no matter how far away those brushes are.  They scale with whatever geographic areas you add.  This means the closer and more compact you can build your rooms the smaller the probe file will be.  Had I known this then I would have constructed all the rooms in Deflex to be right smack on top and next to each other.  As of now they are all very spread out some as far as 3,000u away from center point.  With 7 rooms all spread that means a larger probe file than had all the rooms been closer and more compact to zero coordinates.  I assume it starts as 0x0x0 but I haven't tested that.

 

Lightprobes are like light samplers.  That's a great way to describe them.  When ILM first started using them they only used a basic white ball.  Then they switched to a diffused grey ball.  Then they started using a grey ball on one side with a mirror on the other.  ILM's work with lighting really pioneered a lot of features that people take for granted today.  They really honed in on what it takes to recreate realistic lighting for movie special effects.  Their techniques did more to progress lighting in 3D engines more than any other breakthroughs in the past decade.  If you haven't read up on ILM's work you should.  There's always diffused light and specular light to be measured.  Lightprobes in Reflex work in much the same way.

 

The spheres they are holding can be considered lightprobes and are the reason we have awesome lighting in 3D engines today.

 

coke_hdri_500.jpg

Share this post


Link to post
Share on other sites
  • 0

The probes are used to light dynamic objects such as players and weapons as they move through the world. Lightmaps can't do this since they're flat -- they have no volume. If you stop including probes with your maps, any dynamic objects will appear black and look shitty.

Share this post


Link to post
Share on other sites
  • 0

Ops... had completely overlooked dynamic lights. Thanks everyone for clearing that up.

 

With

r_lm_showprobes 1       // 0, show the light probe spheres in map

you can track just how far these probes go.

 

With such a superstructure outside the map, that I have now placed very much closer to the map, a probe_clip could be useful, to contain the probing to only the areas a player can actually reach to ignore anything outside. Basically the level designer would used one huge brush that defines the extent of the probing, anything outside the brush would be ignored.

 

Such large "outside" areas are not unusual for maps, e.g. those that have vistas, but are clipped off from the player. Just a thought.

Share this post


Link to post
Share on other sites
  • 0

No, actually it would be just one single brush. Thought the mapper would need to know what he/she is doing.

 

Made the mistake of using my map as the general case. Should you have TP separated spaces (rooms), it would be one brush per separated space. But still super fast to add.

Share this post


Link to post
Share on other sites
  • 0

It's not that easy when you are talking about more than 3 rooms unevenly spaced apart.  All of the space in between each room would have to be clipped and it's not as simple as drawing a couple brushes.  Would need considerable brush work.  Hope you see why I'd rather see it built into the engine. 

 

In the case of my 7 randomly spaced rooms it would be a nightmare to fill in the blank 3D space between every possible room combination especially when some rooms begin much higher and lower than others on the Y axis, sometimes by 1000u or more.  Had I known this when I started all of these rooms would be right next to each other and much more neatly organized.  Currently they are wasting a ton of space and increasing the lightprobe area considerably. 

 

At the time, I thought putting rooms outside the visual plane and increasing the distance between rooms might actually be a better thing for performance.  I didn't know about the lightprobe area at the time.  Really need group selection to optimize this kind of thing.  Moving all of these rooms 1 brush at a time is inconceivable.  When group selection does happen I'm sure lightprobe area will become another optimization technique, at least for maps with modular rooms like this.

 

This screenshot represents about 7000x7000x2000 of used area.

2014-12-06_00001_zps2dc17a98.jpg

 

I know it's dark, my map is designed that way on purpose.  Couldn't change the background color without it killing the lightmap.  At 1.5 hours per build will just have to squint a bit to see everything.  Lightprobes only show up after the lightmap is built.  Using showprobes 1 will do nothing while in real time lighting mode.

 

2014-12-08_00003_zpse15eaad9.jpg

 

Now looking from the opposite direction you can't see the lightprobes anymore.  They have this weird habit of only being visible if looking in a certain direction. No idea why.

 

2014-12-08_00002_zps1ef45e44.jpg

 

As you can see the lightprobes do show up in 3D space between rooms.  They must span the entire geographic map to touch every single brush no matter how far away it is.  This leaves a ton of wasted lightprobes sitting out in space.  In my case we're talking tens of thousands of wasted light probes.

 

2014-12-08_00001_zps89cad818.jpg

 

So in my opinion it's better for the lighting engine to group all rooms as closely together as possible.  Limiting the total geographic size of a map can make a difference for optimizations.   Wish I would have known this from the start.  This was an experiment in a way to see if visual plane would act as nodraw and not draw those rooms if far away thus increasing performance.  That experiment was a failure it didn't help at all and now I'm left with massive open spaces and tens of thousands of wasted light probes all combined to create an excruciating long lightmap build time.  Visual plane distance doesn't have any effect on what is seen by the lighting engine since probes are created after the lightmap is finished.  Hey, we're learning some good stuff little by little though.

Share this post


Link to post
Share on other sites
  • 0

God no. You would have to use a probeclip brush everywhere between rooms. That would cause me nightmares.  Would rather see it automatically clipped by the engine.

If the light probe density varied depending on either how close to a surface the probe was or perhaps the lighting gradient across that region of space by having an octree of probes or whatever that would probably achieve better reductions without actually needing to completely cull them.

But this is just another one of those things we should just wait for the devs to optimize and not worry about I think. :)

Share this post


Link to post
Share on other sites
  • 0

The spheres they are holding can be considered lightprobes and are the reason we have awesome lighting in 3D engines today.

 

coke_hdri_500.jpg

And this is the perfect time of year to pick them up for cheap as repurposed christmas tree decorations =D

Share this post


Link to post
Share on other sites
  • 0

If the light probe density varied depending on either how close to a surface the probe was or perhaps the lighting gradient across that region of space by having an octree of probes or whatever that would probably achieve better reductions without actually needing to completely cull them.

But this is just another one of those things we should just wait for the devs to optimize and not worry about I think. :)

 

That's a good idea!  On the flip side, one way to drastically improve lighting would be to decrease lightprobe spacing making them closer together.  Not sure how texel size and lightprobe spacing is related yet.

 

That's up to the developers but it's something they will probably have to address sometime in the future.  For now it's plenty good enough to handle the majority of maps out there.   Unless you make a relatively huge map like Deflex or Parkour Station then lightprobes aren't really something you have to worry about.  This issue only really affects the largest of maps.  I can only think of a few really large maps that could stand to gain from lightprobe optimizations.  So it's not really a priority.  Actually, all of this can be more easily fixed by map authors once we get group selection capability.  It's not a perfect solution but it's a much better one than having developers spend time trying to figure out lightprobe culling when a map author can simply move their rooms closer together. 

 

This is something that Parkour Station has a definite advantage over Deflex.  Parkour Station is basically one huge room with multiple interconnected rooms.  Deflex has multiple rooms widely spaced from each other.  Parkour Station also has much much better map performance leading me to believe that perhaps this is a critical optimization that Deflex is missing by having the rooms so grossly spaced from each other.  Parkour Station also uses absolutely zero nolight texture, has missing textures, and also has plenty of artificial lighting.  Brush count, brush size, room size, lighting, and construction techniques are all very similar.  The biggest difference is geographical size and map performance.  Parkour Station out performs Deflex by far in FPS.  This leads me to believe that geographic size might just end up being more important than originally thought especially since Deflex has every possible optimization technique and Parkour Station has none.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×