-
-
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
WebGPU: Introduce Fat Points #26930
WebGPU: Introduce Fat Points #26930
Conversation
TBH, I'm not really a fan of the |
Sidenote: At some point we should maybe rename examples like |
But these are not sprites. They are points, sized in pixels. When re-implemented in TSL, they would replace the single-pixel points rendered by Instanced sprites have a map, are sized in world units, can be size-attenuated, and can be rotated. I am inclined to think we are talking about two different things.
That's fine. Different nomenclature can be used. |
We can also call them |
Regarding #25697 (comment): With this implementation, is the point size now consistent when changing the renderer's pixel ratio? |
The user should not have to worry about the device pixels.
|
That is good since it solves one issue with previous point primitive rendering. |
The "Fat Points" nomenclature can be changed. |
import { OrbitControls } from 'three/addons/controls/OrbitControls.js'; | ||
|
||
import { FatPoints } from 'three/addons/points/FatPoints.js'; | ||
//import { FatPointsNodeMaterial } from 'three/addons/points/FatPointsNodeMaterial.js'; // why not this, instead? |
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.
You can actually use just FatPointsMaterial and it would be auto-converted to FatPointsNodeMaterial by WebGPURenderer based on its name.
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.
Here I just meant that you can import just the FatPointsMaterial instead of FatPointsNodeMaterial and it should work exactly the same.
For background I believe setting scene.background = THREE.Color( 0x222222 )
should also work just fine as scene.backgroundNode = color( 0x222222 )
. So basically using the same code as for WebGL should work 🙂
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 we no longer need FatPointsMaterial
. My intention is to remove it. (I just wanted to get its shader to work correctly before attempting the Node version.)
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.
You can actually use just
FatPointsMaterial
and it would be auto-converted toFatPointsNodeMaterial
It does render, but the vertex colors are not honored.
Assuming that will be fixed, would it be preferable to retain FatPointsMaterial
(in glsl) and remove FatPointsNodeMaterial
?
ping @sunag @LeviPesin
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.
If the main scope is WebGPURenderer
, I vote yes.
It's great to see NodeMaterial
saved lines of code in relation to the same material created in ShaderMaterial
, with the advantages that each "uniform" is a channel for a procedural node.
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.
For background I believe setting scene.background = THREE.Color( 0x222222 ) should also work just fine as scene.backgroundNode = color( 0x222222 ).
For WebGPURenderer (both backends), it appears
scene.background = new THREE.Color( 0xff0000 ); // does not honor viewport/scissor
scene.backgroundNode = color( 0xff0000 ); // honors viewport/scissor
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.
scene.background = new THREE.Color( 0xff0000 ); // does not honor viewport/scissor
Could this be happening there because scene.backgroundNode
overrides the scene.background
settings?
I tested it in webgpu_lines_fat
replacing all scene.backgroundNode
to null
and work. (or just remove all scene.backgroundNode
assigns)
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.
@sunag For me, the background color of the inset view extends to the entire screen when scene.background
is used in WebGPURenderer.
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.
scene.background = new THREE.Color( 0xff0000 ); // does not honor viewport/scissor
Could this be happening there because
scene.backgroundNode
overrides thescene.background
settings? I tested it inwebgpu_lines_fat
replacing allscene.backgroundNode
tonull
and work. (or just remove allscene.backgroundNode
assigns)
Setting the background color using the clear color doesn't work in the same way as WebGLRenderer. The scissor area does not constrain the region cleared.
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.
/ping @sunag @LeviPesin See comment by @aardgoose .
Please remove the |
@sunag Let's also consider calling them |
I vote for this too 👍 We could, instead, introduce |
As suggested in #25697 (comment).
Based on #11349. A "fat point" sized in pixel units is just a "fat line" of zero length.
Note, these "fat" points are sized in pixel units. This is different than the
THREE.Points
implementation.//
So, what features do we want to support?
How should this be integrated into Core?
In particular, what should be the API?