Cheetah3D 7.3 Beta 1

[Hasdrubal]

Mis' last picture is a good example of the added realism through caustics. It's not much, lots of people wouldn't be able to point out what's missing without them, but they would know it subconsciously and recognize the pic as fake.

There's one thing I don't like that much about it, though, it's this kind of hyper-realism that's coming with the pbr. It would help to weaken the normalmap and displacement effect just a little bit in my opinion.

But 7.3 is really a wide step up for Cheetah.

 

[misoversaturated]

Thanks guys!

It would help to weaken the normalmap and displacement effect just a little bit.

I'm new to PBR texturing but you're on to something, in this case I didn't use any displacement, only the normal maps but those seem to be quite strong.
So here's a new render (and how to scale down normal maps) :wink:

 

[uncle808us]

I have a question. If as I read here on the forum there is no transparency map in the PBR material how did you make the bottle transparent. I don't use nodes much due to the lack of a preview in the modeling window.
Anyway that is my question about transparency.

 

[uncle808us]

PBR question

Can PBR be used in the Cheetah Renderer? Or is it not a Physical Based Renderer?

 

[frank beckmann]

I have a question. If as I read here on the forum there is no transparency map in the PBR material how did you make the bottle transparent. I don't use nodes much due to the lack of a preview in the modeling window.
Anyway that is my question about transparency.

Simply use the "dielectric-shader" shader.

Cheers
Frank

 

[frank beckmann]

Can PBR be used in the Cheetah Renderer? Or is it not a Physical Based Renderer?

No it's not and you can use it with Cheetah.

Cheers
Frank

 

[uncle808us]

Simply use the "dielectric-shader" shader.

Cheers
Frank

But then it is no longer the PBR shader correct?

 

[frank beckmann]

But then it is no longer the PBR shader correct?

No - the dielectric shader is physically correct afaik.

Cheers
Frank

 

[uncle808us]

Thanks Frank.

 

[Hasdrubal]

Hi Mis

Sorry, I wrote displacement and meant the normal map all along. They usually are quiet strong, but that's not bad. Sometimes it's exactly what one wants. Most times not and that's this 'hyper realism' effect i've seen quiet a few times in other galleries.

I, for my part, like the picture now much better. The pbrs seem to give more realism in falcon, really beautiful wood. But the icing on the cake are the caustics :smile:

 

[Shift Studio]

... (and how to scale down normal maps)

This looks great - nice work. Also thanks for the normal intensity method. I assume you can just tweak the texture's mix value to adjust as necessary?

--shift studio.

 

[misoversaturated]

Also the new PBR materials work well with caustics

If as I read here on the forum there is no transparency map in the PBR material how did you make the bottle transparent.

Hi uncle, sorry that I caused confusion, I meant to say that the caustic patterns (generated with a dielectric shader) work well (on surfaces) with PBR materials.
Of course you're right that the PBR shader doesn't allow for transparency and therefore cannot be used on the glassware.
The new PBR shader has different reflection properties than the old material shader and I was curious how that looks.

Also thanks for the normal intensity method. I assume you can just tweak the adjust property as necessary?

Thanks shift, in order to adjust the strength of a normal map you need to use RGB 128,128,255 as the mix color of the normal image node.
That resembles a flat map with no bump.
Then you can adjust the mix value from 0=flat to 1=full normal bump as you like.

-cheers!


______



And here some more caustics (without PBR):

 

[Shift Studio]

Thanks shift, in order to adjust the strength of a normal map you need to use RGB 128,128,255 as the mix color of the normal image node.
That resembles a flat map with no bump.
Then you can adjust the mix value from 0=flat to 1=full normal bump as you like.

Excellent! this will probably come in handy.

--shift studio.

 

[podperson]

A bit of experimentation with C3D's gltf files is very promising. (I haven't looked at the animation side of things yet…)

A few gotchas — use web-friendly texture formats because browsers can't handle TIFFs, right now the material comes through as super shiny and nothing is set up to cast or receive shadows and transparency doesn't seem to get through from C3D to gltf yet.

So I wrote simple function (similar to something I wrote for C3D) that walks a tree and applies a function to it recursively:

const walktree = (node, f) => {
  f(node);
  if (node.children.length) {
    node.children.forEach(child => walktree(child, f));
  }
};

And apply it like this:

walktree(scout, n => {
  n.castShadow = true;
  n.receiveShadow = true;
});

The first model I tried was my pirate ship, but because it uses two-sided polygons for the sails, the self-shadowing was nightmarish. Rather than try to fix it by creating sails with thickness, I switched to a simpler model. If the cockpit glass were two-sided I could at least turn receiveShadow to false and it would look OK, but this would entail "finding" the appropriate element deep in the scene and setting its properties programmatically since we don't have any linkage from C3D's materials to the gltf output (yet).

Anyway, attached is a screenshot of my model with simple flat materials in C3D and then loaded into threejs with realtime soft shadows.

You'll notice that the cockpit isn't transparent. I could brute-force it as noted above. If I were "doing this for real" the entire mesh would use a single material which would make things much easier since everything would be driven by maps and the material could be found and "fixed" and shadows enabled easily.

