-
-
Notifications
You must be signed in to change notification settings - Fork 35.5k
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
BufferAttribute: Make normalize() and denormalize() internal functions #24512
Closed
donmccurdy
wants to merge
4
commits into
mrdoob:dev
from
donmccurdy:cleanup/normalization-naming-fix
Closed
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
93eb9ab
MathUtils: Rename normalize() → floatToInt(), denormalize() → intToFloat
donmccurdy 64f0c46
BufferGeomtetryUtils: Remove redundant normalization.
donmccurdy 3e71793
BufferAttribute: Clean up.
donmccurdy 16cfc1f
BufferAttribute: Limit exports from src/Three.js
donmccurdy File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
What's the value of this field?
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.
Is it possible to avoid this property and just evaluate the typed array in
normalize()
/denormalize()
?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 think passing the entire array into normalize/denormalize as a huge 'type' argument was never ideal as a public MathUtils API... if this went back into MathUtils at some point, I think it is better to use types like IntType / ShortType. But since this is just internal, I suppose it does not matter so much. Any preference between:
__type
or#type
/cc @WestLangley
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 prefer B for now until there's a practical reason to change it. It makes it hard to see what the other meaningful changes are in this PR, as well
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.
TBH, I prefer any form of (A). Passing the array is horrible, IMO.
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.
imo passing a three.js enum can result in unnecessarily verbose user code with no value. If something like "A" is used I'd prefer to pass in something like the array type / constructor:
normalize( value, Int8Array )
.A lot of the code I've been working with has been written to generally support array types within three. For example packing buffers into textures for three-gpu-pathtracer, generating data structures in three-mesh-bvh, etc. A lot of the code in three.js isn't designed to support these types of use cases which is fine but it would be nice to keep it in mind when adding new functionality to the system - these use cases have been the driver for #24515.
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.
What if we keep these functions accessible through THREE.MathUtils, but rename them much more explicitly, and export getArrayType(array) as well. Then usage might look something like:
I think this naming might be less likely to confuse people, as it's a more explicit about the use of integers as an encoding of floating-point values, per the OpenGL definition:
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'm still not fully understanding the need for a separate set of "type" constants. I guess I'm just not understanding the need to redefine constants that the language already has built in with the typed array constructors. It just feels a bit roundabout and redundant - similar to the
Float32BufferAttribute
,Uint8BufferAttribute
, etc classes. But I won't fight it if it's what the project wants.