When it comes to rapid prototyping, rather than creating a new scene in the 3d or 2d modelling tool of choice, and then importing that scene to Godot, it would be great if one could just add primitives like spheres, cylinders, circles, etc. to the scene directly from the Godot editor.
Also exporting the scene from Godot as COLLADA and maybe SVG for 2d scenes, would make easier to move from prototyping to fleshing out the scene with textures and more detailed geometry.
this makes a lot of sense..
On Tue, Feb 17, 2015 at 11:24 AM, rraallvv [email protected] wrote:
When it comes to rapid prototyping, rather than creating a new scene in
the 3d or 2d modelling tool of choice, and then importing that scene to
Godot, it would be great if one could just add primitives like spheres,
cylinders, circles, etc. to the scene directly from the Godot editor.Also exporting the scene from Godot as COLLADA and maybe SVG for 2d
scenes, would make easier to move from prototyping to fleshing out the
scene with textures and more detailed geometry.—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1381.
I've been thinking the same thing.
With the addition of navigation polygons there are now three different 2D polygon types.
It'd be cool if Polygon2D and the other Shape2D classes could be made multi-purpose for physics, drawing, navigation (where relevant).
If a shape is the child of a physics body then (by default) it is not drawn, but used for physics. (An option on physics bodies to draw shapes would be good for when you want both rendering and physics)
If a shape is the child of a CanvasItem then it is drawn, but not used for physics.
Closed https://github.com/godotengine/godot/issues/1508 because it was a duplicate but @bojidar-bg had some idea there:
_I think that it will be better if we have classes like "CubeMesh", "SphereMesh", etc. that extend the "Mesh" class. That way we won't have nodes for everything in the node selection menu, and it will be easy to change properties like size, subdivisions from the inspector_
Also set the milestone to 2.0 because https://github.com/godotengine/godot/issues/1508 had 1.2 milestone
I would like to have something like CSG, but don't know much about it
On Wed, Oct 28, 2015 at 6:02 PM, kubecz3k [email protected] wrote:
Closed #1508 https://github.com/godotengine/godot/issues/1508 because
it was a duplicate but
bojidar-bg had some idea there:
*I think that it will be better if we have classes like "CubeMesh",
"SphereMesh", etc. that extend the "Mesh" class. That way we won't have
nodes for everything in the node selection menu, and it will be easy to
change properties like size, subdivisions, *—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1381#issuecomment-151989144.
It's hard not to mention "Add Primitives" plugin made by @TheHX which generally solves the issue and is working quite well: https://github.com/TheHX/add_primitives
I'm using @TheHX 's plugin as a reference to implement this as a C++ module.
https://github.com/kjohnson0451/godot/tree/primitive
IMO this is better in the 3.0 milestone, since the renderer will be improved for 3.0 and probably the 3D tools too.
@godotengine/bugsquad WDYT?
@neikeq well I think you are right, in 2.1 we will get plugins, I'm quite sure there will be plugin for that quite soon (it already is actually), so I guess we will need to rely on it for some time.
I think the objects should also not be named test objects. Why exactly can people not use this to build actual levels directly not just for testing? Not everyone needs fancy highres 3d models for everything, so some are going to be fine with primitives for simpler graphics styles. Naming "TestCube" degrades it in a weird way, as if it wasn't going to work properly in a final game.
Also, this should definitely be available without plugins or the respective plugins should be installed per default. Pretty much all 3d editors of all engines provide cylinders, cubes, .. out of the box, so not having this is confusing and weirdly limiting.
Now that the 3D editor is getting interestingly complicated I agree with this, but not nodes like TestCube, it need builtin meshes to use everywhere, even on the particle system.
Or maybe ship a set of resources with the engine (meshes, materials, shaders and simple scenes ready to use and tweak).
Fixed by #8661.
Most helpful comment
I think the objects should also not be named test objects. Why exactly can people not use this to build actual levels directly not just for testing? Not everyone needs fancy highres 3d models for everything, so some are going to be fine with primitives for simpler graphics styles. Naming "TestCube" degrades it in a weird way, as if it wasn't going to work properly in a final game.
Also, this should definitely be available without plugins or the respective plugins should be installed per default. Pretty much all 3d editors of all engines provide cylinders, cubes, .. out of the box, so not having this is confusing and weirdly limiting.