If the lighting actually doesn’t take into account whether the material is conductor or insulator, then why it’s being rendered as insulator? There’s no in-between results, it’s either Metallic or not. Also vast majority of Epic’s example contents don’t plug a 0 to Metallic input either. Do they not know how the engine works? They’re confirming that plugging 0 to metallic is a redundant step.
Right.
Good.
When and where did this buyer input take place? how many buyers gave that feedback and where’s the data? this folder structure has been the same since the early marketplace days. I assume a few buyers who completely lacked any production experience said something about the structure years ago and it became the standard golden rule because there was no proper structure defined since the beginning of marketplace, and now the majority of people including professionals are suffering from it. We get that it’s easier for reviewer if every asset type is put inside a single folder but clearly everyone who actually uses the content has mentioned in this and the other thread that this structure has been very problematic and inefficient for their projects. Why do you not try to publicly take community’s input on this now?
That’s not quite what we said. We’re talking about localizing each asset with it’s dependencies i.e rock meshes should be in one folder with their corresponding materials and textures. Tree meshes should be in one folder with their corresponding materials and textures and so on. To break up a tree into several different paths like:
You’re basically making people continuously go back and fourth between folders while working with an asset and tweaking it. It wastes a lot of time.
The way we did it was:
Please go ahead and fire up Kite Demo, or Open World Demo Collection and have a look at how the structure there looks like. That’s quite messy what they have there, I’d say. But everything is extremely localized it makes it super easy to work with the content and their corresponding dependencies.
I’d appreciate if you reply here since it’s not just me who is interested in an answer.
Thanks.
Have to agree with -Dev on the folder structure. So long as the project is organized and all subsequent folders are under one of the project name it shouldn’t matter which approach devs take. Some projects are too large where dumping 800 textures into one folder isn’t going to be optimal at all, and will only frustrate the end user.
Also are you going to address the no overlapping uv requirements? Because that needs addressing as well.
To be fair, unless I’m misreading things, it wasn’t specified that all 800 of those textures have to be in one folder. Mike said you could use “ProjectName > AssetType” or “ProjectName > AssetType > SpecificAsset”, so you could in theory have those textures in folders of their own within the Texture folder. I know I do this in submissions and I’ve not once, in 6 submissions, had any issues with folder structures for my submissions.
Honestly, this is one of the more important points that needs to be discussed, at least from what I understand (though keep in mind, I’m not a modeller).
Regarding the folder structure discussion being had, at this point I honestly think sticking with the current standard is the right move, as there are 2200+ assets already matching that. Consistency is more important here than anything, and while I agree having a Marketplace folder at the top, or something similar, would have been ideal, changing it now seems counterproductive. Honestly, the fact that this is even a discussion being had when Epic aren’t requiring something absolutely bonkers feels like a waste of everyone’s time. I also, personally, much prefer having all Materials in a Material folder with a specific asset subfolder than the other way round, just to throw that in there. It makes far more sense to me, given assets are re-used and such, than the method that is being proposed by -Dev. I also don’t agree that it shouldn’t matter which approach is taken - I think maintaining consistency across the marketplace is one of the most important things to be considering with new submissions. We have to remember that a HUGE portion of the community may only be skilled in one specific area of the engine, so the more consistent it is, the easier it becomes, and the less hassle it is for everyone - including sellers (less support and such).
Pretty sure that metallic scalar material input gets compiled with default value of 0 if it is unconnected, and has absolutely no effect whatsoever, thus the doubts about forcing authors to plug in zero constants for nothing.
Consistency |= efficiency though. In my bundle for example, I have 5 of my packs that are in a folder structure as so:
>Starter Bundle
…>Modular SciFi: Hallways
…>Modular SciFi: Interiors
…>Modula SciFi: Command Center
…>Modular SciFi: Materials & Decals
…>Modular SciFi: Props I
…>Maps
…>Textures
…>Materials
…>Meshes
…>UE4 Example Assets
I can’t merge the individual texture/mesh/material folders into a folder in Starter Bundle. It would be incredibly confusing as users wouldn’t know which files corresponded to which pack. This way is the most organized, and efficient in understanding what belongs to what. I’ve sold my content on Gumroad with this setup and have had no one report any issues. If anything people had nothing but praise for how everything was organized in the bundle. A one size fits all solution never works for everything. This bundle is a perfect example of that.
If a wrong structure should be kept the way it is just to have consistency with the previously released projects then communication shouldn’t improve either since it’s been semi broken since the beginning. Rejecting improvements so we’d have consistency? What you’re saying doesn’t make any sense. There’s no need to have consistency with something that has not been acceptable by industry professionals in the first place.
I have not proposed any methods on my own, mind you. All of what you’re calling “standard” is -NOT- standard outside this UE4 Marketplace platform. These -standards- are not even adhered to by Epic itself all across the content examples and other projects. I can bring you at least 10 example projects right off the Learn Tab and none of them follow what we’re required to follow. Actual artists and designers tend to keep everything organized while maintaining high efficiency and it hurts to have to follow a set of guidelines designed by people who have no idea about production, I’d be really interested if any of them had a single finished project on their resume (in this case the few buyers that have contacted mike years ago).
Buyers reading this might assume we’re suggesting something in our own favor, that is not true. If localizing the assets (like Epic does for their own projects) makes it easier for the developer to work with the content, it’d be even much easier for the end user since they’re not familiar with where each asset is and where it’s dependencies are.
I want prove of this.
I cannot find any documentation backing this up. (besides on rumor)
Not to mention that there is barely any content epic ever released which follows this.
Not to mention:
So unless something changes after cooking, or someone comes with prove I am going to assume this Null/NAN thing is not true.
Additionally, if this is true than it would mean specular would never work unless the metal value input is set to zero instead of “no value”
No really, I want this to be clarified for once and for all.
Fair call on the bundle, though this is not a usual pack in that regard. There should, of course, be exceptions allowed where it makes sense - as is the case with bundles. But in 99% of cases the rules outlined above are fine. And whilst I agree consistency does not equate to efficiency, theres nothing particularly wrong with the folder structure they are requesting IMO - so unless they are going to ask all prior assets to be changed and enforce it (which, being pragmatic here, is not happening) then I would vote for consistency over efficiency in this particular case.
Good job inserting words where there are none. I didn’t say communication shouldn’t improve - of course it should. Communication from Epic has been absolutely awful. And using the words “current standard” also does not imply that it is a universal standard, or that it’s standard outside of the UE4 marketplace, but it is “a standard” that is currently being used with assets in the marketplace. I also didn’t say Epic’s content meets that standard, but Epic also don’t sell that content on the marketplace. I agree that their content should match the requirements of the marketplace, no arguments there - but its clear that they do not feel that way for one reason or another. Their content ALSO doesn’t meet any sort of consistent system. There are heaps of different naming conventions, file structures, etc. at play in different learning/example content provided by Epic. So not really sure what the point of bringing that into the discussion is as it actually doesn’t aid either of our side of this debate.
My point was that in the interest of consistency, we should be sticking to a consistent standard where it is not required to break it (as is the case with the bundles, which provide a legitimate reason why that structure may be more beneficial to the end user over consistency). At this point, the sheer number of assets that do match the outlined structure is a huge point in favor of maintaining it.
Didn’t insert words anywhere. You’re argument of not having to improve the folder hierarchy in order to keep consistency with previously released projects is the same as asking for no communication improvement in order to keep a consistent broken communication.
Do you know why this thread and others like this exist? do you know why about 90% of the content creators aren’t happy with the platform? do you know why you often voice your MP concerns on discord? it’s because a lot of the things that are currently going on with marketplace are wrong on many levels and people (including you) don’t like it. It’s because majority of what’s been going on has been wrong since the start, and so everyone desires improvement. Project structure is one of those things people want changed/improved. Now the fact that you’re backing it up just because it’s been done like that since the start is nothing short of backing the idea of not being able to update the images of your own product, just because it’s been that way since the start. You’re defending the current structure because it didn’t affect you personally but as soon as it become an issue to one of your future projects you’d be here.
Like I said, those contents are better localized. You can find what you want in one place, which is what we’re talking about. Regardless of naming convention and other issues.
Huge sheer of mistake shouldn’t convince you to reject future improvements. It wouldn’t hurt people if they finally get to work with projects more efficiently instead of browsing through assets with every part of it being spread across dozens of folders.
Your argument is based on keeping things the way they are because they have been this way and you’re ignoring any other better options that are available here regardless of how many people are saying the current setup is problematic and not a practice anyone would want
to have in production.
Arguing a point does not say anything about your views on other things. I am saying in this case, it does not make sense to all of a sudden rapidly change things that, at the end of the day, are not actually hindering use of the asset. And FYI I’m well aware of the state of the marketplace, how content creators feel about it, and how I feel about it (imagine that). Again - commenting on a single issue does not then mean I am happy about all the other things. Sometimes, believe it or not, people can address a specific thing as that specific thing But go for it - shout from the rooftops all you like. I’m out of this one.
Your engineers have determined 0.04 as the default value for Metallic pin when left disconnected. Not Null. And they’ve determined 0.04 serves best for insulators, not 0. You are in fact making it less PBR by connecting 0 to Metallic pin.
Just because I’m saying the suggested structure isn’t a proper one it doesn’t mean I want to shout. :rolleyes:
There’s no way to fix such an issue slowly over time. It’s either this or that structure.
Here’s a list of people who I could get their opinions on the current structure:
Please don’t call it a waste of time when people are asking for improvements that helps them save time.
A lot more people share the same thoughts if we actually ask for their input publicly.
Either way, see you in other threads.
Looking at the code, I have suspicion, that connecting metallic input rule was mistakenly done the other way around. It should sound “Leave metallic and specular unconnected, if not used”.
Because when these two input pins are disconnected, mobile material will use a cheaper shader path. That is the only difference.
When you have specular input disconnected and metalness input connected, there will be no visual difference, but mobile shader will be more expensive.
I suggest you to seek clarification about that from responsible staff and correct me if i’m wrong.
(4.16 MobileBasePassPixelShader.usf, line 42, MaterialShared.cpp, lines 947, 1452 ).
Epic, could you consider creating a council of marketplace sellers that could help develop the structure / policy? This would allow transparency and allow input from your community devs. Win win for all.
I’ve been following this thread closely and don’t have anything new to add to it, but I’d like to add a +1 to this gentleman’s suggestion. Indeed a win-win situation.
The Review Process and Guidelines
The current TRC is our first draft that we are using as a basis to refine our review process and has already improved the amount of time it takes to complete a full review. I am still revising the TRC in order to create a smoother process and it will include some updates to a few of our outdated/unnecessary requirements. Our goal with these guidelines is to maintain quality and consistency in Marketplace assets. Moving forward we will have a less-stringent policy for publishing on the UE4 Marketplace. Once the TRC is complete, we will update the “Preparing Your Assets” portion of the guidelines to reflect and explain these new policies.
Folder Structure
While we understand that ultimately these items will be used in your projects, we aim to provide our buyers with a consistent folder structure for distribution so that anyone purchasing an item from our Marketplace can easily navigate their files. The folder structure requirements will stay as-is for the time being, but we’ll take your feedback into consideration as we review our process.
Metallic and PBR
I spoke with one of our developers here about this. We tested it out, and you guys were right. Metallic does not default to “null”. This requirement will be removed from the TRC and won’t prevent an asset from being published on the Marketplace. I’m glad this one’s settled.
That’s what we’re trying to figure out. Because overlapping UVs is common. So in the review sheet this is supposed to say No Overlapping Lightmap UVs then?
As for folder structure, again consistency doesn’t equal easy navigation. The criteria should be that the project is clearly organized, and that all assets are within a parent folder that shares the name of the product in question. (As I outlined a few posts above) I have a submission that due to it’s bundle nature cannot have all of the products merged into one folder like that. I’ve had many people who’ve purchased it on Gumroad and have never had one issue with the way I organized it. This same product is in review for the UE4 marketplace. So you’re telling me that because it doesn’t adhere to this unnecessarily strict folder structure that it won’t pass? The quality of my work speaks for itself, and so does my organization. You’re putting restrictions on us here that your own company doesn’t even adhere to. How is that not hypocritical?
So to clarify, by No Overlapping UVs you basically mean “No Overlapping Lightmap UVs” right? Generally having overlapping UVs for materials doesn’t result in any errors before/after light baking unless it’s the lightmap UVs that overlap.
Edit: @ Ninja’ed. :eek:
Edit 2: Regarding folder structure, basically what said. There are ways to better organize the content which will be appreciated by both sides. Like a common practice in game development. Paragon’s folder structure might be a good example if we want to have a starting point (haven’t seen it, but definitely should be something along the lines of what we’re talking about).
Thanks for being man enough to look into it. The current folder structure makes it confusing when people are looking for a specific file and they have to browse through lots of files to find it. Any chance you could reconsider this?
But go for it - shout from the rooftops all you like. I’m out of this one.
