Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Fluss

Pages: 1 [2] 3 4 ... 26
16
Work in Progress/Tests / Re: dubcats secret little hideout
« on: 2019-01-31, 15:42:13 »
From the screenshots it looks like you didn't plug the highpassed linear roughness map into the mask slot ? Hard to tell since the screenshot is clipped off.

It was plugged in, that's a gamma issue for sure, I'll prepare you an explanation of what's going on.

FStrorm still does volume displacement, and it's fuc***g awesome. https://fstormrender.ru/manual/displacement. Ever wondered why fStorm users can use displacement on every single plant in their interior, and why the displacement only take like 400mb instead of 200 gazillion terabytes ? This is why.

Yep, Fstorm displacement is great (the only drawback is that it does not handle procedurals)! we discussed that in this thread: https://corona-renderer.com/forum/index.php?topic=22625.0

17
Gallery / Re: Pictures from Corona Land #1 - Winter scene
« on: 2019-01-30, 15:50:43 »
Nice work man, looking forward to see more too!

18
Work in Progress/Tests / Re: dubcats secret little hideout
« on: 2019-01-25, 02:02:26 »
Hey dubcat,

Looks like the exposure inconsistency is related to the gamma 2.2 part in the IOR mask generation. Why did you choose to perform those operations in gamma 2.2 to put it back into gamma 1.0 afterward? To my knowledge, playing with gamma while performing arithmetic in a node tree that is supposed to be plugged in a linear input always end-up in a bad way, especially with data as sensitive as IOR.

19
Work in Progress/Tests / Re: dubcats secret little hideout
« on: 2019-01-24, 16:25:30 »
For people who are reading this later, feel free to simplify the material with pure float values as Fluss mentioned.

There is a really strange behavior I cannot explain. After further testing, it looks like it's the 1/IOR part that not working here. On the render result at least as the material preview and the rendered material do not follow the same behavior. Here are some examples demonstrating the issue :

No IOR map plugged (IOR 1.5 in the material) :



1.5 IOR linear float corona color plugged in, work as intended :



Mixing 1.1 to 1.8 linear float using your node graph, the material preview is fucked up but render looks fine to me :



Mixing using the 1/IOR method, the material preview looks fine but render does not :




I have the feeling that there is some weird gamma related stuff behind that.


For the glossiness darkening and for the plasticy bump feeling, I'm not sure we are talking about the same stuff (see my previous posts).

20
Feature requests / Re: Cloth BRDF
« on: 2019-01-23, 18:37:51 »
Wouldn't it be better to put efforts in geopattern instead, which has way more uses?

If I have to choose between Geopattern and this tech to be implemented first, I'd definitely go for Geopattern because it is way more versatile indeed! It is not limited to fabrics so the cloth shader is not the priority TBH.

But you'll still need much more effort with Geopattern rather than this tech tho, just because you have to model the pattern by hand. What's more, Geopattern is useful for small repetitive cloth patches but as far as the yarn pattern is not consistent on the full mesh, it's another story. The real benefit of this is its procedural nature. You can reproduce patterns in no time.

Here is a small example (patterns don't match between examples but anyway, you got the idea):

Build the pattern with the pattern editor :



And you're done! This pattern will be used by the shader to build the yarns structure :



Then, each yarn will be replaced by a fully simulated fiber model with both dense fibers and flyaway fibers (those ones create the fuzziness). And you get control over a few other parameters :





That would be the ultimate cloth solution which is a tedious part in CGI since a long long time.

21
Feature requests / Re: Cloth BRDF
« on: 2019-01-23, 12:22:31 »
Thanks for the suggestion, but it's probably not going to happen any time soon.

We have our own hair shader already, and I _suppose_ something similar could be achieved by building a woven cloth our of splines and then using hair plugins to create hair along those splines. Then apply Corona's hair shader (which supports scattering and all that physical stuff), and voila!
Not sure about render speed and RAM usage though... I don't think anyone tried pushing hair plugins + Corona hair so far. :)

Hi maru, thanks for your feedback! Using the Corona's hair shader? Definitely! And it will probably look even better! But the whole point of this is that you do not have to create the woven geometry, everything is procedural, even the yarn curves. So you can create your own patterns procedurally and easily with a pattern generator. Then, curves are generated from that map as guide and then replaced by the fiber model. What's more the examples shown above have a 200MB RAM footprint, I doubt you can achieve this with any other method.

So basically, Input a pattern map -> Realistic cloth. It's a huge time saver and it looks insane.

22
I just checked the roadmap and filtering will be improved with V4, really good news! The next release will be freaking awesome!

In the roadmap only image filtering is mentioned, but not the bitmap filtering. That is slightly different thing, no?

You're right, I read it too quickly...

23
Feature requests / Cloth BRDF
« on: 2019-01-20, 02:27:09 »
Cheers guys!

Recently stumbled upon those papers :

https://shuangz.com/projects/procyarn-sg16/procyarn-sg16.pdf

https://shuangz.com/projects/proccloth-egsr17/proccloth-egsr17.pdf

I was mindblown by the level of realism these guys succeed to achieve with a full procedural model. I have to admit that looks pretty complex, but damn that's beautiful! Memory wise, the RAM usage presented in the last paper is not that big considering the complexity of the model. Rendertimes seems to be consequent at first but the hardware they are running is pretty old (from 2010).



Basically, they are building yarn patterns (woven or knitted) from which they generate fibers. So no need to cheat the scattering effect with fresnel curves or sheen anymore! I know you guys are busy right now and V4 will be insane but it would be good to consider a good cloth BRDF at some point ;)




