Door Inconsistencies

[mr. iagea]

Okay, so I've got some weird door behavior in the beginning stage of a new drawing.

On one layer, I've got some doors, all with a class "Doors". They show up great, all nice and perfect (see "Door-1.png").

On another layer, my doors are all showing up unfilled and just as lines (see Door-2.png).

Both layers' doors are EXACTLY the same, same class, same visibility, everything. What gives?

THIS is the inconsistent behavior that steams me about VW. Everything else is just peachy.

Any ideas?

[gmm18]

I know you said they have the same visibilities...but to be sure...is there a "Style" class that is not turned on or something?

[mr. iagea]

all classes are on and visible. there are no special styles attached. all doors are exactly alike.

tried trashing the prefs, restarting, etc. no difference. even the doors with solid leaf panels are transparent.

[Pat Stanford]

What happens if you copy and paste one of the "good" doors to the "bad" layer?

What about pasting one of the doors from the "bad" layer to the "good" layer?

[mr. iagea]

the "good" door retains its goodness when place on the "bad" layer and vice versa (bad stays bad on good layer).

[mike m oz]

Your wireframe doors will almost certainly be because their 'container class' has no fill, or the door is not set to have its fill by Class. With one of the problem doors selected check what Class it is on the OIP. Video Tech Tip No. 9 shows the impact a global change like incorrect Class or texture application has on a door or window object.

If that doesn't fix the doors then look at the Class attributes of its parts - Settings / View tab.

[mr. iagea]

I'd love to tell you that the info provided here is the solution for my file, but it's not working that way, and I have never had to set those parts classes beforehand up to this point. As Alisha (in the Video Tech Tip #9, see link below) points out at roughly 0:42 of the video, when the door is originally placed, the entire door renders with the attributes of the class it is originally assigned to. This is consistent with the way my doors have been being placed up until yesterday morning. They all have a "Door" class assigned to them, which has a simple white fill, exactly as the tech tip suggested. There are no other discrepancies. Let me say this a third time: THE DOORS ON BOTH LAYERS ARE EXACTLY THE SAME IN EVERY WAY.

Look at the file "Door-3.png". That's a brand new file, with just a door added to a wall. I created a "Door" class that has a simple white fill, nothing else and assigned the class to that door. It renders as expected, and as all the other doors in my previously dubbed "good" layer. In the "Parts" tab, were I to set the leaf to "Custom" and select a leaf style, that would duplicate EXACTLY the condition of the door in my earlier file "Door-1.png".

Now, have a look at file "Door-4.png". That's my original working file, after taking the suggestion to individually assign a class to each door part. I created a class with a delightful chartreuse color (a developing trend in doors...you just wait! ;-)) and assigned that to every part using the "View" tab of the Door Prefs. Note here that the leaf is still transparent (even though it is set to "Solid" in the "Parts" tab of the Door Prefs), has the "Door" class assigned to it, with the "Door" class having a white fill. This contradicts what was specifically indicated in the Video Tech Tip, as well as about 20 other doors that were created in this file.

I get the concept of setting classes to the discrete parts. No trouble. The point here is that, in typical VW fashion, the behavior is INCONSISTENT. Why would it work fine (as in Door-1" and "Door-3") and then stop working as it was, and start producing doors that render as in "Door-2", and literally by doing nothing more than adding another door?

Makes no sense.

To compound matters, I now discover this evening that I can add a new door, and it renders fine (as expected), but I cannot change the "bad" doors.

Now, if someone can tell me how this is consistent software behavior, I'm all ears.

Video Tech tip #9: http://download2.nemetschek.net/TechTips/Window_and_Door_Render_Settings/Window_and_Door_Render_Settings.html

Edited March 8, 2009 by mr. iagea

[mike m oz]

Charlie, can you post a file containing the wall(s) with the bad doors in it. That might make it a bit easier to work out what the problem is.

[mike m oz]

Charlie, I've experimented and I think your problem is most likely to be because the container Class has its fill set to None. In the attached file:

- The left hand door has its container Class set to None (which has no fill as its default graphic attributes) and the door shows as wireframe (ie no fill) in a rendered view.

- The right hand door has its container Class set to Doors (which has a fill as its default graphic attributes) and the door shows as solid (ie with fill) in a rendered view.

[mr. iagea]

No, as I've said three times already, the doors all have the same container class ("Doors"), and the class has a fill of white. Wow. Seriously, this IS happening. I really have better things to do with my time than make stuff up to post on user forums. I very much appreciate the attempts to help, but really, I don't know how to be any more clear than I already have. This is totally strange behavior, and the software hasn't done this before, and I haven't done anything different. I literally added a door (that came in fine) and then added another, which drew "bad" and I was unable to alter it. The next 10 doors all rendered the same (as the bad one).

The file is 5 MB, so I can't really upload that.

Anyway,

I played around some more (because I apparently have all this extra time to screw around with this unstable software instead of finishing the drawing for my client), and discovered that if I selected ALL the doors in the whole place (the OIP indicated 20 door objects, all with the Doors class), gave them ALL the "None" class, then gave them all the Doors class again, they rendered correctly, except for one, which I had to repeat that procedure to get that one to fill right.

Now the stairs aren't rendering properly.

Whatever grounds VW made lately in regard to being stable, it just lost.

[D Wood]

Charlie

What is the history of the file - was it drawn from scratch (new file, no old data), or is it a previous job that you have modified? Does it bridge any kind of upgrade?

[mr. iagea]

David, this is closer to what I am suspecting the trouble may be. The file is a new file, originated in VW2008, was converted (successfully) and then continued. It is also the first complete project that I've had a chance to do entirely in VW since my learning the program. I am by no means totally fluent, and any review of my past postings will easily illustrate my frustration with several aspects of this app. I'm sure there is plenty of stuff in this file that may be contributing to the trouble, simply because I perhaps have not deleted...um..."learning objects" ;-). Anyway, there have been various changes, but nothing that I considered outside of the realm of what the software is able to do easily.

I discovered that a new test file, built with a simple Doors class and Stairs class (.05 pen, white fill) exactly as my problem file, was able to render new doors as expected (with the proper container class attributes), as were the stairs.

So, the trouble is clearly with the file itself, and that's the baffling bit. I've since run the "Purge Unused Objects" command, and deleted some symbol resources, as well as looked at the door schedule, and other resources to pare the file down to what is actually needed. That seems to have fixed the trouble?I can now place new doors and they render as expected with the attributes of the Doors class (again, .05 pen, white fill, no extra parts classes assigned).

At this point, I think I'm okay, after a very frustrating and confusing door storm arrival on my little boat, but I think we're sailing in clear weather again now.

Thanks again everyone for their input, especially Mike for the offer to take a look at the file. Much appreciated!

[D Wood]

Charlie

That's good news that you are back on productive time!

I am still on v12, but it has a special tool to convert (upgrade) symbols from earlier versions (part of my work is based on re-working standard designs, some of which go way back), so it occurred to me that maybe something similar is going on with your file, where 2008 objects aren't converting truly or completely to 2009 parameters.

As you've found, selecting them all, changing something minor then changing back again can sometimes get them all back up to speed. If it is one symbol, deleting and remaking the symbol in the new program can work too.

I guess it's an argument for never bridging an upgrade within a file.