PolyShape3D node

[insomniacUNDERSCORElemon]

A 3D node that gives 3D context to 2D nodes such as polygon2d and line2d. Similar in functionality to sprite3D. Allows both for cool aesthetic/art-stye (and less work for 2d) with basic functionality, on top of the much simpler asset creation you get from working with editable-in-engine nodes, also with a negligible (if done right) data footprint. And leveraging 3d support of vertex colors rather than rendering things to a texture.

Basic functionality is rendering these nodes as a billboard.

Advanced functionality, simplest-first:

• non-billboard 2D representation
• extruded mode
• revolved mode (for lines at least)... both for pipes/wires/neon signs etc and for vase/bannister-like
• label support too (billboard, extrude, bubble letters, bevel maybe?)
• automatic collision generation, at very least bounding box
• lighting/material modes: fullbright, darken-only, normal lighting for 3d
• custom materials in general
• allow for factors such as brightness of vertex color (via shader graph?) to also factor into something like bump/displacement or metalness
• cage transform (and simple bends/skews etc) for all extruded/revolved polygons/lines
• skeletons
• option (or alternate node) for 2nd input (or more?) to turn node into true 3D model
  • for instance using a polygon as the surface of something like a surfboard and a line to create the side profile.
• allowing multiple nodes in a tree to be processed at once, hopefully transferring it to the new mesh as vertex colors. Likely imitating 4.0 option clip children... as in only the parent node is used for outer shape, rest only add internal mesh+vertex color

Notes:

• possibly CSG usage, either internally (not seen by user) or directly (end result is usable in CSG)
  • similarly, some features might be possible via existing parametric add-ons, but I doubt they'll be as easy as using nodes directly
• something that I think would make this easier is if there were a container for polygonal art
  • for instance allowing to store grid settings and having a specific canvas size
  • a separate (floating) editor rather than being pulled into the 2D editor for something intended for 3D
  • live editing+feedback in 3D might negate the need for a floating editor
  • general editor stuff like mirroring (filter and continuous)
• name of node with shape is so it isn't tied to 1 type of node specifically though maybe in a technical sense shape isn't the right term

[Xrayez]

From what I could grasp, something like this could be made possible by rendering to a viewport and displaying that via mesh. But likely overkill. I'm not proficient in 3D to say for certain.

• name of node with shape is so it isn't tied to 1 type of node specifically though maybe in a technical sense shape isn't the right term

If we take PolyNode2D in Goost, that could be PolyNode3D. Although that would mostly reflect CSG shapes in Godot.

Basic functionality is rendering these nodes as a billboard.

Maybe it should just be named as Billboard node.

[insomniacUNDERSCORElemon]

Maybe it should just be named as Billboard node.

That would be ignoring so many capabilities though. Such as Parappa or Paper M[REDACTED] style. Or as I've said, very quick(+easily editable) 3D assets such as pipes/wires/signs/wall decorations/floating text etc. that are useful in any style of game. Especially if it's something in a background or in an effect (like an in-game TV) you'd never guess that it was made from processed 2D elements (you might instead assume it were manually made+exported etc).

Billboard is useful, but I don't think it should be its own node if more advanced functionality can be had.

something like this could be made possible by rendering to a viewport and displaying that via mesh. But likely overkill. I'm not proficient in 3D to say for certain.

Is it overkill? For one that seems relatively simple (to do once) but viewports have a resolution and I believe you'd still have the problem of 2D AA given you're using the 2D rendering engine. That and I assume using many viewports for a game isn't a great practice, like it'd impact performance (or at least inch closer to some sort of bottleneck).

My ideal idea here is to convert a 2D mesh into a 3D mesh (including things with actual depth that wouldn't work with a viewport) which is much more of a complicated idea, but would allow for much more as stated. I guess that'd be more worthy of calling overkill, but I feel like that's kinda the point to take advantage of parts of the 3D workflow (3D shaders+shader graph, materials, AA, etc) that aren't quite up-to-par (if available at all) in 2D... particularly if it'll be the base of game (like when it's an aesthetic choice).

If we take PolyNode2D in Goost, that could be PolyNode3D.

At that point you could just call it poly3d (because you don't need to say that it's a node). My thinking with shape would be to communicate that it uses 2D shapes. Though maybe something like 2dShape3d or 2dProcess3d might make it even more clear.