Messages

46

[Max] General Discussion / Re: Tonemapping - Plz Halp

« on: 2020-05-08, 14:45:09 »

Hard to draw a definitive conclusion taking into account that you are not a proficient Fstorm user and this may depend on the shader setup but Corona result clearly different from Fstorm.

Super easy to observe the differences while you overlay the renders. In the floor shader example there is waaay more detail in the shadows and highlights are better preserved in the Fstorm example.

There seems to be some exposure difference but even while bringing the two examples to aproximately the same level shadows in Fstorm have nice definition while the one in Corona example have some sort of patina-crush overlay on them.

47

[Max] General Discussion / Re: Tonemapping - Plz Halp

« on: 2020-05-05, 09:40:18 »

contrast does not affect saturation

This one is bit unfair, Corona's Contrast is identical to Adobe's, it's basic contrast. It's not mistake that it doesn't operate on luminosity channel only, or offers selective smart saturation (Vibrance).
Some raw editors replaced Saturation with Vibrance (and call it Saturation again), but since we already have saturation, I would just add vibrance. The saturation is the weirdly integrated feature.. doesn't act like anything I know (affects luminosity&contrast way too much).

How is this unfair Juraj ? I converted a simple Corona playground scene of mine and when boosting contrast to 5 out of normall 1 my wood shaders started a new after psychedelic like life. They went to the moon with saturation. When doing the same in Fstorm the image remains visually 90% the same, only gets punchier.

I know you optimize your workflow and for sure you have some sort of a shader library of your own. This works great. Lets you streamline your workflow and become super efficient especially when incorporating triplanar wherever possible.
Only problem is that if you prepare your shaders in a controlled dedicated scene (say contrast 1) and then bring them to a more contrasty scene all of a sudden the colours break apart. This should not be the case.

Now, whether you call it saturation, vibrance or other is not important. If we get both controlls- contrast and saturation, imho contrast should operate only on luminosity, saturation should be saturation. And even saturation here does not work as it should - it shifts hue.

I agree that people wanting magicall "make dis shiet photoreal" button will get dissapointed because it will not happen as this comes from a lot of variables - working with references, matching colours etc. but lets just make the tools that we have work as they should. and upgrade the ones that are just bad at the moment - like HC, contrast, etc.

48

[Max] General Discussion / Re: Tonemapping - Plz Halp

« on: 2020-05-04, 23:14:57 »

In general...

• I never use contrast < 1.0
• I never use highlight compression <1.0
• I never use highlight compression <3.0
• I never use contrast > 1.0 in combination with a LUT
• I never use filmic shadows in combination with a LUT
• I never use LUTS
• I never use LUTS at an opacity of 1.0
• I never use the built-in vignetting
• I never use color tint
• I never use filmic highlights
• I always use filmic highlights = 1.0
• I always use filmic highlights = 1.0 when using a LUT
• I always use Dubcat ACES emulation
• I always increase / decrease saturation a little bit
• I never adjust saturation
• I never use green-magenta tint
• I always use sharpening / blurring in the VFB - here are the settings
• I always keep exposure = 0 and modify light sources instead of EV spinner
• I never use bloom / glare

This list is exactly the back and forth that I go through during almost every new project - I wish I could decide on a definitive personal favourite - but I can’t. Would love to know everyone else’s approach to all of the above.

Because you just can't decide.
I mean you can find the tone mapping settings you like and stick to them. But then if you find yourself in a situation that you really need more contrast and crank it up - all of a sudden your shaders will mostly break apart, saturation will go crazy and all this nonsense.

Just tried Fstorm again - have the demo installed but its pain in the @ss on my gtx1060 - contrast does not affect saturation - awesome, reducing burn value does not make the image instantly dull, in fact it does not make the image dull at all - you can even go with negative value - again awesome.

Try for yourself.

Can't really wait what Nvidia shows this year :)

49

