-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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
Importer option for permanent scaling of the scene #60115
Conversation
Typo on the commit message. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see a lot of unnecessary data copies, and a lack of const correctness. Can you go through and check on them? A lot of the data copies will not be able to be solved due to lack of move semantics however.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looking ok.
I do wonder... do we need to consider other objects types for rescaling? For example, light attenuation? camera scale/near/far?
while (i < current_bs_vert_arr_len) { | ||
current_bs_vertex_array.set(i, current_bs_vertex_array[i] * p_scale); | ||
i += 1; | ||
} | ||
current_bsarr[ArrayMesh::ARRAY_VERTEX] = current_bs_vertex_array; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code is really messy.
I did things this way in my GDScript implementation because we do not currently have access to a better API for modifying ImporterMesh.
But since we're making a core engine change, it might be better to provide access to the vertex positions of EditorSceneImporterMesh so that they can be modified without deleting and readding everything.
Here's or chance to improve the APIs to make them less clunky.
Want to rebase and try resolving the review comments? |
According to @lyuma this resolves the blend shape bug. Will test. |
Can this function be applied to rotations as well? I was thinking of something similar in #63662. I prefer that those transformations need to be PreProcess for retargeting. |
I want to propose to set the root transform as the default value of this importer option. |
800fc97
to
6cb1fdc
Compare
9c3bf07
to
dcdedb8
Compare
I'll see if I can reset the branch to avoid the big diffs. |
Seems good for the most part, should be able to merge it |
Will revise the for loop. |
READY TO GO
|
Cameras and punctual lights are like points, so scaling a point doesn't do much. I don't know if scaling a light's light-units by distance-scale has a good formula since the physical light units is not default. A camera is a node 3d, might work by chance. tl;dr not a blocker. |
Scaling a positional light by increasing its range should work well enough in some cases. Keep the same attenuation, and keep the same spot angle. Cameras should be kept identical – don't change their FOV depending on scale. |
@reduz can you remove the merge block? The while loop has been removed. |
Thanks! |
This is a draft PR tied to a proposal to replace or provide an alternative to the existing importer root_scale option (godotengine/godot-proposals#4379). The root_scale option only provides a one off modification to the root node's scale value when its instantiated, whereas this option provides a permentant modification to the underlying geometry and animations of a scene.
Left in draft while proposal is considered and the PR is being throughly tested for bugs.
Thanks to @lyuma for the original script implementation of this which I used as reference when writing this C++ version.