VectorBuffer concept

[zcxv]

Description.
I've noticed that VectorBuffer generally used in temporary vectors calculations inside RLib. It's good way but maybe it would be better a change general concept to the pool?
The pool may also work like buffer if control code won't put vectors back. In big calculations (planes, polygons, motions and other) if control code frequently calculate that stuff RLib will over-allocate necessary memory or waste in stupid way already stored vectors for temporary calculations.
We can optimize those cases with pooling. It will speed-up (vectors can run out in buffer and buffer must create new vectors, this case is memory allocation which we are trying to avoid; if vectors will be stored in buffer for too long, GC will move vectors to old-generation objects, it's a big problem in temporary calculation cases because vectors removal is going only in full GC stage) and save the memory (we can use vectors again and avoid memory over-allocations).

TL;DR
My suggestion: move all temporary calculations to pool and delete maybe VectorBuffer (I think VectorBuffer is not needed with pooling).

Plan.

1. Analyze all VectorBuffer usages to change concept
2. Write a pool, some like it:

public abstract Vector3Pool implements Pool<Vector3f> {
	private final Array<Vector3f> pool;
	private final Supplier<Vector3f> supplier;
	private final Consumer<Vector3f> freeConsumer;

	public Vector3Pool(int capacity) {
		this.pool = ArrayFactory.newArray(Vector3f.class, capacity);
		this.supplier = getVectorFactory(); //by default: Vector3f::new
		this.freeConsumer = getVectorFreeAction(); //by default: vector.set(Vector3f.ZERO)
		for(int i = 0; i < capacity; i++) {
			pool.add(supplier.get());
		}
	}

	protected abstract Supplier<Vector3f> getVectorFactory();
	protected abstract Consumer<Vector3f> getVectorFreeAction();

	@Override
	public boolean isEmpty() {
		return pool.isEmpty();
	}

	@Override
	public void put(Vector3f object) {
		freeConsumer.accept(object);
		pool.add(object);
	}
	
	public void put(Vector3f...objects) {
		for(int i = 0; i < objects.length; i++) {
			put(objects[i]);
		}
	}

	@Override
	public void remove(Vector3f object) {
		pool.fastRemove(object);
	}

	public Vector3f take(float x, float y, float z) {
		return take().set(x, y, z);
	}
	
	public Vector3f take(Vector3f vector) {
		return take().set(vector);
	}

	@Override
	public Vector3f take() {
		final Vector3f object = pool.pop();
		if (object == null)
			return supplier.get();

		return object;
	}

	@Override
	public String toString() {
		return pool.toString();
	}
	
}

Or make interface:

public interface Vector3Pool extends Pool<Vector3f> {
	void put(Vector3f...vectors);

	Vector3f take(float x, float y, float z);
	return take().set(vector);
}

3. Move all VectorBuffer usages to Vector3Pool.

Risks.
Minimal risks inside RLib: it's a just like VectorBuffer refactor.
About exists projects where's RLib already using: need a analyze VectorBuffer usages, pluses and minuses by switch buffer to pool. I known you have some projects like jMonkeyBuilder where's RLib is used and you are need to analyze this issue to compability with your projects firstly.

Implementation.
I can do this issue if you agree.

[JavaSaBr]

I think we can add additional methods to the Vector3fBuffer interface.