Chaos Corona 13 for 3ds Max - Daily Builds Discussion

[LukaK]

Please please pretty please could we finally get a toon outline shader? Or even just expand coronawire to include a profiles mode (like sketchup profiles) without needing to outline every face?

At work currently to produce elevations with just the profiles outlined and not every polygon we are relying on a free third party exporter to export to sketchup and then produce them in there. If corona had the ability to render outlines it would have saved me genuinely weeks of work in the last two months.

It has been requested since 2014 for the exact same purpose and theres a TON of support for it every time someone posts about it. I dont think ive seen many people asking for ink and paint style shading. Just this outlines feature.

I imagine youll say you cant make any commitments to features etc etc and to post it in the feature requests etc which is fine. But toon outlines have been requested since the beta days and are consistently requested still and are one of the most backed and popular requests every time its mentioned. So if you could consider this for v13 it would make lots of your core user base very happy.

Agree 100%. But it seems they just don't care what customers are asking for for almost a decade. Corpo behaviour at its finest, thanks to Chaos I guess.

[maru]

Hmm, I don't understand the strong reaction regarding the history autosaving. Let me try to explain what the original issue was and how we ended with the current solution:

First of all, there was a long and thorough discussion before making any decisions. The discussion involved the devs, support, and QA.

The issue was that while rendering in "silent" mode (no UI, no VFB, for example distributed rendering) with the history autosaving enabled, a pop-up message could appear when the HDD size / number of snapshots limit is reached, asking the user whether to delete the history snapshots or not, and this would halt rendering. So theoretically you could start rendering in the evening and wake up to see only 10% of your animation rendered.

We were considering either ignoring the popup in silent mode or disabling the history autosave in this case. The thing is, we could not think of any scenario where a user would like to use silent rendering and sequence rendering and use the history autosave. We assumed that you either set your main output file or you use the "regular autosave" (not history autosave) for this. It can also store images on render end, and you can set the limit to 0, and it saves to CXR format.


Here are my requests/questions:

Okay, sorry about that. I'll try to be more clear. I just meant this (render history A/B comparison). When I use DR, it no longer saves the CXR file. But without DR it saves it.

Please explain why exactly you need the history autosave here and the "regular" autosave is not enough for you. What is your exact workflow, what you are achieving thanks to using the history autosave?

Can you explain why exactly you would like to autosave history items when using DR? What's your workflow?

Am i missing something here?  But surely the answer is "for the exact same reasons as when not using DR"

And what exactly is that reason? Can you please provide a use case? Why not use the "regular" autosave instead of the history autosave?

Agree 100%. But it seems they just don't care what customers are asking for for almost a decade. Corpo behaviour at its finest, thanks to Chaos I guess.

This is simply not true and this case has nothing to do with Chaos (as in: the whole company, or other people than the Corona team). Please check this article: https://www.chaos.com/blog/behind-the-scenes-the-corona-renderer-development-process

"Which does not mean we always get it right (we don’t, whether that’s in picking features, or estimating how long things take). What we can say is this though – even when we get it wrong, our heart was in the right place!"

"The article mentions how important user feedback is, so here’s how you can become part of the process! Keep up-to-date with the Changelogs in the daily builds sections of the forum:


Corona for 3ds Max Daily Builds
Corona for Cinema 4D Daily Builds

The Changelog posts in those sections detail what is in each daily build, giving you a chance to test new features well before release. Then you can give us your feedback in the discussion/reporting threads there too, where we welcome suggestions for those new features, as well as any reports of problems using them."

Please note that:
- Saying "this feature is a broken mystery" will help literally nobody. You should instead explain what exactly is wrong and how we can improve it.
- Saying "surely the answer is "for the exact same reasons as when not using DR"" will help literally nobody. We need to know what exactly you mean by "the same reasons".

[dj_buckley]

Can you explain why exactly you would like to autosave history items when using DR? What's your workflow?

Am i missing something here?  But surely the answer is "for the exact same reasons as when not using DR"

And what exactly is that reason? Can you please provide a use case? Why not use the "regular" autosave instead of the history autosave?


