Jump to content

DDDesign

Member
  • Posts

    215
  • Joined

  • Last visited

Everything posted by DDDesign

  1. No, that's not how my suggested mode would work. In the example above, since you're not attempting to drag a selected object, but clicking, the top object would select as you expect. As I've said before, I'm not changing how selection occurs. merely the fact that attempting to drag a non-front object will not automatically revert to dragging a front object. To refine the idea further, I'm suggesting that to drag a non-front 2D object, you will need to drag it by an edge or point (as would happen with 3D objects anyway). NB- the presnet situation is you are given cursor cues of edges and points of a hidden object, so you would use the cursor cues to locate where to drag the object - straightforward. This also means if you select/drag on a front filled 2D surface, it will select and drag as you expect, even if a non-front selected object is behind it - unless you are over an edge of that object, in which case you will know this because of the cursor cues (and the handles) and then the non-front object will drag. So you will only drag the wrong object if you ignore the cursor cues.
  2. I can's see why you'd be surprised. After all, if an object is selected, it's selected because you specifically selected it, right? (If it's there because of copying etc it will be in front instead). So if you you understand you are using the "selected object moves" mode and you know the object is selected, especially because its handles are now clearly visible, then surely you won't be surprised if it moves! Even if it's behind something else - in fact that is the whole point! OK, maybe the selection was accidental, or you've forgotton what what you did because you went to get a coffee or something, or because of the scale of the object handles are indicating its selection are off screen, then perhaps the edges of selected objects that are behind filled objects could be made to somehow ghost through to give an additional clue. But I really think the way the handles currently appear through the front object are should usually be enough. Overall I don't share your concern because I am so used to working with 3D where you can't select a surface anyway, that I automatically dont' try to select a 2D surface, only edges and points. And as I've said I don't find moving a 2D object by it's surface useful - it's generally too vague, so I find the behaviour of surface selection annoying if anything. If I'm missing something here about 2D use, then maybe we just agree that the method is more suitable for 3D. If it's an optional mode then you don't have to use it anyway. Or maybe the mode is constrained to 3D objects. It would still be great to have especially as I maintain the whole selection issue is more of a problem in 3D work. By the way, Rhino gives you a drop-down menu as you click on an edge, and highlights each object that that edge could belong to as you scroll through it. I'm not asking for that much.
  3. Yes it would be nice, and as I've said I would welcome it, but at the risk of repeating myself, it would not be my preferred option. I think that the discussion has unearthed some fundamental differences of where we're coming from on this, and that's fine - it's reflective of the variety of the VW user base. You said that you've never done a project in 3D. All of my projects are in 3D and start as 3D, practically the only 2D is annotation. In 2D, at least with filled objects you can tell what object is in front, it will therefore be obvious when you need to use your selection suppresion mode. In my work if I drag an edge it might typically move one of half a dozen objects- and there is often no way to tell which one until I've already dragged it - Murphy's law dictates it's always the wrong one. You envision a tool that "you wouldn't need a lot". I'd prefer something that I would use all the time, even as a default. You have emphasised the advantage of VW's select and drag and combination yet the option you propose suspends this multifunctional arrangement, so it is really not going to be used in this mode by default. I believe the "drag selected object" alternative I've proposed would be used in this way because it fits logically with the rest of VW - operations affect the selected object. You see a selected object, you drag it, the selected object moves. If you go to rotate a selected object for example, it isn't the front object that moves instead! I don't think this proposal it's incompatible with the current select/drag operation as you fear. Select/drag where there is no prior selection or common edge would work exactly the same as it does now. Where there is a common edge and a prior selection it would only take another click to change the selection or a deselect to select/drag the front object But your vector move function would have enough support to warrant it anyway, so as I've said before there is an argument for having both new modes. And either would be better than nothing. However, the point is does the admin even recognize that the selection function could be improved? I know we never get told about what's in the next version, but are we just wasting time (and boring the rest of the forum) talking about it?
  4. 2D - well I guess that shows how much my focus is on working with 3D. But maybe the idea is still valid for 3D use. Stacking order. It's a common concept in other applications I have used. I haven't used Sketchup so I don't know about it. But in wireframe it can be impossible to tell what is nearer, just as what is in front of the stack. What happens in Sketchup if you see 2 objects - one behind the other? If you select an edge that appears to coincide - based on the view you are in - then you select the nearest object right? But what happens if you want to select the object behind - then you have to change the default selection order somehow - it seems much the same thing. What happens with two objects that occupy the same space - which gets selected? Seems to me there's got to be a stacking order logic somewhere. Anyway I understand Sketchup is not as powerful as VW, so maybe it's not the best example. Remote Vector Move. Well I guess it would be OK, but I've never felt the need for it. Where I've had to used a vector move tool in other applications I found it more cumbersome than VW. There does seem to be a lot of call for it in the forum, especially from ACad users, so it would not doubt be popular and it is an elegant way of having one modifcation that solves two problems. Maybe we should ask for both - your modifier key, and my original "drag the selected object" mode. Maybe thow in the "keep selected object in front" mode for 3D as well. (this is like what Rhino does, by the way). I would think they're all compatible improvements. Then we'd both be happy!
  5. Yes, such a tool would be useful and surely would be easy to implement, but I've just been thinking of another solution, and it could be even simpler: Another mode would be added to the select tool that brings any selected object to the top of the stack. This means that instead of the most recently created object remaining in front, it will remain in front until another object is selected/modified. I think this makes sense with workflow, because often the object that you've modified is the one you will want to return to to re-modify. This will of course solve the whole issue of being able to drag a selected object that is behind, because it comes to the front once it is selected. Now, it may not work for some situations, especially in 2D where stacking order affects the look of filled 2D objects. However stacking order in 3D is irrelevant in terms of look of renders. In fact part of the problem in 3D is that even in wirefame, unless line attributes differ, it is impossible to tell just from looking at objects which is in front. So I can imagine I would use the select tool in the "bring seleced object to front" mode as a default, especially as I'm manually bringing selected objects to front much of the time anyway. I reckon it could work. What do you think?
  6. The penny has just dropped for me, because we aren't all talking about the same thing at the same time... To start, Jan15's chart for me is incorrect, it should be a yes/no, same as Jeff. It's not a hemisphere thing at all, and we're not all going down the drain the wrong way! I was always talking about 3D in this thread, but I may have started the confusion.The initial post said "solid object (in 2d)" and I misread the 2d. So I apologise if this was resposible for getting the thread off the track. I think the confusion stems from the terminology being used. When I see the "solid object" I always think of a 3D solid. VW has three types of 3D objects - solids, meshes and nurbs, with solids being the most common. To me 2D objects are either filled or unfilled - I'd rather not use the term solid in reference to a 2D object at all. A filled 2D object can be - and always has been - able to be dragged by its surface. In v11 and v12 no 3D object can be, whether rendered or wireframe. I have a vague memory that this may have changed from a previous version, but can't be sure. If there was a change it's vast improvement in selecting and manipulating 3D objects. Jan15's suggestion that shaded and unshaded polygon renders should be selectable has some logic, as the 3D objects now have a surface, but I can't see how useful this might be. I can't see why one would want to select a surface instead of an edge or vertex - It's much less accurate. And dragging a rendered object initiates a re-render. That seems to be a very slow way of working. Some further level of complexity to the issue is introduced when the fill options of a 3D object are considered, because a 3D solid may have a fill that is never apparent, even when rendering (when the texture is shown instead), and it can be specified to have no fill at all. Actually I think the option of having an unfilled 3D object is nearly more trouble than it's worth. I'd say It's one of the greatest causes of models not rendering properly - as evidenced by discussions in this forum - I'm sure even the most experienced users have been caught out from time to time... In any case fill options have no influence on selecting and dragging in the current version In Amy's post she referred to objects having a texture and a hatch. It doesn't make sense to say 2D objects have a texture, nor 3D having a hatch, which is why I asked for clarification. I had assumed we were talking about 3D up to that point, not 2D as Jan15 had assumed. Jan15 also assumed I was talking about 2D objects because we were discussing the 2D selection tool, however I nearly always use the 2D selection tool for moving and dragging my 3D objects, because I prefer to model only in standard orthographic views. Hence I was refering to 3D objects, not 2D. I missed Jan15's reference to rectangles, as I was already thinking about 2D, just as she might have missed my reference to solids (meaning 3D). Well, what a mess! I hope that's cleared it up, but even more that the merit of some of the suggestion for changing selection and dragging hasn't entirely been obscured.
  7. The data bar can in fact be used as you require. Drag the object, then drag back without releasing. Note the data bar now has established a new origin. Press tab to activate the data bar, then enter the relative move co-ordinates (still keeping the mouse button down), tabbing between fields, and enter when done. Release object and the move is complete. Moving can also be done via the OIP. I usually use the move command as it has a shortcut key, and if I want to repeat a move the coordinates are already there from the previous move.
  8. That hasn't been my experience. Is this a general problem? The inability to edit a fillet is a bit frustrating - but I can imagine why it's not possible. If you edit a solid subtraction or addition, you can predict what the result might be, but if you edit a fillet object - say add an extra edge - what is the result going to be? Will that edge be filleted or not?
  9. Are you really talking about a solid 3D object here?
  10. No, I think you're mistaken, I've just checked v11, and it's the same.
  11. The resize mode only works if the object is first selected. If you drag the object by the end in its unselected state the resize mode will not be invoked.
  12. I can't see why you would expect that at all. It doesn't work like that at the moment, and I don't think it should. At the moment you can't click anywhere on an overlying solid and select it - you can only select it by clicking on an edge or vertex. If there is more than one edge or vertex, then the front object is selected, regardless of what has been pre-selected or not. I'm not proposing to change that, and I'm not proposing to change anything to do with so selection hierarchy. It's not ideal, but unless you are trying to select a coincident exact duplicate there is usually a unique edge or vertex by which the object can be selected. (Although I do like the system of cmd-clicking that cycles throught the stack eg as used in InDesign). And if you are going to drag an object, I'd always drag it by an edge, or preferably a vertex anyway, not just anywhere, otherwise the move is too vague and the smart cues won't work. All I am saying is - simply - make dragging work the same as the select tool in scaling mode and in fact every other operation in VW I can think of. That is, make it work on the selected object.
  13. Jan15, I haven't suggested any change to this - refer to my post 6/27. With my suggestion grab'n go would work exactly the same. To summarize: 1. Click/drag on object = front object is selected and is dragged. (ie grab'n go as present) 2. Click on object = Object is selected (as present) once object is selected: 2a. Drag handle of selected object with select tool in resize mode (interactive scaling) = SELECTED object resizes (as present) 2b. Drag handle or edge of selected object with select tool in select/drag mode = SELECTED object is dragged (NOT front object as present) It's only mode 2b I'm suggesting the change which i believe will make the select tool more convenient, logical and consistent. Perhaps set the new system up as a preference for anyone who doesn't want/need the change.
  14. Ah, yes. I hoped there might be a key. Couldn't find a reference to it in the manual. Thanks.
  15. Jan15, your method would work fine, appears easy to implement and it would be a lot better than the current difficulty and work-arounds. However, a selection suppression mode is really just compensation for what is a logical flaw in the existing tool. If you've selected something, and then you try to drag it, why should the tool revert to dragging the frontmost object? It defies what seems to me a clear intent to do otherwise. Your selection suppression mode would still work, but in practice I think that you would invoke it only when you specifically need it - when the required object is not the front object. The problem is often you don't know this until you discover you've already (annoyingly) dragged the wrong object. I still think the best solution is to have the object that is dragged being the object that has previously been selected, not the front object. This rule works perfectly well for the resize mode of the select tool, it must surely be a better method than the current one. And it would make the tool more consistent anyway. But I guess there's nothing to say you couldn't have a selection suppression mode as you've suggested as well, just as having a toggle key for the resize mode would also be useful.
  16. One thing I miss in VW is the ability to do a loft with 2 rails with multiple curves (cross-sections) can C4D do this? Also decent surface blending tools and fillets? Rendering in VW has improved a lot for me since the introduction of area lights (I have't played around with radiosity proper as yet). I've used 3DMax for for some renders, but it's usually hard to go past the convenience of a fully integrated rendering engine.
  17. On thing I miss in VW is the ability to do a loft with 2 rails with multiple curves (cross-sections) can C4D do this? Also decent surface blending tools and fillets?
  18. DBLand, the object get that gets moved is the one "in front" - ie not physically the top object but the front with reference to what is drawn on the layer. The last drawn object is always at the front. An alternative method is to modify>send>send object to front to make it the front object, then it is the one that will move when you drag it. Katie, grabbing by the line is often not very convenient if you want to align or snap to a point. Id have to move an object away from it's overlapping position, let it go, then grab it again by a point and then move it back. Very fiddly! I've commented before that this is a bit inconsistent with the resize function which works (thankfully) on the selected object, not the front object. It would be a boon if the select tool could be improved. I'd suggest a change to the selection tool so that if you drag a non selected object, the front object moves; and if you select first, then drag, the selected object moves. I think this would go part-way toward solving the issue. In the meantime I'll probably have to go for the Vectormove option.
  19. Yes, this is what I've noticed - the wrong part of the arc gets deleted. Also, sometimes the fillet doesn't quite meet the arc at a tangent. Glad to hear that a fix is on the way - hopefully it is in an update, not just in the next vesrion.
  20. Robert, I'd disagree that there's a training issue. My experience is that the fillet tool is indeed unpredictable and sometimes incorrect when it comes to filleting objects with curves. I can understand Mark's frustration. Also there are no cursor cues when using the tool and this can create further issues. Perusal of the forum seems to indicate the problem has been around for a while now.
  21. Gerard, do you use 4D for modelling at all? If so, how does it compare with VW, especially for fluid shapes?
  22. In the case of this example I would probably use the rectangle tool instead, and then modify>convert>convert to polygons. And for more more complex shapes, where possible I prefer to generate them using the clip and add surface commands - the result is always a polygon - and the polygon is always closed. With the driveway example you may have ended up with more than one poly because there may have been some lines with some non co-incident end points when you tried to compose them.
  23. For me I got v12 because of the Mac issue, and because of it's faster rendering performance - the intel/VW12 combo was a big improvement. The more surprising thing is what I've found now I like best is the zoom wheel function - it's really improved my workflow (20% faster maybe) and accuracy.
  24. Viewport crops don't work on annotations as you've discovered, but what about using the clip command or trim to line tool to trim away the annotations you don't need in the new vp. Or the old trick of pasting a white object with stroke set to white or none? Another thing that might help with your manual sectioning is you can convert the whole viewport to lines (convert command).
  25. Well, no. This isn't the case where a sheet has more than one page. Obviously it is then the page that is the same size as the printed page, not the sheet size. Scaling the sheet size has nothing to do with scaling the size of the page. And rescaling VP's has nothing to do with the issue as far as I'm concerned. As an example, I have a logo, as a symbol, and I use it in a VP, say at 1:10. If I want to use it in a title block, then I have to create a new symbol scaled to a tenth of its size. Maybe the way I use sheets is different to most users, and maybe it doesn't bother anyone else, but my gripe remains - why has the scaling of sheets been changed to make it less flexible?
×
×
  • Create New...