Messages

1

[Max] General Discussion / Re: is this UI sluggishness normal?

« on: 2024-01-17, 14:08:59 »

Thanks for the valuable feedback Juraj!
Autodesk is not recommending NAS according to this article at least, so I should look into other options.
https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Working-with-multiple-copies-of-3ds-Max-across-a-network-environment.html

I'm actually looking into Connecter Suite these days, and it's not without its issues... Hard to set up without doing things wrong and having to do it all again. And the fact that all users still need to have the same file path because of 3ds Max leads me to believe an external disk(ideally Thunderbolt and m.2) with the same letter is needed by all users, be it on-site or remote.

2

[Max] General Discussion / Re: is this UI sluggishness normal?

« on: 2024-01-17, 13:34:11 »

I noticed his laggy Corona moment is with a texture that is like 7k x 12k.  I recently discovered that a lot of my material editor lag (and IR startup) in corona was due to texture size.  I have a 10gb ethernet and all assets on nas are on ssd raids, but even still with 6k+ textures (or just large pngs etc) max was really slowing down bad when running corona IR or Material Editor.  I ran the pixamoon resize script and downsized all textures above 4mb (as a test) and holy cow it’s fast again.  So perhaps it’s something about Corona and large textures?  Not sure, it’s been so long since I used Fstorm I can’t compare directly.

Stupid question but, do you also have a 10Gb network card or motherboard?

I've recently tried to look at other options for storage and an internal or even an external m2 disk would be miles above what you get from a 10Gb. Curious if this would affect the sluggishness of Max. Anyone experienced with the difference in speed?

3

[Max] I need help! / Re: Corona / Vray - Affect atmospheric for light

« on: 2024-01-04, 14:36:39 »

I would like this to be added as a feature request :)

4

[Max] Bug Reporting / Re: Bug with DOF Highlights solver

« on: 2023-10-23, 08:45:46 »

Ah, so this was the culprit! I had a deadline that I almost missed because I had crash upon crash. After much testing turning off the highlight solver fixed the issue

5

[Max] I need help! / Re: Can't do perspective match

« on: 2023-09-14, 07:50:26 »

Hmm, I'm not sure if this is going to help, but:
Remember that to get portrait photos in real life you have to rotate your camera. (or by cropping a landscape photo, but then you wouldn't be able to match it)

Rotating the coronacam 90 degrees instead of switching the height/width in render settings has helped me match some photos in the past. Not sure if this would play well with the perspective match tool, but worth a try? :)

6

[Max] I need help! / Re: Texture Variations - Not Directly Corona Related

« on: 2023-09-13, 12:55:12 »

A quick and dirty way I usually do it is like this:
Make the textures tileable
Load them into multitexture and bercontile and randomize -1 to 1 in U and V, plus randomizing whatever scale and rotation I can without it looking weird. You can also do a slight hue and/or gamma randomization to break it up further.
This is usually enough, depending on the type of tile ofcourse

7

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

« on: 2023-09-12, 08:40:58 »

chiming in for +1 to Vantage

And "willing to pay the extra $600 a year on top of the Corona subscription?" - that's an important point to let us know when chiming in for Vantage :) Thanks!

Yes, if it reads 100% of all corona related maps and materials and works out of the box. And I might do it even if it ain't a 100%

8

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

« on: 2023-09-11, 09:06:29 »

chiming in for +1 to Vantage

9

[Max] Bug Reporting / Re: Corona proxy exporter exports more frames than selected

« on: 2023-09-05, 07:40:07 »

Seems to me you forgot to press the checkbox that changes from "Active time segment" and to "From frame / To frame" ?

10

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

« on: 2023-08-30, 11:30:07 »

+1 to parsing indeed. Already voted but seeing as it got some traction I wanted to chime in :)
+ also fixing corona bitmaps in material libraries so they don't freeze up max if you touch the timeline the very first time(Currently waiting 3-5 minutes at worst)

11

[Max] Feature Requests / CoronaLayeredMtl Number of Inputs

« on: 2023-08-24, 11:35:20 »

Hi there, I'd like to request a tiny quality of life improvement to the CoronaLayeredMtl to bring it more in line with other nodes:
Add the option to increase/decrease the number of layers/masks on the CoronaLayeredMtl
The default of 10 is a nice big number, but in most cases this ends up being a giant node that I barely use half of the inputs on, cluttering my material graph until I hit the inevitable "-" to minimize.

