Messages

16

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

« on: 2019-08-09, 18:02:40 »

HQ filtering is silently disabled

Ohh that makes sense.
If I disable Optix, is HQ filtering used? Or is it just always disabled?

17

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

« on: 2019-08-09, 15:37:55 »

Since the Nvidia Denoiser and High Quality Image fitlering are both on by default... do they now work together?
Since they used to be semi-incompatible...

18

[Max] General Discussion / Re: "Rough AO"

« on: 2019-08-09, 08:03:38 »

Sorry to bump in, but to me it looks like the purple part is AO (red+blue) and green part is glossiness (more green = more shiny, the polished parts of the cobbles). Just some quick thoughts. ;)

Just double checked to reassure myself of my sanity.
https://texturehaven.com/tex/?t=cobblestone_floor_04
AO is green, glossiness is copied twice in the red and blue channel.

But I did mix it up in the image =.=
So 50% sanity I suppose? I can live with that...

19

General CG Discussion / Re: Why is Redshift so popular?

« on: 2019-08-05, 15:46:59 »

I'd love to see some current hardware price / performance metrics.
A new Ryzen 3900x compared to a 500€ equivalent graphics card, like the RTX 2070.
My feeling being, that Corona and CPU rendering in general still holds the upper card or equals GPU rendering in performance per dollar.

20

[Max] General Discussion / Re: "Rough AO"

« on: 2019-08-05, 13:37:11 »

Ok, I just double checked the channels. You both were correct.

The Rough AO map has indeed a copy of the AO map in the Green channel
and two copies of the same roughness map in the red and blue channel. How this is supposed to save space will be forever a mystery to me  :S

Also the Gamma values are screwed up. The AO Map in the rough AO map has a gamma curve applied, which is almost gamma 2.2. It doesn't quite line up, the conversion software was lazy. The roughness map is even worse, the gamma 2.2 is off by quite a bit.
Why the Rough AO map has gamma applied in the first place is beyond me.

21

[Max] General Discussion / Re: "Rough AO"

« on: 2019-08-05, 11:42:19 »

I presume the same. IIRC, it's standard for Unreal Engine texture maps created with Substance apps.
Those are simply values (0-255). To use and apply you separate, then convert a R/G/B channel to BW using nodes.

Makes total sense. Why have roughness in both Red and blue though?

I have no idea. They could add height into blue channel, since all their maps are 8 bit anyway.

Reminds me of the trickery valve did to get more wound masks and emissive without including more maps. They used a free alpha channel and seperated it into the first 128 and second 128 gray values. First 0-128 were the wound masks and 128-255 were emission maps for reflective clothing. Gotta find that presentation again...

22

[Max] Resolved Bugs / Re: corona lights with directionality going black when seen through refractive glass

« on: 2019-08-05, 11:40:05 »

Alternatively use the Rayswitch Material and skip having two objects. (Corona light rectangle is the same as a plane with light material, when the plane has only one face)
For GI have the Light material with directionality and for everything else have a copy of the light material without directionality

23

[Max] General Discussion / Re: "Rough AO"

« on: 2019-08-05, 11:06:37 »

I think it's simply AO in green channel and roughness in red and blue channels. Just to save some space.

Ohh, that makes sense :D
But why red and blue?
Isn't roughness single-channel information?

24

[Max] General Discussion / "Rough AO"

« on: 2019-08-05, 10:49:49 »

Hey there.
I recently came across the excellent texturehaven.com collection. In there, besides your typical maps is something called "rough AO", a green-pink colored AO map.
I have never seen it in use and can't find any reference for it.

Can someone enlighten me on what it is supposed to do?
Like here: https://texturehaven.com/tex/?t=cobblestone_large_01

I guess you could use it as pink = dirt, green = wear/tear in you shader, but I don't see how this is different from getting that info from a normal AO map, based on a threshold. Maybe this skips over having to define a threshold by getting the red/green channel respectively?

25

[Max] I need help! / Re: Anisotropy

« on: 2019-06-18, 06:10:51 »

