D1 22 problems

[rm]

[attachment=0]ARCHICAD D1 22.png[/attachment] I keep finding inconsistencies between 2d settings and 2d plan views in door & windows. This is particularly bad with D1 22.

1. You cannot get the door rough opening to display in plan. Instead the rough opening dimension somehow is being applied wrongly to the door leaf opening!

2. The trim casing on the outside of doors will not be placed in 2d view correctly, yet shows up correctly in 3D views. The trim casing is being offset from the frame some random dimension, while it is showing up correctly on the inside face of the door.

3. Now that TwinMotion is being added into the mix for AC 23, every door and window needs to have a separate selection for materials for vertical and horizontal running materials Why,? so when you rendering the model the grain of the wood or texture of the metal shows up correctly on the trim or frame. No body installs horizontal trim with the grain running vertical and nobody install vertical trim with the grain running horizontal, speaking of wood trim here.

There are certain library objects that must be fully vetted and working accurately including all doors and windows. Why doesn't GS get this?!?!?!?

[Lingwisyer]

2. For the AUS doors, the trim offset does not seem to take into account the tolerances set so it needs to be set to "x - offset".

3. The issue there is the material mapping direction. If the textures are mapping all in the same direction, the parts were either scripted without using COOR commands or without rotating components drawn in a single orientation.

Note: This is not an issue in the AUS and INT libraries.



Ling.

[rm]

Ling, I tried an "x - offset", however, no matter the "-" figure I typed in, it would default back to zero. I assumed that meant you cannot use an amount less than zero. Either way, GS needs to fix this in this door and any other door or window with the same issue. As I sad many times on the is forum, every building has doors and windows. If there are library parts that should be scripted PERFECTLY, consistently and tested for every object in the collection, it should be doors and windows!!!

Ass to scripting using COOR commands, I trust what you are saying, but if that is what is need to get materials running in the correct direction, GS needs to consider that too. If that works correctly in the AUS and INT libraries, us in the US would appreciate that coded into our objects as well.

I just realized because I could only upload a .png file instead of jpg, resolution of the uploaded image suffered. Is there a way to upload a jpg, pdf or tif instead of .png

[Lingwisyer]

Use an image editor to change the format?

There are quite a lot of objects that are scripted inconsistently. I have not encountered any issues with the primary objects in the AUS library yet through. QC seems a bit mediocre...

An input limit that makes sense if the object was working correctly but makes it so that you cannot use a hack solution when it does not...



Ling.