Observations/suggestions for the orthographic environment

[thewhitemetroid]

Being a pressure vessel designer and having design experience in other disciplines as well, I have a strong appreciation for the inclusion of an orthographic workspace. However after using it I found its implementation left a lot to be desired. Before I layout some observations and suggestions I would like to provide a primer: 

It's possible that you guys have some kind of tolerance value built into the game that would allow for minor misalignments in vehicle design verses the physics calculations so whatever variance I see in the design of my vehicles may be accounted for by your code. Or maybe you don't have a tolerance, either way there is a problem presented for each. If tolerance is built in the code the user has no way to know what that tolerance is so they can not know how far to bend the rules before it breaks. If on the other hand no tolerance is allowed, then it becomes important to be given some simple proper tools to be precise in the vehicle design. When all the node snaps work perfectly this is not an issue, but all the node snaps don't work perfectly and I suspect that there will always be some issues like for example, when using trusses. The node snaps are very fiddly when trying to build with these parts. I believe that using the ortho environment in an expanded way can alleviate, and even eliminate these issues. I know, I know, KSP 1 has been out for a thousand years and we have deployed our rockets just fine but you put this environment in there so you've forced my hand . Besides all this, I'm a technical designer, I live and die in the world of precision and if I don't know a part is perfectly aligned it drives me nuts! On to the discussion:

1). When in the orthographic environment, part translation and rotation should be locked to the current plane of view.

This in my opinion HAS to be implemented or else this environment is wasted. I know you have designers and engineers who know just fine what I am saying, but I just want to be clear that we understand each other so I'm going to qualify what I mean by "plane of view". Let's assume that in the coordinate system Z is up, pointing to the sky, and the XY plane is parallel to the VAB floor. If I were to be looking at the "top" view, then the XY plane becomes my current "plane of view".  If then in the top view, part translations and rotations need to be locked in the current plane of view, the XY plane, until the user switches to another ortho view (at which point the parts can be moved within this new plane of view) or when the user returns to the normal perspective environment translation and rotation returns to unlocked.  Currently this is not the case. This will only causes frustration for the user because they have no control over the translation and rotation of the part in the plane perpendicular to their view.

2). Provide object running snaps.

This is another suggestion I believe has to be implemented for this environment to be useful. Again, your designers and engineers probably know what I mean when I say object running snap and I'm not going to try to explain it in a technical sense, but I think explaining it only in how I think it should be implemented will  suffice. the problem that I encounter is that I have no way to reliably line up parts in a way that is repeatable and easy. If you look at the image below I have two fuel tanks connected by a truss(unseen). You'll notice they are not aligned perfectly and unfortunately will stay that way because when placing a part in space the coordinate value is continuously variable. So when I try to use the move gizmo to fine tune (even when pressing SHIFT), the increments are not lined up so the part will always be a little too low or too high. A solution to this could be a snap grid but I'm not fond of that solution. Instead, it would be incredible if each part had an invisible plane associated with the extents of the part such as the top, bottom, sides if flat, as well as planes about the centerlines and object midpoints. Let's say the part on the right has a plane associated with the top extent of the part that is perpendicular to the view. this plane remains invisible until it becomes coplaner with top plane of the part on the left, at which point an indicator appears such as a dotted line showing the alignment. This is an object running snap in it's simplest form. This solution won't cover every possible outcome (I don't expect it to be as sophisticated as a proper CADD program of course) but it will cover the vast majority and provide players an extreme level of confidence and satisfaction when making complex designs. If this were to be implemented along with a snap grid I think it would cover more than enough possibilities. Both should be implemented with a toggle though.

Another view to illustrate the problems with alignments.

3).  Provide node grabbing in ortho environment. 

Although not critical like the two examples above, I believe this would be an extra step in the right direction to provide the user with a powerful tool in their design. ONLY while in the ortho view, it would be quite powerful and a sweet Qol feature to be able to selectively grab the nodes instead of just the root of the part. This environment evokes a sense of precision so changing the way the player interacts with the part in a meaningful way will go a long way in improving the experience while also streamlining the build time. Can't tell you how many times I've fiddled with moving a part around the screen juuuuuuust right to get the node I want to snap to. This coupled with #1 would be powerful.

4). Allow user to place move/rotate gizmo.

