Replies: 9 comments 17 replies
-
|
It looks like a good idea. Even some kind of "container" that could hold |
Beta Was this translation helpful? Give feedback.
-
|
Some sort of ViewportTexture that is more than a simple Texture, more like an Editor Viewport (to receive inputs, see and allow edit nodes) but that can also be applied to any 3D surface. |
Beta Was this translation helpful? Give feedback.
-
|
Why is it "Eldritch", though? |
Beta Was this translation helpful? Give feedback.
-
|
How is your proposed 3D container any different than a Viewport? My understanding is viewport editing pains are mostly gone in 4.x... |
Beta Was this translation helpful? Give feedback.
-
|
Oh, no, that capture is Godot 4, the pain is there, alive, with a new hat. This should work like an already configured and applied ViewportTexture, that also allow to see and edit the content (viewports have that capability but for an user to make it work in the editor it may need to be a really complex tool node/plugin) |
Beta Was this translation helpful? Give feedback.
-
Ah, gotcha |
Beta Was this translation helpful? Give feedback.
-
|
See also #3219. I think 3D label rendering is by far the most common need, and is requested more often than anything else. Therefore, I believe it makes sense to provide a simplified solution for this purpose. Anything else (such as drawing indicator waypoints) is usually done well enough with billboarded sprites.
I don't think in-game 3D UIs are very common nowadays, aside of some novelty/easter egg uses. |
Beta Was this translation helpful? Give feedback.
-
Also 3D paths like the shop trails in Killingfloor, and so |
Beta Was this translation helpful? Give feedback.
-
|
3D UI in AAA may be more common than it seems because it can be subtle
|
Beta Was this translation helpful? Give feedback.
-
|
@passivestar I think this is standard 2d just with a lens deformation applied after |
Beta Was this translation helpful? Give feedback.
-
|
@Zireael07 not in that particular game. that one is full of 3d ui 🙂 Screen.Recording.2023-12-04.at.19.27.59.mp4 |
Beta Was this translation helpful? Give feedback.
-
|
fwiw, lense distortion applied afterwards is almost never done for UIs; it's slower and lower quality than perspective transforming them (i.e. putting them in 3d space) |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
@HeavyRail0451 Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead. |
Beta Was this translation helpful? Give feedback.
-
|
Why we need this? This will be a great tool for easy creating 3d UI for those developers who not familiar with programming such myself. And this little 3d like container cut-off questions from everywhere how to create 3D UI. Unity has it, Flax has it(UI Canvas). By the way you can see from Flax how this works. 3D Ui demo doesn't help to implement it to current project. Godot leaks of Input explanation tutorial to understand it. |
Beta Was this translation helpful? Give feedback.
-
|
I want to be in favor of this, but I can't really see a way where this isn't like... a super confusing workflow? Generally, the nodes that combine functions of a bunch of other nodes tend to be the hardest to understand and follow. This would just be a MeshInstance, presumably a plane, with a pre-applied texture. You'd still be working on UI in the 2D editor either way. I think it's a similar issue to this. Aren't templates a better option than nodes that pack too many different unrelated features together? For the case with shape primitives, spawning a StaticBody with a matching mesh and collision shape would be better than CSG with built in collision, wouldn't it? At least in terms of helping new users understand what's going on there. And for this scenario, if it's going to be a mesh with a viewport and texture behind the scenes... why not just give the user that mesh/viewport combo? These are features intended to make things fast for people new to the engine, so why not also expose exactly what's going on to those users so they can learn Godot's node/resource system in the process? Let them take it apart if they want to, so they can understand each individual part. Rather than giving new users a pure black box that makes things more confusing down the line. The workflow itself might need improvement, but that can be done on the viewport end of things rather than by adding a completely new node, right? |
Beta Was this translation helpful? Give feedback.
-
|
I've opened a proposal specifically about 3D progress bars, which I feel is the largest missing piece of the puzzle for 3D UI as it stands: #8430 |
Beta Was this translation helpful? Give feedback.
-
|
I think that I have a perfect case of use in my working company. I make a lot AR objects and is very common that witch one them have is on floating interface. This is an example that we are trying to convert from Unity. In same scene we can have more then one of this objects, and that is the why we couldn't use the screen overlay interface.
|
Beta Was this translation helpful? Give feedback.
-
|
To this discussion be promoted to a proposal, is there any requirements? Or we can just create a new issue already as proposal? |
Beta Was this translation helpful? Give feedback.
-
|
There needs to be a concrete technical implementation before an issue can be opened; I'm not seeing any in this discussion so far. Given the number of input/focus-related issues we have with 2D UI already, I expect this to be very complex to implement correctly. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, this might be a bit complex to do well and with a decent UX (maybe some clever viewport wrapper or something more performant). If you have something in mind you can add it here to discuss too (but I think that talking in rocketchat may get better feedback) before creating a proposal. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Modern games use a lot of UI elements in 3D space, trying to achieve this in Godot is a pain, since ever.
Set up a viewport/subviewport with am untouchable scene inside, make all the chain of resources that will use the ViewportTexture as local in a particular tree order or load them via script to avoid being yelled by the Engine.
All just to put labels, buttons, fancy screens on a 3D/XR game
We need something like a 3D Container, something that can be added to the world and work as a Control, allowing to get Control children and visible AND editable in the 3D viewport like if it were a 2D view, that will speed up all the process of adding fancy labels, progress bars and panels to 3D elements.
I don't know if it could be a MeshInstance-like or a Eldritch Texture Resource that can be added to any surface, I think that just a MeshInstance with a rectangular Mesh, maybe with configurable divisions to manipulate vertices, may be enough for most cases.
And I know that there are ideas for a Label3D node but that is way behind of current needs in games.
Beta Was this translation helpful? Give feedback.
All reactions