for instance, I might use the align button and want rooms to snap to a line. I can’t tell if they snapped to the line because the gap was likely very small. No problem with small gaps, but it is irritating to run a feature and have no feedback for what was changed and where it was changed.
I would like to have feedback if a parameter of a room is changed by lighting up of the room (or particular part of the wall) instead of just a simple text box because. It helps me get a feel for what happened to the geometry. I press these different feature buttons that do different things but often nothing moves on the screen besides a text box that said that something changed successfully.
The text box is cool but it would be engaging and intuitively helpful to have rooms light up that were changed through the magic of clicking a button. This would provide a richer experience for the user who engages with an abstract 3D model and abstract features.
makes sense?
JUST AN IDEA, BUT I THINK IT 'S AN EASY AND GOOD ONE
Let me start by saying that I love the idea. I even propose to do this instead of lighting up the rooms so it will be dust all over the place.
This is a very valid point but unfortunately it is not as easy to implement with our current structure. We currently do not keep track of which rooms have changed and which rooms have not changed. We simply send the rooms to the command, and replace them with the ones that are returned.
@chriswmackey, am I right about this? Or do we keep track of the changes, and there is an easy way to tell which rooms have been affected after running a certain command?
Its’s a great idea but it is not easy to implement. If we wanted to add support for something like this, I would probably need to add a dedicated new script that takes the old room and edited room as input, analyzes whether anything significant changed in relation to the model tolerance or some other threshold, and then returns true/false for whether there was a change.
So it would probably have to be some type of keyboard shortcut for “highlight change of last operation”.
The idea of post-processing is actually a good one to test. We can use the same code that we use for facade and room area change as a starting point. It won’t catch changes for commands like join co-planar faces but I imagine that’s OK. If the command became very popular we can add checks for change in number of vertices, etc.
And since it will add time to the calculation we can make it an option in the settings for the user to choose. @antonellodinunzio, am I right that we could use this method like a callback only when the user selects the option?
Yes, that’s correct @mostapha. We could introduce an additional callback to retrieve the change data. To preserve performance, it would remain optional.
