Announcement

Collapse
No announcement yet.

Review Information! *Please Read*

Collapse
This topic is closed.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Review Information! *Please Read*

    Hi Guys!

    In an effort to make the review process a bit easier and more transparent for you all, we’ve put together a Technical Review Checklist (TRC) that you can download and preview before you submit your assets! This is the same checklist we use to review your assets, so this gives you a good idea of what we’re looking at when we receive your assets.

    As always, there will be some edge cases that will take additional consideration and there are a few things that people seem to have some trouble with, such as naming conventions, file structure, etc. To help clarify some of those cases, we are putting together explanatory text and tutorials (which we will drop here when we post those) so you guys can have that to reference before you submit as well. The hope is that sharing this information with you will give you a better understanding of what we look for in an asset during the review process.

    Please note that this is for reference only and to provide you with an opportunity to give your content a precursory check before undergoing review. This is not intended to be a “fastpass” for release, as all assets will still be subject to a review once they hit our desks. Using this to pre-check your own product prior to submission has the potential to expedite the review process by minimizing the need for changes due to discrepancies outlined in this list.

    If you guys have any questions please let us know!

    Thanks,

    Stephanie
    Attached Files

  • #2
    Downloaded! thank you.

    The more the community handles our own stuff by ourselves the better; I hope review times significantly decrease after these measures you've been taking.
    | Finite State Machine | Object-Pool Plugin | Auto-Save Plugin | Anti-Cheat Plugin |

    Comment


    • #3
      Hi [MENTION=29169]Smarkoff[/MENTION],

      The wrong review rules are rather more annoying than review length.
      I'm gonna break it down for you with a detailed description on what is wrong.


      Folder hierarchy is structured correctly
      The folder hierarchy suggested by Marketplace is against the norm. It doesn't work well with production. Epic Games does not follow the same suggested folder hierarchy for their own internal projects. Thoroughly discussed here. It results in nothing but chaos to move every texture present in a project to a folder called "Textures". Move every mesh included in the project into a folder called "Meshes". Not only this makes it super hard for developers to work with their own content, it makes it even harder for the end users who have significantly less knowledge about the project. [MENTION=3692]RyanB[/MENTION] can confirm this.

      All Materials are PBR (contain BaseColor, Roughness, and metallic nodes)
      Metallic pin of the material has a default value of 0. (So when nothing is connected to it, it reads as 0). Marketplace rejects products that do not have a 0 connected to their Metallic pin. They essentially require people to connect a 0 to 0 otherwise they work is turned down. And sometimes people miss one material and their work is rejected just for that, adding at least 1 more week delay to the whole process, which is not a valid reason to begin with. This should be stopped. [MENTION=3692]RyanB[/MENTION] can confirm this too.

      No overlapping UVs
      Overlapping UVs in many cases are an essential part of the process. Having overlapping UVs doesn't mean something is wrong. There are many workflows and techniques that can be used to boost the asset quality with use of overlapping UVs and this should be changed to "No overlapping lightmaps" instead. There's no valid reason behind rejecting packages due to having proper overlapping UVs. [MENTION=3692]RyanB[/MENTION] can confirm this one as well.

      I've tagged Ryan here because it seems like the content creators here aren't trusted when it comes to giving feedback about the review process. But Ryan should be definitely trusted.

      -

      Like I mentioned in the other thread and people agreed, the suggested folder structure is the biggest issue and is massively decreasing the efficiency of working with the content. The larger the content pack is the worse effect the suggested folder structure has.
      Last edited by Maximum-Dev; 08-01-2017, 12:28 PM.
      Artstation
      Join the support channel
      Gumroad Store

      Comment


      • #4
        let me add to that

        Epic/Unreal content is used for display/example only
        then you can basically kick off most vfx-packs, most of them use at least some basic noise texture/normal or some of the generic smoke flipbooks.
        Imho this is more than fine, as long as (speaking for vfx only) as long as the final product does something different with that file.

        Custom Blueprint nodes contain "Static" prefix
        I can already hear Allar scream from the other side of the planet.

        but besides what MaxDev and I pointed out, all sounds fairly well.

        Comment


        • #5
          The requirements would be more well thought out if you also included a "Why?" collumn, as in, why each requirement exists.

          List of Black Fang Technologies' projects -> https://forums.unrealengine.com/unreal-engine/marketplace/119868-list-of-black-fang-technologies-projects

          Comment


          • #6
            Casts contain both a pass and fail condition
            If I don't want to do anything when cast fails, what am I supposed to do? Am I misunderstanding this?
            HeadsAndBrains
            MARKETPLACE | YouTube

            Comment


            • #7
              Yeah the no overlapping uv's requirement has to be an error. I'm assuming it should say no overlapping lightmap uvs? (which would make sense) Overlapping uvs are essential to many texturing methods, including trims. If you have a model with a repeating element you aren't going to waste uv space by creating unique uv islands for it. And as previously alluded to, trim sheets will always have overlapping elements. This is very common in game development, and Epic has even used overlapping uvs themselves so this has to be a mistake.


              SEJonF.com | Twitter | Youtube | ArtStation | WIP | UE4 SciFi Assets Hallways | Interiors | Props | CMD Center | Engineer Halls & Props | Free Asset Demo | Fantasy WIP | Ice Shader

              Comment


              • #8
                Originally posted by Nicat View Post
                If I don't want to do anything when cast fails, what am I supposed to do? Am I misunderstanding this?
                I just do a Print String only to the log to log the cast fail. Too bad there isn't a DoNothing node just so you and reviewers can see that you specifically don't want to do anything.

                Plus I think this is only a recommended check, they won't fail you for not having a fail condition on a cast.
                Marketplace Asset (Released): FPS Battle Royale Template with Gamesparks

                Twitter: Spyke_Dev | Discord

                Main Website

                Comment


                • #9
                  Not intending to submit anything to marketplace anytime soon, but:

                  Assets snap cleanly on 10 cm grid
                  That is totally odd. It is up to pack's author to choose desired snap.

                  No overlapping UVs
                  Should be changed to something like Unwrap on UV1 is suitable for lightmass.

                  All Materials are PBR
                  This is a bit vague. If it looks good, but breaks PBR, whats the deal ?

                  Comment


                  • #10
                    Originally posted by Smarkoff View Post
                    Hi Guys!

                    In an effort to make the review process a bit easier and more transparent for you all, we’ve put together a Technical Review Checklist (TRC) that you can download and preview before you submit your assets! This is the same checklist we use to review your assets, so this gives you a good idea of what we’re looking at when we receive your assets.

                    As always, there will be some edge cases that will take additional consideration and there are a few things that people seem to have some trouble with, such as naming conventions, file structure, etc. To help clarify some of those cases, we are putting together explanatory text and tutorials (which we will drop here when we post those) so you guys can have that to reference before you submit as well. The hope is that sharing this information with you will give you a better understanding of what we look for in an asset during the review process.

                    Please note that this is for reference only and to provide you with an opportunity to give your content a precursory check before undergoing review. This is not intended to be a “fastpass” for release, as all assets will still be subject to a review once they hit our desks. Using this to pre-check your own product prior to submission has the potential to expedite the review process by minimizing the need for changes due to discrepancies outlined in this list.

                    If you guys have any questions please let us know!

                    Thanks,

                    Stephanie
                    Howdy Hi Steph!

                    Just reading through the Assets.pdf, and there is still something that just reaches out and nails. Most of this is subjective, not empirical. I am referring to the blueprints section, but the same can be said for the meshes as well (Modular pieces are adaptable for re-purposing? really? so I build a modular submarine, and the hull is comprised of 3 pieces, which pieces are actually able to be re-purposed? who determines this? How is Epic going to be able to lay down an empirical guideline as to what re-purposing is? if I make a mesh of a Goat? (you know to go with the Unicorn and Duck! lmao)) But specifically blueprints......

                    First it is Epic Games Incorporated (EGI) Market Place, ergo, I am not trying to tell anyone at EGI, what they should do at the MP, only what makes sense to me. The MP would be better off, if it were to get out the dealing with subjective matters. Define what the MP is looking for, and then state it.

                    Blueprints use comments appropriately....
                    Blueprints are clean and easy to read... Subjective as all get out. Someone that is use to writing compilers, is going to be a babe in the woods, when looking at anything of a graphic nature that is of sufficient complexity to make it worthwhile to buy. I highly suggest to get out of the business of trying to make the blueprints a de-facto tutorial. If it's garbage code, it's garbage code, and putting pretty comments on it, means it's just garbage code, with pretty comments. Unfortunately comments don't make code better. If the MP, wishes to have robust code (error recovery, streamlined functionality, top down decomposition (yes a 80's/90's term, that some goofy person tried to turn into a Compiler that goes by the name of C++, and relabeled to be called "OOP", yes it was OOPS for sure). Then it's going to need programmers with real world experience for the reviews to accomplish this.

                    Does every node still have to have a comment associated with that? To be honest, I have moved a fair number of "node sequences" into macro libraries, just because I got tired of commenting a NOT Boolean with, "Flip the Boolean value". And yes, I was told by an Epic reviewer that ALL nodes had to be commented. So when I am told that, and I wish to be involved, I have little choice, even though this whole commenting situation, seems foolish to me. I felt like I was talking to someone that had never really programmed beyond a "Hello World" level. The reason I say this, is that most programmers that have been around a bit, "know" the value of commenting, that a high level overview of what the function is going to do, lays out the skeleton of the function, and the individual comments that are in the code, just add some meat to the bones. But every node......?

                    Casts contain both a pass and fail condition.... Well the way the cast node is set up, is all wrong to actually encourage this. With the two EXEC paths on top of each other, and then the "cast" output being below the EXECs. This means, that more than likely, that the wires are going to cross. unless the error path is so trivial in nature, that one sits there and wonders why the blueprint was made larger to accomplish so little. The cast value pin, should be between the two EXEC pins. Now I feel positive that the MP is not in charge of something like this, still making this a requirement leads, right into the wires crossing, or the failure being ignored.

                    I have also been told that NO wires can cross, none, nada, zilch... had a failed submission over this, fixed it, and never resubmitted, when a friend sent a screen shot of a blueprint that had just passed, which was atrocious with crossed wires...

                    Custom Blueprint nodes "Static" prefix.... Prefix to the name that appears in the titlebar area of the actual node? Prefix in the C++ code for the library?
                    Custom Blueprint nodes from plugins categorized with plugin name as preface... So this means, that my company name is IceWare Inc, and I truncated that to IW when I wrote my library for all functions, and this is not good enough? Now I have to have larger nodes, making the blueprint less readable because each node, is going to have the full name of the library as a prefix to the actual function name itself?

                    Functions, variables, and events use names that reflect intended purposes... Who determines that? Surely EGi doesn't feel that all programmers think alike, and that given a sufficiently large enough population of programmers they would all arrive at the same variable name. So who determines whether a name "reflects" anything at all. One large project I worked on (an operating system), in the assembler code, the labels, were nothing more than a 2 letter prefix, followed by a number, evenly divisible by 1000, and at first glance, maybe that seems silly, but when shooting a dump it makes a lot of sense, in that you know instantly, for the externs, that higher numbers mean that the location for the entry point to the function, is higher in memory. In some ways, this is much better, than the garbage floating around now of "ThisIsTheNameOfAFunctionThatIsSupposedToBeMeaningfulButICouldNotThinkOfARealMeaningfulNameDealWithIt"

                    It just seems to me, that the guidelines are "loose" as all get out, open for many interpretations, and extremely subjective. It would seem to me, that if the guidelines were more empirical in nature, everyone would be better off. The people that submit to the MP, talk to each other, a lot. When rejections feel that they are subjective... this can lead to less than a great PR situation. Yes, EGI, can just respond, "deal with it, it's our sandbox". Because it's is EGI's MP, yet I think this would be a situation that EGI would seek to avoid.

                    Thank you for your time!

                    Jay Ice

                    IceWare

                    P.S. none of the above should be construed as being personal in any fashion, nor should it be construed as being directed specifically at Steph for it is definitely not.

                    Comment


                    • #11
                      Originally posted by Deathrey View Post
                      Not intending to submit anything to marketplace anytime soon, but:


                      That is totally odd. It is up to pack's author to choose desired snap.


                      Should be changed to something like Unwrap on UV1 is suitable for lightmass.


                      This is a bit vague. If it looks good, but breaks PBR, whats the deal ?
                      Even tying it to uv1 is restrictive. Some developers use uv2 for lightmaps and uv1 for other texturing methods. Quite frankly there should just be a requirement for non overlapping lightmap uvs which I'm assuming this was meant to be. Otherwise it's not only restricting common texturing methods but hypocritical given Epic also utilizes them in their games and content examples.

                      Agreed on the 10cm part too, though this has been here since the beginning of the marketplace so I figure most are used to it by now.


                      SEJonF.com | Twitter | Youtube | ArtStation | WIP | UE4 SciFi Assets Hallways | Interiors | Props | CMD Center | Engineer Halls & Props | Free Asset Demo | Fantasy WIP | Ice Shader

                      Comment


                      • #12
                        Originally posted by SE_JonF View Post
                        Even tying it to uv1 is restrictive. Some developers use uv2 for lightmaps and uv1 for other texturing methods. Quite frankly there should just be a requirement for non overlapping lightmap uvs which I'm assuming this was meant to be. Otherwise it's not only restricting common texturing methods but hypocritical given Epic also utilizes them in their games and content examples.

                        Agreed on the 10cm part too, though this has been here since the beginning of the marketplace so I figure most are used to it by now.
                        The 10CM thing is ridiculous to me, as I turn all snapping off in the editor. A seller can use a 10cm snap, a 21.89764532cm snap for all I care. Funny thing is, I do care, that all the modular pieces do fit well together, but not on some silly arbitrary grid.

                        Comment


                        • #13
                          Also, are LODs required now? That has never been the case, and given that they can be created in engine to suit the exact needs of the consumer why should they be?


                          SEJonF.com | Twitter | Youtube | ArtStation | WIP | UE4 SciFi Assets Hallways | Interiors | Props | CMD Center | Engineer Halls & Props | Free Asset Demo | Fantasy WIP | Ice Shader

                          Comment


                          • #14
                            Originally posted by ToxinGaming View Post
                            I just do a Print String only to the log to log the cast fail. Too bad there isn't a DoNothing node just so you and reviewers can see that you specifically don't want to do anything.

                            Plus I think this is only a recommended check, they won't fail you for not having a fail condition on a cast.
                            Even if it doesn't fail the submission -which I hope is the case-, I would like to know why this is even included out of curiosity. Printing to log on every failed cast just fills the log unnecessarily and I definitely wouldn't want to have random prints in my log when I am trying to debug something else. Also, isn't leaving fail path empty a faster way to express not wanting to do anything, instead of having an empty print?

                            I just can't get my head around the fact, someone thought this was a good idea to add to list. I might be missing something because unlike other weird requirements, I can't find the reason for this.. even a weird one.
                            HeadsAndBrains
                            MARKETPLACE | YouTube

                            Comment


                            • #15
                              Even tying it to uv1 is restrictive. Some developers use uv2 for lightmaps and uv1 for other texturing methods. Quite frankly there should just be a requirement for non overlapping lightmap uvs which I'm assuming this was meant to be.
                              Yeah, something like that.

                              Then there is this:
                              Specular is not specified unless used
                              It contradicts itself. If you plug in something there, it is already used. If I consider that I want to dampen specular, it should be my decision as author, and should not be regulated by any kind of submission guidelines. I understand that it is meant to be a precaution against sellers trying to cheapskate and slap together materials out of unedited oldgen textures, which are not suitable for PBR, but still, this checklist item in its present form is slightly off.

                              All textures are appropriate resolutions for their respective assets
                              What can be considered appropriate? What if the pack intentionally has low texel density ? It is somewhat vague.

                              Following that logic, a good deal of rules alike could be set for graphical part.

                              As example no more than 15% of UV area should be left unused in any unwrap, or none of any mesh triangles should have longest to shortest edge ratio higher that 1:20
                              While theoretically it can be an unbiased indicator of... khem... quality, that is nonsense in terms of both adhering to and enforcing such a rule.
                              I think that visuals should be judged by sole discretion of the reviewer, even though it might not always be objective.
                              It is pretty obvious when visual part of the asset is of a low quality, but it is remarkably hard to write a set of indicators, that could be mindlessly followed to judge that.

                              All items regarding general project structuring and naming seems to be totally valid though.
                              Last edited by Deathrey; 08-01-2017, 02:14 PM.

                              Comment

                              Working...
                              X