The problem of overlaying decals
Hello everyone! I'm making a mod with decals and have encountered a problem with their overlay. When one decal overlaps another, they don't blend together, but simply cover each other. DBuffer is disabled in the game, so this method doesn't work. I tried spawning meshes with an offset, but that's not it either. Has anyone already solved the problem of blending dynamic decals without DBuffer? Maybe through Render Target or a complex material?
Solution:
Jump to solution
I was planning on making these exact parts, which is why I already have some of this set up. But this is how I would do it.
The part should a FGBuildableFactoryBuilding, set up as a lightwieght, using FGGenericHologram. This will give you the most snapping options on walls and foundations, catwalks, ect.
There should be a single plane mesh, uv mapped to 0-1, using a material similar to this one. The index changes which pattern is being used. You could make individual material instances for each part, using the correct index, or you could try to set this using custom data (preferred but would probably require cpp since pattern ID's are ONLY applied to FGBuidableFoundations). The material itself is in the Deferred Decal domain....
53 Replies
decals as in the decals sheet used to put details on machines, or as in the customizer Patterns you can build?
@AngryBeaver (FE, CC+) probably has some insights
Customizer Patterns. I am creating a Buildable that has a Decal Component.
Buildings are Already covered in floating overlapping decals though. So I'm not sure what the problem would be.
assuming by Decal Component you mean the Unreal one, that is not what buildings decals (they use a second mesh portion with a different material assigned) or Pattern-applied foundations (I think CSS is doing something custom for that?) are implemented with
Patterns on foundations are mixed into the foundation material. It's why there can be only one.
And it's pulling from a shared atlas texture, which is why we can't easily add new patterns
Since the player would be spawning thousands of these, they should be set up as lightweights. Do not use Decal component or any other component that would make the part ineligible as a lightweight. Lightweights have a static mesh stored in their AbstractDataObject and no other components.
Do you mean Decal_Normal or DecalColor_Masked? How do I use them? I read about them in the documentation, but as far as I understand, they are embedded into an existing mesh, in a specific place depending on UV. And I can't place them where I want. Although I may be wrong.
And I don't use the standard Pattern system through a stencil. I create a separate FGBuildable that has a Decal (UDecalComponent). And when placed over a constructed building (a foundation, for example), this Decal is placed on top. That was the original idea.
But when they intersect, they overlap each other. And I would like them to blend together. I read that it is possible to implement this using DBuffer, but as I understand it, it will not work in the game, even if I include it in the engine itself.
correct, Decal_Normal or DecalColor_Masked will not work for your purposes, because you would need to make new foundation meshes with floating bits for those decals to be applied on
D4rk's point is that you should not use UDecalComponent because the performance will be miserable, CSS has done a ton of optimization on foundations and patterns, by using UDecalComponent you basically opt out of all of those optimizations
I'm not refusing, I just don't know any other way. If it's possible to do this using CSS templates, please let me know how.
I don't think there are CSS 'templates' that would help, you will have to do your own development no matter what
to my knowledge, a way to do this without the performance problems would be to create a new buildable that is a thin plane that can snap to foundations or other instances of the buildable, with no player/building collision otherwise, that takes customizer patterns, or uses the skins system to take skins for custom patterns. then you can stack however many you want in one spot because they are not using the pattern system, but they are still lightweights. let's see what D4rk says though
Solution
I was planning on making these exact parts, which is why I already have some of this set up. But this is how I would do it.
The part should a FGBuildableFactoryBuilding, set up as a lightwieght, using FGGenericHologram. This will give you the most snapping options on walls and foundations, catwalks, ect.
There should be a single plane mesh, uv mapped to 0-1, using a material similar to this one. The index changes which pattern is being used. You could make individual material instances for each part, using the correct index, or you could try to set this using custom data (preferred but would probably require cpp since pattern ID's are ONLY applied to FGBuidableFoundations). The material itself is in the Deferred Decal domain.
If you're curious how the vanilla patterns work, look at this material in the project
FactoryGame/MasterMaterials/MM_BakedStencil_01
I think that's one of the materials we requested they send us the original of, so we actually have it. most of the materials in the project are auto generated stubs
Each group of icons should be it's own material with indexes. That's how I'd do it to encourage batching and leave room for flexibility
You mean split up the stencil sexture into 4 separate textures? One for each channel?
one for hazard lines, one for walkways, whatever the packs you buy from the store are
:interesting:
I had to import a copy of the stencil texture anyway because its virtual and it doesn't like being used as an opacity mask. Breaking it up into multiple would probably be fine.
Thank you, that's something to think about. If using Decal compromises performance, then I'll give it up.
Also, what does “lightweight” mean? I've seen similar classes, such as FGBuildableFoundationLightweight, but when I looked at the C++ files, there was nothing there except the constructor.
Basically there's an ingame system that instantiates the meshes without using up the same number of uobjects just directly placing a blueprint would. It's how you can build so many things without surpassing the unreal engine object limit
Upgrading from SML 3.7.0 to 3.8.x :: Satisfactory Modding Documenta...
The contents of this page will change frequently! Keep your eyes on the #modding-info-feed discord channel to be notified when updates are m...
After conversion they are just instanced static meshes, which is why you cant put any special components in the builder, the actor and all of its components get destroyed.
The system is not currently very modder friendly and you will likely have to wait for future game updates to improve it.(those updates have happened)
Is there any way to access the abstract instance that I added in the editor in the “lightweight” class? I tried using MeshProxy, but it returns null.
I saw that there is Instance Manager and LightweightBuildableSubsystem, but I don't understand how to proceed.
Only through Result Hit Instance Manager? Is it possible to obtain it without tracing? For example, calling a method when creating an instance.
The link D4rk sent shows how to spawn a buildable with a strategy which can spawn lightweights from their building class. You can get data about the type of building from the default properties on its class. Not sure I understand your question
What is an example data point you're trying to obtain and what is the end user interaction that requires it
The lightweights class requires the use of an abstract instance, correct? I add a static mesh as an Instance in the editor in the “Instance data” field.
After creating a buildable in the game, I need to:
1. Change the material parameter, namely the stencil index. This is to avoid creating a separate material instance for each buildable.
2. Disable collision so that it does not interfere with the construction of other buildables. I can disable collision in advance in the editor, but I need it for dismantling. Therefore, I need the ability to disable/enable collision. Previously, I disabled collision in Event Begin and through the StopIsLookedAtForDismantle interface. Enabled it through Mixin Character, did tracing, etc.
And for this, I need to refer to the abstract instance, if I'm not mistaken.
Sorry, don't disable collision, but change Collision Responses for BuildGun.
You shouldn't be using material parameters. You should be using per instance custom data. Material Parameters don't batch anywhere near as well as they should.
And set the collision properly on the mesh itself. That way you can hit it with the build gun but nothing else and you don't have to update it.
And if you need help setting the per instance data on lightweight meshes D4rk knows how.
A quick note. It's fine to use material parameters for things shared across buildable types like the source texture for the images. But stuff like the index and color need to be PID
Actually, I dont. I havent been able to get it to work. At the very least it will require some cpp, I dont think it can be done in BP. These functions are the only ones available, but the resolve is false under all conditions if
self is used as a target, even calling pre/post begin play or construct. Might need Arch's help on this one.
The same BuildGun channel is used for construction and dismantling. But I need a reaction to the dismantling trace, while ignoring construction. I couldn't think of any other way to implement it.
Powerlines aren't solid but can be both selected and dismantled
For #2, I don't think this is possible, collision settings are per component, not per instance, So anything you change would affect all instances owned by the component. In the AbstractDataObject, you can specify a collision profile name only, and nothing else.
Yes, exactly. You're right.
I think you would need a custom collision profile. I don't know if its possible to add that to the game because they are stored as project settings. maybe you could add it in an ini file?
I think that's where they're defined, so you should be able to.
but I also think powerlines have one. But wait that one is transparent to the customizer. I was able to get nonsolid dismantled and customizable as a combo for my powerlines but I can't remember the settings. I'll post when I get to my computer to check
Unless Arch gives us a super easy way to do #1, I think individual material instances per buildable with the correct index is still probably the best way. Most light weights have their own material instance anyway, since they are all baked assets. Just dont try to set it as a parameter using a dynamic material instance.
If this approach is correct and is being used, then I will simply create an material instance. I just thought that, if possible, it would be better to use a dynamic material instance, that it would be more optimal. Perhaps this is not the case.
You should not use dynamic material instances for any buildables. Either use a pre made material instance with the correct values set, or try to set those values using custom data.
DMI's add extra uobjects/draw calls and they have to be stored somewhere.
It will be interesting to see. Perhaps it will help me or give me some ideas.
Although the colors and patterns of the foundations change in the game, I don't think the instance itself changes. For example, MM_BakedStencil_01 has MF_PaternID, which has the PaternID and InputData parameters. I wonder how it works.
That's the per instance data
The buildgun/customizer only sets PatternID (Index 7) on FGBuildableFoundations. It will not work for these buildable classes
No, everything works.
Yes, thank you. I think that's what I needed.
Does that work at runtime? I think it only works for the mesh preview in the editor?
Also, I made a math error in the material I posted yesterday, this is the corrected version.
Yeah this is how my collisions are setup:
Non solid, dismantle, and customization response.
Unfortunately, no. I was so excited, it's sad. But I still learned something useful, which I think will come in handy in other UE projects.
@[CaT] Darkshok were you able to find a fix to your spawned instance problem? you deleted the question you posted about it here. I wanted to know what the resolution was
Yes, I was able to implement it, but only for Abstract Instances.
I get Builable from AbstractInstanceManager and create a BoxCollision component for it during the dismantling mode. The Abstract Instance automatically turns into a regular Actor, and through BoxCollision, I can start the dismantling process and delete the Builable.
If I disable the dismantling mode, I delete BoxCollision. The automatic conversion happens again, and the Actor becomes an Abstract Instance.
This way, the mesh does not affect the construction, and the dismantling uses a temporary separate BoxCollision. The magic happens inside the engine, there is no need to manually add/delete Instances, everything happens automatically.
Unfortunately, this approach does not work for LightweightBuildableSubsystem. I have been trying to find a solution all day today, but so far without success.
I don't know how effective it is, but it works. And I don't know what's really going on. Either a separate copy of Builable is created and the list of instances remains unchanged, or the entire list of instances is updated. So far, I've only tested a few objects, but there might be a problem if there are 1000, for example.
To create the instance itself during gameplay, create a method in the Buildable class.
it's triple `, not triple apostrophe
You can manually fill in the data via FInstanceData InstanceData.
I found this method here.
https://docs.ficsit.app/satisfactory-modding/latest/Development/Satisfactory/AbstractInstance.html
Abstract Instance :: Satisfactory Modding Documentation
Coffee Stain created the Abstract Instance system as a way to reduce the amount of UObjects that static buildings take up and improve perfor...
The main question of this topic has not been solved. But I think it is even better, there will be no problems with Z Fighting.
But I managed to optimize the main solution by switching to Lightweight Buildable. Thank you all for your help.
