upgraded to .7, preview 2 - unable to run basic scenarios, errs with duplicate categories validation

[lessw2020]

I upgraded today to 0.7, preview 2 in order to make sure I am working with the latest codebase.
After hitting issues with my custom code from .6, I decided to just make a whole new project and rebuild from scratch, and then work on importing my earlier code after that.

However, I can't get a basic perception fixed length scenario going with the 2D object labeller as I immediately hit this error:

This is specific to the background placement randomizer. As a result the distraction wall has no textures applied and also appears to be quite blurred:

I'm using 2020 and HDP. Thanks!

[sleal-unity]

Hi Less!

The duplicate categories error is a runtime error that can occurs when a scenario validates the parameter settings configured on its randomizers during the first frame of the simulation. This specific error will occur when something like a Texture2DParameter is assigned the same texture twice in its list of options.

One quick way to confirm that this error is valid is to remove all but one option from each categorical parameter and see if this error disappears. Next, you can go through each parameter one at a time and re-add your options and investigate for which parameter the error is firing on. However, let me know if the error continues firing even though your categorical options are all unique. That would be no bueno.

On another note, I'll see if I can add additional debug information to this error so it's easier to discover which parameter and randomizer this exception is being thrown from and what specific value has been duplicated.

[lessw2020]

Hi @sleal-unity! Thanks for the fast response and info. I did narrow it down further - it appears that if I only select a single folder for textures (either the sample ones, or my own custom textures folder), then this error does not show.
However, if I add a second folder to bring in more textures, which worked on prior versions, then I get this duplicate category error. So it's not so much a specific item, but rather simply pulling from two or more different texture folders via the 'add folder' option, that makes it think it has duplicate categories.

That said, I also still have two additional issues that I thought were caused by the above but apparently are not: 1 - No textures are applied to the background objects. I've tagged them and triple-verified, re-tried in a new scene, etc. but the textures are never applied at run time. Is there a way to set a breakpoint or similar and debug in to see what is going awry? 2 - I get a lot of severe blurring, which I didn't see before on the background objects (as if the frame is captured mid placement with many of the items still in movement, instead of after placing). Thanks again for all the help!

[lessw2020]

Note - I also see odd behaviour with the texture randomizer. If I add a single texture, and run, then it suddenly disappears from being shown after the run. Similarly, if I remove things, they suddenly re-appear after the run in the texture randomizer menu. Not sure if related to textures aren't being applied issue, but wanted to mention it.

[sleal-unity]

Thanks again for the detailed feedback Less. I'm in the process of recreating the perception tutorial project in HDRP to do my best to reproduce these issues your running into.

To address the blurring issue, there are a few settings in HDRP that can cause this, but I'll name the two most common causes:

1. Motion blur post processing is enabled by default in HDRP. To disable this, start by adding a volume component to an empty GameObject in your scene. Next, click the add override button to add a motion blur override from the popup menu. Lastly, click the intensity override toggle in the motion blur menu and make sure the intensity value is set to zero.

2. The camera in HDRP uses TAA by default. This acronym stands for Temporal Anti Aliasing and is a great technique for using past frame data to smooth out the jagged edges of subsequent frames that are common in rasterized rendering engines. However, since every frame is completely randomized, using past frame data to improve subsequent frames is not really a good idea and can introduce artifacts around the edges of rendered GameObjects. I would recommend using the Subpixel morphological anti-aliasing option instead of TAA.

[sleal-unity]

Just got an update from @mkamalza on the adding multiple folders issue. Turns out this is indeed a bug in our code and @StevenBorkman has recently created a PR addressing this. Hopefully we can get this update to you soon.

[lessw2020]

