-
-
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
added setDrawRange to Object3D #9929
Conversation
@WestLangley what do you think about this idea? |
Gee, I am having a hard time understanding why one would want to do that, quite frankly. |
Think of it as having properties that right now are in the geometry and material moved into the object. If you have 100 different objects, each with a different material.color, right now every mesh uses the color defined in the material, so -without getting into vertexColors, custom attributes, etc.- you would need 100 different materials, each with different color. If the color property were in the mesh, and assigned to the material/program when drawing, you'd only need one. This is the same thing but for data related to geometry and data buffers. The original PR is buggy, btw. It would need a better method to mix properties. |
@spite I see. So, in other words, you are proposing moving the uniforms out of the material -- along with perhaps some geometry properties -- into a "renderable object". So we would have |
Rather than moving, having a property in the instance that, if defined, supersedes the one defined in the material or the geometry. |
Oh, yes. That suggestion has come up before -- and likely in similar suggestions in other posts, too. |
Regardless of whether we want to implement this change or not, we can not merge the PR in its current state. At least updating But do we really want to move |
No. I think the proposal in this thread can more-accurately be stated by #9929 (comment). |
Okay, I see. The idea is to keep |
I don't know...if we start with a geometry property, users could also expect material properties to be added to |
@Mugen87 No, the suggestion is not to add properties to We tried to support something similar to this with |
I read the word |
@Mugen87 You are correct. I should have said "instance properties, such as I inferred -- perhaps incorrectly -- that the OP changed his original proposal as a result of the discussion. |
Closing. The workaround for this particular use case is the usage of
With the new material system, custom nodes can be used to supersede material or geometry properties. There is already a WebGPU example that demonstrates this approach: https://threejs.org/examples/#webgpu_instance_uniform This approach will also be possible with |
Similar to #9662, there are attributes that are assigned at the geometry level that should be at the instance (mesh) level. The onBeforeRender and onAfterRender callback are an extreme solution to something that, as the uniforms defined at mesh level, should be managed internally by the engine.
It's assigned to Object3D since that's the base object that the method accepts, but if there are concerns for overhead, there can be an explicit check that the object supports geometry ranges.