line-weight

The stripy lines issue is known about and covered in this thread:

This is actually what I do as well. But it doesn't work for renderworks-quality animations, and doesn't create something you can then edit and refine.

Exactly - describing the path is not really the problem - it's what VW then does with it.

What do you tend to use for animations instead (if anything)?

I'm not having much luck getting animations to render using VW Cloud Services. A few come back OK but there is a pretty high failure rate, a mixture of: - render comes back simply wrong (just a static image of the model, or an image of a sheet layer, or something unrecognisable) - render fails with message "Vectorworks crashed" - render fails with message "Vectorworks deleted" (?!) Mostly if I attempt the same render locally, it comes out ok, if rather slowly. So are there any obvious things I can do to improve the success rate? For example, I'm sending from VW2021, but do the servers render it using VW2022 or something like that? Would it make any difference if the VWX file itself were located in my cloud services folder rather than on my local disk? Does anything I do in VW after sending the render off have any impact? For example if I edit the file or close it or quit VW before the render comes back? Anything else?

Well, some hours fiddling around yesterday and today has given me some idea about what things are not working properly with animation paths - it's not limited to orbit paths. For example, much of the lurching motion seems to be related to intermediate keyframes because you can get a pretty smooth motion (including eg camera rotation) if you make a path which only has a start and a finish keyframe. But this limits you to paths where you don't want the camera to rotate any more than 180 degrees during its course. Also, it does not correctly calculate transitions in camera "pitch" between one keyframe and the next. As soon as you have a camera pitch that is not zero (ie it's not looking exactly horizontally) there are problems. If I set a start and end keyframe, both with a pitch of -10degrees then you might expect that the camera would carry out its entire journey between those keyframes with a pitch of -10 degrees. It doesn't though; for some reason it drops down well below -10 degrees and then comes back up again. I'm sure there is some reason this is happening, something to do with the maths of the "look" direction, and I'm sure if anyone cared enough it could be fixed. I would be happy to do more investigation if there were the slightest indication that anyone at VW was interested in fixing this tool, but the indications aren't great and I suspect that it's just another thing abandoned in a semi-functional state. It's really not fit for purpose as part of a "professional" package. The things I can produce with it that I wouldn't be ashamed to show to a client are very limited. I'll stick with what I do now - screen recordings of me doing a live fly-around of an OpenGL version of the model. This is not great, but less bad than the alternative. I don't think it's possible to produce a professional looking building walkthrough with the animation tool - someone prove me wrong.

Let's hope SP3 (due to appear soon now?) solves these problems. Although I would remain rather nervous that it could all break again with the next update to either TM or VW.

Also: it doesn't actually seem to create a true circular path for the camera, so the resulting orbit motion lurches around. This example used the cylinder as the target object. I did not do anything to the path created by the command. If the camera was pointing at the centre of the cylinder and the path was a perfect circle, there wouldn't be any evident motion in the cylinder at all. But look what the animation produces. I've attached the VWX file as well, in case someone can point out that I have done something wrong. orb_test.mov orbit_test.vwx

Just tried this in VW2021. The UI is as horrible as this thread had prepared me for, however I was at least able to quite quickly produce "something" following the instructions on this thread, which I can see have been sort-of added to VW2021 help documentation but the details remain pretty scant. https://app-help.vectorworks.net/2021/eng/index.htm#t=VW2021_Guide%2FCameraViews%2FCreating_an_orbit_animation.htm Here's what I understand (I think) 1. The camera looks towards the (centre of the?) object you have selected when you do the "create orbit path" command 2. The circular orbit path is centred (in plan) on the object you have selected when you do the "create orbit path" command 3. The circular orbit path is created at a Z height determined by the active layer plane elevation, the working plane elevation, or the selected object's elevation, depending on which option you choose in the dialogue. Firstly a question: Do I have any control over the diameter of that circular path? In other words how close the camera is to the object I'm rotating around? I can manually scale the path to be a larger or smaller circle, but this then breaks the connection between the camera tilt and the object I'm looking at, so it is no longer looking in the direction of what it's rotating around - it's looking at a point directly above or below it. Secondly an observation I think the information in the documentation is wrong (and consequently very confusing) Specifically this: If I select active layer plane, 0X, 0Y, 0Z is not the centre of rotation. This only sets the Z value of the centre of rotation. The X and Y values of the centre of rotation are determined by the object I have selected. Similarly, the dialogue box is misleading: It shouldn't say "rotate about center of", it should say "elevation of orbit path determined by" or similar.

This is something where an instructional video would be quite helpful - specifically looking at keeping things like materials under control. I too have been unsure which hierarchy method to choose. I expect many of us will want a fairly similar workflow: - creation and editing of geometry strictly done only in VW - materials/textures for aesthetic purposes chosen in TM, but associated reliably with something in VW (eg, if I tell TM to render everything that has my VW "brick01" texture using its own brick texture of my choosing, then any objects whose texture I change in VW reliably see the same changes in TM) - freedom to continue to assign things like classes and textures in VW without having to worry about additional considerations to avoid messing things up in TM - a clear understanding of what we can/can't and should/shouldn't do within TM's object hierarchy (for example, is there a way to turn an entire VW layer or class on/off within TM? Or do we effectively have to make separate exports if we want different "versions" of a model) For me the priority is leaning as much as possible on already-learnt organisational strategies within VW rather than having to learn a whole load of new TM stuff, and feeling that everything is "under control" and that I understand which things I do in TM are persistent regardless of what changes I make to the VW model. The problem of TM materials "resetting" is exactly the kind of thing that makes the process feel sketchy and not "under control" and I think efforts should be made to make sure it doesn't happen. I'd like to use TM more because I can see that for certain things it can produce acceptable results much faster than Renderworks - but I am holding off using it for any real projects for now because I don't feel confident that I've got a solid grip on what's going on.

You can run twinmotion on mac but it looks like they regard windows users as higher priority - recent releases of TM have had features available to PC users but not mac users, who it seems have to wait in line before those things are made available. I'm a fairly long time mac user and I plan to stay that way rather than going through the pain of changing ... but if PC is what you are used to I'm not sure really how much you gain by switching to mac. The thing that mainly concerns me about being a mac user is the limited choice in applications outside of VW - and rendering applications are one of the areas where this is a bit of an issue, especially now that it looks like the way things are going, people are going to be moving to using "real-time" rendering applications like Twinmotion as standard, instead of doing it within VW in Renderworks. As far as I can understand, a lot of the "heavyweight" 3d world has moved from Mac to PC in the past 10 or so years and this affects the choice and types of software available on the platform. I'm not sure to what extent it's true to say that this is partly because Apple seemed to shift its emphasis away from the type of user who'd previously have had a Mac Pro (which used to be quite customisable and upgradable).

Same here. Working with EAPs is very frustrating. As others have said, it *is* possible to edit path objects but it is affected by the view direction in ways that I never quite understand (and is not documented as far as I know). And when they are converted to NURBS this often makes editing awkward. I think this can happen with the profile object as well as the path? You can run into all sorts of problems if you edit the path in such a way that you move its "start" point because it changes the origin. At times, when trying to do something a bit complicated, I have resorted to keeping a "spare" copy of the path geometry somewhere outside of the EAP object, so that I have the option of editing that and then using it to replace the old path object inside the EAP.

Thank you very much for the update. I will look forward to testing it, when SP3 is released. If it's really fixed, then this will make a big difference to my daily VW experience.

@Landartma The issue is VW not finding the face correctly (ie. the face I hover the cursor over, does not highlight in re as it should). It has nothing to do with what mode I am using the tool in. As you say, usually you can eventually manage to select the face by moving around with the flyover tool, and looking at it from various directions. That is not how it should be though, and that is not an efficient way to work. The P-P tool seems to operate correctly in orthogonal mode, but not in perspective mode. This is a big problem for me because that's how I work in 3d - viewing in perspective. The only "workaround" for me would be to start operating in orthogonal mode but this would be very disruptive to my workflow, and I have good reasons to want to view models in perspective. VW is supposed to let me push-pull object faces while in perspective mode. It doesn't work properly, the problem has been known about for at least 5 years, it's not been fixed, and we are given no information about when it might be. Welcome to Vectorworks! It might not be too late for you to check out other software packages before you get too invested in it!

Yes! this is exactly what I've been complaining about since the first post of this thread ... in 2017.

I don't! Those just happened to be the elements I could isolate from a larger file and use to produce some replicable weird behaviour. It sounds like you are experiencing some weird behaviour even if it doesn't match mine. That confirms to me that something wrong is happening, as far as face selection is concerned. I don't think I've tried either of these test files since I've had VW2022 installed. I'm on an M1 mac mini too so I will try doing that, and see if my experience matches.

I don't suppose there's been any progress on this in the meantime? My workaround had been to re-render a bunch of viewports in one pass, if i needed them all to match pixel-for-pixel. However VW seems to have a new behaviour where it will now sometimes freak out and crash if I ask it to render multiple viewports in one go.

Are you navigating in perspective (rather than orthogonal) view? If so and you can't replicate problems in the file posted at the start of the thread, can you replicate the one in this post:

Just to clarify for other readers of the thread... the problem @Landartma describes, is not the same as the main subject matter of this thread, which is a fundamental dysfunction of the push-pull tool, not something that can be resolved by the user following the correct method. And VW have failed to fix it for 5 years and counting now.

Same here.

Someone at VW needs to sort out the documentation for EAP, which is inadequate and confusing, and this is demonstrated by the number of threads like this asking how it actually works.

They basically (at least here in the UK) set up the pricing so that if you don't go for service select, and choose not to upgrade for 2 or 3 releases, then when you do want to upgrade, you end up paying the same as you would have done, had you maintained a VSS subscription and upgraded at each release. Therefore the only real advantages of not paying for VSS are: - cashflow if you don't fancy shelling out X amount each year, and would rather pay the whole lot further down the line when you're ready - you think you are unlikely to want to upgrade for maybe 4 or 5 years. But that's becoming increasingly difficult to do as you get trapped in an interdependent cycle of hardware/OS/software no longer being supported There are supposedly various other "benefits" of VSS but I've never really made use of most of them.

I don't feel too optimistic about that producing any results when it's seemingly too much to ask, even for the help documentation on NURBS to be accurate...

Do you mean graphics performance is affected? This is something I've been complaining about for some time - I have mostly given up using floating panes because they seem to end up suffering from various graphics problems (eg jittery motion and strange snap behaviour) and become very irritating to use. This predates VW2022, but maybe it has become worse in 22?

In what way?