3D viewport camera pivot is wrong

I am constantly running into an issue where when navigating the 3D viewport, the camera pivot is somewhere far beyond the landscape mesh, causing the panning and orbiting to be wildly off:

How do I fix this?

I’m not seeing anything weird in that video you’ve posted, so I’m guessing the navigation is working correctly, just differently than what you’re used to.
I will mention, the thing that took me the longest getting used to when working with World Machine (coming, as I was at the time, from Cinema 4D as the only 3D or semi-3D program I’d used), the pivot/origin point does not move with the terrain. It seems to be locked to a singular point in the center of the viewport. Because of this, once you start panning around the landscape, the camera navigation may react differently than one might expect when coming from another program.

The surface being panned moves way faster than the mouse cursor. This is not how it works in pretty much any other 3D software which has 3D viewport you can navigate.

This is not about expectations or preferences. This is just straight up a bug in where pivot point of the viewport camera is.

I’m fairly certain this is not a bug.

As @blattacker pointed out, it has to do with the pivot point of the camera. As a matter of fact, you can recreate this effect in Blender if you have the pivot point of the camera “far behind” the plane, as illustrated below:

1 Like

@Rawalanche Blender works with trackball orbiting and panning, based on the object’s origin. It has a complex system in place, decoupling the camera object from the viewport.

World machine works on arbitrary world coordinates, so camera pivot is fixed to a point in the center somewhere.

The pivot does not move with the terrain, as there is no real object there.

Definitely not a bug, expected behavior.

1 Like

The problem is that there is no way to re-center the pivot. Once you move the camera a few times, you are screwed. How can you possibly claim that not being able to center pivot to the sole object in the viewport you are viewing is an expected behavior. No user would expect that’s the behavior they desire.

You can!

image

That doesn’t seem to work. The pivot remains somewhere in the distance, as if I was panning around an object that is far beyond the terrain mesh:

You can clearly see the pivot used for orbiting does not match the pivot used for panning.

ah okay yes that is still annoying. I still think this is the intended behaviour, but agree it should be more logical/in line with other programs.

Just a quick thought: Are you working at a different extent size than the default 8km²? I’ve noticed the camera gets increasingly finicky and hard to work with if you start changing the extent size, especially if you go smaller than the 8km², or if you go larger but want to zoom into specific areas.

Yes, its 2x2km. I need this size to have the proper height/scale ratio for UE5, so the heightmap matches what I get in the engine.

As I said, it’s just a bug. Resetting the camera should place the pan pivot at the center of the mesh bounds. Or ideally, pan and orbit pivots should not be separated. Alternatively, the issue is in inaccurate mapping of mouse movement to the camera transform.

As @WFab and @HYLK have stated, this is seems to be the intended behavior of the camera, not a bug. Have you tried the orbit camera mode to see if it suits your workflow better? I personally find it more difficult to work with, but it’s a bit more similar to a 3D program’s camera object.

@Rawalanche The “pan” operation doesn’t seem to be using a pivot, it seems to be working in the way game engines do, like “walking” with wasd. Thought I should mention. In short, “Orbit” uses a random world coordinate (probably 0,0,0) as a pivot, and “panning” seems to be “flying” with respect to terrain, instead of moving camera. The whole thing seems to be working without a “camera” perspective tbh.

This is sounding more and more like a “Feature request”, though still not a “Bug”.

What you just said makes no sense whatsoever.

No, pretty much every game engine out there has the typical 3D DCC navigation living alongside the free look navigation without any issues, unlike WM. Having broken panning pivot is not a condition for free look camera implementation. This is Unreal, Blender and Godot (I do not have Unity installed, but I guarantee it works the same):

WM has na explicit switch between orbit camera mode and free look mode. Even if you were right, the viewport camera was using “no pivot” when in orbit mode, not the free look mode, then that would be a bug, since that should be restricted only to the free look mode.