Thanks for the updates @sleal-unity! Glad the folder issue was isolated, will work around that for now and look forward to the PR. 1 - The volume game object plus motion blur to 0 for blur suppression worked great. Back to crisp background shapes. (of note, my profile for sky and fog doesn't have motion blur. I had to use HDRPDefaults or VolumeGlobal profile to get access to the motion blur).

2 - Thanks for info regarding Temporal Anti-aliasing. I'm using Subpixel already as that tested out the best earlier when adjusting anti-aliasing generically, but appreciate the detailed info regarding TAA and artifacts!

I'm still unable to attach a texture to the background shapes. Fortunately I have to gen some images for our mobile project that requires a white background (perfect timing) so I'm not blocked atm, but appreciate any info on resolving the inability to apply textures. Thanks again!

[sleal-unity]

No problem, but I think you had a few more questions throughout this thread that I still need to address. Let me see if I can hit them all in this post.

In regards to breakpointing, you can indeed configure the perception package for more hands on development so you can breakpoint perception package specific C# code. You just need to do the following:

• Clone the perception package to disk
• Checkout the perception package version you want to debug (whether it be master or a specific release like 0.7.0-preview.2)
• Add the cloned package to the project's manifest.json file. Here's a guide on how to do that.
• Add the package to the testables section of your project's manifest.json file. Here's how to do that. Scroll down to the "Enabling tests for a package" section for this doc.

Now you should be able to breakpoint the perception TextureRandomizer for testing in something like JetBrains Rider or Visual Studio. The debuggers for either program can connect to a live Unity editor.

Lastly, I'm also scratching my head about the texture issue. I'll try to recreate an HDRP project on my end to be sure that we're overriding the textures of tagged GameObjects properly for HDRP's default lit shader. Could you provide some screenshots of how your objects are tagged and your scenario's randomizer configuration? This might clue me into the issue that's affecting your project.

[lessw2020]

Hi @sleal-unity - thanks for the info above! Great to know how to breakpoint in to help isolate things. 1 - I'm attaching an image set to show my settings for the lack of texture.
I reset everything to just use items from the sample assets to try and make it as reproducible/clean as possible.

A - Tagged prefabs:

B - Scene settings - I added the folder for the background objects and the folder for the sample textures only:

C - Resulting output- just generated 5. (Side note - I always get a blank rgb_2 image....haven't figured out how to avoid that but it's not part of this issue).

[sleal-unity]

Alrighty, I think I've got this sorted out.

So the unrandomized textures problem stems from the fact that the tutorial assets are using a custom shader (made with shadergraph). This shader uses a hard coded property called "_BaseMap" to assign albedo textures to the shader. This is good, because the default lit shader for URP also uses the same "_BaseMap" property name for its albedo texture. Unfortunately, HDRP breaks this pattern and uses the name "_BaseColorMap" as its albedo texture property name. We have a compiler define in the TextureRandomizer that automatically uses one name or the other depending on the current project's render pipeline, but in this case, the tutorial assets are using a custom shader that just so happens to share the same property name with the default URP lit shader. So yeah, I'll need to update the TextureRandomizer to accept a custom shader property name.

In the meantime, you can use the following custom BackgroundObjectTextureRandomizer instead of the included TextureRandomizer to get you unblocked. It uses the correct shader property name for the custom HueShift shader used for the tutorial background objects.

using System;
using UnityEngine;
using UnityEngine.Perception.Randomization.Parameters;
using UnityEngine.Perception.Randomization.Randomizers;
using UnityEngine.Perception.Randomization.Randomizers.SampleRandomizers.Tags;

/// <summary>
/// Randomizes the material texture of objects tagged with a TextureRandomizerTag
/// </summary>
[Serializable]
[AddRandomizerMenu("Perception/Background Object Texture Randomizer")]
public class BackgroundObjectTextureRandomizer : Randomizer
{
    /// <summary>
    /// The shader texture property to apply the random texture to
    /// </summary>
    static readonly int k_BaseTexture = Shader.PropertyToID("_BaseMap");

    /// <summary>
    /// The list of textures to sample and apply to tagged background objects
    /// </summary>
    public Texture2DParameter textures;

    /// <summary>
    /// Randomizes the material texture of tagged background objects at the start of each scenario iteration
    /// </summary>
    protected override void OnIterationStart()
    {
        var tags = tagManager.Query<TextureRandomizerTag>();
        foreach (var tag in tags)
        {
            var renderer = tag.GetComponent<Renderer>();
            renderer.material.SetTexture(k_BaseTexture, textures.Sample());
        }
    }
}

In regards to the first frame always being white, this is likely due to that fact that HDRP uses auto-exposure by default to control the camera exposure. The default directional light in HDRP is very bright (because it's the sun) and will cause the camera to rapidly climb from its default underexposed state over the course of a few frames when the simulation first starts, causing at least the first frame to be white.

I'm not 100% sure if this will be an issue after your texture randomizer is working properly, but if your first image is still white, you can use a manual exposure configuration by selecting the "Fixed" mode in your exposure override within your scene's volume settings. This will work fairly well as long as you are not randomizing your light settings.

[lessw2020]

Fantastic, thanks for ferreting this out @sleal-unity! Will run this first thing in the morning and update.

[lessw2020]

Working like a champ now, thanks again!