Open thehatless opened 2 years ago
QuadMesh/PlaneMesh has a center offset property available, but it's not available in the rest of PrimitiveMeshes.
This makes simple animations complicated and complex animations a big waster of human and cpu time.
You can use a Spatial to act as a pivot point (except within a particle system, which is why Center Offset was only added for PlaneMesh and QuadMesh). This won't use much CPU resources at all.
I don't think an offset is essential and thus it shouldn't be added.
Please use an offset Node3D or manually apply the position to each of the mesh's verticies.
QuadMesh/PlaneMesh has a center offset property available, but it's not available in the rest of PrimitiveMeshes.
This makes simple animations complicated and complex animations a big waster of human and cpu time.
You can use a Spatial to act as a pivot point (except within a particle system, which is why Center Offset was only added for PlaneMesh and QuadMesh). This won't use much CPU resources at all.
This is what I have been doing, up until the bit where I threw my hands in the air and said 'boy am I tired of working around the arbitrary barriers Godot has put in my way.' A big object heirarchy with dozens of invisible but vital pivot nodes is a living bug factory, truly painful to use. The pain is increased because a simple solution exists but is locked away by the interface.
The functionality exists already. Rather than hiding it in some cases, don't.
I don't think an offset is essential and thus it shouldn't be added.
Alas, it already exists.
Please use an offset Node3D or manually apply the position to each of the mesh's verticies.
I was surprised to discover you can't alter a PrimitiveMesh's vertices.
The functionality exists already. Rather than hiding it in some cases, don't.
Godot follows a "prefer local solutions" philosophy, which means that we prefer adding properties to subclasses whenever possible, rather than the base abstract class. We can reconsider this if there's strong demand, but we are careful about avoiding bloat in base classes that are extended by a lot of other classes.
Can you describe a concrete example of the kind of animation you're creating?
Can you describe a concrete example of the kind of animation you're creating?
I'm making a first-person game with a stylised look similar to Kurzgesagt. Lots of characters made from complex hierarchies of capsules and cylinders walking about (+Dumb Shader Tricks for the Adobe Illustrator look.)
Hopefully somebody else can speak up in favour, but I do strongly recommend adding Center Offset to the base class. It's not only significant in this particular case, but in almost any case where you're using primitive meshes as anything more than quickie placeholders, because almost nothing in real life pivots around its geometric center.
Why only primitive meshes? I suggest having pivot for any Mesh or MeshInstance. If I added a model from sketchfab, why do I need to change the offset in Blender or add extra Spatials
Controls do have rect_pivot_offset (iirc the name).
pivots in the engine with your suggestions is equivalent to have implicit node transforms and our skeleton determinations is fragile
https://github.com/RevoluPowered/FBX-Document-Notes/blob/master/index.md#pivot-transforms
I suggest having pivot for any Mesh or MeshInstance.
Changing the center offset in a Mesh requires regenerating the geometry, which is slow for complex meshes. I'm worried about people using this within animations, which should never be done as geometry would be regenerated every frame.
I'm worried about people using this within animations, which should never be done as geometry would be regenerated every frame.
I think this can be solved by editor/docs notification like "don't change it often!"
Describe the project you are working on
A graphically stylised game that uses a lot of built-in mesh instances
Describe the problem or limitation you are having in your project
A PrimitiveMesh always has its center point at the geometric center of the mesh. This makes simple animations complicated and complex animations a big waster of human and cpu time.
The solution would be a way to move the center point around the mesh. Happily, this solution already exists.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Plane meshes and quad meshes have a Center Offset value which shifts the object's center. They don't suffer from this problem! If this value were exposed to other mesh types, it would solve the problem for them also.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Expose the Center Offset value in every type of PrimitiveMesh, not just those two.
If this enhancement will not be used often, can it be worked around with a few lines of script?
Not to my knowledge (I was surprised too.)
Is there a reason why this should be core and not an add-on in the asset library?
The feature is already here. It's just not evenly distributed.