-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2020-05-09: Honeybee Viewer 2020-05-08 #12
Comments
Hi @theo-armour, This is actually how the model is. For large models one can use a representative floor with a "multiplier". See here for more details: https://bigladdersoftware.com/epx/docs/8-3/tips-and-tricks-using-energyplus/using-multipliers-zone-and-or-window.html As for the viewer, this is what we would expect. I personally liked the color of faces in the older version of the viewer more. 😁 |
Thanks for the explanation. it helps. what element (string?) do I look for in Dragonfly in order to establish what the multiplier is? I can find it, but you could save me some time. ;-)
As shown currently, "MeshNormalMaterial" is the lorem ipsum of three.js texture/color handling. eventually the colors will be determined by things such as what is in the construction data, or values as reported by analysis apps, or what Zia and Hannah decide they should be or whatever. |
Hi @theo-armour,
It is a property of the story: https://www.ladybug.tools/dragonfly-schema/model.html#tag/story_model
Got it! I think our family would vote for using face type for the default colors. |
Your advice is follows good and practical engineering practice. I am quite certain that a good engineer such as Michal would very much agree. An interesting aspect is that viewers and file browsers are highly user-facing aspects of a project. Given that this is part of an ongoing commercial project, what the users would like to see may well differ with what you or I might want to see. Considering what customers see may well be more important than what we might want to see. Considering the bias and predilections of the potential purchase decision-makers may be the most most beneficial strategy. Here are three simplistic observations or instant judgements: Engineers want to see projects that look and feel very similar to past projects that are known to have performed well and have had a minimum of statistical fails. All projects look alike. Architects want to see projects that look and feel original, unique and have a flair so that they fit into their milieu and yet stand out. All projects look different. Property developers want to see projects that look and feel like the best and most expensive projects recently completed and sold. All projects follow the current trend. So a good idea would be at some time in the future to consider a variety of uses cases for the Viewers and to customize the Viewers in ways that benefit and attract the selected types of users. As designers we must ignore or put aside our own workflows and consider the workflows of, fingers crossed, countless users of varying types and locales. |
Hi @theo-armour, great points and I agreed. I think I should have explained more about what I meant there. I'm going to make a distinction between the "viewer" and the "editor" and separate them as two separate products from user's point of view before getting to my comment about the color choice. Here is why: Following the Bushnell's Law to keep it useful and interesting at the same time a good product should be "easy to learn/start and difficult to master". In that sense I see the embed viewer with minimal functionalities as the "easy to start" point and the full-fledged viewer/editor as the "difficult to master". I will refer to the first one as "viewer" and to the second one as "editor" to keep it clear. To me the viewer is the starting point and where someone sees the model. They can get a sense of what is inside the model and they can query the data by hovering their mouse and clicking on the objects. They will not be able to change or edit the colors or make adjustments to the model. I think the scope of changes in an instance of the viewer should be minimal. This doesn't mean that the all the viewers should always have the same color. We can very well have different pallets and dispaly-by options but that is the decision that is made by the person who sets/embeds the viewer in a page. That person makes the call on the best representation for that context. Let's say something like this: Then it comes the editor for someone who wants to make changes. I totally agree with your point of view that different people have different desires and because of that one should be able to click on the viewer and go to the editor where they can customize the model the visualization and so on as they wish. My comment above was about the viewer and the default color for that. I think we are fully in agreement when it comes to the editor. 😀 |
Honeybee Viewer LT
https://www.ladybug.tools/honeybee-viewer/viewer-lt/
Beginning to read Dragonfly files. Still a ways to go.
Need to bring in JSON text parser and interaction with the model in order to locate sources of issues
The text was updated successfully, but these errors were encountered: