Author Topic: [test] C4D procedural noise shaders  (Read 8217 times)

2015-11-18, 20:10:28

burnin

  • Active Users
  • **
  • Posts: 1532
    • View Profile
For those having problems with C4D procedural noise shaders, made a staged test scene.


5 Variations / cameras:
1 - displace + diffuse
2 - displace
3 - diffuse
4 - bump
5 - bump + diffuse

proc4DnoiseTest_a41.7z attached

Correct if any mistakes found. Develop further. Hunt for bugs.
Those who have reported crashes i suspect GPUs.
Note: Wait for material preview to render. Do not disturb it, it might crash - experienced with older cards.
No problems here whatsoever. Not yet crashed.
« Last Edit: 2018-07-07, 17:41:11 by burnin »

2015-11-19, 23:10:38
Reply #1

Rhodesy

  • Active Users
  • **
  • Posts: 553
    • View Profile
Cool test.

Re crashes, I wrote this on the 4.1 thread....

I had big issues with using the C4D noise shaders resulting in instant crashes but it only occurred on one machine, and did it in both R16 and R17. it was fine on another couple of machines that I tested. After some head scratching I reinstalled C4D to a new folder then copied it into my original MAXON installation folder and deleted the original installation. Now everything works. Might be worth a try. You can give it a dry run by just installing c4d to a new folder and the copy across the corona plugin folder and .dll files from your original installation.

2015-11-20, 11:23:34
Reply #2

Nejc Kilar

  • Corona Team
  • Active Users
  • ****
  • Posts: 1245
    • View Profile
    • My personal website
Are we talking about crashes here or are the noise shaders getting inaccurately represented in render time? Apologies for not testing it myself...
Nejc Kilar | chaos-corona.com
Educational Content Creator | contact us

2015-11-20, 12:38:18
Reply #3

burnin

  • Active Users
  • **
  • Posts: 1532
    • View Profile
From my tests everything works here.
Even IPR with displacement, noise, bump & all...
Made a scene so users (some complaints in the alpha 4.1 thread) can find bugs in their system, resolve or report...

2015-11-20, 17:19:40
Reply #4

Nejc Kilar

  • Corona Team
  • Active Users
  • ****
  • Posts: 1245
    • View Profile
    • My personal website
From my tests everything works here.
Even IPR with displacement, noise, bump & all...
Made a scene so users (some complaints in the alpha 4.1 thread) can find bugs in their system, resolve or report...

Right... I haven't done any testing myself but I remember having some strange bump results in the previous version and I am not sure if it was because of the noise shader or the bump channel. Anyway, thanks for the scene, great effort man!
Nejc Kilar | chaos-corona.com
Educational Content Creator | contact us

2016-01-25, 17:39:07
Reply #5

4b4

  • Active Users
  • **
  • Posts: 163
    • View Profile
thanks for putting this together burnin

Have you had any luck using a normal texture map in the bump channel via the Corona -> Normal option?

I (think) we're supposed to do this but I get very odd results- maybe that's just for max users at the moment?

2018-07-07, 17:40:31
Reply #6

burnin

  • Active Users
  • **
  • Posts: 1532
    • View Profile
thanks for putting this together burnin

Have you had any luck using a normal texture map in the bump channel via the Corona -> Normal option?

I (think) we're supposed to do this but I get very odd results- maybe that's just for max users at the moment?

// updated the file with Corona Normal shader version in Bump channel.

Seems to work fine

i guess - cuz i never use normal maps in context with physically accurate/unbiased rendering (light transport simulation)
imho, it's nonsense, an oxymoron & their use in such way is more problematic than helpful :p
Normal maps are intended to fake light distribution over surfaces (bumps & dents), enhance low poly geometry & in RT game engines.

Same happens here.

eg
As i had IPR running & developing shaders with Corona Normal shader in Bump channel,
after almost every 3rd/4th time the change to shader was made (specifically: swapping RGB channels direction),
IPR first starts to show only raw, flat shaded geometry and needs to be restarted or after a while, Cinema crashes.




PS
File in OP uploaded, updated with Corona Normal shader in Bump channel of Corona Material: noisetest_B2.7z





2018-07-07, 19:59:16
Reply #7

Eddoron

  • Active Users
  • **
  • Posts: 552
  • Achieved Pedestrian
    • View Profile
The last version with standard noises plugged into NRN is clearly wrong.
The additional bump channel is strong enough to take over the most, but it's still noticeable. all the swapping doesn't help if you don't have RGB lit noises.
The only thing that you get without additional bump is some fake shine on the surfaces because the engine assumes the polys to be in some weird position.
Similar to rotating the vertex normals too much.

Unfortunately, the normalizer doesn't work with all types of noises or they have to be "hidden" inside another shader, but the normalizer would be the correct way.

Here it is with a repeating b&w gradient

2018-07-07, 20:56:26
Reply #8

burnin

  • Active Users
  • **
  • Posts: 1532
    • View Profile
Yes, i too noticed that c4d noise doesn't get through Normalized shader function into Corona Normal (other c4d procedural textures work fine) & as i wrote, i never use normal maps in unbiased, especially spectral engines. Bump & displacement are more than enough. This example clearly shows what waste, confusion & time consumption it makes while giving no true benefit.
So for 'ground truth' rendering I'll always take better memory management & efficiency VS fake options.

2018-07-08, 00:18:44
Reply #9

Eddoron

  • Active Users
  • **
  • Posts: 552
  • Achieved Pedestrian
    • View Profile
I would agree with your argument but:

1. I like normals, especially object & world space allow cool animations like raindrops sliding down. Bump maps contain only height info, normals can have any angle. Normal maps, also known as "dot-3 bump maps" are basically the latest version of bump maps.

2. IIRC, bump maps have to be calculated 3 times (for x, y, and z)

3. They're crisper than bump maps and allow a greater amount of space just by using different colors, while a bump map needs to be 16 or 32 bits to achieve that amount if you don't want step artifacts. In simple .jpgs, a 24bit nrm map has 3x the accuracy of an 8bit bump.

4. Great for LODs and simple to create. This is very handy for animations. Adaptive subdivision/per pixel displacement is nice but you can't control the outcome at certain distances.

5. You can't create a bevel on an edge with a bump map.


I'd also use Displacement if possible, but sometimes it's just a lot faster to have a displacement for the medium-large effects and normals for the smaller ones where the resulting image is exactly the same as a fully hires displaced output.
There's no way around normals if you want to have quality but are limited by RAM.

I might be wrong on some things (Saturday is brain-off-day) but I don't see any disadvantages in unbiased engines.
If there are any, or me being wrong on something, please let me know.