24
I just checked the roadmap and filtering will be improved with V4, really good news! The next release will be freaking awesome!

25
The best solution so far is to leave the blur value at 1 and wait for something like the Pixar's bump to roughness solution to retrieve information loss by filtering.

26
Work in Progress/Tests / Re: romullus wips
« on: 2019-01-18, 18:46:16 »
Mostly for cloth and any repeating geometry pattern. I see guys using it quite regularly on their facebook page. What's more, when you don't have the displacement map you need, it's quicker to use geometry rather than create a displacement map. And most likely, it's about details shot or High-res renders. Displacement stretches the mapped textures and looks ugly. To me, it's not a displacement alternative, both are great and used for different purpose.

27
Work in Progress/Tests / Re: romullus wips
« on: 2019-01-18, 14:23:34 »
We don't need the geopattern now. Sorted.

Geopattern is definitely more convenient ,Ram efficient and the result are better. sorted

28
Gallery / Re: Incredible Landscape Project at Trabzon
« on: 2019-01-16, 18:44:00 »
Nice project, love it! Nice job guys! This kind of non-invasive architecture is extremely valuable, I like the way it blends to the surroundings without completely destroying the landscape. Not that easy, especially considering the scale of the project. So thumbs up for the architects too!

29
Work in Progress/Tests / Re: dubcats secret little hideout
« on: 2019-01-16, 14:42:25 »
Also, have you tried to change the exposure between renders with the node graph you provided plugged in the IOR slot? Render->Lower exposure by let's say 2 stops->re-render. I have some weird inconsistent results under different exposures here. Everything is fine when you generated IOR map is unplugged. Let me know if you observe any issue or if it is on my side.

30
Work in Progress/Tests / Re: dubcats secret little hideout
« on: 2019-01-16, 14:32:31 »
OK dubcat, got it, thanks!

I have a few questions :

From my test, corona seems to map the value as 1/IOR only when the input is below 1 (so in the sRGB range). Every value above 1 seems to be treated as a proper IOR value. So if you're inputting 1.5 linear value in the Fresnel IOR slot, you should end up with the right result. That's actually quite smart as the lowest IOR value of 1 (linear) is the highest value in sRGB range (255=1.0). So 1.0, the only common value of the two range( [0,1] ; [1,999] ) give the same result (1/1=1). It works with a corona color plugged right into the fresnel slot but as far as I try to mix two linear values together, the IOR is completely messed up, despite the fact that the "perform mixing in sRGB space" checkbox is unticked. Do you have any insight about that? That's totally freaking me out! It would be so much easier to work with linear data directly..

Also, don't you think the glossiness darkening induced by single scattering GGX is kind of a blocker here? I mean, when I look at a linear RAW DSLR picture, it's really flat. We are loosing up to 60% energy on low glossiness values, which bring a lot of contrast (not to mention that it's physically nonsense). If we're aiming at photorealism, especially using real scan data, this phenomenon should have a pretty big impact here.

Finally, as you said, Micro shadowing most of the time overlooked. If it's not that much an issue on close up shots like in your examples but as soon as we move away, filtering comes to action and we're loosing all the micro d├ętails when using bump/normal and micro-displacement maps, resulting in a flat/plasticy render. So translating bump/micro-disp/normal map to microfacets is a must have too. It can also be declined to solve some artifacts introduced with normal mapping with BDPT algorithm (Bump/normal mapping is not reciprocal). And that's what bump to roughness does with no negative impact on render time. These examples speak by themselves :

Bump to roughness :



Normal to roughness :



Regular bump :



Bump to roughness :





Quote from: PIXAR link=https://renderman.pixar.com/stories/cars-3

"We noticed a significant improvement on environment detail, especially surfaces such as concrete and marble,"


Quote from: PIXAR link=https://renderman.pixar.com/stories/cars-3

"Typically with Marble, we try to avoid a glassy look, where the marble is too shiny. With Bump-Roughness we were able to capture all the subtle imperfections that give marble its most distinctive properties,"


Quote from: PIXAR link=https://renderman.pixar.com/stories/cars-3

"The benefits don't stop there, as previously mentioned, Cars 3 saw huge improvements in render times. Bump-Roughness is over 35% faster than bump alone"


Pages: 1 [2] 3 4 ... 26