Make "TraShad" ON by default?

(simhar) #1

Hello,

I would suggest to make TraShad (the ability of a material to receive transparent shadows) on by default.

I think it’s a common task, that an object should receive transparent shadows. Especially for new users it’s a mess, to find out why an alpha-mapped leaf on a plane casts the shadow of the plane and not the shadow of the leaf…

What’s the reason to make it off by default ?

S.

0 Likes

(Alltaken) #2

I agree that its a common sense intention when a user makes something transparent, so i’m all for it.

There may be a performance reason why its not on by default, but these days the computers available are normally pretty capable.

I think the general reason why new features are not turned on by default is because they are a “deviation” from peoples previous experiences with older versions, but over a few versions common settings that get turned on should be considered for default status.

Good spotting.

Alltaken

0 Likes

(JiriH) #3

I also agree that this is very good point. Hope some coder reads this thread.

0 Likes

(Felix Kütt) #4

totally for it, its such a common thing, and those things that don’t need it, i dont think it really changes the rendering speed that much on most computers, indeed… :slight_smile:

0 Likes

(jensverwiebe) #5

Hi
To have for example “TransShadow” as default,
go in blender/source/blender/blenkernel/intern/material.c
from SVN-code.

There you find in line 168:

ma->mode= MA_TRACEBLE|MA_SHADBUF|MA_SHADOW|MA_RADIO|MA_RAYBIAS|MA_TANGENT_STR;

Add

|MA_SHADOW_TRA
at the end so it reads:

ma->mode= MA_TRACEBLE|MA_SHADBUF|MA_SHADOW|MA_RADIO|MA_RAYBIAS|MA_TANGENT_STR|MA_SHADOW_TRA;

Recompile.Thats all.Now it is active by default.

I´ll put it in the next build for OSX at Graficall ( next week )

Greetz…Jens

0 Likes

(osxrules) #6

The Blender defaults were carved in stone many millenia ago and handed down via the great Bikkie Dikkie to mortals. They cannot be argued with for fear of upsetting the mighty Blender deity in the sky.

But I agree this is one of the defaults that should be changed.

0 Likes

(Ace Dragon) #7

While Transhadow makes rendering times longer it would help to have it on by default so you don’t accidently have it off when having transparent materials, good idea.

0 Likes

(-TheAmiMan-) #8

While we’re at it… i’m all for setting the jpeg quality to 100% by default

0 Likes

(simhar) #9

thanx for all the replies.:eyebrowlift:

I see that it’s a common wish, so I will write a suggestion to the developers.

@AmiMan
Through the ui-redesign by broken, there will be presets for that. :eyebrowlift:

Thanx
S.

0 Likes

(Aligorith) #10

http://lists.blender.org/pipermail/bf-blender-cvs/2007-September/011211.html

There… I’ve committed jensverweibe’s little patch to svn (trunk). Someone can disable it later if there are any performance impacts in general due to this change… XD

Aligorith

0 Likes

(simhar) #11

WOW Thanx!

Think it’s a small change, but a huge benefit for new users.

Thanx
S.

0 Likes

(mattebb) #12

simhar:
One thing about thinking about usability is that you have to be careful not to just extrapolate your own experiences and assume its the same for everyone. I know you do architecture, so alpha mapped leaves probably come up a lot, but I don’t think it’s a big issue for most other users of Blender. I’ve used Blender for a long time, and I use it full time, every single work day, and I’ve never once needed to use transparent shadows. I’m not saying that means they’re useless or anything, but that this probably isn’t causing headaches for as many people as you think.

There are most definitely performance impacts - it’s not a real good idea to commit things like that, which will cause performance problems, without fully understanding their implications or even doing some benchmarks to test, and I think you should revert it until there’s a better solution.

When that feature first got put in, I felt the same way - it seemed illogical to have to set it on the receiving material, and I was annoyed it wasn’t on by default. But after recently working in the raytracer, I know why it is, and should be that way.

Here’s how raytraced shadows work:

  • On the currently rendered surface, for each sample of each ray shadow casting lamp, a ray is traced going from the current point on the surface to the light source.
  • If that ray finds an intersection with another piece of geometry, it is considered to be in shadow (since there is geometry blocking the line of sight between the lamp and that point on the surface).
  • For soft shadows, this process is repeated over and over again, but aiming at different points on the area light, and then an average is taken to see what ‘proportion’ is in shadow, and how dark the shadow is at that point.