No, orbit does not use random world coordinate as pivot. The orbit pivot moves with the view. It’s placed somewhere at the world, and moves as you move the camera. The position of the pivot on camera XY space is correct when orbiting (always the center) but it’s depth (camera Z axis) is wrong when panning:

There is a camera perspective. It’s not orthographic view, otherwise the perspective would be orthogonal, and the terrain square would always have parallel sides, which it does not:


I mean the UI even mentions the word “Camera” on so many places.

I am sorry but at this point it’s increasingly difficult to take you seriously, given how untrue pretty much everything you write is. It’s all the more puzzling given the “Alpha Tester” label next to your name…

If we continue this debate, please refrain from any insults/personal attacks, even the slightest hint/remark to it. Let’s keep it civil and friendly.

I think we can agree the camera behaviour is puzzling and not intuitive. I do think it would be better if it were to have similar behaviour to other 3D programs, for example, like Blender.

1 Like

All I said was that it’s increasingly hard to take him seriously. I’d take someone straight up lying to me as more of an offense then being told someone doesn’t take me seriously, to be honest.

Anyway, the main issue here is that pretty much every single UX failure gets labeled as feature request by this community, so that it can be swept under a rug, and that’s why this UX of this software barely ever improves.

Case in point: Restore UI workspace on startup - World Machine
This one has been requested half a year ago, and the state is still “under consideration”. It’s not a feature, as in adding new functionality. It’s literally serializing of one or couple of properties and reading them on the next startup/file load. WM doesn’t suffer lack of features, but at the same time it consistently suffers from lack of UX standards for over a decade now.

@Rawalanche Well, you’re free to ignore anything I say then. I won’t bother correcting some inaccurate assumptions from the whole tirade you posted directly in response to me. Good luck with your, well, whatever you’re calling your posts lol! Muting now.

@HYLK Don’t bother, this one has a habit of shutting down discourse based on incomplete knowledge. And there are usually personal insults involved for attention mongering.

1 Like

@Rawalanche I’m not sure what your goals here are. You’re bringing a frankly weird amount of aggression to a conversation about the UX of a program that, to my knowledge, is still designed and developed by one person. On a forum that is usually very pleasant. I keep writing these long-winded paragraphs in response, but I’m not even sure it’s worth it.

So I’ll leave with this: the UX works. You may not like it, it may not be up to your personal standards/preferences, but it works. So when there’s new functionality/features/devices that the developer is much more excited to work on, of course that’s going to get worked on first. Especially with software like this, design and interfaces are far less important than the actual functionality of the product. As was mentioned in a previous thread (that you brought a similar amount of aggression to), this can be clearly shown by a not insignificant amount of professionals who prefer command line interfaces over graphical.

I get why you say this, but I do not fully agree. Bad UX will hamper everyone, and prevents us from utilising the program to its full potential, as workflows get clumpy or, in this case, views do not work as expected. All those small bumps and kinks in the workflow get annoying and frustrating to work with, and will to some extent influence the quality of your work.

Additionally, for newcomers the UX is even more terrible. Since we’re so familiar with the program, we can quickly overlook the imperfections of the UX, because we’ve learned how to deal with it without even paying attention to it, we’ve accustomed to it, and we must realise we have a significant bias when it comes to evaluating the UX.

So I agree with Rawalanche, the UX needs improvement, and the camera view needs to be on the same level as the rest of the industry. This improves inter-program workflows as well.

1 Like

I agree that the UX could be improved, I just don’t personally think it should take precedence over, for example, setting up more devices to utilize multithreading. Or other performance-based improvements like GPU acceleration. I’ve taught friends with zero experience in this (or any related 3D fields) how to use World Machine in a matter of minutes, so while the interface may be slightly unintuitive, I’d still argue that it has a better UX than, say, ZBrush (a program I’ve been using for nearly 6 years now, and still have to google how to actually get to the modeling mode every single time). Actually, in my personal opinion, I’d say out of all the professional software I’ve used, World Machine actually has the easiest learning curve as far as the UI and UX goes.