From a production workflow point of view, what we have now is great (short of animation which I haven't looked at). Because names are preserved you could simply use a naming convention to communicate to your code (and have scenes automatically switch on shadow settings etc. based on the names of meshes or materials). For a long time this was the easiest way to get things working in Unity and it was fine.

Question for Martin: is there a command-line mechanism for C3D to export gtlf (as I believe there is with for FBX which is used by Unity?). If so it would allow C3D Buddy to generate scene previews and also potentially allow for Unity-like workflows when developing browser games.

 

[Jeanny]

Miso

Also the new PBR materials work well with caustics, the setup is super easy and the result looks just right:

View attachment 32635​

Your Render is Gorgeous . . . Absolutely Gorgeous!
Thanks for your tenacity in pursuing Glass Renders in C3D!

My Best
Jeanny

 

[misoversaturated]

Thanks Jeanny!

Here's another one, with IES lights and soft shadows instead of an HDRI.
Looks even better imo.
I disabled adaptive sampling cause it currently doesn't detect caustic noise well (filter at 0.05) and ran this render for 1.5 days but it still needed a bit of cleanup in PS.
Maybe the 32 glossy bounces necessary for clean glass don't work well with the PBR rough specular gloss?

 

[podperson]

Here's the final javascript demo which embeds a model straight out of Cheetah 3D.

http://bindinator.com/#source=threejs.component.html

The ground plane is created separately, but could obviously be in the model if so desired.

The model is modified after being loaded by this code:

walktree(scout, n => {
    if (n.material) {
      if (n.material.name === 'Cockpit') {
        n.material.transparent = true;
        n.material.roughness = 0.1;
        n.material.metalness = 0.5;
        n.material.opacity = 0.4;
      } else {
        n.material.roughness = 0.25;
      }
    }
    n.castShadow = true;
    n.receiveShadow = true;
  });

I'm not sure how much Martin plans to modify the behavior of his exporter, but the code gives you a pretty clear idea of how you could use object names inside C3D to communicate with your importer to (for example) set things like shadow behavior (or attach behaviors, collision detectors, and so on). I also note that non-mesh nodes are preserved (along with their names)

(Personally, I would prioritize tweaking the FBX exporter to do a better job of communicating material settings with Unity — particularly if you use the PBR shader, since I'm pretty sure there are or will be more C3D users doing this than struggling with WebGL.)

Oh, and it looks like there's no animation support at all right now so the route from Cheetah 3D to animated meshes in browsers is still going to be pretty convoluted for the time being .

Anyway, I hope to, some rainy weekend, knock up some kind of browser-based 3D game entirely using Cheetah 3D and threejs.

 

[misoversaturated]

Another scene with caustics on a PBR material.
Falcon caustics are a lot nicer than those in Cycles and faster too with the default values of filter=0.1 and clamping=10 (+adaptive sampling).
Deviating from there needs patience :smile:

 

[KurtF]

Here's the final javascript demo which embeds a model straight out of Cheetah 3D.

http://bindinator.com/#source=threejs.component.html


Anyway, I hope to, some rainy weekend, knock up some kind of browser-based 3D game entirely using Cheetah 3D and threejs.

Nice use of 3D in the browser. I liked the effect of the light source following the mouse cursor. Good luck with your game efforts.

 

[misoversaturated]

While I get that the new PBR shader is valuable for compatibility reasons it should also be helpful for rendering realistic diffuse and rough reflection materials or so I read in the papers about the Disney shader.

Secretly I was hoping for Oren-Nayar diffuse roughness but no such luck,
with metallic and specular level set to zero, changes of the roughness value don't affect the render anymore.
Apparently that's meant to be so according to the specifications because this PBR shader handles reflectivity at grazing angles via specular roughness, that's why the specular level is at 0.5 by default and not changed with any kind of specular map but roughness maps instead.

That's great for realism but comes at a prize because blurry reflections are expensive (regarding sample count) to render and also reflective caustics come into play here for energy conservation.

In order to test all this I set up a scene with mainly indirect lighting and (an attempt at) a procedural weathered concrete BPR material with a roughness map.
Now that was a stupid idea because the combination of indirect light and a procedural mat with blurry reflections reliably brings the Falcon renderer to its knees. Also my material sucks but a more realistic pattern requires more fractal nodes when each tends to double the render times.

Also when setting up an overnight render hoping to find a clean result in the morning I just found that the adaptive sampling algorithm again doesn't detect the (presumably) reflective caustic noise well and terminated the rendering too early (see second image which is an excerpt of the original, the one above is size reduced and denoised and actually looks quite well).





Looking at those pics I think the BRDF is well implemented and looks ok (and would even better with quality image based materials).

What's needed now imho is some improvement in Falcon regarding indirect lighting and the rendering of blurry reflections. For the latter we already have the caustic filter (biased) which helps and also adaptive sampling (unbiased) which needs better detection and/or manual adjustability.
Another possibility would be branched path sampling addressing the need of higher sample count for reflective (rough) materials. There are branched path tracers (like Cycles) out there which are notoriously hard to tweak but I think there could be an easier adoption like an automatism that would introduce branching and by doing so doubling or quadrupling the sample count whenever the roughness value in a metal, dielectric or PBR is set to non-zero?
(I'm just wildly speculating here.)

Regarding indirect lighting, apart from bidirectional path tracers the unidirectional renderers mostly use light portals.
I'd like to see something like that in Falcon.
Multiple Importance Sampling is already implemented I think and there are possibilities to produce visibility maps automatically to help finding ways towards the light.
One could think about rendering a quick blurry photon mapping pass (a photon mapper is already implemented in the Cheetah renderer) or a primary light tracing pass just to gain information about the light distribution for a map that then is used for importance sampling.
While a portal would guide the rays only to the opening in the ceiling, a light map would consider also the bright spot of sunlight on the ground which is probably more important than the piece of visible sky.
Also Metropolis Sampling comes to mind but that may be too difficult to implement (the Luxrender guys have it for ages but the Cycles guys don't get it done).

These are some thoughts of mine regarding the evolution of the Falcon renderer.
I'm somewhat concerned that there aren't more responses to the new features like PBR or IES on the forum, I haven't asked for those but now that they are here I learn to know them and also to like them and am developing an interest to get them integrated better.
I'd really like to see more people utilize the great stuff Martin has gifted us with and see more Falcon renders made with it!
:smile: