OpenInEditor() opens material child texture in Textures panel, not Materials panel (v6 & v7)

Rhino Developer
,
#1

When using RenderContent.OpenInEditor() on a material’s child texture (from within the Materials panel), the texture is shown in the Textures panel rather than the Materials panel. This differs from the expected/desired behavior seen when selecting a child texture of a Rhino Custom material, where the texture is shown “in place” in the Materials panel.

If the Textures panel is not open, OpenInEditor() still succeeds, but “nothing” appears to happen (in fact it is still selected in the not-visible Textures panel), so it just seems to the user that your button for selecting the child texture does not work. To edit the child texture “in place” the user must select the texture using the Materials treeview, or the material’s breadcrumb nav.

Anyway, that is how things are working here, so I would like to know if this shows a bug, or if there is perhaps some way I need to set the context for OpenInEditor(). Attached is a minimal example that reproduces the described behavior.

TestEditTexture.cs (5.5 KB)

#2

Hi @jdhill,

Thanks for reporting this. It is indeed a bug, and I have filed it as https://mcneel.myjetbrains.com/youtrack/issue/RH-58438

This will be fixed in the next V6 service release.

John

#3

Great, thanks!

#4

I am not sure if this is related to changes made to address this issue, but after updating to the latest build (6.26.20133.12291, 5/12/2020), I find the behavior somewhat changed. Using the same example code provided above, focusing on this part:

if (!rc.OpenInEditor())
{
    var edited = rc.Edit();
    if (edited != null)
    {
        var undo = _doc.BeginUndoRecord("Edit " + rc.Name);
        rc.BeginChange(ChangeContexts.UI);
        rc.Replace(edited.FindChild(_textureSlotName));
        rc.EndChange();
        _doc.EndUndoRecord(undo);

    }
}

  1. In this build, OpenInEditor() is failing, so we hit the rc.Edit() call, and a modal editor pops up.

  2. Already this was behaving a little weird, since you see there we are replacing the content using edited.FindChild(_texturedSlotName). This is because Edit() is returning not the edited content, as stated in the docs, but rather its top-level parent (not sure if this is true in all cases).

  3. That worked for the example, but it is problematic for a slightly-more complex scenario like this:

    image

Here, it will be the grit texture having Edit() called when the link is clicked, but it will be Conductor that is returned, and not being the direct child of Conductor, FindChild will fail to find the grit texture. I guess I can probably find the child that was edited with a recursive search, but it seems like there is an issue here.

#5

Hi @jdhill,

Before I made the fix, it didn’t work at all. Now it’s ‘working’, it must have uncovered a new issue that was hidden before. I will look into this tomorrow. Sorry for the trouble.

Regards,

John

#6

No worries, thanks Sir!

#7

Hi @jdhill,

I’m embarrassed to say that this problem is happening because the documentation is wrong. This is because a long time ago, we changed the way this works in order to solve some very difficult problems, and I forgot to update the documentation to be more accurate. I will do that as soon as I can.

This is how it really works:

When you edit a render content, you are really editing the entire hierarchy. Inside the modal editor you will be able to navigate to any of your three items. When you click OK, the editor returns the top level parent, because it’s returning the entire edited hierarchy. The intention is then that you would replace the entire hierarchy in the document, not just one of the sub-children. Instead of rc.Replace(...) I believe you would need to call rc.TopLevelParent.Replace(edited);.

Please try that and see if it works.

Regards,

John

#8

Thanks, I confirm that replacing the whole top-level parent does indeed appear to work fine for this modal Edit() case.

#9

@jdhill,

Could you let me know once you have had a chance to test if RenderContent.OpenInEditor() now works correctly for child textures? It should be working in the next Rhino 6 service release.

Thanks,

John

#10

Sure thing, I’ll do a thorough test again and let you know.

#11

Hi again John, apologies for the delay, here are my findings:

using 6.26.20136.5111, 5/15/2020

when textures panel is closed at startup:

  - OpenInEditor() succeeds for child material, which is shown in place
  - OpenInEditor() fails for child texture, so Edit() is used to open it in modal editor

when textures panel is open at startup, or is opened afterward:

  - OpenInEditor() succeeds for child material, which is shown in place
  - OpenInEditor() succeeds for child texture, which is shown in textures panel

when textures panel is closed after having been open:

  - OpenInEditor() succeeds for child material, which is shown in place
  - OpenInEditor() succeeds for child texture, but textures panel is closed, so "nothing" happens

using 7.0.20140.14505, 5/19/2020

all cases:

  - OpenInEditor() succeeds for child material, which is shown in place
  - OpenInEditor() succeeds for child texture, which is shown in place

So, behavior for material-based content is as expected/desired in all cases on both versions. And behavior for texture-based content is as expected/desired on V7, but not V6.

#12

RH-58438 is fixed in the latest Service Release Candidate

#13

@jdhill,

Thanks for the extensive report. I think I may have jumped the gun asking you to test in V6 as the service release was not quite ready. If you try again now, you should find it fixed, but please let me know if there is still a problem.

Thanks,

John

#14

Seems to be working slick now, thanks!