[Max] General Discussion / Re: Tonemapping - Plz Halp

« on: 2020-05-04, 13:22:56 »

I think we should wrap this up at this point to a conclusion that everyone is trying to contribute towards the same goal - improvements in the area that as we can all see is really really wanted by many.

Current tone mapping is not working as it should in many areas that were discussed back and forth many times.
Original contrast destroys blacks, oversaturates colours to a point that you are no longer able to see the original texture used which is really annoying when working with product design or anything that requires more than just a punchy-candy picture.
LUTs are also not the way to go, they should be used to get a certain degree of mood imho, not the base acceptable picture.

What concerns me the most is the fact that this in one of many topics abut all those issues and we still can't get noone from the Corona team to participate.
We still get all those "key new features" like faster color picker and the important stuff as we can see and extrapolate from the most wanted features poll gets neglected.

Those discussions basicaly IMHO end up in a vacuum and we get this BS policy of a roadmap that is all but "no promisses".
If the community wants certain features and they end up not being developed and we can't get any promisses then I vote for bringing back the box licence so I can upgrade when and only when the features that community wants get implemented.

My few cents.

50

[Max] General Discussion / Re: Tonemapping - Plz Halp

« on: 2020-05-03, 00:52:31 »

Since I never tested fstorm I cant tell what causes this but I noriced this on Bertrands scene he sell. The Fstorm has much stronger direct light. Why is it? Clamped GI? Is it accidental or intentional. It gives the space more readable light in way that I doubt is due to tonemapping.

Someone would have to do a deep dive becayse the features have odd parity in behavior. Fstorm HDRI has two modes (weird option to cut off direct light?), their portal light effectively becomes new area light (like one option in Vray).

Very hard to pick out what exactly is the cause with so many variables.

With Dubcat, we suspected the shader. I wonder if something lije OrenNayar wouldnt cause more highlights from durect light?

I was trying to pinpoint what is the difference between the two engines and came to the same conclusion as you have Juraj that in Fstorm light seems to be more directional.

Flash-light renders looked totaly photorealistic back in the vray 3 days even with crappy shaders. This thogether with superior tonemapping is imho the key to ultimate realism.

Can't say tho whether the directionality comes from the shader as you guys with Dubcat suspected or form the GI algorithm.

Asked about Oren-nayar shader model in the daily builds but the devs haven't picked up the conversation. Take a look:



It instantly looks 10 times more realistic. The devs tho are busy with according to trello "key new features" like faster colour picker....

51

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

« on: 2020-04-25, 14:41:03 »

Hi Ondra, and what about real time zoom in interactive rendering, this was such a nice feature in Vray, save us (back in the days) a lot of time in our workflow.

In VRAY it is possible to zoom in a certain area where you expect errors , correct the error and see the change on the fly!!

And with zoom i mean keep the zoomed (area) image sharp

You can already use 2d Pan Zoom Mode for this. You must have missed it.

52

[Max] Resolved Bugs / Re: Opacity - Forest Edge + Corona Multimap = crash

« on: 2020-04-20, 22:55:54 »

Hey man. Thank you for checking that. Appreciate you took the time :) !

53

[Max] Resolved Bugs / Re: Opacity - Forest Edge + Corona Multimap = crash

« on: 2020-04-20, 12:37:14 »

Hey there Frood. Using 5.0.5. Do you have an active maintenance plan and can check that version ? I ditched mine unfortunately and not too keen on upgrading since I have all the features I need in this version.

There really is no need for any scene. Just open a new one, plug Forest edge into opacity, then Cmultimap in the addtional opacity slot and you get a crash.

54

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

« on: 2020-04-19, 17:56:35 »

Hey there guys.
Already posted this in bug reporting section but everyone is much more active here and this is some major QOL bug:

when I try to plug Corona Multimap into Forest Edge in opacity slot every time i get a crash.

Corona 5 + Max 2016
No need to attach anything. Happens every time even is a new scene without any bitmaps added. You will reproduce it easily.