Looks like normal smoothing is a bit off.
Either put faces on the inner part of the bowl all in one Smoothing group using edit poly or if memory serves me correct, throw a smooth modifier on it. It allows you to set smoothing to auto and just input an angle which it auto smooths with.
That'd be my guess.

26

[C4D] General Discussion / Re: Flashing lights

« on: 2019-06-18, 05:59:09 »

You got it right. Animate the light's intensity. With a fast attack and a slow fallow & orange tint towards the lower brightness if you want light bulb style flash instead of a LED style flash.
The characteristic thing about a flash is not necessarily the light, but the glare. So turn up glaring to get that, which is what actually creates the flash look, see image.

edit: A flash is very short, so 1 frame only for an LED style flash, unless you want something artistic. Then disregard this.

27

[Max] General Discussion / Re: Corona 1.3 Benchmark

« on: 2019-06-18, 01:16:28 »

Anyone knows about this and can explain?

If you mean in general, multi socket boards have existed since forever.
In case of threadripper you are correct, there are no multi socket boards for thread ripper, only for the epyc line up.

The Corona benchmark accidentally counts the multiple dies as multiple CPUs. Whilst you could make the argument, that the way thread ripper is set up it's not too far away from that idea, it's a bug.

28

[Max] Feature Requests / Re: To go further with "Set Focus"

« on: 2019-06-13, 01:05:27 »

will be near zero, can't we ?

Yeah, the point of sharpness remains an infinitely small plane, as it is in real life.
You can get around this by doing what game engines do: Render 3 images and composite based on the depth pass. (some engine's call it focal regions I believe, it is done because purely DoF from depth has edge blending problems)
If you want perfect sharpness between 20cm and 50cm, you set focal point to 20cm and render. Then you set focal point to 50cm and render. And lastly one render without DoF.
In Photoshop you blend all three based in depth. 20cm, only in brightness regions smaller than 20cm, the no DoF image in between and the 50cm image from 50cm and more. This will make the 20cm-50cm region perfectly sharp with proper transitions to the other out of focus regions. Also, edge blending problems can occur depending on how your geometry is layed out.

All of this is obviously a fake.

29

[C4D] Feature Requests / Re: Multiply the GI

« on: 2019-06-10, 06:55:20 »

another things could be great is to increase or decrease the GI the objects could receive or generate, with control panel inside the corona compositing tag.

Just in case you are unaware, Corona has it's Corona RaySwitcher Material, where you can increase decrease GI by changing what the GI ray sees for instance.
Tutorial for 3dsMax linked, but the same applies to C4D.

30

General CG Discussion / Re: Working remotely (reduce lag)

« on: 2019-06-01, 11:14:17 »

I found that RDC didn’t utilise the remote PCs graphics card at all (I think because it’s natively built into Windows, the OS knows that the GPU isn’t in use) - whereas Teamviewer seemed to still utilise all the hardware, provides you have a monitor or HDMI single attached.

Obviously Corona doesn’t need the GPU, but even for viewport speed I found it made a difference.

Window's remote Desktop:
It does use your graphics card and is currently the best integrated remote tool in windows. (Open up the task manager and drag a window around, you'll see quite a chunk for GPU usage). Nothing currently beats it in latency vs Quality.
The thing is, it does not expose the GPU in the classical way.
DirecX is not affected by this. OpenGL is - which is why it breaks many professional applications. The reason is a combo of Microsoft and Graphics Driver Teams being stubborn aholes. There are workarounds by the way, of which I wrote up a bunch here.
3dsMax is btw unaffected and runs just fine.

VNC as a protocol is really not meant for low latency work. The most low latency implementation is TightVNC with's encoding + Jpeg and it updates only the inside of the window and not everything by default. Very neat, but it is still beat by Window's remote quick quality scaling and pretty smart "progressive updates".

There is also NX, which uses Video compression techniques and is the goto in *nix world and replaces VNC in terms of speed, but RDP is still faster on windows.

I have never used TeamViewer but from what I understand is that it routes the images through their servers, which would obviously kill latency, though I may be worong.

And of course, nothing of any of this matters if you have a bad upload speed. Then you won't have a good experience no matter what. My 10mbit upload is barely enough to work with 3dsMax with acceptable levels of jank.