Another non critical but would be a powerful addition. Again, ONLY available in the ortho environment, allow the user to grab the move gizmo at its local zero and snap it (important part is snap, I don't think it wise to allow free coordinate movement of this gizmo) to other nodes or root of the part. If you look at the gizmo in the image above it is stuck on the side of the part. This is pretty useless in my opinion. I would like to be able to rotate this part  in the current view about the centerline of the tank by 45° so that the two paint strips on the side of the vessel are in a more ascetically pleasing position. There's now way I'm going to attempt that in the current configuration. The utility of this cannot be understated.

5). Remove environment lighting.

Obviously not critical, but would be a better design choice. Point one: this is an ortho view therefore the image is "flat". It does not follow that environment lighting should be seen in a flattened image because real light exist in 3D space (unless you're a flat earther !) point two: personal opinion here but when I get in this space I imagine I'm "going back to the drawing board", something isn't right I need to get out of the shop and sit down in front of the drawing to fine tune this thing in the office. Might be just me but that's what I imagine I'm doing so the environmental light (aka VAB lighting) throws me off.

I think this was a great idea and addition to the game but it needs some tools for it to be worthwhile. Otherwise all it's really good for is making sure my boosters line up with my decouplers and such. Lots of potential in this. Hope this was helpful and if you guys already had these ideas in mind but haven't implemented them yet then I say good job. Looking forward to KSP2's final form!

 

 

Edited March 12, 2023 by thewhitemetroid

[Sea_Kerman]

in KSP 1 the move tools had an absolute mode where things would snap to an assemblywide grid and thus you could line things up perfectly.

[thewhitemetroid]

It's been a while since I played KSP 1 so I don't remember exactly how it worked and I'm almost tempted to go spool it up to refresh my memory. So far as I can tell there is not sufficient tools in KSP 2 to reproduce that. I do see a tool in the translation mode to change the gizmos location to relative and absolute, but this is not very a useful tool at the moment as it seems it's limited to the node of origin. There is also semblance of a snapping grid in place but again it is not the most useful implementation. The grid does not seem to be absolute, but relative to the individual parts insertion origin into the model space.  This is a problem because the user could place a part in infinitely different 3D coordinates. A way to realign the parts to an absolute grid could help with this problem, but I would at this point be concerned about the implications of grabbing a mostly assembled vehicle of even moderate part count, and then tripping the flag to snap the part(s) to the grid and borking the entire assembly.  Given the broader scope of this game (assuming of course it will achieve this), a more elegant and efficient way of designing is needed to facilitate building large interstellar vehicles, colonies, etc...IMHO.

[Derb]

On 3/12/2023 at 10:39 AM, thewhitemetroid said:

The grid does not seem to be absolute, but relative to the individual parts insertion origin into the model space.  This is a problem because the user could place a part in infinitely different 3D coordinates. A way to realign the parts to an absolute grid could help with this problem ...

For me this is the priority 1 issue keeping me from enjoying the game anywhere near the level of KSP1. We're designing spacecraft here, so the precise alignment of parts is critical for aerodynamic and center of mass considerations. Absolute grid alignment wouldn't fix everything wrong with VAB building on its own, but I have absolutely no hesitations that it is a necessary feature.
 

On 3/12/2023 at 10:39 AM, thewhitemetroid said:

but I would at this point be concerned about the implications of grabbing a mostly assembled vehicle of even moderate part count, and then tripping the flag to snap the part(s) to the grid and borking the entire assembly.

I am not so concerned that such a feature would present a downside at all - ctrl-z to undo already works, vessels can be saved. As a quick and dirty starting point, snap the part origin coordinates and angles to a global grid (aligned to VAB building) would at least enable us to align things in a replicable way.

I completely agree with all your other suggestions to make the orthographic designer a vastly more powerful and useful tool. I would even go further to add (in 3D and orthographic):

-ability to display xyz coordinates and rotation of a part relative to the anchor part (local grid), the VAB building (global grid),  or any arbitrary part selected by the player.

-ability to modify these xyz coordinates and rotations by directly overwriting them using a text box entry

In line with your suggestions, in the orthographic mode these abilities could be limited to the unlocked axes for the current viewpoint.

The orthographic mode would also lend itself well to displaying and changing measurements between parts as is typical on technical drawings/blueprints. Combined with the suggestion regarding planes to define the extent of a part, and selectable nodes - in a measuring mode one could measure between selectable part edges, nodes, or origin points, and then define the distance numerically if desired.

The same numeric placement and measurement ability could apply to the move/rotate gizmo as in suggestion #4, allowing rotation and movement around any arbitrary point or at any arbitrary angle.

The usage of numeric measuring/placement should of course be optionally displayed at the discretion of the player, as with any particular building mode or tool. But the addition of such a feature would give a maximum of precise control over the craft building process.