Would be nice to iron this out before v6 comes out since you address other bugs also.
Thanks!


mod edit: this only happens in older versions of FP, reported here: https://forum.corona-renderer.com/index.php?topic=28904.0

55

[Max] Resolved Bugs / Opacity - Forest Edge + Corona Multimap = crash

« on: 2020-04-19, 00:13:27 »

Hey there guys.
As in the topic title - when I try to plug Corona Multimap into Forest Edge in opacity slot every time i get a crash.

Corona 5 + Max 2016
No need to attach anything. Happens every time.

56

[Max] Feature Requests / Re: Corona Camera - Object Visibility

« on: 2020-03-07, 18:47:45 »

Hello,

Regularly, I find the name of this functionality pretty confusing. While Object Visibility makes objects totally non-renderable, sometimes it would be very practical to only make them invisible to camera, but keeping them visible to reflection/refraction, and keeping their shadow casting as well. Do you guys think it could be possible to add an option allowing to choose ? Object(s) in this Exclude List could be either totally non-renderable or simply not visible to camera ?

Thanks in advance,

Regards.

+1

57

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

« on: 2020-03-03, 18:59:42 »

"""

But I was talking exactly about the stance that Romullus here presented. You misunderstood me. I perceive it much like you do.

And aside from the whole discussion I think you should take a deep breath. There seems to be too much anger.

Noone forces any of us into using this engine. We are all free to walk away. If the trend continues that none of the most requested features (none of the topmost three voted, not even one c'mon) get implemented in a years time development cycle then I think more and more people will start to evaluate their options.

58

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

« on: 2020-03-03, 00:15:54 »

Roadmap definition aside. Is there a particular reason why user requested features are the ones that get put aside for developer features? The pool for big ideas is like a who's who of past poll winners and megathread discussion topics.

+1
it really doesn't matter how people relate to the roadmap. The important thing is whether they get the features they ask for, and if so, how soon?

+1 and if they do not get the features they ask for, why they dont get those features since they pay for the product ?

59

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

« on: 2020-03-02, 21:04:30 »

Guys, let's not forget that there was a tragedy in between.
On top of the low morale at certain point, it's a small team too.
Changing the roadmap is totally understandable under those circumstances.

And so the advocating began.
Did someone from the team mentioned the tragedy ? I heard only about hackaton and the subject being more complex than initially it looked to be.
You also missed the chronology a bit.
The unfortunate passing of Yaroslaw (may He rest in peace!) occured somewhere around the beginning of December. I posted about PBR being in the works around 19th of December in the daily builds thread (and I check trello rather frequently) so it appeared on Trello around that date I believe.
It would be understandable that in the above circumstances the development period for V6 would have been prolonged securing enough time to deliver the features.
Anyway the discussion has aparently no point as we seem to have a new definition of a roadmap and long awaited features can be postponed at any given time :)
Guess you can either stay and live with that or leave looking for alternatives :)

60

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

« on: 2020-03-02, 19:20:24 »

Well. I do not consider myself a fanboy, not in any manner. Just weighting pros and cons.
Not being a fanboy, and just a paying consumer in "fair SAAS" model I do feel that by paying the fee that amongst current active licence and other things covers further development of the engine I have the right to know what I'm paying for. Also development-vise.

Considering the above I do believe that roadmap should be a roadmap, not a bag of ideas subject to change at any time because then how am I to predict the development direction of the engine and whether or not I still want to partly-fund the development of something that does not potentially allign with my vision of the software I need?
Taking the above into account is frequently changing "the plans" fair ? Dont think so.

Plans/loose ideas should be what they are called and you have a column for those on Trello. Core features of upcoming version should be decided before it goes into development and should be not moveable. Core features should be those that the user base votes for.
Otherwise from my POV there is no dialogue between the userbase and the development team. And it used to be the opposite which saddens me.