Three.js: Geometry of purely custom attributes does not render at all (position must be set)

[frederikaalund]

Description of the problem

BufferGeometry with only custom attributes does not render in r84. Said geometry used to render in r79 (I think the issue was introduced in r81).

Example:

let geometry = new THREE.BufferGeometry();
geometry.addAttribute('gc_position_x', new THREE.BufferAttribute(positionsX.value, 1));
geometry.addAttribute('gc_position_y', new THREE.InterleavedBufferAttribute(positionsY, 1, c , false));
geometry.setDrawRange(0, N);

This used to render just fine in r79. In r84, I have to add the following line to get it to work:

geometry.addAttribute('position', new THREE.BufferAttribute(positionsX.value, 1));

I don't even declare position in the shader but three.js r84 still forces me to add the attribute. I think the behaviour from r79 was better. Can this be re-introduced?

Thanks in advance!

Three.js version

• [ ] Dev
• [x] r84
• [ ] ...

Browser

• [x] All of them
• [ ] Chrome
• [ ] Firefox
• [ ] Internet Explorer

OS

• [x] All of them
• [ ] Windows
• [ ] Linux
• [ ] Android
• [ ] IOS

Hardware Requirements (graphics card, VR Device, ...)

[makc]

reminds me this https://github.com/mrdoob/three.js/issues/7304#issuecomment-147096788

[mrdoob]

Yep! Try with mesh.frustumCulled = false;.

[makc]

@mrdoob the fiddle there has frustumCulled = false and does not work

[mrdoob]

Which jsfiddle?

[makc]

http://jsfiddle.net/1v2Lyftu/ nope
http://jsfiddle.net/b1u8czcw/ no worky
http://jsfiddle.net/g0v9ofxd/ na-ah, black screen here too

[frederikaalund]

Thanks for the feedback!

@makc Yes, the problem is exactly the same in the those fiddles as in my application. Thanks for sharing. Indeed, all three fiddles can be fixed by adding a single line:

geometry.addAttribute( 'position', new THREE.BufferAttribute( indices, 1 ) );

My argument is: Why do we have to declare the position when we are not even using it in the shader? All three fiddles would have worked fine in r79. I think the issue was introduced in r81.

[pailhead]

This really didn't work with frustum culling disabled?

[pailhead]

i tried the fiddles, and its indeed strange

So i've stepped through the code on this one:

dataCount stays zero here

https://github.com/mrdoob/three.js/blob/cd3807b3ed778a216e2692f21a83019198dfaae3/src/renderers/WebGLRenderer.js#L799

followed by:

drawEnd === -1
drawCount === 0

and exits here, without issuing a draw call
https://github.com/mrdoob/three.js/blob/cd3807b3ed778a216e2692f21a83019198dfaae3/src/renderers/WebGLRenderer.js#L814

I've no idea whats supposed to happen here. I tried making a smaller position buffer with a 1000 items, and that got drawn. This was compared though to both infinity, from rangeStart + rangeCount and the 100k number set by geometry.setDrawRange( 0, particles );

The position buffer size seems to win, and when its undefined it's just left at 0, hence the early exit.

[michalburger1]

The problem is this line:

var drawEnd = Math.min( dataCount, rangeStart + rangeCount, groupStart + groupCount ) - 1;

Even if you specify a custom drawRange the Math.min call will reset it to zero because it thinks that there are no vertices.

The only solution I can think of without breaking backward compatibility is blindly obeying the drawRange but only if neither index nor position attributes are defined. What I would actually prefer is always obeying drawRange even if it seems to exceed the dataCount and let the developer deal with it but that might break some existing code.

[michalburger1]

(The regression must have been caused by this https://github.com/mrdoob/three.js/commit/31d125e6d4e5d8e6650cbc06b29afd1d8bb44276)