compatibility with upcoming R72 of three.js

[vincent-courtalon]

Hello, i am not sure if it is really a bug or just a temporary change from R72 dev version of three.js, but using the shaderParticleEngine with it does not work for me (it works with r71 of three.js)
it makes a webgl warning "WARNING: Attribute 0 is disabled. This has signficant performance penalty" on chrome, and the particles are not visible...

if you have any idea of a quick fix (some suggestion i found was using index0AttributeName on material)? I will try later to pinpoint at what commit of three.js it happen.

and thank you for this project, it is a really fast particle engine!

[titansoftime]

In the dev version as of this post I get this error: THREE.ShaderMaterial: attributes should now be defined in THREE.BufferGeometry instead.

[titansoftime]

@squarefeet r72 is now live. Unfortunately (once again) there are no release notes /sigh.

[weiserhei]

Changelog is up 📄 https://github.com/mrdoob/three.js/releases/tag/r72
Also the ones for previous versions, wasnt too problematic to migrate my applications.

I will also update my projects using ShaderParticleEngine shortly and test with r72.

[squarefeet]

Hey guys, sorry for the delay in getting back to you all.

Going to grab me some r72 action and see how it fairs; will try to resolve any bugs with it should I (probably) come across any.

Thanks for the heads up :)

[squarefeet]

Okay, first problem I can see is that Shader Material seems to only play ball with THREE.BufferGeometry instances now (rather than plain ol' THREE.Geometry instances, and at least when custom attributes are being used - hence the attribute0 error), so I'll jump on that!

EDIT: @titansoftime - just seen that you'd already pointed this out. Derp.

[titansoftime]

@squarefeet Awesome! Super happy to see you on this =]

Your hard work is much appreciated. This library kicks ass.

[squarefeet]

@titansoftime Ha, no worries, Walter ;) It may take me a few days to get it up and running (got to convert from Geometry -> BufferGeometry, and don't want to cut any corners), but I'll be playing in the dev branch if you feel like coming along for the ride or want to point out I'm going in a stupid direction.

Currently wondering whether I should store all attribute values in a single ArrayBuffer (per emitter), using Float32Arrays as windows into the buffer, or whether a single buffer-per-attribute would be fine. Not sure of any performance gains from doing the former, nor the latter. Any ideas?

[titansoftime]

Ha, no worries, Walter ;)

HA! I don't roll on SHABBOS!!

Not sure of any performance gains from doing the former, nor the latter.

I'm right there with you, not sure. Sorry for my complete uselessness there =]

[squarefeet]

Saturday, Donny, is Shabbos, the Jewish day of rest. That means that I don't work, I don't drive a car, I don't fucking ride in a car, I don't handle money, I don't turn on the oven, and I sure as shit don't fucking roll!

[titansoftime]

"I'm calmer than you are."

[glibersat]

thx @squarefeet for having started the port to r72, I can't wait for it to be released! :)

[squarefeet]

@glibersat No worries, sorry it's taking so long - life is getting in the way!

[andrislusis]

indeed thx @squarefeet for the effort, I am on the waiting list for the port as well. :)

[squarefeet]

Okay, should have some free time coming up this week and over the weekend, so will hopefully have something up next week. Will keep this thread updated with progress! Hang tight, and thanks for the patience!

EDIT: The reason it'll take a bit longer than I expected is that I've got to move over from using THREE.Geometry to THREE.BufferGeometry and as a result swap all the attributes over to THREE.BufferAttributes (which stores data in TypedArrays, leading to incompatibility with THREE.Vector* instances to storing values/props/etc.). Ouch!

[titansoftime]

Ha, yea I started working on this (more so just playing around to better understand the code) and holy crap. Not an easy task. Your efforts are most certainly appreciated =]