Messages

61

[Max] Feature Requests / Re: The most wanted feature?

« on: 2020-03-02, 18:50:38 »

Look's like we won't come to an agreement on the roadmap manner.

Current approach means we do not get the features majority of people voted for for about a year.

But the above is of no less importance than the frequent roadmap changes, and corelates with the roadmap itself. You think it is also a no-biggie right Tom ?

62

[Max] Feature Requests / Re: The most wanted feature?

« on: 2020-03-02, 18:37:13 »

You're absolutely right in updating the roadmap as things progress. Im sure most people here completely understand that things change and you have to stay agile and adaptive because otherwise you just waste your own time.

Curious to know how is that a waste of time. This is a manner of holding to your word or not. Hackathon or not the things that emerged just recently could as well get implemented later on.
Current approach means we do not get the features majority of people voted for for about a year. 6-7mo - V6 development, as life shows 3mo code cleanup V7, 1-2mo before V8 dailies start showing up.
Fair ? Personally dont think so.

Well say for instance you put something on the roadmap and then discover that vray devs researched it and it cant be done the way you initially though it could. Of perhaps autodesk makes a change in a max update that means a feature is no longer needed or has to be implemented differently.

You're talking hypothetical. I'm talking what is acctually happening here.

63

[Max] Feature Requests / Re: The most wanted feature?

« on: 2020-03-02, 18:34:01 »

You're absolutely right in updating the roadmap as things progress. Im sure most people here completely understand that things change and you have to stay agile and adaptive because otherwise you just waste your own time.

Curious to know how is that a waste of time. This is a manner of holding to your word or not. Hackathon or not the things that emerged just recently could as well get implemented later on.
Current approach means we do not get the features majority of people voted for for about a year. 6-7mo - V6 development, as life shows 3mo code cleanup V7, 1-2mo before V8 dailies start showing up.
Fair ? Personally dont think so.

64

[Max] Feature Requests / Re: The most wanted feature?

« on: 2020-03-02, 18:00:09 »

As a note on the roadmap, as the roadmap clearly says, it is not WHAT will happen, but what we are planning. And as with everything in life, plans change, and when that happens, we update the roadmap. This is why it's important to keep a watch on it, and not just glance at it when 5 comes out to see what 6 will have, as what 6 will have will change (e.g. we start development and find it will take longer than expected; we find something not on the roadmap that can be quickly integrated so we add it; and so on).

Just that I've seen some people basically complain that the roadmap changes, which is a misunderstanding on what the roadmap is.

To clarify. You guys added that statement pre V5 as far as I remember because we had the exact same discussion after slicer clipper was postponed for the second time (as of then).
Most of the people clearly perceive the roadmap differently than you guys do. And IMHO they are right.

A map by definition is a medium by which you can tell a road from A to B. You by definition make assumptions based on that.
If you're in point A in your business and you want to get to point B and you treat the engines roadmap as a map (or a road, for that particular example does not matter) that lets you guess that you will be able to reach point B in a certain amount of time. People make decisions that this road is the right one. Or search for alternatives. That often implies decisions like costly hardware upgrades (you can clearly go CPU way now, or GPU way).

If you change the map midway you let people to a dead end. That was our case with slicer/clipper that first appeared on the roadmap before V3 as far as I remember, was postponed two times, and hasn't been developed till today.
If you treat the roadmap the way you do, just name it as a "big bag of loose ideas that we might or might not develop as we see fit" and people will stop taking it serious.

But this on the other hand looks like there is no long term development strategy people can count on. If there is none and you decide from version to version - OK. But make it clear and obvious it is that way.

Same thing was discussed recently on Fstorm group. People wanted to know what will be developed next and they got no information. Just make it clear.

65

[Max] Feature Requests / Re: The most wanted feature?

« on: 2020-03-02, 17:19:15 »

look tough guy, a major feature got shot down, we want an explanation or we are storming area bs bs something. seriously though, it's a big feature what did you expect? and nothing out of the ordinary was said above.
two options:
a technical difficulty
OR
a business decision

very reasonable actually. don't blow things out of proportions. just don't be the censorship, it's vastly unpopular these days.

This.
Each time people start asking questions there ALWAYS comes someone who's not even part of the Corona team and advocates on their behalf like he knew exactly what and when the team was doing and reasoning behind teams decisions. Or suggests that you are being disgracefull to the team because you dare to ask questions about the product you pay for.

Questions asked to Corona team should be answered by Corona team members. Unfortunately many topics in feature request section (not only here) are left with no answer at all IMHO because it works like this:
A: "hey team, what about feature X, that would work like this and that"
B (user, not Corona member): "why dou you need this, I think that it is not necessery and you can always workaround this"
...
Same goes to even slightest critique of the development subjects.

I still remember the days when Ondra himself talked to people on the forums about new features and introduced them overnight.
I also understand that things are now way more complex and this is not doable anymore.
However recently in daily build section there was a discussion when dedicated people posted examples concerning some hints about research being done elswhere on the PBR shader, diffuse model, some papers on the subject etc. only to be removed by moderators as pointless discussion. Rly ? When people try and be helpfull in any way ?

And the initial roadmap is not being followed once again and top three features from the poll are not being developed.
What is the reason behind this topic then ? This supposed to be a major version with new features and yup, there are many. Just not those that majority of the people want aparently.
Development of V6 will take over 6 months, then standard period of 3mo code cleanup version and there you have it. 9/10mo development cycle that introduces none of the most wanted (according to the poll) features ? Quite possible.

Was really hoping for that new shader with lambertian controlls, sheen etc. as well as tone mapping rework. So disappointed again.

66

[Max] General Discussion / Re: PBR shader discussion

« on: 2020-01-29, 13:11:08 »

