Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3d Scene 'Dummy Camera' on play #60

Closed
DevinPentecost opened this issue Sep 12, 2019 · 6 comments
Closed

3d Scene 'Dummy Camera' on play #60

DevinPentecost opened this issue Sep 12, 2019 · 6 comments
Milestone

Comments

@DevinPentecost
Copy link

DevinPentecost commented Sep 12, 2019

Describe the project you are working on:

When working on 3D Scenes, it is painful to have to temporarily add a Camera node and position it accordingly just to be able to see how the scene looks. If you fail to do this, the scene is simply rendered as a black window and is a waste of time either way.

Describe how this feature / enhancement will help your project:

Development workflows and prototyping can go much faster if users can simply play a scene, and if there are 3d nodes found and no camera available, it will copy the position and orientation of the Editor camera to instance a new 'temporary' camera for viewing.

Additionally, this camera could be fitted with a simple 'fly-through' controller to allow users to quickly travel around their scene in-game without having to go through constant camera setup and teardown just to work on their scenes.

Describe implementation detail for your proposal (in code), if possible:

Some possible Psuedocode:

scene_launched():
  if scene_is_2d():
    return
  if scene_is_3d():
    
    if current_camera():
      return
    
    var editor_camera_transform = editor_camera.transform
    var new_flythrough_camera = FlyThroughCamera.instance()
    new_flythrough_camera.transform = editor_camera_flythrough
    scene_tree.root_node.add_child(new_flythrough_camera)

Of course, this psuedocode is very optimistic, and does not go through the FlyThrough camera controller, but those are straigtforward and can be implemented easily.

It can be non-trivial to determine what is a 2D scene vs. a 3D scene, especially with viewport trickery, but I think that if a scene ONLY has 3D nodes (and possibly GUI nodes) in the tree then it is obviously a 3D scene. Additionally, you can traverse the scene tree looking for any camera nodes set to Current, and if none are then make the camera.

I'm unsure of the specifics for passing through the current editor camera view, especially if there are multiple views (or none!) in the editor but then it could simple pick one at random (or the 'oldest' one), or simply add a default camera in the 'middle-ish' of the scene.

Is there a reason why this should be core and not an add-on in the asset library?:
I believe that all developers working on 3D games, including artists, will be utilizing this feature heavily. Additionally, this greatly reduces the barrier of entry for new developers to get started making games. By reducing frustrations and improving general workflows, the Godot engine will benefit with growth and interest, especially from users who are used to other game engines who are interested in switching over.

Thanks,
-Devin

@JFonS
Copy link

JFonS commented Sep 12, 2019

I like the idea of having a default free flying camera for debugging and quick prototyping but we have to be really careful on the way it's presented to the user. It has to be perfectly clear it is just a debugging camera or else people will be confused when their exported projects don't behave the same way as in the editor.

I was thinking about making it an option that can be enabled through the "Debug" menu on the top bar, but that would make it a lot less discoverable.

Another option would be to have it always enabled when no 3D camera is found but add an overlay to the running project stating that a debug camera is in use (and maybe a couple of settings can be added there too)

@DevinPentecost
Copy link
Author

Hi,

Discoverability + Ease of use is my number one concern with implementation on this. Especially with new, frustrated, or inexperienced users, having things not work and then having to seek through settings menus and documentation just to make things 'work like they should' is not a good experience. I use Godot almost daily and I still get frustrated and wish things 'just worked', whatever that means!

I like the overlay idea - it makes things obvious to the user that things aren't 'right' and also can act as a 'jumping off' point for directing them to the next step in their workflow. I think there are good ways to customize this, but I think Godot could really use a base implementation for this. In 2D I already have a default viewport, why not 3D? 😄

I haven't used Unity or Unreal in years, do they still do this? Perhaps we can learn from those tools.

Thanks,
-Devin

@Calinou
Copy link
Member

Calinou commented Sep 12, 2019

Is this solved by godotengine/godot#27742?

Also, as @JFonS said, I'd be wary about having features silently disabled in running scenes or exported projects. This happened frequently to users with the 3D "default light" in Godot 2.x.

@HeadClot
Copy link

Hey @DevinPentecost

I haven't used Unity or Unreal in years, do they still do this?

I use Unreal 4 and it does this by default and it is really helpful to new comers to the engine :)
Unity does not unless you import the correct package into a project. Which can be confusing IMO. That said I am happy to see this being tackled. :)

@aaronfranke
Copy link
Member

aaronfranke commented Sep 19, 2019

Is there an API for getting editor information in scripts, such as the editor camera's transform? This would be a great idea for a plugin.

@Calinou
Copy link
Member

Calinou commented Nov 23, 2019

I'll close this, as this is now provided by godotengine/godot#27742 which has been recently merged. Click the camera icon in the 2D or 3D viewport while the project is running:

image

It works even if no Camera node is present in the running scene. Further usability improvements could be considered, such as allowing the button to be activated before the project is run (the setting would then be enabled when running the project).

@Calinou Calinou closed this as completed Nov 23, 2019
@aaronfranke aaronfranke added this to the 3.2 milestone Aug 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants