Light Awareness component usability extension.

[cem-akkaya]

1. As a designer I would like to provide return owner variables to component as well as tags to improve identification in large systems.
2. As a designer I would like to make a mini gameinstance subsystem for registering and deregistering components on runtime so that users can access light provider components with ease.

Discussed in https://github.com/cem-akkaya/LightAwareness/discussions/4

^{Originally posted by **r0b3rtf1sh3r** October 15, 2024} thank you for creating this, it fit my needs perfectly for detecting light levels driving "solar panel" regeneration style effect in my game easily just added to plugins folder. configured variables. and debug readings to adjust factors. and BAM works perfectly. one suggestion. perhaps include a way to determine which actor is checked for light. that way you could check the collision capsule or any other thing instead of character/actor =)

[r0b3rtf1sh3r]

Awesome. yeah i was going to ask about the component tag. is this a tag you provide to any instanced actor in the scene to be registered (even if not contributing to GI or visible on screen) will be registered? i have something similar when checking if object between cameera and player and if has tag to fade objects or not.

atm im just using global illumination thru lumen driving the light level. its practically turns my mesh into a light meter its great. i have it running on a timer by event at 0.25 sec looping while active. also a "just bottom" direction would be awesome to. practicality probably calls for integration into physical materials, this functionality would syncronize with line traces for stuff like determining phys material. (under feet,touching/overlap etc) this way you can compare both of them. get the materials add them to a preliminary array, create a 2nd array of the same and set them as a temporary "dynamic" material. this way you can update the "light meter aka light awareness component" from the same event/call =)

idk just some idea. i was totally blindsided by this plugin. its the coolest thing since sliced bread.

[r0b3rtf1sh3r]

Let me know if there is any testing or help i can provide in facilitating this =)

[cem-akkaya]

Sure think I can add couple of more flex option to component itself like render only down. (tbh I though there won't be any use cases for it but here we are).

Can add couple of states to component like Registered RegisteredRecentlyRendered Unregistered

Recently rendered is quite cost efficient method to know if the object is visible or not. Otherwise the plugin will scope up to a scanner/targeting system if we want the object to be providing distance angle to the source (player). Tbh depends on the use cases, having that on the component by default would be imo costly for many other users of the plugin however RecentlyRendered can be implemented easyly.

Tag wise I was thinking the LightAwarenessComponent:GetObjectName which would be uniqie string where you can always strip from ":" and get ObjectID if you need to do further identification.However in subsystem we can already save them actorcomponentArray->component->State etc

but if you have a use case that you need to fast find a specific object in that array (not sure how many objects can be around you at a single time let's say 500) On that cases TMap can be better since you can search for specific item on the map more faster. Lets say the ones that are in StateOf: RegisteredRecentlyRendered

Let me know your toughts. I am in the middle of something else that I can not context switch right now but as soon as I do that a bit, will make sure of some improvements get implemented to LightAwareness.

[cem-akkaya]

hi made some changes

-General refactors -Component adds tag with owner name identification both to component and owner actor -Component has Inactive, Active and Active Rendering States -Component can check its owners rendering state and define component state -Component settings refactor for is valid asset state checks -Optimise and briefly refactor GetBufferPixels() -Possibility to only render bottom directional light status -Subsystem addition providing possibility to mass scale get light awareness responders, their status and register unregister events.

Let me know if these additions are beneficial for you and imrpoves the overall ux of the lightawareness.

Let me know what you think and if you need something specific. Would be great if you test it.

Cem

[r0b3rtf1sh3r]

ill try the new version thanks for making these changes, you're amazing, (bug submit below) I was noticing a weird hitch when i use the component on a player character, (regardless of size location or moving) will hitch every 1 second. u can see a visual stutter. also tried lowering the tick from 0.01 to 0.1 and 0.5 and 1 etc i have a check that runs every 1 second when it is in use. originally 0.25 sec but unsure as it wasnt noticed at first. any idea what to check? perhaps its just a heavy request?

[cem-akkaya]

Not at all not sure what hitch is: can you describe what is happening in detail or its like stutter hiccup?

if so what is cpu specs and your current fps in game and how many components are running at a given time?

[r0b3rtf1sh3r]

perhaps ill upload a video, this my first year using unreal, perhaps you may spot something.

[r0b3rtf1sh3r]

sorry for delay here is a video i have a print string (top right) shows value currently of light as float. on delay timer every 0.25 ill post screens below of my logic here is video highlighting the microstutter when plugin is enabled

https://vimeo.com/1026089545?share=copy

[r0b3rtf1sh3r]

image this is on begin play and paused.

[r0b3rtf1sh3r]

here is the logic. breakdown; (check if in sunlight (or artificial light) for different regen rates build on light value %threshold value x regen rate)) pause energy refill if under threshold. delay , notify/dispatch and delay on completed (currently unplugged for debug testing)

[r0b3rtf1sh3r]

i find having the light gem here works best (esp when i want to check if standing on illumination (eg a charging pad etc) but ive recently been testing without bottom and placing it above head, and using no GI trying to turn a emisive (light material function as cloud material) to mask the alpha as it will always be a positive technically as emissive. but thats a side note..

[r0b3rtf1sh3r]

i have it currently on 0.1 tick. if i set it to 0.25 (like the timer, there is a chance it will miss on frame and cause i have max 1 per frame will be forced to wait until next) microstutter is still their either way =)

[cem-akkaya]

I understand the component already needs some optimization during searching the value and reading the value from render target. So in meantime will do that since it shouldn't make your render time go up dramatically up to 3x.

Besides this you can leave tick interval of the component as it is since it doesn't do much things related to render thread. If you ask component to get light status , In that tick will go ask the scene capture component to read its values. So the tick over there doesn't really function

[r0b3rtf1sh3r]

(re tick changes) yeah, thats what i may have noticed via testing, but not known exactly what to report. thanks. any thing else i can do to help let me know =)

[cem-akkaya]

made some updates here and there, and dig deep into a little bit more on lower level code of component.

Implemented 2 methods for you where you can choose on component as : Detection Method : Manuel / Update With Distance / Every Tick.

On update with distance you can choose what would be delta distance to trigger capture event for light. like 10 units or more depending on your game. If not going to use that you can set it to manuel.

Scene capture is now deferred and on these methods returning their value on next tick with event :

I was able to achive vsync 60 fps constant but you can test on yours and we can see what are the results. However RenderTargets interestingly very costly in unreal , so using the component wisely in that terms is important. You can lower sensitivity and use the delta distance method given.

There is also a new variable called "Light Update Step Threshold" this is usefull especiially if you want to ignore changes like 0.05 . If there is an update above that on tick event triggers.

Another advice with respect to not knowing your game. You can always ask component its status from subsystem rather than component constantly updating

EX:

1. Enemy senses trigger update event sense (vision)
2. Enemy accesses light awareness subsystem and finds sense target (us)
3. Enemy queries light status reaching a certain threshold and do more gameplay on it.

Please do not hesistate to contact me further about it, happy if it helps.

https://www.veed.io/view/f11d562d-98fd-4157-9aee-9b4993a427a1?panel=share