投票:修订云图纸空间/模型空间
我很抱歉在讨论这个话题时迟到了。我做了一个快速搜索并阅读了一些关于修改云和使用的层等的信息，但没有找到讨论过的这个特定标准。该标准尚未在我目前工作的公司中建立。有些人一直在纸质空间中对修订进行云计算。其他人则在模型空间中进行所有云计算，除非更改是纸质空间中的某些内容。
我更喜欢在模型空间中进行所有云计算，特别是因为我们所做的95%的工作都在模型空间中。我喜欢在更改发生的地方进行云计算（意思是在它发生的空间中）。所以如果更改是纸质的东西我们很少有使用多个视图端口（具有不同比例）甚至相互引用的情况。但如果是这样，我可能会在模型空间中云化并为每个云规模具有不同的层。这样我就可以冻结特定视图端口的错误比例的层。
你更喜欢什么？
**** Hidden Message ***** 我们95%的工作都在Modelspace中进行。 所有这些谈话，我没有把基础问题拿出来...
为什么你更喜欢这种方法？
你为什么不选择另一个？ 嗯嗯嗯....3向领带。 我在PS中在revcloud层上完成所有rev-cloud。 在某些工作表上有多达15-20个vport，层管理已经是一场噩梦，我不需要增加负担。
顺便说一句，Autodork什么时候会让他们的行为在一起，让你在分裂（2 +）vport中调暗一个对象？ 一个30'的C10X20有七个1 5/16孔需要多个vport.（或者它自己的床单，为了皮特斯的缘故！变暗。 皮塔！！
这正是我们在模型空间中进行所有尺寸标注的原因。如果我们所有的工作都在3d中完成，我想这将会迫使PS中的暗部问题出现。...然后，我们必须将我们的视口缩放到“不需要的”设置。
也许对于这里所有的“破解”编码人员来说，这是一个很好的Swamp项目？创建跨越多个视口的关联PS尺寸的方法。
对于提到的层管理问题，我会投票支持PS中的revcloud。
云是注释，所有注释都在PS中。 不需要的设置???,什么？？
几年前就退出了。 我通常将云线批注放在模型上……然而，我有一个例行程序，它会创建一个图层，以便云线继续……因此，第一个修订将是
“s-rev1-cloud”，带有修订号的增量或修订块位于一个保持不变的图层上……如果有多种类型的修订号，如果需要将它们分开，我会将它们放在单独的纸张空间中……通常在涉及到使用新的数字进行了七次修订，增量几乎被省略……相反，如果添加了新的云，将省略云
不要在我的办公室！
页:
[1]
2