For transparent shadows the process is much more complicated. Rather than just checking to see if there is an intersection and considering it in shadow, the renderer then has to examine the material of the piece of geometry that intersects, and find out its alpha value. This isn’t as simple as just checking the alpha variable, since it can be affected by textures, so the entire material/texture stack must be shaded, to figure out what the alpha value at that intersection point is. Not only can this be very time consuming if there are lots pf procedurals involved too, but if you’re using soft shadows it gets multiplied even more. So for example if you’re rendering a surface which is softly shadowed by a lamp with a sample count of 5 in the UI, that shadow casting material must be rendered internally 5 * 5 = 25 time per pixel just to calculate the shadow opacity, regardless if the shadow is even affecting transparency at all, and this shading isn’t even something that you see in the final render! This is a huge overhead, and of course is totally inefficient to calculate all this if (like in most situations) you’re not using any materials that cast transparent shadows.

A smarter way to do it could be to, at the start of the render process, inspect the texture stack and find out if that material affects alpha at all, or if it will always be totally opaque, then cache that information and use it to skip the transparent shadow calculations. But this needs to be made by someone :slight_smile: I recommend that the recent commit should be undone until something like that happens.

0 Likes

(TheANIMAL) #13

You can do that by saving it to the B.blend file cant you? Ive change a few things on that.

0 Likes

(jensverwiebe) #14

Hi folks
Due the renderspeed-impact and brokens argumentation,
it think the patch should not be commited but made available
to the people who wants to have it like this.
That means it should be included in a special build.
If anybody absolutely wants it, please tell the builder ( at GRAFICALL
for example ), i think it is no problem to tweak it.
I can give away a according build for OSXintel as usual.

Otherwise i fear it will be an endless discussion if everybody want´s
his preferred defaults in blender. This decision could only be made
by the most experienced users / dev´s.

Other preferences like jpeg-quality can be saved with the User-defaults
and have not to be discussed here. Just read what is included in user-def…

Greetz…Jens

0 Likes

(simhar) #15

yeah, that could be right :confused:

maybe I see the whole problem at another place (and yes, here again I extrapolate my experience):
I think, that a (new) user, who gets the problem with the alpha-mapped shadows , thinks first:

a) the object-material is wrong (not the shadow receiving) or

b) the render-settings are wrong

but (I think) it’s not obvious, that it’s a problem with the underlying material. maybe there could be a small pop-up-hint to “turn on trashad on the receiving material”, when activating the map-to-alpha button?? :confused:

btw: I don’t know no other 3d-program that has this workaround. mostly it’s default, that an underlying material receives alpha-mapped-shadows. but, yes, it could be a workaround affected by blenders render engine…

btw2: hey, that’s why we are here: to discuss different point-of-views…:eek:

thanx for your reply,

S.

0 Likes

(mattebb) #16

Yes, there’s no argument there, it’s definitely not obvious. I also think that although it would still have performance issues, it would be easier to understand if it were a lamp setting, not a material setting.

But although the way it is currently is not clear and difficult to discover, it’s still like that for a good reason. Weighing the slower render times for everyone vs having a setting being a bit hard to understand without reading the docs, I (and obviously Ton too since he made it that way) would err on the side of performance, and hope that people can learn about the setting from the docs.

Of course there’s also the option of investigating ways to do it smarter and more efficiently, but I don’t think the brute-force method, doing what jens mentioned above is a very good way to go about it.

PS. the commit has been undone by Aligorith.

0 Likes

(jensverwiebe) #17

Eh broken ?
What do you mean i do brute-forcing.
Maybe i havn´t understand it clearly.
I just wanted to weight out between good non-tweakable defaults and
point out there are lots of user-tweakable-defaults.

Jens

P.S.: Do you have know-how about OSX-coding ?
Iám trying to find out what´s preventing SOC-GLSL from
working on Mac, whrereas maike is doing his exams.
Mail me if you like.

0 Likes

(RamboBaby) #18

Well, I just tried this for my log home and, even without ANY transparent shadows being cast, enabling TraShadow for all materials increased my render time from 3:02 to 16:03.

The option is definitely off by default for a very good reason.

0 Likes

Shadow Casting Broken In 2.48
(CubOfJudahsLion) #19

Whoa.

In related note, it just seems curious that you can turn on TraShad without having Shadows on.

0 Likes