Implement ability to change model from the 3D Geometry Preview View (set Construction, ThermalZone, reverse Vertices)#863
Implement ability to change model from the 3D Geometry Preview View (set Construction, ThermalZone, reverse Vertices)#863
Conversation
…re from Javascript to C++
…showStory to sessionStorage and restore it - C++: Before calling refreshClicked(), runs a JS snippet that persists settings.renderBy and settings.showStory to sessionStorage. The reload only happens in the async callback, guaranteeing the save completes first. - JS (initDatGui): At the end, reads those keys back, updates settings directly, calls updateDisplay() to sync the dat.GUI dropdown UI, then calls the normal update(). Keys are immediately removed so the next manual refresh starts clean. This preserves the render mode (and story filter) across any mutation-triggered refresh, without touching the camera state or other settings.
|
this is awesome. can you do a multi-select? |
|
Dude! let me be content for a day before asking for more 🙃 (I think that'd require a significant change) |
| } | ||
| } | ||
|
|
||
| void GeometryBridge::triangulateSurface(const QString& surfaceName) { |
There was a problem hiding this comment.
Just curious, do you have a use case for this?
There was a problem hiding this comment.
For sun-related things like shading, having a non convex surfaces (eg a L, H shaped roof) is a problem, so I could see myself wanting to do this. I don't know, I was just in the flow and thought about adding it so I just did.
| } | ||
| } | ||
|
|
||
| void GeometryBridge::setOutsideBoundaryCondition(const QString& surfaceName, const QString& value) { |
There was a problem hiding this comment.
Setting the adjacent surface could be cool, although I guess you can do that from the surface tab too.
There was a problem hiding this comment.
I think that's a valid point.
You can also set the outside boundary condition and all from the surface tab too, it's just more tedious especially if you have auto-named surfaces like "Surface 114", which makes it quite hard to remember what you're touching.
|
|
||
| function displaySelectedObjectContextMenu() { | ||
|
|
||
| contextMenu.innerHTML = '<h2>Actions</h2>'; |
There was a problem hiding this comment.
Is there a way to give this menu a close button?
There was a problem hiding this comment.
Yeah, but is that necessary? Just click outside of it and it goes away. We don't have a close button on the left-click info panel (displaySelectedObjectDetails)
|
|
||
| GeometryBridge::GeometryBridge(model::Model& model, QObject* parent) : QObject(parent), m_model(model) {} | ||
|
|
||
| void GeometryBridge::reverseSurfaceVertices(const QString& surfaceName) { |
There was a problem hiding this comment.
Set surface type could be useful as well.
There was a problem hiding this comment.
I think that one definitely makes sense.
There was a problem hiding this comment.
Do you think it would be worthwhile to add DisplayName and CadObjectId to the info messages if they exist?
There was a problem hiding this comment.
Not 100% sure if that's valuable for people or not. I'm guessing if you care about these, you're definitely using another 3D editor as the driver (eg: Rhino with Ladybug tools) and probably less likely to be trying to do that in the 3D GeometryPreview.
The question is whether this info is in the ThreeJSForwardTranslator export or not (I will have to check, cant remember)
It's a simple code change though for us, and most models won't have it, so I guess it would be fine to add it.
There was a problem hiding this comment.
After checking, AFAIK this is not exported by the OpenStudio SDK. https://github.com/NatLabRockies/OpenStudio/blob/8008ef767fdc0f9d3dd3fabd383da15d009aef76/src/utilities/geometry/ThreeJS.hpp#L169
|
This is really cool @jmarrec great job! |
|
Left some optional comments but approving as is. |
I am pretty darn excited about this. I think this is huge.