Messages

61

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

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

Regarding that image of my earlier test, as others noted, I would have to use the exact same HDRI and closest as possible materials, not a simple conversion.

So I repeated the test. Same HDRI, Same LUT (KimAmlan02), Matched white balance. very simple materials.

Do you really see a 50% bump in realism in the Fstorm one? Maybe I don't have your eyes, it is entirely possible that I actually don't have the perceptual capacity.



Anyway, now that I've conducted the test in a more proper manner, my point stands. I will write it in bold so you don't miss it and you stop arguing with something I'm not saying:

Fstorm has better tonemapping.   I wish Corona had a DSLR like tonemapping

However, I don't think that is the main reason for the Fstorm community producing seemingly more realistic images more consistently than the corona render community.
I think there is a small number of users (Agentdark45 included) who have superior understanding and perceptual abilities and actually notice the super slight differences between the two renderers, which are real and measurable.

But I believe what MOST people notice is a vibrant community that attracts great artists who are learning faster and feeling comfortable sooner with Fstorm, and thus, becoming good enough that, overall, the Fstorm community is producing better renders, more artistic, more realistic.

Just to be super clear, FSTORM HAS BETTER TONEMAPPING, 100% agree. And it has a real impact in realism! I wish Corona implements this soon
ps. I also wish corona becomes a lot more beginner and artist friendly by making it MUCH EASIER to produce the best possible images it already can, which, BTW would inevitably be WORST than Fstorm regarding tonemapping. At least until corona implements a better tonemapping, which I will continue to push and wish for.

Apologies if I missed the spirit of your post, it seemed contradictory at the time of posting. I'm glad to see you are supporting the call for improved tonemapping in Corona.

My main contention here is that some posters are claiming:

1. "Everything is fine with Corona as is, zero perceptual difference in tone-mapping between Fstorm and Corona; the issue is noobish user error being fixated on stock settings".
2. While other posters are stating that there is a clear and obvious limitation with Corona's tonemapping (despite Bertrand Benoit levels of Corona mastery and tweaking), and we want improved colour space/ACES like tonemapping implemented as a priority over other seemingly trivial features that eat up precious dev time.

Regarding your recent comparison, yes there is a difference between the two (perhaps not 50%) but I can clearly see the black crush in the shadows issue I have mentioned before in trying to achieve a contrasty punchy image whilst retaining not overly clamped highlights (look at how much detail is lost in the lower right shadow on the floor in the Corona version, along with the shadow at the base of the exterior sphere, the soft shadow gradient on the left hand interior wall, and the tendancy for Corona to go to pure black in corner gaps - the dynamic range of the shadows have been butchered). Now scale this issue up to images that mostly deal with subtle tonal variations (i.e moody or brightly lit product shots).

As a side note outside of tonemapping, you can also see the filtering issue I mentioned previously in the Corona example. Look at how much detail has been smoothed out of the concrete walls and wood material in the Corona version.

62

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

« on: 2020-05-02, 03:42:37 »

There is no way 50% of the realism coming from the Fstorm community is because of the tone mapping. Install Fstorm and try it. See if your images look 50% more realistic just like that. They won't.

But the fact that so many people think that so much of Fstorm's realism is because of tonemapping, does not make sense. The fact that you estimate that Fstorm is more realistic 50% thanks to tonemapping is evidence of that.

You yourself claimed you are not an experienced Fstorm user - I am a very experienced dual user of both Corona and Fstorm (along with other engines). As mentioned in my last post I exclusively use Fstorm for high end product vis. Why? Because due to testing both engines extensively on many scenes back and forth, some even with very basic materials, the result is always poorer in Corona (and no, this isn't down in part to DOF settings, material conversion or a lack of knowledge of non "out of the box" Corona settings). It is down to tonemapping and how highlights and blacks are handled by each engine. I have tried for days in some circumstances to match the image in Corona and the same ultra-photographic result simply was not possible within Corona's VFB no matter any combo of curve adjustments, contrast tweaking, HC tweaking, Kim Luts, various other LUTS, Dubcats settings e.t.c. I'm simply not willing to go "yeah that looks pretty close", which might suffice for some.

Again, look at your own example (attached). Highlights have been visibly ruined and the wood tones are off and not reacting correctly as they should IRL - an observation I went into in detail previously. The average viewer may not spot this but in detailed viewing it is clearly apparent. If you don't think this affects overall photorealism, or certain edge cases in visuals in any meaningful way (would you concede to some degree?) then I don't know what to say to you.

Why am I bringing up Fstorm? Because out of all of the render engines I've used it simply produces the most true-to-life images possible right now (and yes, it requires settings tweaking just like every other engine, so it's not a case of n00bish "hurr muh default settings" user error). The tonal balance of the image one is able to get out of Fstorm is always superior, and I'm no Fstorm fanboy either - I wouldn't use it if I didn't have to, I would love to use Corona for everything due to it's superior feature set.

If not for tonemapping, what else do you think contributes to Fstorms superior photorealism? I've already mentioned several times on the forums better bitmap filtering/sharpness, bump mapping implementation, colour handling, pleasing noise patterns, and better DOF speed/sampling - however most of these can be worked around within Corona, Tonemapping however cannot be as it stands. Hence my prior statement of 50% (which was a fast and loose approximation, not verbatim gospel) - put a highly experienced user of both engines to work on the same scene in both engines, work around the quirks of both Corona and Fstorm, and the Fstorm image will be more photographic and pleasing to look at, fact. Case in point: look at anything Bertrand Benoit has produced (who I think most would regard as one of the best in the game that uses many different rendering engines), and compare to his Fstorm renders, and this was with his first trial of the engine: https://bertrand-benoit.com/blog/westkaai-via-fstorm/ there is always something "off" about his photo realistic Corona and Vray renders (a minor uncanny valley effect, i.e lacking in brain fooling true photorealism).

Side note: Fstorm as a rendering engine in general is terrible in some real world use cases; interiors with a lot of bounced light where it's annoying portal system will not save you. And not to mention VRAM limitations. It's lack of material and plugin support is also shocking (still doesn't have proper composite maps and multi-layered materials) - another reason I don't use it for anything more complex than product vis.

63

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

« on: 2020-05-01, 22:11:29 »

I really did not create this thread with the intention of comparing FStorm and Corona Renderer...

I think people are making the comparison because Fstorm has the best tonemapping algorithm out of all common rendering engines at the moment.

The thing is, as Juraj pointed out, we're not even sure the "Fstorm look" can be attributed to tone mapping only. So further investigations need to be conducted before making such a claim.

Maybe not attributed solely to tonemapping, but I would hazard a guess it's at least 50% of the reason. Please look at the highlights and roll-off to extreme black in the examples posted earlier by lolec - that is one aspect that is definitely down to tone mapping. Colour behaviour differences could be due to the internal colour space/custom matrix, I agree.

I would urge anyone who has doubts about the highlight/black crush issue to test it for themselves in 1:1 comparisons as Fstorm is fully functional (with watermarks). You will not get the same level of pop/photographic contrast in Corona (without external post processing), without sacrificing either blacks or highlights - I would almost liken this to differing dynamic ranges of cameras as an IRL analogy.

64

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

« on: 2020-05-01, 17:08:01 »

I really did not create this thread with the intention of comparing FStorm and Corona Renderer...

I think people are making the comparison because Fstorm has the best tonemapping algorithm out of all common rendering engines at the moment.

65

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

« on: 2020-04-30, 19:39:01 »

There you are, the effect on this one is more what we are referring to when talking about Fstorm TM. I wouldn't even call this image realistic, there is a bunch of stuff that are off but there is something in it that feels natural indeed.

The Fstorm TM tonemapping magic imo is mostly to do with the way it handles highlights/burnouts, the falloff to extreme blacks (and colour behaviour in general) and the ability to produce a nicely contrasted image without sacrificing the previously mentioned elements. The Corona VFB crushes the hell out highlights/blacks when trying to achieve a contrasty photographic image, either via a combo of stock HC/contrast/LUTs (see the previous comparison examples by lolec and my detailed observation notes). The way Fstorm clamps highlights and the gentle roll off to true black is beautiful, it isn't in Corona, period.

Again, I cannot stress enough that the handling of highlights and blacks cannot simply be fixed by arbitrary curves/LUTs inside of Corona's VFB - sure we might be able to get close (read: 90% as close) by rendering out a linear 32bit image and fooling around in photoshop - but goddamn, what a painful workaround.

I'm also starting to think part of the Fstorm magic is the internal colourspace, take a look at the examples on Chris Brejon's ACES page (at the very bottom and click left and right): https://chrisbrejon.com/cg-cinematography/chapter-1-5-academy-color-encoding-system-aces/ - notice that even GI gets affected along with colour bounce, most apparent in the red ball.

Again I should stress that I am nitpicking here, Corona has decent tonemapping options but when compared to FStorm it simply isn't on the same level after using both engines extensively. Sure, I can produce nice images in Corona (and I do for all interior work), but if I wasn't as limited with Fstorms materials + VRAM I would use Fstorm everytime. For high end product shots I use Fstorm exclusively - I have tried to match a lot of my scenes 1:1 in Corona and something is always off in comparison (overly clamped highlights/highlights too burned/colours being weird unless manual silly tweaking/blacks being crushed when trying to achieve more contrast...the list goes on).

66

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

« on: 2020-04-26, 13:48:26 »

@agentdark45 just to be clear, the summary of your analysis is that Fstorm and Corona are not on parity in terms of tonemapping (?) and you are in disagreement with @lolec who is saying that, on balance, the tonemapping potential of both renderers, Corona and Fstorm, is basically comparable(?)

Correct. One more example to show how badly Reinhard stacks up compared to a proper filmic/ACES implementation:



Again, this cannot be done just by sticking a LUT over an image (i.e the band-aid approach).

67

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

« on: 2020-04-26, 05:46:34 »

Regarding the "colour" issue, I'm talking specifically about saturated colours breaking down in unrealistic ways under certain lighting conditions. There was an example above that shows the difference with what happens to reds and blues in ACES vs SRGB colour spaces as the exposure/lighting intensity changes. I have noticed this first hand in my scenes (yes even with the fabled Kim LUT) that sometimes a material that is properly created, without wacky RGB values will just not work as it should in real life and will need heavy post editing - I have yet to come across the same issue in FStorm.

While I appreciate your latest tests lolec, you would need to redo this with exactly the same materials (not quickly converted ones) and an HDRI capture of the exact same exterior lighting to draw any meaningful conclusions. We would also need to see a histogram of the images to compare what is going on in more details. When I talk of Coronas tone mapping limitations, which cannot be fixed by simply cranking the contrast slider (which crushes the hell out of blacks) + applying a LUT; I'm speaking specifically about the well known limitations of Reinhard tonmapping (burnt, saturated highlights or murky greys when clamped). The interplay between highlights, mids and the falloff to extreme black levels without getting crushed blacks gets completely ruined by cranking Corona's contrast slider.

Lets take a look at your last example, I will bullet point the major differences:

1.  The highlights are clearly overly clamped on the Corona version - most noticeably on the exterior/backplate, look at that ugly Reinhard burn and grey murkyness surrounding it. Now compare to the Fstorm version, notice how the highlights have a much more photographic burn and a realistic falloff to the green mids on the plant (which has kept its vibrancy and contrast, vs being washed out in a shade of grey). In fact you can see Corona struggling to tame the highlights of the exterior and plant from the very beginning (look at that neon green/yellow, and it doesn't get any better until it goes grey...sigh.)

2. Wood tones have not desaturated or lightened realistically in the presence of light/exposure in the Corona version. Perfect example of what I'm talking about when it comes to colour issues (along with the neon green plant highlights). I've had wood go vibrant overly contrasted red on certain parts of a scene, when the same material is almost desaturated in other parts of the scene (which it should have all been fairly desaturated) - usually in the presence of strong directional spotlights with a realistic Kelvin value. A good test of this is warm spot lighting in wooden shelves, with the same material elsewhere in the scene. Give it a go in Fstorm and Corona and marvel at the difference (again in a full scene). This colour phenomenon also happens sometimes to materials with a strongly coloured reflection (gold, copper e.t.c - and no, the RGB values were not sky high).

I will sum this up: you can not simply stick a LUT on a photo taken with a phone camera from 2010, adjust the contrast and claim it's as good as starting with the photo taken with the DSLR. You might get 90% of the way there, maybe fool a few people who think "it's good enough" but after extensive testing of both engines myself in many different types of scenes (yes even with dubcats ACES emulation settings, Kims LUTS e.t.c) I can hands down tell you they are not at parity tonemapping wise.

68

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

« on: 2020-04-23, 19:53:54 »

Thanks for taking the time to post up the Cornell box tests lolec.

While I agree that the Kim Amland LUT with minimal VFB fiddling produces a vastly super result than stock settings, the way Fstorm handles highlight peaks, the bottom curve of extreme darks and colours in general is still superior. It may not be as apparent in a simple Cornell box scene - start populating a real scene, with strong lighting certain areas and watch what happens to your highlights, strongly coloured materials and deep shadows; things start to break down and you end up chasing the dragon.

You can start to notice it in your Corona + Kim example 1; look at the exaggerated shadowing and black crush creeping in, as well as the front face of the small cube compared to the Fstorm tweaked example. Overall scene contrast is retained in the Fstorm tweaked example without exaggerated shadowing - it almost looks like light is behaving more realistically on the objects.

69

[C4D] Bug Reporting / Re: Yet another critical problem with bump mapping

« on: 2020-04-20, 15:33:23 »

Max Corona user here and I can confirm (along with others) that there's a big issue with bump mapping being view/resolution dependant. The issue becomes more apparent when using micro fine bump maps (fine plastic pitting, fine stainless steel brushing e.t.c).

I've posted this before but if you want an example of rock solid bump/filtering implementation, at least as far as needed for our purposes take a look at this video:

The anistropy of the stainless steel is purely derived from the fine bump map (no dedicated anistropy slot) and being a dual user of Corona and Fstorm I can guarantee that if you try this in Corona using bump maps, it will break. You might get a semi decent result for one particular view but as soon as you increase the render resolution or change the view all hell breaks loose and you'll have to re-tweak the material.

This is quite a large problem imo, as it impacts pretty much all common materials - wood, concrete and wall paint for example. The natural anistropy from the video example will be lost on common materials unless explicitly mapping it (and even then you won't be able to get as fine a result unless rendering larger and downsampling).

This isn't a knock on Corona - I still use it for 95% of commercial projects, I'm just trying to aid in key areas that could use some improvement.

70

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

« on: 2020-04-20, 03:20:44 »

Basically, if Corona copied FStorm's tonemapping 1:1 I would most likely never touch FStorm again (apart from simple animations with DOF as it resolves DOF noise so damn quickly).

The user request vote has had reworked tonmapping in top spot for months (years?) - please devs can we put focus into this over items that users have not asked for. We can live with any current quirks of Corona (Reflection environment overrides not working, microbumps being resolution dependant e.t.c)...but FStorm quality tonemapping would be a fundamental difference to the engine.

I spend at least half a day per project fighting with highlight compression, curves, various LUTS, post pro trying to get a decent image without murky greys/crushed blacks/over burnt highlights/washed out or super saturated colours in Corona, whereas as Yuriy mentioned - it is literally minutes of setup to achieve a bang on DSLR like result in FStorm.

Cliff notes:

- 10-15% future speed up, consuming months of dev research and testing...meh.
- ACES/FStorm like tonemapping: inject it straight into my veins.

71

[Max] Resolved Bugs / Re: Difference between old displacement and new displacement

« on: 2020-04-10, 15:38:50 »

Did the rug geometry have any long, thin polys on it by chance?

I've attached a crop of it (old displacement, 1px), it was fairly evenly subdivided, with supporting edge loops (all quads, uv unwrapped) and an opensubdiv applied on top.

The displacement map is a coronamix map of the edge lines of the colour pattern mixed with a circular noise map jpg (I think taken from one of the stock Corona carpet material displace slots).

72

[Max] Resolved Bugs / Re: Difference between old displacement and new displacement

« on: 2020-04-10, 14:53:29 »

Just to follow up here, I recently completed a project with a very finely displaced rug - I ended up having to switch back to the regular displacement mode (1px) as I was getting some weird shading issues with the new 2.5D displacement.

There were some odd "vertical lines" that kept popping up along the length of the rug and would only disappear if A. I increased the scale of the displacement map (bigger/less "threads") or B. I switched to the regular displacement. Auto bump in both scenarios only affected the darkness of the rug (didn't fix the vertical line artefacts in 2.5D mode). I didn't save any images of the issue unfortunately as it was an active project with a tight deadline - I may be able to revisit it later.

There was a noticeable speedup using 2.5D and no visual difference (apart from the artefacting) so it would be great to get this resolved.

73

[Max] Resolved Feature Requests / Re: tyFlow instancing support

« on: 2020-04-10, 14:39:07 »

+10000000

In general Corona is a bit buggy with TyFlow, we typically do anything TyFlow related with Fstorm (the speed difference is also quite noticable in Fstorms favour for simple animated scenes with heavy DOF - single 2080ti vs Threadripper 3970x).

74

[Max] I need help! / Re: How to boost reflections?

« on: 2020-04-10, 14:22:42 »

This may seem obvious but have you tried cranking the IOR of your material to something >5. For reflective silk materials as you've posted I've had great success by placing a heavily contrasted version of the main texture map in the IOR slot (inverted) or the reflection slot along with various maps in the anistropy + rotation slot. Tinting the reflection colour (either using a map or solid colour) can also work depending on the material. This coupled with the usual falloff-diffuse tricks can produce some very convincing materials, couple of examples attached.

My materials are quite evenly reflective, whereas for your material you would definitely need to add a map to differentiate the reflective parts from the diffuse.

75

Gallery / Re: Ruelle ( Alley )

« on: 2020-03-31, 19:22:16 »

Incredible! Could you share some of your tonemapping and lighting settings? Absolutely photographic.