this might be a loading issue. create parts in your workspace and apply your decals to those parts that way theyre loaded into ram and then run the same script and see if that eliminates the flickering
1 Like
Oh my god that actually worked tyyy,
So the problem is roblox unloads the decals?? that’s a bit weird.
But how do i implement it to the actual game? i can’t just have the parts just there and i can’t hide them when occlusion culling comes along
any ideas?
You could use a part cache, like what FastCast does
Essentially store each part inside of a Folder, then teleport each part to where you want the pillar to be, then teleport the part somewhere where it won’t be seen to remove it without having to repeatedly destroy and create new parts
2 Likes
Every game does this to save on resources. RAM is needed to store data that needs to be called quickly, such as animations, audio, and more. Because RAM is limited, game engines will unload unnecessary items to free up resources. The only thing that most games do differently is that they store dynamic textures as flipbook textures so that only 1 texture stays loaded at all time, and all that needs to be edited are the UV’s.
Since Roblox doesn’t support this feature, it will automatically unload textures to save on RAM, and will intead have them loaded in either local storage, (which is slower) or stream them from servers (which is REALLY slow, and doesn’t happen in this case) which explains why textures appear to ‘flicker,’ as textures that aren’t completely loaded are not drawn.
Apply the decals to a transparent part, set the decal transparency to 1, and hide the parts in a place where the player won’t be able to interact with them, such as inside a wall or underneath the map. The textures should still be loaded into RAM and thus flickering should not be present.
I don’t believe occlusion culling should affect whether or not textures are loaded into RAM so I think you won’t have to worry about that.
Also this should go without saying, but make sure you Anchor the parts if you’re hiding them under the map so they won’t fall, and despawn which will cause the textures to unload.
1 Like
This is the oddest solution I’ve seen yet. If this is indeed a loaded problem you could just cache them by using them. Run them on some part that is hidded. Then when you call your object they will already be “cached”.
My reasoning was: If the pillar is going to be used as a special effect, it would most likely require multiple copies of the pillar. The amount of copies required would change with how many players there are, so using a system similar to FastCast makes sense, since you can cache a few copies for when the server isn’t under load, and only create more copies once more players join. Doing so would save having a ton of parts stored even though only a few players are currently playing the game
If there’s only going to be one pillar, then there’s no need to use this system, setting their transparency like how @A_SquaredAnimations recommended is enough
Well if it works that’s all that matters. I had a problem a bit like this in a game I’m putting together. When you would spawn a new car it would part by part spawn in … looked very odd.
So I found a solution to this with preloading the cars. After that they spawn in as a whole car.
local content={}
local cars=game:GetService("ServerStorage"):WaitForChild("CarFolder")
local ContentProvider = game:GetService("ContentProvider")
for _, car in ipairs(cars:GetChildren()) do
table.insert(content, car)
end
ContentProvider:PreloadAsync(content)
1 Like