Please note that:
- Saying "surely the answer is "for the exact same reasons as when not using DR"" will help literally nobody. We need to know what exactly you mean by "the same reasons".

I was more so getting at the fact that whether it's a DR render or single workstation render shouldn't make a difference as to whether a certain feature works or not.  Most of us use DR simply to get faster renders, so if something works when doing a local render, you'd assume it would work when bringing DR into play, because you're not changing anything workflow wise other than wanting to get a faster render by adding more processors into the mix.

Also, I thought the OP of that comment had already given his reasons "I've been using this as a way to save the full CXR file since there is no other way to do it."

As I understand it, this feature worked previously but the functionality has since been changed.  Was the change documented/announced anywhere or was it another under the hood change that users weren't notified about?  Because that's happened before and I remember users weren't too happy then.

Also if you're basically saying "you don't need this feature" which is certainly what it sounds like.  Then why does it/did it even exist as an option in the first place?

Ultimately the users determine how they use the product and if the option is there, chances are someone will find a reason to use it.

Also I wasn't try to be confrontational/unhelpful in any way.  Frood actually beat me to it when they said "DR on/off should never ever make any difference while using any feature anyway."  That's all I was getting at

[maru]

Also, I thought the OP of that comment had already given his reasons "I've been using this as a way to save the full CXR file since there is no other way to do it."

We understand what you would like. But we do not understand why. None of the replies so far explains why you are asking for this. The only valid answer would be explaining to us what exactly you are doing with the history autosave feature, not just saying that you are using it.

As I understand it, this feature worked previously but the functionality has since been changed.  Was the change documented/announced anywhere or was it another under the hood change that users weren't notified about?  Because that's happened before and I remember users weren't too happy then.

It was announced in the V13 and V12 HF1 changelog.

Also if you're basically saying "you don't need this feature" which is certainly what it sounds like.  Then why does it/did it even exist as an option in the first place?

Nobody is saying that, I am just trying to understand you (and failing so far). I also do not understand why you can't use the regular VFB autosave feature for this (not the history autosave).

Ultimately the users determine how they use the product and if the option is there, chances are someone will find a reason to use it.

Of course, and we need to know that reason if we made a mistake and should revert some behavior. We do not understand the reason so far.

[dj_buckley]

Let's be clear.  I don't personally use this feature.  I was simply confused as to why DR would make any difference to the OP's reasons (whatever they are) whatsoever.  That's it.  Nothing more.

One thing that does frustrate me sometimes with this forum, is simple questions being answered with questions and requests to justify your reasonings.  So perhaps it just got my back up a little bit and I replied with a reactionary response.

[TomG]

Our questions are so we can prioritize this, and see if any changes are required. Naturally we don't want to assume that we think is correct - we want to hear from you all on what and why you use a certain approach / feature / workflow, as there may be things not obvious to us. It is not an attempt to deflect, by answering a question with a question, just that we are trying to properly understand how and why something is used in real world work scenarios, so we can prioritize things accordingly (far better than us just assuming we know what is "the right way" to do something, right?). Hope this helps clarify why all the questions!

[TomG]

PS - also, the questions are so that if a change or fix is required, we get it right first time (we hope!), and that again means we have to understand precisely why this approach is needed (in this case, vs. other things that seem to us to achieve the same goal... but we may be wrong :) ).

[Frood]

The discussion involved the devs, support, and QA.

"The article mentions how important user feedback is, so here’s how you can become part of the process!

So where is the user here? There has not even been a daily containing those changes, it just has been released in a final hotfix version with no chance to discuss anything, not to mention testing.

- Saying "this feature is a broken mystery" will help literally nobody. You should instead explain what exactly is wrong and how we can improve it.

I'd say instead, quoting a single expression without context won't help.

If you read 1) and 2) it should be clear. VFB history is an interactive feature and it got crippled because of some situation that may occur if users brain is in idle state. I already mentioned, that disabling history autosave in slave mode of course is something that should have been there out of the box. But why those master and sequence restrictions? No one would render a complete animation having history autosave activated. If so, it is just a user error, nothing more. Corona does not check dozens of other user errors like that (worse ones that should be handled at Corona side included). But in this case it does, while obscuring the feature at the same time.