12

Gallery / Re: Santacruz Nomad v5 - Full 3D Bike Park

« on: 2023-08-24, 11:22:21 »

These are excellent, thanks for sharing!

13

[Max] General Discussion / Re: Roughness implementation correct?

« on: 2023-08-14, 07:52:52 »

Thanks, I get it now. So it looks like with high roughness it reflects more light back in the direction of the light source than into the camera. It's something like retroreflection, or the negative directionality values in Corona Volume Mtl.

Yes, this is what it looks like to me too.

I can understand the thought behind a very rough surface showing me the "shadow side" and hence making the surface appear darker in this case.
But when checking with the white furnace, there seems to be some issues with the shading model. This makes me question how much darker it should be getting, if at all. Not really sure if this is a valid way of checking this, so if anyone has any notes please chime in :)

Checking online I do actually find more evidence that the Oren Nayar model has some energy loss at high roughness.

Anyway, that is the shading model we have, so now I'm just wondering if anyone else has had any issues with this. Should we be careful with a roughness value past a certain point, or am I over complicating things?
I guess it's only something you notice if you pull the camera back and forth between the sunny and the shadow side of an object, so maybe it's only a "problem" in animations?

14

[Max] General Discussion / Re: Roughness implementation correct?

« on: 2023-08-10, 15:16:10 »

Hmm, interesting, too bad I can't really go to the moon to check it out, eh? :)
But I should probably find a really dusty surface and check that!

Thanks for the information

Anyway, in your article it says that "The main offender on the Oren-Nayar implementation (rombo DiffuseGeneralized, Arnold Std Material) is that it is based on single scattering and so it leaks energy (diffuse gets too dark with increasing roughness). "

Isn't this what the CoronaPhysicalMtl uses?

So in other words, it's not correct?
This is in line with the "white furnace" test I did
Ideally the material should be invisible when rendered in this environment no matter the roughness level

@Maru, sure see attached images. Look at the top face of the cube and the way it darkens a lot in "CamBehind" compared to the "CamFront" picture when Roughness is 1. This is obviously opposite of what happens with reflective surfaces, hence my surprise. (Exposure stays the same between images)

15

[Max] General Discussion / Roughness implementation correct?

« on: 2023-08-10, 13:45:08 »

Hi there

I've recently converted my material library to the new PhysicalMtl and noticed an effect I hadn't really thought about before:
When a material has a high roughness value it makes the material appear darker when looking at it towards the sun, and brighter when you have the sun at your back.

To recreate:
It seems to be an effect that starts at around 0,5 roughness, and easiest to see when using a cube/plane and a simple corona sun and sky setup. Look at the cube at gracing angles in RT and rotate between having the sun at your back or when looking towards the sun. As you increase the roughness value the materials noticeably darkens when you rotate to look towards the sun.

Is this physically correct?

I've just never seen this effect in real life, and so I started digging online

--Commence rambling--

Is it because the material BRDF(?) tries to emulate a masking and shadowing of microfacets?

This led me to try and check the energy preservation of the material by using what I've learned is called a "white furnace" that is a "a uniform lighting environment set to pure white, to validate the energy preservation property of a BRDF. When energy preservation is achieved, a purely reflective metallic surface (f0=1) should be indistinguishable from the background, no matter the roughness of said surface."

Increasing the roughness of a white(255) material in a white(255) environment is clearly showing a darkening at gracing angles with the PhysicalMtl, but not on the LegacyMtl

If I'm understanding things correctly this is mainly because these different BRDF's(?) all try and emulate a proper physical reaction to light and all fail in different ways. None of these BRDF's are perfect.

This might be entirely unrelated and is a bit out of my area of expertise so excuse my ignorance on the subject.

--Rambling over--

Anyway, if this darkening is indeed wrong, I would like to know how to deal with it.
Maybe one should try and keep roughness below 0,5 or even use the legacy material for very rough surfaces? I noticed the legacy material staying completely invisible in the "white furnace", but it probably has other issues, I'm sure I've read some old complaints about it.

If on the other hand this effect is physically accurate, what materials can have this effect? I would be interested in fine tuning my materials even further and would like to check this out in real life.