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

BatchedMesh: add method to check if geometry can be added #27979

Open
marwie opened this issue Mar 23, 2024 · 5 comments
Open

BatchedMesh: add method to check if geometry can be added #27979

marwie opened this issue Mar 23, 2024 · 5 comments

Comments

@marwie
Copy link
Contributor

marwie commented Mar 23, 2024

Description

How should i detect if my BufferGeometry can be added to a BatchedMesh before calling addGeometry?

I know there's _validateGeometry - but this method seems not meant to be part of the public API. I'd need a way to detect if calling addGeometry is safe.

Solution

Expose _validateGeometry - not sure if it should throw however - perhaps it could return an object or string containing a reason for why it can't be added (and then the addGeometry call could still throw)

Alternatives

Calling _validateGeometry (this is very slow) - but an official API method would be preferred

Additional context

No response

@gkjohnson
Copy link
Collaborator

Of course you can currently use a try / catch block to test if adding the geometry is successful, but I understand it's not ideal.

Calling _validateGeometry (this is very slow)

In what way is this slow? I'm looking at the code and it doesn't look like it should take an unreasonable amount of time if it just returned success or not.

@marwie
Copy link
Contributor Author

marwie commented Mar 25, 2024

Perhaps something else in the code was causing the performance issue - I can't say for sure right now, sorry for implying.

What do you think about officially exposing the method or adding a public method for testing which returns information if (and if not) the object can be added: { success:boolean; reason?:string }

@gkjohnson
Copy link
Collaborator

What would you plan to do with the "reason" string? An API structured such that you can do the following feels best:

if ( mesh.canAddGeometry( geometry ) ) {

  const id = mesh.addGeometry( geometry );
  // ...

}

@marwie
Copy link
Contributor Author

marwie commented Mar 26, 2024

The reason for this object return type was just so that it could also be called internally (and replace __validateGeometry) and then throw with the reason given to the Error.

@gkjohnson
Copy link
Collaborator

The reason for this object return type was just so that it could also be called internally (and replace __validateGeometry) and then throw with the reason given to the Error.

Got it - I think this can be achieved with an internal function while retaining a simple public facing function that can be used like above.

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

2 participants