End goal: A set of gems that permanently activate and glow on player overlap. When the gems activate, they also cause the ground material around them to become emissive (I plan to have veins inside a cave glow based on distance to the player and these activated gems).
What I currently have working: All of it except this final piece. The system currently works with the player and a single gem blueprint. However, when I activate any additional gems, it causes any previously activated gem (and the ground around it) to reset. Here’s a gif of that:
And here’s the BP setup:
I’ve tried as many different things as I could think to search for (but I’m still pretty new to the software, so I probably just don’t know what I’m looking for). I really hoped a Get Parameter Value node would work (assuming the values would be stored after each BP fires, then I could just add the previous results to the new triggers). However, this version is even worse. It works as expected for the first gem, but then it resets all gems and doesn’t light any up them up after that.
I also tried adding each gem to an array, but I was purely mashing things together and hoping it would work because I have no idea what I’m doing with arrays, or UE in general—if I’m being honest
I’d greatly appreciate any help or ideas about how to make this happen. Cheers <3
It’s probably because you’re using a parameter collection.
The whole point of a collection, is to be able to change many objects at once, and you don’t want that. You want to change one object at a time.
So, just a dynamic material instance on the object, and set the params in that instance on overlap.
PS: It’s a good idea to check for your player on overlap. Many others things can cause an overlap, and you will spend forever trying to track something down when that happens
Hi! Thanks so much for responding <3
After doing a lot more work on this last night and trying to figure out how to maybe pull it off with arrays, I finally started to see why I probably wasn’t going to get it to work with the MPC, like you said. Even if I did manage to figure out how to get the array to spit out the vector locations, they’re all still going into one vector parameter to create a sphere mask, which doesn’t make any sense, right? Just trying to make sure I actually understand so I can learn from this mistake.
So, just a dynamic material instance on the object, and set the params in that instance on overlap.
I’m trying to understand this. It sounds like it would work fine for the gems themselves, but I also need the material around the gems to become emissive when the gems activate. Can I do that with the Dynamic Material too?
PS: It’s a good idea to check for your player on overlap. Many others things can cause an overlap, and you will spend forever trying to track something down when that happens
I’m pretty sure I have my collision boxes for the gem set to only check for pawn overlap. Is there a better way to do this?
If you’re asking if all I need is the gems to become emissive and light the area around them, no. Yes, the gems are emitting light onto the area around them, but the more important part of this scene will be the ability to control the intensity of emissive surfaces based on their distance to these gems. I plan to control the glowing surfaces with a texture mask and/or a separate material ID, so I need some way to communicate to a master material where the gem epicenters will be for the sphere masks. I want the gems to “power” the area around them.
In short, I need to find a way to set up several sphere masks on one master material that are individually activated by their respective BP (instances).
It occurred to me several days ago that I can probably do this with the system I already have. I just need to create as many parameters in my MPC as I have gems and make each gem BP unique instead of an instance. This will probably be fine since I currently plan to have only 3 or so gems. However, this seems like a really inefficient way to do all of that, so I’m trying to find a better way first. And, I don’t know for sure that i won’t want to have a lot more gems, and I don’t want a ton of stacking masks in this master material.
I hope all of that makes sense. I think part of this is inspired by Kena: Bridge of Spirits. Here’s a clip I found. You can kinda see what I’m going for here. The gems are trigger by a pulse from the player and then the gems light up emissive materials around them. This is basically the mechanic I’m going for (excluding the pulse. I’m just going to use a sphere collision to trigger the gems).
Ah, fine. A lot of people just go piling in without any sort of check
Haha. No worries. I’m new to UE, but I am trying to set good habits from the beginning. I’m frequently testing my prototype and focusing on the MVP before allowing myself to get lost in making them look pretty (which is really hard )
No, it doesn’t look like a sphere ( it’s actually a large one ) But as you can see, you can get something scanning over everything using a post process material.
I think you have MPCs back to front
They are for when you want to control a lot of material instances with one parameter.
Dynamic material instances, are for when you want to have parameter control over each instance individually.
I took the weekend off so I’m just now getting back to the project. I just watched a video on Dynamic Materials and this is clearly the proper solution to the gems themselves. After I got a grasp on the concept, I went back and implemented the BP code in your screenshot. It works on the gems! Thanks for the help there. I totally get what you’re saying about MPC vs Dynamic Materials Instances now.
Going to watch the video you shared and look into Post Process Materials now and try not to get too intimidated
Okay, that video was super cool and very well instructed. I definitely got some good ideas for my project from it, however they still used an MPC in the exact same way that I am, so it doesn’t seem like it solves my main issue, which is “scanning” from multiple locations.
ClockWorkOcean is correct, MPC will not work as expected because each gem needs to react to the player overlaps independently from one to another.
Here is an overview of the suggested solution:
