Credit for Paid Items?

Crediting or attributions isn’t required or mandatory or enforced by Epic’s licensing as said before, and It’s totally your choice to credit or not. The point, i read from reading replies here, is that crediting is a fair thing to do if it really helped your game, which i can understand as if any of our packs would be used and be extensively used it’s nice to get credit. The other part is to tell everyone that you made it, since there’s no enforcement you can’t say this, that’s a bit of a rude move, even if paid for the items. But then again it’s totally up to you to do this or not, we nor Epic can enforce you to credit or not say you made it.

Personally if we’d buy anyone’s pack from the marketplace and we’d use it to make a game with we would totally give an extra section in the credits for the packs we’d effectively used in the game or project. But that’s how we would do it, how you do it is up to you :slight_smile:

@mariomguy, your graph is a mess haha!! Material functions for the win :wink:

You think I didn’t try? The parallax system with channel masking was NOT working with material functions at all. It didn’t work until I pulled all the nodes out of the function and manually hooked everything up. And for everything else, the real problem with my system is the results from one part of the shader need to feed directly into several different sections scattered all over everywhere else. The tile map drives ALL of the variation procedures, so they ALL need to link back to it. The falloff blending/mask handling system feeds into every single aspect of the tile and grout rendering, so every section of the shader that differentiates between tile and grout relies on the results of that section to take care of it! There’s also glass, metallic, and interscattering tiles laid out on top of each other, and while glass is compatible with interscattering, neither are compatible with metallic tiles, and metallic renders differently than all of the above. There are a TON of custom functions specific to certain parts of the shader, a ton of procedural math, a ton of UV scaling and shifting, and yes, even a ton of material functions all bundled in here, and they all work off of the values from everyone else. It is simply not possible to simplify this shader any further. This level of inter-communication is absolutely necessary to get the code to work, and in the Material editor the only way to communicate is through wires. So, spaghetti code ahoy.

This shader has already been simplified many times over. Believe me, this is both the most optimized and the simplest code this system has ever been in. Unless I just outright get rid of features or force users to use features they don’t want to, this is the leanest the system can possibly run. I don’t need more material functions, I need remote connections. The ability to send a result from a bunch of nodes to multiple locations without the mess of wires. Just use a send-event-like node that can then be called from an event receiver node to other parts of the shader. But my shader is a highly complex and unorthodox use of the Material Editor, so that kind of a wouldn’t really help anybody other than me. Typically, you’d separate different materials into different shaders and make your materials more specific to the object at hand, but in my case since all the materials use the same system and there is no way to simplify the rendering, it makes sense to have just one massive shader and allow users to toggle which features they want. There is no way to get out of the problem. Every node in this graph has earned its right to be there, and by association, so has every wire. I just compressed all of my local scaling into simplified material functions, and I saved 0 space in doing so.