amazing

[vegarringdal]

amazing

[vegarringdal]

How are you planning to use BatchedMesh to address this?

Hoping to reduce drawcalls. Atm I use geometry groups on merged meshes based on area. They are optimised when loading model. Mostly 3-4 drawcalls per area.
But I can end up with a lot more groups when users select items/highlight. Users might also set user set color/move based on selection.

Frustum culling will be possible without a huge perf hit (many more groups).

Just need to learn more about texture and see how fast updating is.
What could go wrong 😂

That makes sense if they're using gpu picking - it wasn't clear from the presentation.

yes, well thats what I plan to try. Need it since i remove buffers after upload.

Actually because of frustum culling and object sorting gl_DrawId isn't so useful because the objects are rearranged and filteredbefore rendering. Using the batchId attribute will give you what you're expecting from draw id.

Well I made PR anyways
mrdoob/three.js#27630

Sorting the offset/setting count to 0 would give you the same without and additional attribute.
Just started experimenting, so I have no idea how it will go atm.

BatchedMesh makes it really easy to call multidraw extension, would have been really hard to try this without your prev work here. 👍

Most of my meshes is already merged/I know offset/count/bounding box etc. So I will make a simplified version for my experiments.

Pretty much need to just set the correct values right away

    // constructor
    this.isBatchedMesh = true;
    this.boundingBox = new Box3(); // not important atm
    this.boundingSphere = new Sphere(); // not important atm
    this._multiDrawCounts = multiDrawCounts;
    this._multiDrawStarts = multiDrawStarts;
    this._multiDrawCount = multiDrawCount;
    //etc

[gkjohnson]

Generally I'm not working on this project or batching at the moment so I can't put much thought into this. I recommend making a thread at the forum to discuss other potential features. My first impression is that this shouldn't be needed, though, since you can just add each geometry range to the BatchedMesh separately.

[vegarringdal]

Maybe items should be able to share matrix, since you might move groups of items, atleast in cad/bim models
Then logic of app would just add this matrix transformation to parts needed.
No need to matrix4 if you might not even move it

Little weird video of app where I just use normal mesh and groups with material index.
So I get some performance hit if someone would select many individual items in merged meshes

Every group also have a matrix4, so if I move a part of a range, I add matrix to prev etc..

msedge_PUsn0qaKd9.mp4

[vegarringdal]

when i think about it... guess what Im doing when I move selection is this...

only Im just just using material index and groups on normal mesh.
So doing similar with batch meshes might give me less performance hit in the long run.
And I could just set count to 0 on items I want to skip for frustrum culling...

just thinking out loud here... so might be not a good idea.. 😂

[vegarringdal]

if this is a idea really depends how fast I can replace the textures I guess...
when doing stuff like invert selection etc

[gkjohnson]

Glad you're enjoying the work.

So I get some performance hit if someone would select many individual items in merged meshes

This is the reality of updating complex hierarchies of 3d transforms, especially in Javascript. If you need help figuring out how to optimize this I'd recommend asking at the forum.

Found this, dunno if its any help/can give ideas
https://www.khronos.org/assets/uploads/developers/presentations/Philip-Taylor---Leveraging-multi-draw-to-improve-performance.pdf

The current BatchedMesh implementation is doing most of whats outlined in that presentation and more (sorting, frustum culling). And multi-material property is support can be done manually as shown in this project. The support for reusing geometry in the batched mesh is not supported, though, and likely would make frustum culling and sorting more complicated.

What I don't understand is what the point of the geomId and boundingBox that is packed into "draw data" texture is for. It's not at all described in the presentation. It's possible they're just for app features that aren't described in the to paper (like highlighting all geometry of type X or within a size). If you'd like to ask them it might provide a bit more insight.

[vegarringdal]

This is the reality of updating complex hierarchies of 3d transforms, especially in Javascript. If you need help figuring out how to optimize this I'd recommend asking at the forum.

