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

Add more primitives to the editor for rapid prototyping #1381

Closed
rraallvv opened this issue Feb 17, 2015 · 11 comments
Closed

Add more primitives to the editor for rapid prototyping #1381

rraallvv opened this issue Feb 17, 2015 · 11 comments

Comments

@rraallvv
Copy link
Contributor

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.

@reduz
Copy link
Member

reduz commented Feb 17, 2015

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
#1381.

@not-surt
Copy link
Contributor

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.

@kubecz3k
Copy link
Contributor

Closed #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 #1508 had 1.2 milestone

@reduz
Copy link
Member

reduz commented Oct 28, 2015

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 #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
#1381 (comment).

@kubecz3k
Copy link
Contributor

kubecz3k commented Jan 8, 2016

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

@kjohnson0451
Copy link
Contributor

kjohnson0451 commented May 12, 2016

I'm using @TheHX 's plugin as a reference to implement this as a C++ module.
https://github.com/kjohnson0451/godot/tree/primitive

@neikeq
Copy link
Contributor

neikeq commented Jun 3, 2016

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?

@kubecz3k
Copy link
Contributor

kubecz3k commented Jun 3, 2016

@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.

@kubecz3k kubecz3k modified the milestones: 3.0, 2.1 Jun 3, 2016
@ghost
Copy link

ghost commented Jan 3, 2017

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.

@eon-s
Copy link
Contributor

eon-s commented Apr 9, 2017

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).

@akien-mga
Copy link
Member

Fixed by #8661.

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

8 participants