Submission Guidelines - Feedback Thread

[Maximum-Dev]

Hello,

I was reading through the Submission Guidelines (Updated edition) and I find quite some issues in there worth pointing out.

5. Meshes

1. Submissions with less than five major assets must be rigged and animated.

What if it’s… 4 rocks? or anything that doesn’t require any movement.

4. Assets must be UV mapped so that 1 texture tile covers 1m in the game world.

If this is about texel density then it differs from one texture to another based on their resolution. 1 512x512 texture tile covering 1m in the game world isn’t the same as 1 2048x2048 texture tile covering 1m in the game world. Besides that, I find no two packages on the marketplace that have a unified texel density all across the assets.

8. Must not have any lightmap issues.

For instance in a forest package, nature assets react to the wind and they should cast dynamic shadows as they sway back and fourth. In this instance baking lighting isn’t intended to begin with. So the question becomes this, can an asset pack be created for dynamic lighting only without lightmaps since there are cases where assets wont function properly if lighting is baked?

6. Materials

1. General use assets must include effective inputs in the Base Color, Roughness, and Metallic nodes.

You should probably replace Metallic node by Normal node.

3. Specular should not be specified.

Specifying a specular map is actually the proper way of surface definition which is why there’s an input for Specular to begin with. A very very basic example is overlaying cavity by 0.5 and plugging it into Specular slot, which is mentioned in the UE4 Documents as well. It can go up to more complex calculations to replicate real life specular behavior. After all, documentation says leave Specular disconnected for most cases. Not all. Even Epic’s contents extensively specify Specular on non metallics. Such as Kite Demo assets.

4. Metallic can be a constant.

Still not sure why there should be a 0 constant connected to Metallic input for non-metallic materials while the default value for metallic is already 0. Have had submissions rejected in the past just because of that.

7. Textures

2. Textures must be an appropriate resolution for the intended assets.

Generally the larger the better. A 4k material might seem overkill for a pair of shoes but it’s the industry standard to give the end user the high res textures so they have the freedom to downsize or use the full res.

13. Asset Naming and Folder Structure

6. All of the project content should reside within the first folder, that has been named after the submission.

7. Differing asset types should be separated into separate sub-folders within the Content folder.

#6 Says make it like Content>“ProjectName”>SubFolders
#7 Says the content should be put in Content>SubFolders

10. The folder structure should appear as follows in engine:
    - Content
    – MyProject (main project folder)
    — Asset Types (subfolders)

11. The folder structure should appear as follows on the hard drive:
    MyProject (main project folder)
    Config (folder)
    - Content (folder)
    – Asset Types (subfolders)
    MyProject.uproject (file)

Based on #10 statement, #11 is incorrect. It should be like:

     MyProject (main project folder)
        Config (folder)
      -  Content (folder)

•       --    "ProjectName" (folder)
  

•                ---    Asset Types (subfolders)
        MyProject.uproject (file)
  

14. General Quality Standards

5. Submissions must have clear value, usefulness and worth.

Shouldn’t the community of end users decide that instead of the individual who reviews the product for possible errors and mistakes? I’ve witnessed quite a lot of times many products getting rejected from Marketplace and people asking the creator to make the product available to them through other channels.

6. Submissions must add distinct variation, superior quality, or higher overall value than what is currently available on the Marketplace.

There is only 1 issue with that, if there’s a flower package on the marketplace with 40 flowers, you stop releasing any other packages with 5 or 10 flowers because you consider the existing one to have more value, and you close the doors to new content and freedom of choice.

1. Any plugins used in the project must be available on the UE Marketplace.

This says any products can rely on any plugins that are available on the UE Marketplace. Let’s read the next one.

15. Restricted Content

7. Submission must not rely on third-party content not created, owned, and distributed by the seller in order to function.

This says no products can rely on any other content (including plugins) from UE Marketplace as long as it’s not from the same creator.

16. Submission Process

Image must be 1920px by 1080px, in png format, and named <ProductName>_Screenshot.png.

File sizes cannot exceed 1mb for each image.

If file size has to stay under 1mb, which means heavy compression, why not require .jpg instead of .png? In many cases a heavily compressed .png has artifacts that aren’t present on a non compressed .jpg.

Additional feedback

In the feedback emails that were recently sent to sellers for testing there were a few issues worth pointing out.

1. “Shouldn’t have overlapping UVs.”
   There are two scenarios (that I can think of atm) where overlapping UVs are actually intended.

A) You want to seamlessly texture an object and so you do a Spherical, or Cylindrical UV projection or create other types of overlapping UVs.
B) You create an object and UV it, then to save time you copy it around and finally merge them all (in the modeling software). This way your instanced objects share the same UV layout and can also share one material which is very efficient. Since they share the same UV layout it means their UVs are overlapping.
Generally speaking overlapping UVs are an error only when it’s not intended and results in wrong visuals. But most of the time it’s intended and that is why there are tools existing in modeling software for creating overlapping UVs, such as the projection mappings I mentioned above.

2. “UVs are outside the 0-1 space”.
   Having UVs outside the 0-1 space can be intended. That’s when the model is supposed to have a tileable material assigned to it. Tileables aren’t limited to the 0-1 space and can function properly no matter where the UV is.
   Surprisingly, the review team seemed to be taking the two issues above as errors that need to be fixed while in fact everything has been functioning properly and as intended.

…And we all lived happily ever after.

Edit:

5. Meshes

6. Must not have any visible seams.

Like previously mentioned, overlapping UVs are a common way of hiding seams where no other way works. But it’s considered an error by the review team.

[Shirk]

These are some very valid points, Id like to see them fixed in the submission guide.

[DANDERSON]

4. Assets must be UV mapped so that 1 texture tile covers 1m in the game world.

If your object is bigger than 1m your UV’s have to exceed the 0-1 space to follow this rule.

[SE_JonF]

For number 5 I think that was their way of addressing character packs with less than 5 characters. The guidelines used to say you needed 5 characters as opposed to just 1.

For the overlapping UVs, I think that is supposed to have lightmap in front of it. As you mentioned, overlapping UVs can be necessary depending on your texturing style. Same with uvs outside of 0-1 space, that should be referring to lightmaps.

As for seams, sometimes there’s no way to eliminate them entirely unless you’re dealing with solid colors. The best you can do is minimize their visibility, but for some objects it’s impossible due to the nature of UVs.