Open sampottinger opened 4 years ago
Super, my initiatial proposition is not work on PVector double, just propose a class Vector version different, with ivec
vec
and bvec
and why not dvec
for double. And use vector like a type for the case, like in the glsl language. for now my library provide the same service than PVector for the class vec
and few more... and provide the minium for the class ivec
and for bvec
et voilà!
To quote the other-nuts-and-bolts page:
New vector class PVector is optimized in ways that people don’t really use, making it more confusing than necessary
I don't really get what Ben Fry means with this. For me personally it's that a lot of methods can't accept a PVector as an argument. Like line
, scale
, translate
etc. I would really like to know why other people don't use it. Is this statement even true. And if they don't use it, then what do they use instead?
But since the name of your OP, how often have people that they prefer double in practise. I don't really see issues about it on github or the forum. I myself have it like once in a few years that I need to use double which often is like a 5 minute fix.
Also introducing a second vector will be a pain. Now half the libraries won't support that vector. And changing it to double is also bad. Cause now half the libraries are broken cause they are not compatible with the updated vector.
I think if the vector has to be double then it should be done when processing is moving away from java to another language.
Anyway, about the library of StanLepunk. I think having 18 classes for having a vector is not a step forward but a huge step backwards. Also the library is way to complex and inefficient, I don't mean this offensive.
Let's take vec2
for example. First of all classes have to start with a capital, that way we know when we use static methods that they are static and not used on some variable. It's one of the most important java conventions.
Back on topic vec2
extends vec
, so it inherits all those properties!
public int num;
public float x,y,z,w = Float.NaN;
public float e,f = Float.NaN; // for vec5 and vec6
public float s,t,p,q = Float.NaN;
public float u,v = Float.NaN;
Then vec
extends BigBang
which contains:
public PApplet pa;
private String VERSION = "0.8.5.30";
So every vector created has not only a reference to the PApplet, but also a version.
Then when it comes to methods there are things like:
public float max() {
float [] list = new float[num];
if(num == 2) {
list[0] = x;
list[1] = y;
} else if(num == 3) {
list[0] = x;
list[1] = y;
list[2] = z;
} else if(num == 4) {
list[0] = x;
list[1] = y;
list[2] = z;
list[3] = w;
} else if(num == 5) {
list[0] = x;
list[1] = y;
list[2] = z;
list[3] = w;
list[4] = e;
} else if(num == 6) {
list[0] = x;
list[1] = y;
list[2] = z;
list[3] = w;
list[4] = e;
list[5] = e;
}
return max(list);
}
Which not only creates a new array everytime. It also has to set all the elements, and does a lot of branching which is not ideal for cpu's.
Also when I look at other things I see:
public vec3 set(float x, float y, float z) {
this.x = this.s = x;
this.y = this.t = y;
this.z = this.p = z;
return this;
}
There is so much overhead.
Apart from the Vector discussion. I thought the main reason of this fork was support for Java 11, OpenJDK, and OpenJFX. Which I believe work fine? For me personally I would really love to see this migrate in the main branch (of processing/processing) soon.
Last year openFrameworks (a C++ framework in some ways similar to Processing) replaced it's own vector classes by the GLM library. This avoid reinventing the wheel, is a standard, and the syntax is similar to GLSL.
I just checked and found GLM for JVM: https://github.com/kotlin-graphics/glm
GLM provides the vector and matrix math required for 2D and 3D graphics, so in theory it might help simplify the Processing code base, and using the same syntax as in other platforms would make it easier to port code between them. At the same time it can be a huge effort.
Still I wanted to throw the idea here.
Also, the vector story in Processing is long :) It seems standards are not liked, so ToxicLibs, heMesh and maybe others implement their own. Then you always end up with glue code to convert vectors from one to another. But I've seen the same on C++ too. Too bad 2D and 3D vectors and matrices are not a core datatype.
@clankill3r thanks for your strong feedback :) that's very nice for my personnal code improvement. for the first I know the convention about the uppercase for the classes name, and I do it to be similar of the GLSL convention and I I assume this weird choice but very logic for me, because I want considere the vec like a type, not like a class. I'm not real expert coder, more artist coder for me when you know the rules sometime it's can be necessary to break it. In this case I considere it's a time to break the rule.
For the second...this library is work in progress, I'm sure there is a lot of default must be, can be corrected, improved... At the first time of my library I don't use the class vec
ivec
bvec
but directly vec2
vec3
vec4
vec5
and vec6
but after using like that, I see the utility to use a mother class to swap from vec2
to vec3
to return vec2
and to do that have a mother class is not bad... I understand that's create a useless variable and it's a problem. but is I understand when Java when variable is not instantiate that's not a problem for the memory ?
For the third, I'm very open to find a way to improve my library all help is very very very welcome @clankill3r
@hamoid thx for the link https://github.com/kotlin-graphics/glm when I've a time I going to look it, that's can be a very very good way for my library and for Processing too :) thanks.
PS : So for my english, it's like my code very very artistic !
To quote the other-nuts-and-bolts page:
New vector class PVector is optimized in ways that people don’t really use, making it more confusing than necessary
I don't really get what Ben Fry means with this.
I don't get the weirdly negative tone in these comments and the rest of the thread. Why am I referenced personally? I'm building this thing in my free time and this animosity is bizarre.
It means that a lot of the design decisions, and the way that the methods work in PVector
are ways to keep things fast (i.e. the various static
methods that don't allocate memory, etc), but that most people don't use them that way, so the result is that their use makes their code a little weirder than necessary, if they didn't care about performance.
For me personally it's that a lot of methods can't accept a PVector as an argument. Like
line
,scale
,translate
etc.
Passing a PVector
instead of x
and y
is slower. In the past it was 2-3x slower. I haven't bothered profiling it recently. In practice, it can be even slower than that because you're creating a bunch of PVector
objects inside draw()
, which makes the garbage collector do a bunch of work.
So… do we ~double the number of methods in PGraphics
to support something that we wouldn't encourage? That doesn't seem like a good idea.
I would really like to know why other people don't use it. Is this statement even true. And if they don't use it, then what do they use instead?
As with all design decisions we've made, it's always about providing a balance between 1) what's intuitive, 2) what people will use, and 3) what has good performance. There are always tradeoffs, but those are the criteria, and we do what we feel is best for the community.
Also, the vector story in Processing is long :)
Is it? A vector class was (originally) terrible for performance, but it's helpful as a container. So we eventually added a class for it. Others made their own, but weren't used universally, so it didn't make sense to use them as a replacement. Toxiclibs had a nice one, but it was designed for advanced users, not our core audience. No need to be melodramatic.
But addressing the original question for this issue… Why would we switch to double? What's fixed? There are currently 524 open issues for the project. To my knowledge, it doesn't fix a single one of them. It also doubles the amount of memory required to hold the objects. Sure, double
is technically better than float
for accuracy, but understanding practice and context here are important.
If you want double
in a vector object, why not make a library? If anyone wants it badly in PGraphics
, it's straightforward to extend PGraphics
to do that. If you do that, and others want to do the same, then it's likely to be picked up as part of the core.
@benfry thanks for your light !
I understand well the Processing process now, and better the PVector history.
Personnally at the begin I use a lot PVector and i never have a problem with memory or slow down problem with it, except when I create maybe one or more thousand of it... I just create my vector class because tape the name PVector
is too long versus just vec
and manage the difference between vec2
or vec3
is sometime usefull and have a vec4
class is helpful too.
And again thank to you and @reas to lead the awesome project.
@StanLepunK To reduce the noise in this topic I gave some feedback on your library in your repository. https://github.com/StanLepunK/Rope/issues/4 I can provide some more later.
@benfry
To quote the other-nuts-and-bolts page:
New vector class PVector is optimized in ways that people don’t really use, making it more confusing than necessary
I don't really get what Ben Fry means with this.
I don't get the weirdly negative tone in these comments and the rest of the thread. Why am I referenced personally? I'm building this thing in my free time and this animosity is bizarre.
It was not meant negative. And it was referenced personally since you wrote that page. I just didn't know if it was about the lack of double support or vec2 and vec4 or the methods present.
From @StanLepunK in https://github.com/processing/processing/pull/5753,
What are people's thoughts?