I am assuming you mean shadows in the OpenGL view (VISUALISE tab), in which case what you are describing occurs only when you choose to show the shadows only from objects you have specifically selected or assigned a different shadow colour. In fact, shadows do penetrate right through other obstructions in their way. The thing is you don't normally see this because of the shadow cast of the actual obstruction. A point shaded by one opaque object is just as much 'in shade' as a point shaded by many opaque obstructions. Thus, when you do a normal shadow projection in Ecotect, the shadows should look fine.
However, when you choose to 'turn off' the shadows of some objects, you are effectively making those objects transparent to the Sun. They will visually appear solid and opaque, but sunlight (and hence shadows) will travel right through. This is a highly abstract way of looking at things and something that you cannot possibly achieve in a physical world - but with a computer you can do pretty much anything. Hence there is no right or wrong way of doing such an abstract representation, we just chose to show the full extent of each shadow's projection right down to the ground plane as this seemed to be what people most often expected to see.
If you meant shadows in the 3D EDITOR view, then this is just a wireframe model which defaults to showing just ground shadows. If you want to see shadows projected only onto specific objects, then simply select them and tag them as Shaded Surfaces using the Shadow Settings panel.
This means that if I want to check the effect of a single building I will have to see its shadow go through the neighboring obstructions? How is this helpful? More than anything else it seems to me simply unrealistic, as you pointed out in your reply.
The same happens if I am tagging the building as reflector then, I imagine I will see its reflection going straight through the surrounding obstructions. Is there a way to avoid this?
That's true - objects 'transparent' to shadows are also 'transparent' to reflections.
There is a section in the help file that discusses this in relation to the Display Reflection Obstructions option. This is near the bottom of the Analysis >> Shadows >> Shadow Display Options page. You can get to it directly by entering the following link into the Internet Explorer address bar if you have Ecotect installed in the default installation folder:
Computationally, I am not sure if it is possible to render truncated shadows as quickly as fully projected ones. There may be some tricks (such as rendering shadows from 'transparent' objects in the same colour as the background) but I can also see an equal number of situations where potential artificacts might be just as confusing as the way we chose to do it.
I will check that out to see how can it help me, although I have the impression that I have tried it already.
I am impressed by the speed of your reply so I am going to try my luck by copying a post I had sent a while ago on the Ecotect forum and has never been replied to.
"A couple of issues if I may;
1) solar incidence analysis: I have tested and retested solar incidence analysis without getting a consistent result out of it. I have used the adjacencies trick too, without success.
My issue is that I don't exactly get how Ecotect calculates the shading mask in order to derive the radiation from the climate data. If I may be more specific:
a) if you look into LondonE.wea there are some radiation values which are negative , how come?
b) given that the shading masks should register obstructions based on geometric angles (maybe I am wrong here...) this is how you can derive the angle of incidence (cosine law) at which radiation hits the tested surface, and find out where this is obstructed or not.
When I tested various orientation and angles I did get different results, which is positive. Although, when I tested a very simple flat horizontal plane, I do not achieve the irradiance (horizontal) I expect from the climate file values I am using. Even more specifically, it seems that Ecotect manages to calculate the diffuse part pretty fine (I bet this is because it is independent from orientation), whilst it seems to underestimate the direct component.
What am I missing?
c)if i repeat the flat plane exercise with the analysis grid, my results then are simply incomparable, although I go through the same wizard choices. This is confusing.
I have noticed that the results you get from the grid analysis are expressed as W/h whilst the ones from the surface analysis are expressed in Wh/sqm.
This is once again trivial; does it mean that if you run the analysis on a grid , the resulting values get divided per area covered? I have tried to do that manually (on a 1sqm surface) but the results do not match.
If instead I run my surface analysis and I calculate average daily values, shouldn't the scale read: W/sqm? This should be the case, because in a single hour case, solar flux and irrandiance match and mathematically the 'h' value can get omitted.
As you can read I am in need of clarification..
I am used to write my own rad materials, build my Ecotect library(with same names) and then export my geometry having Ecotect look up for .rad files and substitute them to the ecomaterials straight away; somehow this does not work any longer. Is it a possible bug or am I doing something wrong?"
Sorry if this is so lengthy, but I am very fond of the efficiency of Ecotect, hence I get anxious when I stall because I can't work it out.
I got a bit lost around the middle of your post so I'll have to go back and have a better read. However, I can answer your last question pretty quickly.
If you go into the Element Library dialog in Ecotect, you will see an Advanced Export tab. This lets you actually embed the Radiance material definition within the actual model itself, making it much more portable. You can see that you can do this for lots of different exports, not just Radance. If you enter some text in the edit box there, Ecotect will use that instead of it's own generated definition. You can also use <!NAME> in the definition to automatically insert the current material name.
I thought the previous .rad file lookup was still working if you didn't include a definition but I will check this for you.
This is what happens when I display Reflection Obstructions(see attached image). It is not the same as you show in the help file, but maybe I am doing some wrong.
What you show in the help file is exactly what I would need.
(Sorry if you have seen my crossposting to the old squ1 forum... not sure where we should all be.)
I have also been experiencing trouble with materials. After upgrading to 5.6 my materials ceased being replaced with specified rad material files upon Radiance export. This procedure now seems to require all material files be located in the same directory as the .eco file, no matter what the material export directory has been set to, for it to work. Needless to say, this is extremely inconvenient.
The new option of the Advanced Export tab in the Element Library may help, but there is no help file or instructions for using this... would I have to replace every ecotect material with the corresponding Radiance info one by one? Please tell me I don't have to re-input all my materials...