Atm I just do it on current shader when they move selected, then when they stop I call rust wasm in own worker that keeps state/geometry ranges + transformation correct.
Worked atm its working really nice.

Hoping I can use batchedMesh to improve this part.

What I don't understand is what the point of the geomId and boundingBox that is packed into "draw data" texture is for.

I dunno about the boundingbox, but they might use the geomId to generate color for gpu picking, so they can remove index/buffer after its uploaded to gpu.

[vegarringdal]

@gkjohnson
Do you know why #extension GL_ANGLE_multi_draw : require isnt used ?

#extension GL_ANGLE_multi_draw : require
void main() {
    gl_Position = vec4(gl_DrawID, 0, 0, 1);
}

[gkjohnson]

Hoping I can use batchedMesh to improve this part.

How are you planning to use BatchedMesh to address this?

I dunno about the boundingbox, but they might use the geomId to generate color for gpu picking, so they can remove index/buffer after its uploaded to gpu.

That makes sense if they're using gpu picking - it wasn't clear from the presentation.

Do you know why #extension GL_ANGLE_multi_draw : require isnt used ?

It wasn't needed BatchedMesh since gl_DrawId wasn't used but it would be good to add.

Actually because of frustum culling and object sorting gl_DrawId isn't so useful because the objects are rearranged and filteredbefore rendering. Using the batchId attribute will give you what you're expecting from draw id.

[gkjohnson]

Sorting the offset/setting count to 0 would give you the same without and additional attribute.

I'm not sure what you mean by "sorting the offset". If you rearrange the ranges to draw then the draw id will not be what's expected.

[vegarringdal]

I would need to sort the texture with itemId too.
But Im sure there is a lot Im missing. But it will be fun to see what I manage to do 😁

[gkjohnson]

It doesn't sound like you're saving anythough then, though 🤷 It just sounds slower. You're just replacing the attribute with a texture you have to sample and you have to reupload it every time it changes.

[vegarringdal]

yes 😂
Im sure I will do some weird stuff while experimenting 😁

[vegarringdal]

gl_DrawID is considered ‘uniformly varying’, so
texture lookups will be cached across a given draw.

Noticed this in the link I posted earlier. So might have som advantages some places. But if I need to sort a lot using attribute will prb be faster. 👍

[vegarringdal]

It doesn't sound like you're saving anythough then, though 🤷 It just sounds slower. You're just replacing the attribute with a texture you have to sample and you have to reupload it every time it changes.

Gave this som more though today. if you use attribute it size needs to match index(position size/3) But if you use the draw_id it only needs to be same size as offset array when you call multidrawwebgl function.
So texture with draw_id would usually be a lot smaller.

Or maybe I got this part wrong 🤔
Guess I just need to and make something and learn by trying and failing understand texture part /draw_id more 😁

[gkjohnson]

This occurred to me later, as well, but you still wind up using an extra texture slot. I think this is a hyper optimization until there's a reason to add it to BatchedMesh.

[vegarringdal]

In the PR you said this:

It does occur to me that a separate texture like this, though, can be used to render multiple of the same geometry in a single BatchedMesh without having to duplicate the data in the vertex buffers. So effectively we could cover instanced meshes and batched rendering all with a single object and draw call. An API with this in mind would need to be designed, though, which doesn't sound straight forward.

Are you thinking about ext.multiDrawElementsInstancedWEBGL() or using ext.multiDrawElementsWEBGL()
or using both with one buffer ?

[vegarringdal]

Been giving this some more though.

Atm we have groups we can use in standard mesh.
Using groups is very nice way to work with to set colors on parts like I do in the video in earlier comment.
But if you set many different colors you might end up with more drawcalls.

But what we we added another group prop ?
Like batchedGroups where we also had boundingbox for culling/sorting.
Or just use groups and prop to tell it needs to try and batch it, if it has boundingbox prop in groups it can try and use it.
This would speed up normal groups without users needing to do anything if Im not missing anything.

What do you think ?
Might be useful ?