Why use x,y,z parameters instead of Vector3 about voxel-engine HOT 7 CLOSED

Using Vector3 couples voxel plugins more tightly to three.js. Since three.js doesn't support loading multiple instances and is a rather large library, using the entire library just for a plugin to access Vector3 is cumbersome.

[x,y,z] works with every javascript library out of the box and is easy to convert to Vector3, if needed.

I personally would like to continue moving away from peer dependencies like this to avoid this problem: http://dontkry.com/posts/games/where-voxel-js-has-failed.html

from voxel-engine.

Well, I meant, any generic object with .x .y and .z members, which is equally portable in either direction. Using objects as interfaces works better because it is easy to add new members but hard to change function signatures. That is one way to move toward your goal.

from voxel-engine.

Sorry for any confusion. The intro doc describes "any object with x, y, z member" as a ThreeJS vector, so I just used what I thought would be the more formal term given the definition. But I really meant any old object with those three members. It is just a unit vector with magnitude zero.

from voxel-engine.

Basically you create an object abstraction layer that works between any library and the core. You generally make only additive changes to the abstraction layer. This makes it easy for applications to depend only on the abstraction layer and they don't have to worry about the version of the core, because the abstraction layer depends on the correct version of the core and the core does not depend on the abstraction layer. When core changes are made, the abstraction layer can hide the changes temporarily via deprecated methods for a version or two, then drop the functionality when it becomes a burden to maintain. People that start using the abstraction layer shouldn't rely on deprecated functionality.

So instead of a Vector3 you create VoxVec3. It can have a constructor that takes up to three parameters. If the first parameter is an object (and only one param was provided) then use the x,y,z members on it. Otherwise if all three are scalars, just set the properties on the new object to the given values, or if they are all vectors, use the x, y, and z member with respect to the functional position.

Pretty much anything going into or out of the core should be abstracted like that.

from voxel-engine.

You also need a little API for the API, that is you have to be able to query the engine capabilities. This allows modules that are written against older engines to still operate properly with the newer engine, even when using the API calls available in the old abstraction library with the newer abstraction library that is installed. If the capability is not available, the API calls are "unsafe" and you should exit and upgrade your libraries.

from voxel-engine.

If you like this idea, I'm happy to help. I think this is an awesome project and I've been looking for something interesting to work on that isn't SQL related.

from voxel-engine.

I don't think that would fix my issue but rather just shift it. Generic is better here, IMO. I know it's common for other game engines to build large core libraries but we have an advantage here that I think we should use instead, npm.

If we used Vector3 or forked our own Vector abstraction, we would be forcing every voxel library to use that. Which means if there is a feature needed, the user would have to send a PR here thus burdening Max responsible for every voxel plugin. Also, breaking backwards compatibility in that abstraction is inevitable. When that happens, every voxel library is broken until each author updates. Making a terrible user experience as I outlined in my blog post.

[x, y, z] is generic and flexible. If I want to apply some vector math to it, I simply npm i vectors and require('vectors'). When vectors gets updated, my library continues to work using the older version of vectors until I am ready to upgrade. If vectors doesn't have a feature I need, I don't need to send a PR and wait. I simply find another library on npm or write and publish my own. No peer dependencies required.

Also, voxel-engine used to use Vector3. Everyone agreed and switched to the more generic array. You would have to convince and implement every dependency of voxel-engine to switch back. I am certainly -1 for switching back.

from voxel-engine.