And exactly right now I use that feature in Corona 11: the client has chosen a few shots and I render those frames into history because there will be some changes. And I need the current state for later comparison. And yes, it's a frame sequence (with disabled output). And yes, I have some DR nodes active to speed things up. The use case is to use the feature, that's it.

The obvious solution for me would have been to check at render start if 1. VFB history is enabled and 2. if a sequence is going to render and if so, to issue a warning when starting to render. This should be enough to solve that issue (if it even is one) without restricting a feature that has been working perfectly until now.

Finally about "mystery": try to make a lists of DR render on/off, iterative render, interactive render, frame sequence, single render where you would see the consequences of using VFB history autosave. And try to create a support article about it. And compare the result with the (former) philosophy of Corona.


Good Luck

[dj_buckley]

Our questions are so we can prioritize this, and see if any changes are required. Naturally we don't want to assume that we think is correct - we want to hear from you all on what and why you use a certain approach / feature / workflow, as there may be things not obvious to us. It is not an attempt to deflect, by answering a question with a question, just that we are trying to properly understand how and why something is used in real world work scenarios, so we can prioritize things accordingly (far better than us just assuming we know what is "the right way" to do something, right?). Hope this helps clarify why all the questions!

I think the biggest issue is that when people post on the forums, they're generally mid-job and are looking for a quick fix/answer to a new problem.  The last thing they want/need is to have to put a full business case together in order to get a response to a relatively simple question.  And they most definately don't want to have to change all or part of their workflow mid job just to be able to achieve the same thing they were achieving previously

[Frood]

And they most definately don't want to have to change all or part of their workflow mid job just to be able to achieve the same thing they were achieving previously

At any time, kick legacy stuff if outdated or designed newly and properly. But what is happening here is pure activism, destroying (again) a working and useful feature.


Good Luck

[karelbuhr]

Hello,

I'm not upset or anything. :)
So I'll try to explain in more detail:

I've been using history autosaves to save CXR files for quite some time. It was fine with me that these files were deleted after 3ds Max or C4D was closed because I would copy them to a folder with renders or rendered elements before closing. This way, if my clients wanted any changes to the image in progress, I could easily make them using the full CXR file in the VFB. That's why I prefer to keep these files. I agree that it doesn’t make sense to enable this for a single station and disable it for DR. I have two PCs with approximately similar configurations, so my render times are twice as fast. That’s why I use it. Before version 12, it sometimes saved thousands of CXR files, and I didn't mind. The problem now is that these files are no longer deleted after the application is closed, which causes that pop-up dialog to appear. In my case, it has frozen 3ds Max a few times.

If I can achieve the same result with Output Autosave without saving tens of GB for each image (which would use up my TBW within a year), I'm okay with that.

Have a nice day,
Karel

[maru]

Please try the autosave feature and let us know if it works for your use case. You can also load a CXR file (saved from autosave, manually, or any other way) into the VFB:

[romullus]

Messages with feature request were moved to appropriate thread: https://forum.corona-renderer.com/index.php?topic=96.0

Please stay on topic people, this thread is for discussing issues related to Corona 13 daily builds. Don't make life harder than necessary for mods, thanks.

[Frood]

Please stay on topic people, this thread is for discussing issues related to Corona 13 daily builds.

All IS about v13. The fact that a v13 daily got v12.1 (the usual procedure) does not change the fact, that things are suggested here to be "ok" for v13. Nobody mentioned that any change is a temporary solution (cure the disease by killing the patient - see Francis Bacon) because there are issues. It is rather presented as a "fix" and I never ever want to have this "fix" in 12.1 nor in v13.


Good Luck

[romullus]

All IS about v13. The fact that a v13 daily got v12.1 (the usual procedure) does not change the fact, that things are suggested here to be "ok" for v13. Nobody mentioned that any change is a temporary solution (cure the disease by killing the patient - see Francis Bacon) because there are issues. It is rather presented as a "fix" and I never ever want to have this "fix" in 12.1 nor in v13.

There were few messages with wishlists for future versions. I moved them to feature request board. I think that everything that left here is appropriate for this discussion. Peace.