e. I think I got the daylighting workflow, I have good background in daylighting simulations.
I have a question for you
Do you think daysim will be able to handle a Radiance material that has BTRD function, such as this one that I created using optics6
Here is an example material created by Optics 5
void glass Solarglaze 70 DS_glass003 0.670 0.713 0.688
void BRTDfunc Solarglaze 70 DS_front100.094 0.095 0.0930.615 0.654 0.6310 0 0.09 0 0 0 0 0 0 0 0 0
void BRTDfunc Solarglaze 70 DS_back100.104 0.105 0.1010.615 0.654 0.6310 0 0.09 0 0 0 0 0 0 0 0 0
I have another question, about the EC glazing, I would like to setup Honeybee so that when window surface temperature becomes larger than a specific value the glass changes to tinted one with low transmissivity , how do I go about that? can this be accomplished by setting up a schedule?
Thanks
Rania…
.
3. This output is the input of another ghPython component which calls the methods of the output class.
So the problem is that when I test the second python script, it does not work.But when I recompute the whole grasshopper definition, it works.
If I look at the outputs when testing the single script, they appear Null.
I guess the problem lies in the tasks management of the software itself:When I test the python component, it works only in the component environment, like everything outside does not exist (not even the previous ghpython component --> not even the class with the useful methods).When I recompute the definition in grasshopper, the software reads and calculates all the components.
Find attached the whole script.To show the error, first run the "DS" python script (F5). Then, quit the shell and recompute grasshopper definition.…
thus is the more "safe" approach. For instance Imagine branches with unequal N of items etc etc.
Plan B: Is the way that PM works ... but obviously {A;B} > {B\something} assumes that branches are equally populated: a recipe for Armageddon in other cases.
Plan C: Is equally "shallow" since getting a List out of a Tree and then doing the Skip/Take thingy assumes that ... see Plan B . Of course using FromList.ToList().GetRange(startIndex, nOfItems);
is the same kind of rabbit hole.
Native: See Plan C.
PS: Something/OtherSomething IS NOT the same animal with Something\OtherSomething not to mention that {A;B\Something} gives 2 dimensional (wrong) results.
PS: Some of your Lofted stuff is "weird"/twisted (check this, this and that he he).
PS: Notify if you want a pack of 66.66 "easy" C# examples about how to get a tree and make chaos or order or whatever comes first.
Moral: cold of warm Guinness? that's the 1M question.
best, The Lord of Darkness…
Added by peter fotiadis at 12:16am on September 27, 2015
surfaces, extracting their contours, putting them to plane and recreating a surface (don't know if there was a quicker way).
However, my problem is: when I connect the components all together, all the surfaces I obtain are overlapping (see attachment).
I though of creating a vector that goes from one end to the other of one of the smallest sides (let's call it ds), meaning that every surface should move according to this vector. But now I face the fact that a generic i surface should move according to the previous, and so on; which is, I need to someway loop the component move over and over.
In layman's terms, that's what I have and what should happen:
Surface 0 in the list should not move.
Surface 1 should move according to point 0 and vector 0.
Surface 2 should move according to point 1 and vector 1, HOWEVER point 1 and vector 1 should have move previously, as they belonged to surface 0: so they should have moved according to point 0 and vector 0.
Surface 3 should move according to point 2 and vector 2, however... and so long.
I recognize a looping fashion in this algorithm that I can't come over.
Thank you for your help!!
(see attachment)…
Added by Pietro Pedone at 12:49am on February 8, 2013
radiance parameters to get rid of blotching. To add another level of complexity to my problem, I am running simulations with a translucent material with the following properties: void trans testTrans
0
0
7 0.478 0.478 0.478 0.000 0.010 0.178 0.635
I have had no issues with the renderings when I use clear glazing, as seen on this image:
However the blotching-issue becomes very noticeable when I introduce translucent glazing into the scene:
For the two above cases I used the following parameters:
_av_ is set to 0
xScale is set to 2
_ab_ is set to 6
_dc_ is set to 0.5
_aa_ is set to 0.2
_ad_ is set to 2048
_st_ is set to 0.5
yScale is set to 2
_ps_ is set to 4
_ar_ is set to 64
_as_ is set to 2048
_ds_ is set to 0.25
_pt_ is set to 0.1
_dr_ is set to 1
_pj_ is set to 0.9
_dp_ is set to 256
_dt_ is set to 0.25
_lr_ is set to 6
_dj_ is set to 0.5
_lw_ is set to 0.01
I ran another test with increased Radiance parameters and got the following output:
with the following parameters:
_av_ is set to 0
xScale is set to 6
_ab_ is set to 6
_dc_ is set to 0.75
_aa_ is set to 0.1
_ad_ is set to 4096
_st_ is set to 0.15
yScale is set to 6
_ps_ is set to 2
_ar_ is set to 128
_as_ is set to 4096
_ds_ is set to 0.05
_pt_ is set to 0.05
_dr_ is set to 3
_pj_ is set to 0.9
_dp_ is set to 512
_dt_ is set to 0.15
_lr_ is set to 8
_dj_ is set to 0.7
_lw_ is set to 0.005
Although the second blotching case is much better than the first, it is still very bad for hours when the sun is lower in the sky. The above images are rendered for a clear sky at 18:00 in Germany in a West-facing room.
Sorry for the long post! Can someone help? Kind regards, Örn
…
思った感じになりません。
balls の代わりにplanarカーブを直接入れてみましたがエラーが出ます。
ファンクションにしてみたところ、forループので作った数値が反映されていません。
ファンクションのインスタンス?を出力していないと思い上記のようにしましたがエラーが出てしまいます。
以上の事から自分の認識が正しいのかよくわからなくなりました・・・
python自体の深いところをわかっているわけではないので余計こんがらがりました。
そこで、for b in ballsはどのような条件または使い方であれば使えるのでしょうか?
そして、上記のように別のオブジェクトに対しての使い方はどのようにすればできるのでしょうか?
2:同じファンクション内のdist = rs.Distance(self.pos,b.pos)についてですが
この文章も for b in balls によってbはBallのインスタンスであると定義?されたためb.posがbの位置であると分かるのでしょうか?
pythonは定義しなくても動いてしまうのでどのような時に使えるのか文章見ただけではよくわかりません・・・
大変細かいことかもしれませんが、よりpythonをしっかりと理解するためにも、どなたかわかる方ご教授いただけると幸いです。…
by anything else (like walls, ceiling etc.). So, specifying ambient parameters in the simulation does not serve any purpose.
2. Get rid of source subdivision by setting -ds to 0. This will make Radiance assume that your source is a point source ( which seems to be a valid assumption in your case).
3. Finally, you can cut down the time even more by magnifying the candela value of a single light fixture instead of using the 9 fixtures that you have right now. This is a hack, but will work because that way, even the deterministic part of the calculation will feature only 1 variable instead of 9. You can make this work by increasing the candelaMultiplier of that one source by 9.
I have attached a gh file (which shows the parameters options) as an example. The points I have made above will mostly work for electric lighting only. Daylighting needs different kind of optimization because we are dealing with parallel rays from the sun and not a source with directional distribution like electric lights.
The image below is base-case. Takes the maximum time, using default settings.
This one is with direct-only calculations.
This is the case where a single fixture was used and the candela multiplier was used to magnify it's brightness 9 times. Took the least amount of time....but as you can there is a perceptible difference between this one and the base-case.
…