Turning off Viewport.AutoNavigation

I’ve set Viewport.AutoNavigation := True which is fine.

I’ve bound Viewport.Camera.GoToInitial; to the R key (Reset scene)

I press an Arrow key to start the scene rotating.

Problem is that after pressing R while the scene resets as desired it immediately starts rotating again.

I can stop it by setting Viewport.NavigationType := ntNone; but now there’s no navigation at all.

I even tried binding Viewport.NavigationType := ntExamine; to the keyR release event - no joy there (having set ntNone in the press event)…

Search reveals a Stop in UIState - something to do with that?

Basically I want the same thing to happen as when you press the Space key with AutoNavigation turned on, stop it then do something when one of the AutoNav events occurs.

Also, can you add a Reset option like I’m trying to implement to view3dscene please?

I understand you use the “Examine” navigation (default, if your model/code doesn’t specify any navigation by other means mentioned on https://castle-engine.io/manual_load_3d.php#section_camera , and you just set AutoNavigation := true).

To stop the rotation, just call the TCastleExamineNavigation.StopRotating method (you can ignore the result).

Since you used AutoNavigation := true, the navigation instance is already created for you and placed in MyViewport.Navigation. So I would recommend doing it by

if MyViewport.Navigation is TCastleExamineNavigation then
  (MyViewport.Navigation as TCastleExamineNavigation).StopRotating;

Also, can you add a Reset option like I’m trying to implement to view3dscene please?

Can you clarify? What should this do? Note that camera classes already feature a method Init designed to set most important properties of the camera (both initial and current vectors).

Well, that did the trick. Exactly what I was looking for.

I added this to my OnPress event handler and everything worked wonderfully…

  if Event.IsKey(keyR) then
    begin
      Viewport.Camera.GoToInitial;
      if Viewport.Navigation is TCastleExamineNavigation then
        (Viewport.Navigation as TCastleExamineNavigation).StopRotating;
    end;

To explain why this is a useful feature…

I’ve associated a fair few model file types (obj, gltd, x3d etc) with view3dscene as it makes converting a model to x3dv simple for further modification (e.g. giving a texture a name)

Something I frequently want to do is examine a model in detail. If the model is simple this is not a big concern but if you’re dealing with a complex model it’s easy to get lost in 3D space. When this happens the only way to get back to the initial position displayed when the model was first loaded is by opening the model again.

This may sound pedantic but the process of opening a model involves multiple mouse clicks, possibly some directory navigation, maybe even some searching through a long list of files.

Binding the R Key to the above code snippet does everything in one go - its far more user-friendly. Six lines of code for a more user-friendly experience is a good deal…

To be completist It could also be a menu option - Reset Model…

Sure, resetting the camera position in 3D is useful.

view3dscene already has a menu devoted to this, in “Navigation -> Jump to Viewport” :slight_smile: If your model has “Viewpoint” nodes, you can move between them, and always press “Home” to get back to first viewpoint. Otherwise you can still go to some default / calculated viewpoints, like “Calculated viewpoint to see the scene (+Y up, …)”.

I should probably

  1. make the “Home” key work always (go to “calculated viewpoint to see the scene (+Y up, …)”, if model didn’t have any Viewpoint).
  2. make it stop rotating, as you found above. Maybe GoToInitial should automatically do it? It would make sense for user.

Ahh - that’s what that menu does. Not overly clear to someone who doesn’t do 3D modelling (I’m getting to be a pro at creating cubes…)

I’ll mention my next bit of experimentation now as you may already have some system I’m not aware of that does this already…

There’s another viewpoint I wanna play with. In, for example, Blender you can zoom out and see the camera and the scene. This would be rather useful for CGE stuff as well. A sort of ‘Director’s Viewpoint’. As things are at present the camera and scene move relative to each other - not sure what the default examine model uses but moving either one relative to the other has the same effect.

If the camera is the thing that moves then in the default examine view the camera presumably is positioned at some point on a sphere pointing at the origin (I’ll have to write some code to work out which is moving).

Anyway, this ‘Director View’ I have in mind would insert a camera object into it’s, static, view and you could see how the scene and camera move in relation to each other.

Where this gets interesting, and the whole point of the Director View concept, is if you then add a programmed path for the camera, something more complex than examine provides. The camera path would be at the simplest possible level, move from point A to point B optionally rotating to angle R. This of course could be extended to involve paths constructed from splines etc.

The final part of this is to abstract the whole lot allowing any object to move relative to any other object along some defined path for that part of an in-game event.

In my own case the more abstract version would include, for example, moving a card from one point to another rotating it as it moves - effectively playing the card in question.

The simpler version of all this is, of course, the Director View where the ‘objects’ under study are the camera and scene where the path is that used is that provided by the examine navigation.

Hope I explained this one better than I did the one that started this thread…

As things are at present the camera and scene move relative to each other - not sure what the default examine model uses but moving either one relative to the other has the same effect.

Indeed, moving a camera by vector V has visually the same effect as moving the 3D world by -V. This is a property of reality :slight_smile:

Fun fact: This property is actually used by OpenGL and other graphic APIs. You can think that GPU camera is actually constant (standing at 0,0,0, looking in -Z direction) and the only thing you can do is move the world. Of course a higher-level engine, like CGE, gives you convenient properties to move camera in 3D, and independently move the 3D stuff, but that’s just using this “hardcoded camera” under the hood.

In case of our navigation classes TCastleXxxNavigation, they only move the camera. That is, they change the Viewport.Camera.Xxx vectors (Position, Direction, Up). They do not touch the world (they do not touch Viewport.Items).

Anyway, this ‘Director View’ I have in mind would insert a camera object into it’s, static, view and you could see how the scene and camera move in relation to each other.

The idea to visualize camera through other camera is something I have planned for CGE editor. Indeed it is useful in 3D modeling software.

Doing this is fairly easy, you just create a TCastleScene, and you can use this scene to visualize a camera, by doing Viewport.Camera.GetView(Pos, Dir, Up) and Scene.SetView(Pos, Dir, Up).

Where this gets interesting, and the whole point of the Director View concept, is if you then add a programmed path for the camera, something more complex than examine provides.

It comes down to an animation system, built inside the engine visual editor :slight_smile: Since you would like animate transformations of 3D objects, like camera and scenes. It is something I would like to eventually have, but it’s a larger feature, so not for the immediate time.

Currently, if you need to design an animation visually – you have to do it in an external program like Blender and export to CGE (e.g. through glTF). Note that animating camera in Blender and exporting it to glTF works cool in CGE, I added a demo about it to https://github.com/castle-engine/demo-models , in subdirectory gltf/camera_animation/ . You can have an animation that you can play, through CGE Scene.PlayAnimation, and it will move the camera (assuming it is the current camera, which means that corresponding X3D Viewpoint is “bound”).

1 Like