Chaos Corona 10 for 3ds Max - Daily Builds Discussion

[shortcirkuit]

Max latest update 2023.3 - when you plug in the organic map OSL to the bump slot - it crashes max

[Vlad_the_rant]

Then you're lucky. Happens a lot here.

"The VFB maximizes on a single click" happens because of the wxWidgets library that's used for the VFB itself and which is, apparently, pretty crappy.
It happens when you've been doing something for a little while outside of Max (so a browser, messenger, whatnot) and then click in the vfb directly (without focusing Max or at least the VFB itself first) to try and add a region or just activate it. This is because wxWidgets apparently have trouble catching the clicks that are coming "from" a window outside Max and it's annoying as hell (as well as the VFB generally not being too snappy and the whole wxWidgets thing sometimes throwing errors about not catching mouse clicks.

The only way to fix this is a VFB rewrite (most likely using Qt, like the new error messages dialog) and the VFB rewrite is a thing that's been "coming" for some years now.

Hopefully the implementation of Qt into other parts of the interface is indicative of the VFB woes ending some time soon although rewriting the VFB not being likely in 10 is worrying as it looks like it's another few versions before anything's done about it.

Try disabling the mouse from affecting unfocused windows ("background window scrolling" I think. Google it) and see if and how much it helps (or makes it worse, results may vary).

[rowmanns]

Max latest update 2023.3 - when you plug in the organic map OSL to the bump slot - it crashes max

Hi,

I'm just trying this out and it doesn't crash for me.. Can you upload a scene where you get the crash please?

Link to the uploader is in my signature.

Cheers!

[TomG]

Aha so that is why I never see this happening, I always return to Max from outside it by clicking on Max in the taskbar.

[maru]

The "click resizes the vfb" thing has never happened to me, not even once. Also, please, when reporting something like this, even if it's the most common issue for you and even if it sounds simple, ALWAYS provide reproduction steps, screenshots, preferably videos demonstrating what exactly is going on. Otherwise, we might not be able to understand you and never manage to reproduce the issue for 10 years or more.

[Jpjapers]

The "click resizes the vfb" thing has never happened to me, not even once. Also, please, when reporting something like this, even if it's the most common issue for you and even if it sounds simple, ALWAYS provide reproduction steps, screenshots, preferably videos demonstrating what exactly is going on. Otherwise, we might not be able to understand you and never manage to reproduce the issue for 10 years or more.

Given the sheer number of threads i linked to that are full of long-time daily users that have +1d this request over the last 6 years, its absolutely happening and has been since version 1.6. Until now nobody on the team (or formerly on the team) has suggested a reason why, so the reproduction steps for us users are always going to be 'click the vfb and it happens'. We weren't to know the library that is used on the backend has this focus issue when switching between windows.

To add some more context i have only ever seen it occur whilst IR is running. It doesnt seem to happen if the render has stopped. It also doesnt happen 100% of the time which makes it hard to give you exact details of how to replicate. But now the information above has been posted its clear that its only going to be solved with a rewrite of the entire vfb which is disappointing but clearly nothing can be done about it until that happens.

I am very much looking forward to the day where i can leave the IR running to get a clear idea of what my scene looks like, jump to speak to someone on teams and then come back to the vfb without the possibility of the render that was running maximising and immediately reverting to first pass pixels. Or be on a video call discussing a scene and be able to run someone through an environment on a video call without having it accidentally maximise when i go to adjust a spinner.

[maru]

Isn't it easier and faster to just provide the steps or record a short video demonstrating what is happening instead of writing multiple posts and linking to old forum threads?
If we cannot reproduce something, or we do not have the required details, we cannot know whether it's a library, something in 3ds Max, or maybe your mouse driver.

[Jpjapers]

Isn't it easier and faster to just provide the steps or record a short video demonstrating what is happening instead of writing multiple posts and linking to old forum threads?
If we cannot reproduce something, or we do not have the required details, we cannot know whether it's a library, something in 3ds Max, or maybe your mouse driver.

Not when its intermittent no. As i say for us users the steps are 'click the vfb'. It certainly wouldn't take me 6 years to test it though. Given we never know if or when its going to happen the chances of catching it on video are slim to none unless we screen capture all day. Hence why its useful to show this isnt an individual issue.

The reason i posted the threads is so that you team member was aware of the issue and that it had been logged twice previously so there was no need to log it again.
Now im aware that nobody has been able to replicate it (which is very surprising) i will try and keep a mental note next time it happens to keep some sort of log and let someone know if theres a pattern.

My understanding so far is that:
- Only happens in the IR window, not when youre running an actual render
- Doesnt seem to happen if the render isnt running
- Doesnt happen 100% of the time
- Happens when bringing the window into focus (though i cant be sure it doesnt happen when going between windows within max)
- I believe it sometimes happens even if you bring it into focus by grabbing the title bar.

[rowmanns]

Hi,

If we can't reproduce something we can't fix it. It's really as simple as that, so video recordings are really helpful in this case. The explanation from Papuca3D is accurate, and you have our answer on what we are planning to do to resolve it.

For now I'd like this to end the discussion on this topic, if you manage to reproduce this bug consistently please contact the support team and we will look into it.

Let's keep this discussion to the v10 daily builds.

Thanks.

[maru]

It certainly wouldn't take me 6 years to test and debug it though.

Something reported as "just click", never recorded, never explained in a few steps, and never reproduced by our team may take forever to debug.

If you mean "ability to lock IR resolution" then we do have it logged and as Rowan said:

We have this in our pool of features, but as per usual I can't give a timeframe on when this will happen. I'd say it is unlikely it will make it to v10.

[Jpjapers]

As i said above im surprised nobody internally has had it happen. So unless someone can figure out the exact cause of the issue that causes the locking feature to be required, and video capture it that way, the chances of someone catching it when they happen to be screen recording are slim. I will try and keep a log of when it happens in future and what seemed to cause it.

With every bit of due respect, this is the first time anyone on the team has said that its never been able to be replicated internally across any of the requests/reports i linked to as far as i can see.

The tracker references i posted were all from threads specifically talking about locking the IR window size, not resolution. All of which reported the issue being the window randomly resizing after clicking back into it.

[Juraj]

I feel I can reproduce following bug, or at least I was able to in succession for few times inside production scene, might try today in isolated one but perhaps some QA have bit time to see as well:

1) Put VrScan inside LayeredMaterial (I am using car paint with clear-coat checked on)
2) Put another material on top
3) Start playing with the layered by either:
    A) put mask to the new material
    B) Click on preview during IR of the layered material

