United States
Joined: Nov 28, 2020
Post Count: 5
Status:
Offline
Can someone please explain plan view "other level' wall visibility?
I'm running 6.4.2 currently.
I've read everything I can find, but the behavior does not make sense to me. If I create a new layout, add a couple walls at "level 0", then create a "new level" (level 1), the prior level walls are shown as "hidden" (guides)...If I raise the height of first levels walls above the "floor thickness", and intrude into the other level elevation, these walls become editable...all good so far.
If I set level 0 active, and "add level at same elevation" (level 2), I can see level 0 (as editable), and level 1 as guides...ok.
Now going back to level 0 active, my level 2 walls are completely unseen (even though at same elevation).
If I add another level to plan (level 3), this level is completely unseen from level 0,1,2 (even though "upper level 1" is visible from level 0). Why is "upper level 3" not visible to adjacent "lower level 1"??
Having levels available as guides is a necessity in my opinion, so this behavior is quite frustrating. Somehow it seems like there are some complicated (possibly contradictory rules in play). Can someone please explain them?
To me, it would just seem that having some attributes in the level settings like "visible" and "locked" would be simpler then whatever is going on now. TIA
United States
Joined: Nov 28, 2020
Post Count: 5
Status:
Offline
Re: Can someone please explain plan view "other level' wall visibility?
I've downloaded the source and trying to understand by debugging the code. It appears the behavior I'm describing is contained within the "paintOtherLevels" method of the PlanComponent. Unfortunately I'm not a native Java speaker, so it's taking me more than a few moments to grok it, but I'm getting there and have a little more free time over the holidays.
I'm sorry that I'm new to the forum...does a lack of reply by anyone mean: - I have never seen this? - I have seen this, but it doesn't bother me? - I have no clue what this guy is trying to say?
Just curious if I should just patch this for myself or suggest it as an improvement to the maintainers?
Romania
Joined: Apr 24, 2014
Post Count: 553
Status:
Offline
Re: Can someone please explain plan view "other level' wall visibility?
I have never seen this?
I see it and I think is the correct mod.
Can someone please explain them?
I'm not an expert but I try. In SH3D are two category of objects: plan components and furniture. They all belong to a level. From plan component only walls (if have enough high) will appear on upper level. The rest only on selected level. Usually I make multilevel plans especially because is this feature. Way I use multiple levels? Sometime at same elevation (for pipes, wires, dimensions, some labels etc.) and I need to see ONLY one at a time. Sometime at a little high elevation (5~10 cm) for floor to hide some pipes or heating system and again at same elevation but an other level for some furniture. All levels could be made visible in 3D for a better view.
Unfortunately I'm not a native Java speaker
Me neither!
it's taking me more than a few moments to grok it
I try this for two years and I can't get anything, but I steel insist.
Just curious if I should just patch this for myself
Of course You can try but first You have to learn how to do this. Then maybe teach me how to do.
---------------------------------------- A computer program does what you tell it to do, not what you want it to do. Murphy's Law (Greer's Third Law) When all else fails, read the instructions.Murphy's Law
United States
Joined: Nov 28, 2020
Post Count: 5
Status:
Offline
Re: Can someone please explain plan view "other level' wall visibility?
I have a further understanding of the code behavior related to the plan view, but still learning.
The code/rules are obtuse and inconsistent (IMO).
paintOtherLevels: paints the "reference" (shaded/hidden walls)
- If at "level0" (the magic "first level created"..."level0" does NOT have to be lowest elevation), ignore any other levels at the same eleveation, show (as reference) any levels that are at the "next HIGHER elevation" (any levels at equal elevation), ignore any levels "above" this. Note that if you insert a level with an elevation between "Level 0" and your (until now seen as reference) levels...they will disappear and only the new level visible.
- If NOT at "level 0", only show as reference the "next LOWER elevation" levels. Your lowest elevation level (if not "level 0") won't show guides. Therefore the order of adding levels impacts behavior.
getDrawableWallsInSelectedLevel: paints the "editable walls" (walls on current layer and those walls from other layers that intersect that layer (...not really))
- If a layer is determined to be "editable" by these rules it overrides "reference" drawing (or at least it is dominant from plan view behavior)...If a wall would have been drawn as "reference" and "editable", it will be shown as "editable"
- If a wall intersects (wall elevation < current layer elevation < wall elevation + wall height) the selected wall is "editable" ...UNLESS the walls elevation is EQUAL to the current layer elevation...in which case the layer attribute "elevationIndex" is checked and only walls on layers with LOWER "elevationIndex" are presented. I currently don't yet understand all the use cases for "elevationIndex", so it is unclear to me if serves any useful purpose.
The above is a simplified explanation of a hierarchy of method calls related to the plan drawing, and some of the lower level class methods may have correct behavior for other hierarchies calls (.ie I really don't want to hack at the low level methods without understanding how they are being used in other cases)
I can only imagine that this behavior is somehow an artifact of when "level" support was added, but the current code violates UI first principles (at least as I have been taught and how I have implemented them in my 30+ year career).
Personally I have no see no value in being able to edit walls on layers not selected...but I really do need to be able to reference/align to them in many cases.
For my first pass at this, I'm just going to add a layer attribute that allows view as reference to replace "paintOtherLevels" logic, and I'm going to modify "getDrawableXXXInSelectedLevel" to only present the stuff in that layer and see how that works for me (If I decide I want other layers editable, I'll do it via layer attribute).
France
Joined: Nov 7, 2005
Post Count: 9178
Status:
Offline
Re: Can someone please explain plan view "other level' wall visibility?
As you observed, only wall guides of the previous level can be seen in the edited level, or at the lowest level guides of its upper level. The idea is that you draw a level, then need guides in an upper level, or in a basement.
having some attributes in the level settings like "visible" [...] would be simpler
It will make the program too complicated, because you would have to detail also in which other levels you want a level to be visible, otherwise you would get many guides for houses with multiple levels. You could simply copy paste walls from a level to another one and remove the ones you don't want to keep, or program you own version, as you decided to do.
Therefore the order of adding levels impacts behavior.
No, you missed the fact that levels are always ordered from the lowest level to the highest, then at the same elevation, in the elevationIndex order set in the level modification dialog with the arrows at the right of Levels summary list.
the current code violates UI first principles
What principles do you have in mind?
----------------------------------------
Emmanuel Puybaret, Sweet Home 3D developer
United States
Joined: Nov 28, 2020
Post Count: 5
Status:
Offline
Re: Can someone please explain plan view "other level' wall visibility?
Thanks for the reply I'm just saying that I quickly became frustrated with the behavior because I did not understand it ("other layers" being guides (or not) or being editable (or not) or visible (or not) in the plan view). So much so, I felt the need to get the source code to understand "why".
It will make the program too complicated, because you would have to detail also in which other levels you want a level to be visible, otherwise you would get many guides for houses with multiple levels. You could simply copy paste walls from a level to another one and remove the ones you don't want to keep, or program you own version, as you decided to do.
I agree that layer attributes may be "too cumbersome" and I would like to have a coherent set of rules for displaying the guides. I'm thinking through it...perhaps analyzing all walls on a level (to determine a level "height" and presenting as guides any other walls from any other level that intersect that level. I am trying to understand the reasoning for allowing "other level" walls being "editable" if they intersect...is that typically desirable?
No, you missed the fact that levels are always ordered from the lowest level to the highest, then at the same elevation, in the elevationIndex order set in the level modification dialog with the arrows at the right of Levels summary list.
I understand that layers are being ordered as modified, the "specialness" of "layer0" was one area of confusion regarding whether guides were from levels "below" or "above"...as the elevation of "layer0" is modifiable, therefore the plan view presentation can change radically based on its elevation relative to other levels.
What principles do you have in mind?
Well...I shouldn't have to read source code to understand behavior I sincerely appreciate the effort that you have put into this tool and am quite happy to have found it. I'm just suggesting that perhaps there are some rough edges in behavior. From a principle standpoint, "reciprocity","orthogonality" (whatever term you like) and "consistency" seem violated. For example, in the below video, levels at same elevation don't even present depending on "elevationIndex"...level 0/1, 2/3 at same level, yet 1 not visible from level 0, 3 not visible from level 2...yet higher levels presented as guides. Adding a level can remove existing levels from being usable as guides, etc. ...Having gone through the code, I understand why things are behaving as they do, but I don't necessarily agree that this is optimal behavior.
And here's the code patch... - Intersecting rooms and walls are guides - "other" layer content is not editable. I don't see a way of uploading files, so sharing via a cloud service.
I'm thinking about adding some level attributes for default wall height, thickness, pattern and maybe a level "color" to help identify the source of the guides.
thanks again for the open source nature of the code, and just some ideas to consider for the future mainline.
