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
…
t file** - ply file with just x,y,z locations. I got it from a 3d scanner. Here is how first few lines of file looks like - ply format ascii 1.0 comment VCGLIB generated element vertex 6183 property float x property float y property float z end_header -32.3271 -43.9859 11.5124 -32.0631 -43.983 11.4945 12.9266 -44.4913 28.2031 13.1701 -44.4918 28.2568 13.4138 -44.4892 28.2531 13.6581 -44.4834 28.1941 13.9012 -44.4851 28.2684 ... ... ... In case you need the data - please email me on **nisha.m234@gmail.com**. **Algorithm:** I am trying to find principal curvatures for extracting the ridges and valleys. The steps I am following is: 1. Take a point x 2. Find its k nearest neighbors. I used k from 3 to 20. 3. average the k nearest neighbors => gives (_x, _y, _z) 4. compute covariance matrix 5. Now I take eigen values and eigen vectors of this covariance matrix 6. I get u, v and n here from eigen vectors. u is a vector corresponding to largest eigen value v corresponding to 2nd largest n is 3rd smallest vector corresponding to smallest eigen value 7. Then for transforming the point(x,y,z) I compute matrix T T = [ui ] [u ] [x - _x] [vi ] = [v ] x [y - _y] [ni ] [n ] [z - _z] 8. for each i of the k nearest neighbors:<br> [ n1 ] [u1*u1 u1*v1 v1*v1] [ a ]<br> [ n2 ] = [u2*u2 u2*v2 v2*v2] [ b ] <br> [... ] [ ... ... ... ] [ c ] <br> [ nk ] [uk*uk uk*vk vk*vk]<br> Solve this for a, b and c with least squares 9. this equations will give me a,b,c 10. now I compute eigen values of matrix [a b b a ] 11. This will give me 2 eigen values. one is Kmin and another Kmax. **My Problem:** The output is no where close to finding the correct Ridges and Valleys. I am totally Stuck and frustrated. I am not sure where exactly I am getting it wrong. I think the normal's are not computed correctly. But I am not sure. I am very new to graphics programming and so this maths, normals, shaders go way above my head. Any help will be appreciated. **PLEASE PLEASE HELP!!** **Resources:** I am using Visual Studio 2010 + Eigen Library + ANN Library. **Other Options used** I tried using MeshLab. I used ball pivoting triangles remeshing in MeshLab and then applied the polkadot3d shader. If correctly identifies the ridges and valleys. But I am not able to code it. **My Function:** //the function outputs to ply file void getEigen() { int nPts; // actual number of data points ANNpointArray dataPts; // data points ANNpoint queryPt; // query point ANNidxArray nnIdx;// near neighbor indices ANNdistArray dists; // near neighbor distances ANNkd_tree* kdTree; // search structure //for k = 25 and esp = 2, seems to got few ridges queryPt = annAllocPt(dim); // allocate query point dataPts = annAllocPts(maxPts, dim); // allocate data points nnIdx = new ANNidx[k]; // allocate near neigh indices dists = new ANNdist[k]; // allocate near neighbor dists nPts = 0; // read data points ifstream dataStream; dataStream.open(inputFile, ios::in);// open data file dataIn = &dataStream; ifstream queryStream; queryStream.open("input/query.
pts", ios::in);// open data file queryIn = &queryStream; while (nPts < maxPts && readPt(*dataIn, dataPts[nPts])) nPts++; kdTree = new ANNkd_tree( // build search structure dataPts, // the data points nPts, // number of points dim); // dimension of space while (readPt(*queryIn, queryPt)) // read query points { kdTree->annkSearch( // search queryPt, // query point k, // number of near neighbors nnIdx, // nearest neighbors (returned) dists, // distance (returned) eps); // error bound double x = queryPt[0]; double y = queryPt[1]; double z = queryPt[2]; double _x = 0.0; double _y = 0.0; double _z = 0.0; #pragma region Compute covariance matrix for (int i = 0; i < k; i++) { _x += dataPts[nnIdx[i]][0]; _y += dataPts[nnIdx[i]][1]; _z += dataPts[nnIdx[i]][2]; } _x = _x/k; _y = _y/k; _z = _z/k; double A[3][3] = {0,0,0,0,0,0,0,0,0}; for (int i = 0; i < k; i++) { double X = dataPts[nnIdx[i]][0]; double Y = dataPts[nnIdx[i]][1]; double Z = dataPts[nnIdx[i]][2]; A[0][0] += (X-_x) * (X-_x); A[0][1] += (X-_x) * (Y-_y); A[0][2] += (X-_x) * (Z-_z); A[1][0] += (Y-_y) * (X-_x); A[1][1] += (Y-_y) * (Y-_y); A[1][2] += (Y-_y) * (Z-_z); A[2][0] += (Z-_z) * (X-_x); A[2][1] += (Z-_z) * (Y-_y); A[2][2] += (Z-_z) * (Z-_z); } MatrixXd C(3,3); C <<A[0][0]/k, A[0][1]/k, A[0][2]/k, A[1][0]/k, A[1][1]/k, A[1][2]/k, A[2][0]/k, A[2][1]/k, A[2][2]/k; #pragma endregion EigenSolver<MatrixXd> es(C); MatrixXd Eval = es.eigenvalues().real().asDiagonal(); MatrixXd Evec = es.eigenvectors().real(); MatrixXd u,v,n; double a = Eval.row(0).col(0).value(); double b = Eval.row(1).col(1).value(); double c = Eval.row(2).col(2).value(); #pragma region SET U V N if(a>b && a>c) { u = Evec.row(0); if(b>c) { v = Eval.row(1); n = Eval.row(2);} else { v = Eval.row(2); n = Eval.row(1);} } else if(b>a && b>c) { u = Evec.row(1); if(a>c) { v = Eval.row(0); n = Eval.row(2);} else { v = Eval.row(2); n = Eval.row(0);} } else { u = Eval.row(2); if(a>b) { v = Eval.row(0); n = Eval.row(1);} else { v = Eval.row(1); n = Eval.row(0);} } #pragma endregion MatrixXd O(3,3); O <<u, v, n; MatrixXd UV(k,3); VectorXd N(k,1); for( int i=0; i<k; i++) { double x = dataPts[nnIdx[i]][0];; double y = dataPts[nnIdx[i]][1];; double z = dataPts[nnIdx[i]][2];; MatrixXd X(3,1); X << x-_x, y-_y, z-_z; MatrixXd T = O * X; double ui = T.row(0).col(0).value(); double vi = T.row(1).col(0).value(); double ni = T.row(2).col(0).value(); UV.row(i) << ui * ui, ui * vi, vi * vi; N.row(i) << ni; } Vector3d S = UV.colPivHouseholderQr().solve(N); MatrixXd II(2,2); II << S.row(0).value(), S.row(1).value(), S.row(1).value(), S.row(2).value(); EigenSolver<MatrixXd> es2(II); MatrixXd Eval2 = es2.eigenvalues().real().asDiagonal(); MatrixXd Evec2 = es2.eigenvectors().real(); double kmin, kmax; if(Eval2.row(0).col(0).value() < Eval2.row(1).col(1).value()) { kmin = Eval2.row(0).col(0).value(); kmax = Eval2.row(1).col(1).value(); } else { kmax = Eval2.row(0).col(0).value(); kmin = Eval2.row(1).col(1).value(); } double thresh = 0.0020078; if (kmin < thresh && kmax > thresh ) cout << x << " " << y << " " << z << " " << 255 << " " << 0 << " " << 0 << endl; else cout << x << " " << y << " " << z << " " << 255 << " " << 255 << " " << 255 << endl; } delete [] nnIdx; delete [] dists; delete kdTree; annClose(); } Thanks, NISHA…
r." I'm sorry to hear that, I take the interface and ease-of-use rather seriously so this sounds like a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative."What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design."Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it."[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Visual Programming.I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
Context sensitivity."There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them."Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal this time around is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
Sliders."I think they should be optional."They are optional."The “N” should turn into the number if set."What if you assign more than one integer? I think I'd rather see a component with inputs 'N', 'P' and 'X' rather than '5', '8' and '35.7', but I concede that is a personal preference."But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly."Agreed.
Components."Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings."I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data."Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
Integration."Why isn't it just live geometry?"This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry."Maybe add more Rhino functionality to GH. GH has no 3D offset."That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
Documentation.Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
2D-ness."I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
Organisation.Agreed. We need to come up with better ways to organise, document, version, share and simplify GH files. GH1 UI is ok for small projects (<100 components) but can't handle more complexity.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
david@mcneel.com…
y anyway ;))
Since 2014 i begun to get back into the construction biz for some dozen main reasons, one of them being the highly increased availability of this kind of software "power", and robotics.
first project ended by 1stQ 2015 was focused on the development of a parametric block for construction. (almost sure the first parametric product designed in Uruguay, and probably one of the few first of this kind globally...)
Far from being a complicated model. In fact the standard model is extremely simple, key thing is that is fully parametric...
dimensions, materials, textures, colors... and so on
second key thing is that the main common component of the blocks (an EPS core) is robotically machined...
the blocks are the base of a construction system (oriented mainly - though not restricted only - to residential buildings) that
- is based on digital models, tendentially to be used in parametric models of buidings
- lab tested to prove to be 1.5 times as compression resistant than traditional bricks and blocks. (autoportability up to two stories buildings)
- has recently proved (due to size) to be 300% more efficient than the classic and 200% more efficient than steel frame in (our country official figures)
check it out here
--
https://drive.google.com/file/d/0B1TRxxgF_sEnQnZrTkZGbUx3cmM/view
--
- and it's aimed to be mass produced and handled by robots...
this project ended on 1H 2016
and i filed 4 patents in the process.
3 of them of mechanical devices designed as extensions for a cnc machine i own
and the fourth (
the patent related specifically with the blocks ) included a dozen of innovations (believe me...i have almost 15 yrs in the biz, and are coool stuff...)
along the project I've been working with inventor, even knowing in advance it will lack the kind of features I wanted to program many things... (lisp, VB, etc.... all same species of -prehistoric - animals) to leverage the tool to the sky - and far beyond... -
but was an alternative valid by that time because it allows the implementation of some form of parametric models, had a local representative and some supposedly skilled guys in the neibourhood....
but life is hard... and none of the latter two rendered me any significant help
so I had to take the tour myself...
- mind i never regret to do things that others cant -
and finish what i start
this one was a great project for many figures... and ended with more results than the ones commited to accomplish...
... some more history here ....
then because of a customer who brought a ZHA project ! to quote..., I crossed with rhino, and then met GH again to notice to my great joy and pleasure, in what kind of animal it had developed...
since money talks I'm investing hard on getting up to the expectations, and beyond as i usually do...
and thats how we met..
2017-2018 it's the time frame to build two robots. first one is a prototype to handle the k-nano blocks in the production process, delivery AND at the construction site ( a "smart crane" we nicknamed...)
the other one is the first prototype of robot to assist in the fabrication (smart blocker we called it to be creative ! ;))
then by 2018-2019 i'll be making a "kinda contour crafter" machine to complete the pie :) (you'll be interested on this..)
i guess you already know what all this has to do with GH...
i already have all the components i can imagine to do almost all i ever wanted to do in relation to this set of projects
but in almost a single tool !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
i can design, animate, render, optimize, simulate and even robotic simulate..
so, i have to ask...
is there a chance you might be interested in helping us in some projects we are starting on march and june 2017 (8 and no more than 18 months of duration respectively) ?
sent you a friend request, for the case you might be interested to continue by e-mail...
in any case many thanks for your help and inspiration !
best regards !
long happy marriage, and large figures bank account !
…
he "return" is comment out as shown below?
After restarting Rhino and Grasshopper, I opened the outdoors_airflow demo file, and the first step of creating the case file is ok:
Then the blockMesh component gives the following error: seems I have to manually start OF first..
so, as the error message suggested, I open OF by Start_OF.bat:
Then come back to the blockMesh component, now it can be executed while the OF command line window is also openning:
... and the blockMesh finished successfully:
... so I proceeded to run snappyHexMesh, checkMesh and update fvScheme:
... up to the simpleFoam component, I got the error again:
The warning message is:
1. Solution exception: --> OpenFOAM command Failed!#0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #1 Foam::sigFpe::sigHandler(int) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #2 ? in "/lib64/libc.so.6" #3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #5 Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #6 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #7 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #8 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so" #9 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #10 Foam::fvMatrix<double>::solve() in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #11 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #12 __libc_start_main in "/lib64/libc.so.6" #13 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
... and the command lines in the readMe! output are pretty long and it is saved in the text file attached here.
So, my questions are:
1. why I have to manually start OF first before I can use the blockMesh component? Should butterfly automatically start OF?
2. what might be the cause of the unsuccessful run of simpleFoam in the end?
Hope you can kindly advise! Thank you!
- Ji
…
l coarse mesh
Subdividing this mesh into strips of thin quads
Relaxing/Planarizing this mesh
Splitting and Unrolling
In this post I deal with the first 2 of these stages.
You can download the example definition here:
developable_strips_tutorial.gh
Drawing the initial mesh
To begin with we need a simple quad mesh. This can be modelled manually in Rhino, and only needs to use enough quads to give the topology and very rough form. No need to worry too much about the exact geometry or dimensions at this point, as we will refine and alter it as we go.
One very important thing that we do need to bear in mind though is that all internal vertices must have even valence (I covered this a bit in the earlier post here).
So for example, this is bad:
(because the highlighted vertex is surrounded by 5 faces)
While this is good (and can still be relaxed to the same shape):
(the top and bottom vertices have valence 8, and the vertices between the arms have valence 4)
With a little practice it should be possible to convert any mesh into one that meets this condition.
The reasons why we need this condition should become more clear in the later steps.
First subdivision
This is where we choose how many strips we want our final model to have, by applying a few rounds of subdivision using the Refine component (you could also use Weaverbird here):
Sorting the face directions
While quad meshes do not carry the same information about u/v directions as a NURBS surface, the individual faces do have a sort of direction given by their vertex ordering. However, these face directions are usually not consistently arranged, especially after subdivision.
The Kangaroo MeshDirection component attempts* to orient all the faces in a mesh so that they match with their neighbours.
For example, before sorting, if we draw a line from the midpoint of the first edge of each face to the midpt of its opposite edge, we might get something like this:
Whereas after sorting, we should get something like this:
*note that I say it attempts to orient the faces consistently. In some cases no valid solution exists, for instance if 3 or 5 faces meet around a vertex, hence the requirement mentioned at the start for even valence vertices.
Directional Subdivision
Now that we have consistent face directions across the mesh, we can apply further subdivision, but this time in one direction only. So we go from roughly square quads to thin rectangles. The idea is that as we apply higher levels of this directional subdivision, the final relaxed result goes towards something semi-discrete. A NURBS surface is fully continuous, and a mesh is fully discrete (made up of separate facets), while this strip model will be smooth in one direction and faceted in the other.
Go to part 2 for the next step of the process
…
eration!
See an example work flow for designing, simulating and analysing a Photovoltaic system below.
Download a Grasshopper and Rhino example file:
https://www.dropbox.com/s/krbszlplj5i40dz/017_HBgeneration%20Rhino%20model.3dm?dl=0
https://www.dropbox.com/s/lxneuzal3mipd2q/017_HBgeneration.gh?dl=0
See a quick introduction and tutorial videos here: https://www.youtube.com/playlist?list=PLrx2KnyhaJ5YXo5hpk8Q9q4Vy99O5IegK
1. Select a building to mount a photovoltaic generator on (seen in Rhino in green).
2. Select a surface within that building to mount a photovoltaic generator on (seen in Rhino in green).
3. Create a Honeybee context surface from that surface.
4. Place a photovoltaic generator on that Honeybee context surface by using the Honeybee generation component. Honeybee_Generator_PV and connecting the context surface to it's input _HBSurfaces. Then you can specify both the performance and the financial data of the photovoltaic generator.
5. Create a Honeybee generation system which consists of the photovoltaic generator in 4. By using the component Honeybee_generationsystem and connecting 4 to its input PVHBSurfaces_. Then you can specify the annual maintenance cost of this system.
6. Run the simulation in Energy Plus by connecting 5. to the input HBGenerators_.
7. Read the results of the simulation:
- The electricity produced by the Honeybee generation system in 5.
- The net purchased electricity of the facility (the Honeybee zone) to which the Honeybee generation system is attached to. This is the electricity consumed by the facility less the electricity generated by the Honeybee generation system.
- The financial costs of the Honeybee generation system; capital, maintenance and replacement costs.
8. Calculate the net present cost of the Honeybee generation system in 5 assuming a 25 year lifetime.
9. Visualise the net present cost.
…
rring to the above image)
Area
effective
effective
Second
Elastic
Elastic
Plastic
Radius
Second
Elastic
Plastic
Radius
of
Vy shear
Vz shear
Moment
Modulus
Modulus
Modulus
of
Moment
Modulus
Modulus
of
Section
Area
Area
of Area
upper
lower
Gyration
of Area
Gyration
(strong axis)
(strong axis)
(strong axis)
(strong axis)
(strong axis)
(weak axis)
(weak axis)
(weak axis)
(weak axis)
A
Ay
Az
Iy
Wy
Wy
Wply
i_y
Iz
Wz
Wplz
i_z
cm2
cm2
cm2
cm4
cm3
cm3
cm3
cm
cm4
cm3
cm3
cm
I have a very similar table which I could import to the Karamba table. But I have i_v or i_u values as well as radius of inertia for instance.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
dimensjon
Masse
Areal
akse
Ix
Wpx
ix
akse
Iy
Wpy
iy
akse
Iv
Wpv
iv
Width
Thickness
Radius R
[kg/m]
[mm2]
[mm4]
[mm3]
[mm]
[mm4]
[mm3]
[mm]
[mm4]
[mm3]
[mm]
[mm]
[mm]
[mm]
L 20x3
0.89
113
x-x
4,000
290
5.9
y-y
4,000
290
5.9
v-v
1,700
200
3.9
20
3
4
L 20x4
1.15
146
x-x
5,000
360
5.8
y-y
5,000
360
5.8
v-v
2,200
240
3.8
20
4
4
L 25x3
1.12
143
x-x
8,200
460
7.6
y-y
8,200
460
7.6
v-v
3,400
330
4.9
25
3
4
L 25x4
1.46
186
x-x
10,300
590
7.4
y-y
10,300
590
7.4
v-v
4,300
400
4.8
25
4
4
L 30x3
1.37
175
x-x
14,600
680
9.1
y-y
14,600
680
9.1
v-v
6,100
510
5.9
30
3
5
L 30x4
1.79
228
x-x
18,400
870
9.0
y-y
18,400
870
9.0
v-v
7,700
620
5.8
30
4
5
L 36x3
1.66
211
x-x
25,800
990
11.1
y-y
25,800
990
11.1
v-v
10,700
760
7.1
36
3
5
L 36x4
2.16
276
x-x
32,900
1,280
10.9
y-y
32,900
1,280
10.9
v-v
13,700
930
7.0
36
4
5
L 36x5
2.65
338
x-x
39,500
1,560
10.8
y-y
39,500
1,560
10.8
v-v
16,500
1,090
7.0
36
5
5
I have diagonals (bracings) which can buckle in these "non-regular" directions too, and they do. If I could add those values then in the Karamba model I could assign specific buckling scenarios..... I can see another challenge which will be at the ModifyElement component, I will not be able to choose these buckling lengths, in these directions.
Do you think this functionality can be added within short, or should I try to find another way to model these members?
Br, Balazs
…