[Thomas An.]

Hi all,

A user (Patrick) brought to my attention that this shading issue is not necessarily a Maxwell bug.

For example, Blender had a similar issue, and here is the explanation of one of the developers (Ton Roosendaal)
http://www.blender3d.org/cms/Misc_impro ... 355.0.html

It seems that Tom was on the right track as well:

This is not a bug, it's a limitation of non-tricky physically based shading of surface. Currently, the only solution is you need to refine the mesh (increase mesh resolution). However, we'll keep our experiments for a better solution.

Casey, may have also been on the right track (if I understand his description correctly):
http://www.maxwellrender.com/forum/view ... hp?t=18352

Other modern renderers seem to overcome this basic limitation because they introduce biasing methods to glean over the issue (but at the same time run the danger of introducing artifacts).

The only practical solution I see so far is to tighten the polygons so as to make this (non Maxwell specific) effect negigible.

[pBarrelas]

Thomas An. - Thanks a lot for these links and the explanation! Yeah, its looks that for now, the only way to deal with this is to use high poly models, which will bring another problem - higher rendering times!!

[Mihai]

It's only the voxelisation that will take longer, but render times won't increase by much if at all. Note emitters should always be as low poly as possible.

[samsam]

I feel uncomfortable reading all these excuses & allowances in NL failing to come up with a solution to the shadow termination issue. Most modern renderers have a way to transparently overcome this problem. To suggest that Maxwell can't do this because "it's non biased" is I think a cop out on the part of the developers. You might as well say that bump/roughness maps should not be in maxwell's feature set because they are approximations of 'micro' surface details. Likewise you might say that textured material maps are also approximations and that the only way to get the correct 'non-biased' result is to specify the molecular composition of a surface.

Maxwell already selectively assumes and approximates many aspects of 'reality'. And even then still produces many errors and artifacts.

The dev's should apply a localised shadow termination solution within maxwells overall rendering solution (or if they really want to get religious about it, offer the user a flag setting allowing us to choose.)

[Fernando Tella]

I feel uncomfortable reading all these excuses & allowances in NL failing to come up with a solution to the shadow termination issue. Most modern renderers have a way to transparently overcome this problem. To suggest that Maxwell can't do this because "it's non biased" is I think a cop out on the part of the developers. You might as well say that bump/roughness maps should not be in maxwell's feature set because they are approximations of 'micro' surface details. Likewise you might say that textured material maps are also approximations and that the only way to get the correct 'non-biased' result is to specify the molecular composition of a surface.

Maxwell already selectively assumes and approximates many aspects of 'reality'. And even then still produces many errors and artifacts.

The dev's should apply a localised shadow termination solution within maxwells overall rendering solution (or if they really want to get religious about it, offer the user a flag setting allowing us to choose.)

+1

[Maximus3D]

I have to say i fully agree with samsam. Sad but true. some flexiblity would not hurt, as long as it makes Maxwell works as expected.

/ Max

[numerobis]

The dev's should apply a localised shadow termination solution within maxwells overall rendering solution (or if they really want to get religious about it, offer the user a flag setting allowing us to choose.)

+1

... 2 years later (Sun Oct 29, 2006 10:46)

[Becco_UK]

Bump maps are archaic (even though I still use them ). Use the bump map in the displacement channel.

[tom]

To suggest that Maxwell can't do this because "it's non biased" is I think a cop out on the part of the developers.

I wish it's like that, but really not. Technical facts and constraints accept no emotions here so we can easily admit it's not perfectly possible. Because, in physical world, there's no smoothing already and all biased/unbiased methods of smoothing are fakes in the end. Flat shading is the most physically accurate way of rendering polygons. When you bias, you can smooth any surface like it's infinitely subdivided and that's good. But, when you're dealing with energy/reflectance calculations like Maxwell and any other unbiased engine do, you have no chance to make approximate calculations on energy flow. So, it's still possible to smooth these polygons until this limit so it's strongly suggested keeping them small depending on viewing distance. It's really not an excuse

[kami]

so our only solution would be to use a finer mesh?

[Becco_UK]

kami: Using a displacement map creates a finer mesh?

[Fernando Tella]

When I build a smooth sphere I want that geometry to approximate a perfectly smooth sphere. I want that approximation and also I want the renderer to treat that object as a perfectly smooth sphere. I don't want to render faces, I want to show objects.

It still sounds as an excuse, sorry. Maybe it's harder to code this into Maxwell but it will make users lives a lot easier. Nobody wants to see those jagged shadows.

[Maximus3D]

I agree with you Fernando, it's only an excuse to say that it's the users fault that Maxwell can only work well with highpoly models, we should not have to use 2 million polys on a sphere for it to render smooth with Maxwell. That would be plain silly! Maxwell should like any modern renderengine be able to render medium and lowpoly models perfectly well without running into issues like this. There has to be some flexibility in Maxwell's design and code to allow it to atleast render what's considered normal in any other engine, unbiased or not. To me it sounds like you NL guys put up so many high barriers to keep Maxwell unbiased that it blocks you from developing a fully functional engine. This is one proof of that.

/ Max

[polynurb]

if i'd put my vote i'd rather want to see native nurbs than complicated workarounds with meshes... as long as you try to represent a sphere in triangles it will never be a sphere.

[tom]

Now, I understand why developers usually avoid making explanations. It's just equal to talking alone. I don't like gravity too, but the planet still pulls me down. I wish I could have time to convince you, but no.