-
-
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
WebGL2: Added support for Uniform Buffer Objects. #21558
Conversation
@Mugen87 Any chance this awesome feature will be added in a future release ? |
@Mugen87 Should we give it a go this month? |
@mrdoob Yes, I would give this a try so devs can start using UBOs with their custom materials. The PR should be a safe change since the additions should no affect existing apps. We should just keep in mind that |
BTW: I'm adding documentation if the PR is going to be merged. |
Hello @Mugen87 , I am needing this feature because I want to send to my fragment shader 64 4x4 invMatrices as well as a top level dynamic BVH that is packed into 256 vec4's. The 64 3D game objects that these sets of uniforms belong to are constantly moving every frame, so writing to and reading from data textures (like I did for static path traced scenes) is too slow. Also, writing 64 4x4 matrices and 256 vec4's as normal old-style individual uniforms works on my laptop, but fails on mobile because there is a lower limit of how many uniforms you can send. So I end up blowing out my uniform slots on my phone for instance. This new UBO feature sounds like the perfect solution for my uniforms requirements! Thanks again for working on this. |
No sorry. Since the PR is not merged it's not yet possible to use UBOs with custom materials. |
Clean up.
UBO is a great feature. It would be awesome to see this one merged! 😊 |
Is this mainly blocked on documentation at this point? How do you feel about this implementation? |
What needs to get done before this gets merged? Is there anything we can help with? |
Yup. Been waiting a while for this. Pretty sure we have the interest to get this done. We need details on what's holding it up. Is the design alright @mrdoob ? Anything you would like changed? |
Sorry for the delay. Was waiting for things to get a bit under control 😅 |
Thanks! |
Nit: on the topic of documentation, grammatically I believe this would be Edit: I see this is more consistent with other utils (#15562 (comment)). |
|
||
if ( material.isShaderMaterial || material.isRawShaderMaterial ) { | ||
|
||
const groups = material.uniformsGroups; |
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.
@Mugen87 I had an exception on this line using a package which had an old TypeScript types of three.js (134)
I'm not sure how it works but seems like something along the way stripped this member from the RawSahderMaterial instance (internally in package this member was initialized correctly to an []
)
uniformsGroups
didn't exist on the instance at all, so the groups.length
was the actual exception
So I feel like there's a backwards compatibility issue here but I can't create a JSFiddle with an example
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.
That is strange since UBO support was added with r143
and all related classes and properties were added with this release.
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'll clarify, I use threejs 143 (no typescript in the project)
I import a package that's using 134+ts
The package somehow creates ShaderMaterials without this property
So the package is not ahead of my project - which I think should be supported
I'll try to work tomorrow on a jsfiddle, but I'm really not sure how I'll import 2 versions of threejs :)
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.
but I'm really not sure how I'll import 2 versions of threejs :)
That would be an invalid workflow anyway. Try using the types from https://github.com/three-types/three-ts-types. They have a r143
release.
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 patched the package on our private copy, so I don't have the issue anymore (doing what you mentioned)
But I believe that given 2 packages A and B where:
- A uses typescript and is using three.js r134 (or anything below 143), and if creating objects to be rendered by B.
- B uses three.js r143 or up (and is not using typescript? not sure it matters), B is running the main rendering loop and is responsible to create the canvas and renderer etc.
A will produce objects which are illegal in B (since this field doesn't exist in r134).
I have very little knowledge on how A and B are interacting with one another, might be a misconfiguration on that particular package and how it's imported.
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.
Seems like I'm wrong, this example shows the same scenario:
https://codesandbox.io/s/pix4d-three-potree-loader-example-forked-s6i6i1?file=/package.json
The imported package uses r139
But the example uses r143 without a problem
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.
It might work to combine three.js
from different releases but officially it is not supported. If library A creates an instance of THREE.Mesh
from r100
there is absolutely no guarantee that application B using r143
can process it. Let's be honest, it's quite unrealistic to support such a scenario.
* WebGL2: Added support for Uniform Buffer Objects. * Update WebGLState.js Clean up. * Fix example.
* WebGL2: Added support for Uniform Buffer Objects. * Update WebGLState.js Clean up. * Fix example.
Hi, it seems like this feature exists, but is totally undocumented. Is that expected? I had a question about usage. I'm working on something that may benefit from UBOs, but I don't really have more than around 384 8 bit components I need my shader to be able to reference. This would appear to still fit in the 1024~4096 or so components that I could expect WebGL2 to give me on most devices, so I most likely do not need to transition to using UBOs for such a need until I have 10x or more of this kind of data. Since I do not update this data except periodically there should be no performance benefit in switching to uniform buffers from uniform arrays. |
@unphased The UBO support in |
Related issue: Fixed #13700
Description
Successor of #15562.