I made this crash both outside of IR (just general working) but mainly during IR.

Generally experience quite bit of crashes right now, but then again I am playing with big features like Scans which might be sensitive in IR in combination with other stuff.

[maru]

I made this crash both outside of IR (just general working) but mainly during IR.
Generally experience quite bit of crashes right now, but then again I am playing with big features like Scans which might be sensitive in IR in combination with other stuff.

Reproduced some crashes and logged them.

(internal id=1019834070)
(internal id=1019822834)

[maru]

As i said above im surprised nobody internally has had it happen. So unless someone can figure out the exact cause of the issue that causes the locking feature to be required, and video capture it that way, the chances of someone catching it when they happen to be screen recording are slim. I will try and keep a log of when it happens in future and what seemed to cause it.

With every bit of due respect, this is the first time anyone on the team has said that its never been able to be replicated internally across any of the requests/reports i linked to as far as i can see.

The tracker references i posted were all from threads specifically talking about locking the IR window size, not resolution. All of which reported the issue being the window randomly resizing after clicking back into it.

Hey, all good, I think we were all a bit tired and frustrated yesterday, sorry for that!

Sadly there are user cases which nobody in our team is able to reproduce, this is not the only one. Some common reasons for this are: using specific 3rd party software (e.g. remote desktop managers), using specific hardware (e.g. misconfigured BIOS, some specific mobo+cpu combo), using different system language, etc. In some cases even if we know all those extra details it just happens to the users, but not on our machines (and we have a large pool). This doesn't sound good, but that's what sometimes happens. That's why we are always super grateful for all the tiny details and video recordings.

[Jpjapers]

As i said above im surprised nobody internally has had it happen. So unless someone can figure out the exact cause of the issue that causes the locking feature to be required, and video capture it that way, the chances of someone catching it when they happen to be screen recording are slim. I will try and keep a log of when it happens in future and what seemed to cause it.

With every bit of due respect, this is the first time anyone on the team has said that its never been able to be replicated internally across any of the requests/reports i linked to as far as i can see.

The tracker references i posted were all from threads specifically talking about locking the IR window size, not resolution. All of which reported the issue being the window randomly resizing after clicking back into it.

Hey, all good, I think we were all a bit tired and frustrated yesterday, sorry for that!

Sadly there are user cases which nobody in our team is able to reproduce, this is not the only one. Some common reasons for this are: using specific 3rd party software (e.g. remote desktop managers), using specific hardware (e.g. misconfigured BIOS, some specific mobo+cpu combo), using different system language, etc. In some cases even if we know all those extra details it just happens to the users, but not on our machines (and we have a large pool). This doesn't sound good, but that's what sometimes happens. That's why we are always super grateful for all the tiny details and video recordings.

Its not a problem, we all have days like that especially with software issues!

Perhaps it would be useful for the community and for the team to know which bugs you cant replicate internally and we can help crowdsource some further info. Maybe a stickied thread of 'Things we need more info on' would be helpful. That way we can know what to look out for.