Can't we adapt the way Arnold handles things ?
https://answers.arnoldrenderer.com/questions/2521/lambert-oren-nayar.html

Everyone would be happy being able to choose pure lambert, pure oren-nayar and anything in between.

My point asking about the shader development on the topic here was to start some sort of discussion with the Devs as to what people expect and that those more tech-guys could toss some knowledge that could be easily overlooked.
Can we hear the Dev side please ? What are you guys planning to include in the new shader ?

the Trello page says Clear Coat, Sheen, and Advanced diffuse model.

Are you a part of the development team JViz ;) ? I am familiar with trello roadmap. Advanced diffuse model can be interpreted in various ways.

67

[Max] General Discussion / Re: PBR shader discussion

« on: 2020-01-24, 14:17:52 »

Can't we adapt the way Arnold handles things ?
https://answers.arnoldrenderer.com/questions/2521/lambert-oren-nayar.html

Everyone would be happy being able to choose pure lambert, pure oren-nayar and anything in between.

My point asking about the shader development on the topic here was to start some sort of discussion with the Devs as to what people expect and that those more tech-guys could toss some knowledge that could be easily overlooked.
Can we hear the Dev side please ? What are you guys planning to include in the new shader ?

68

[Max] General Discussion / Re: PBR shader discussion

« on: 2020-01-23, 20:04:54 »

Wow, the Oren-nayar looks so much better!

Sorry, i don't get it... In my opinion / habits, Lambertian looks better here...

Can you explain why i'm wrong ?

What do you want me to explain ? I staded my subjective opinion, you stated yours. IMHO oren-nayar looks way less plastic - obviously visible in the mud exaple.
Looks also more convincint at grazing angles. Sort of like the lambertian model had kind of a black halo on 0 angle.
Hard to tell the real difference without proper testing in various conditions tho.

69

[Max] General Discussion / Re: PBR shader discussion

« on: 2020-01-16, 15:30:50 »

Wow, the Oren-nayar looks so much better!

70

[Max] General Discussion / Re: PBR shader discussion

« on: 2020-01-16, 13:46:14 »

Does this affect the amount of light transfered after the first bounce, or only the material itself ? In other words will the entire scene using this model get brighter ?

71

[Max] General Discussion / Re: PBR shader discussion

« on: 2020-01-15, 15:03:53 »

Really glad you joined the place Fluss. I really do believe that since the new material is being developed it should be as up to date tech-vise as possible so we wont wait for or ask for another overhaul in a year or so.

72

[Max] General Discussion / Re: PBR shader discussion

« on: 2020-01-14, 15:25:51 »

That will 90perc. be related to GI (particularly clamping) and Tonemapping.

But also... F-Storm doesn't have correct glossiness curve, in fact it's wrong. It can make nice looking materials, but the are absolutely not PBR :- ). Ask Johannes or Daniel, they would love to change this.
So if you're asking for even more tweaked GGX behavior, it will look just slightly bit more advanced than what Corona currently has (maybe 5perc. difference?) but absolutely not like F-Storm material.

Corona's PBR will bring different UI and parameters. It will make a creation of materials easier and more like current industry standard.

They will look absolutely the same though (with exception of Sheen parameter for fabrics). Unless they change fundamentally something under the hood for BRDF, which they could...like Lambert Diffuse is getting pretty old.

Yeah thought so that it might have something to do with Tonemapping and GI. Increasing Max ray depth and sample intensity does not affect the behaviour I'm referring to - it does not make the interior considerably brighter. Changing all materials to whites/white'ish grey overrides on the other hand does. That was the reason why I requested a simple "white override" checkbox in CoronaMtl. And why I asked if Devs are monitoring Dubcats thread quoting the energy conservation thingy.
And I know that white reflects more or the light spectrum than black does, so probably gloomy corners are more or less correct. But something seems off and I can't narrow it down to a single thing.
All in all I think that there is a general consensus that people would love to see Tonemapping and material (including the things you mention) overhaul.

73

[Max] General Discussion / Re: PBR shader discussion

« on: 2020-01-14, 13:33:36 »

just imagine how scenes will look now that the plastic feel of the materials will be gone very SOON forever

Why do you think so? There is fundamentally nothing wrong with current GGX behavior, it's been fixed long time ago. The different energy conservation loss illustrated above only applies to metals.

The PBR will bring new conveniences like Metalness workflow, coating,etc.. and hopefully Sheen for fabrics, but otherwise all materials will look exactly the same.

How so Juraj ? How the engine tells if a material is metal or not ? If you are not using any maps the difference between metals and nonmetalics is IOR. Then if want it to be glossy or not you adjust the parameter.
There is something off imho with current energy conservation in general material. When testing a dark interior painted all graphite with both Corona and Fstorm I'm under an impression that although both are dark the one in Corona appears more gloomy and darker in the corners etc. just as the Fstorm one would use some kind of white GI override to all materials.
Not sure if that has something to do with tone mapping or color space or whatever the reason. I'm by no means as technical as you or Dubcat or Fluss are so I'm just guessing here.

74

[Max] Daily Builds / Re: Corona Renderer 6 for 3ds Max - Daily Builds Discussion

« on: 2020-01-12, 19:32:46 »

Hey Guys, the question about reworking tone mapping still stands.
Another thing - do guys you track all the super interesting things that guys come up with in Dubcats topic in regard to new material?

Here is a more practical example demonstrating the difference between GGX and multiscatter GGX implementation of the blender's Disney principled BRDF

I'm pretty sure Fluss can help and throw up more of such findings that would bring up the new shader to another level.

Any chance for a new build or any news? So quiet here lately ;)

75

[Max] Feature Requests / Re: Include/Exclude list for camera clipping

« on: 2019-12-22, 19:41:05 »

I think this was already requested but a big +1 nontheless