Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (710)
Games in Android Showcase (212)
games submitted by our members
Games in WIP (784)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Point/Vector/Tuple/Coord3f mess  (Read 2223 times)
0 Members and 1 Guest are viewing this topic.
Offline abies

Senior Devvie

« Posted 2003-12-25 15:26:40 »

I have looked at the changes introduced with collision code and I think that xith3d is getting into very dangerous situations because of Point/Vector/Tuple/Coord3f.

In java3d, everything worked on Point3f and Vector3f, almost none of methods accepted Tuple3f. While this caused a lot of headache when you had to move data there and back just to match some method signature, at least it was very helpful (for me) math-wise - if you had ray method, you new what Point and Vector meant without looking at javadoc or parameter names. With pair of tuples, you need to be a lot more careful - and mistake will go unnoticed silently and can even work correctly in some cases !

Now I see that Coord3f extends Vector3f class was added to unify Point3f and Vector3f. Again, I understand the reason - Tuple3f has not exposed enough methods to be useful, so even in xith3d you had to sometimes copy data there and back or rewrite basic stuff like dot product yourself just to have it work on tuples you got from elsewhere (this would be not a problem if they would be Vectors as they should, but...). But then comes the transform and while Coord3f extends Vector3f, MatrixExt4f transforms it as a point... and this is a one step too far IMHO. Look at following examples

MatrixExt4f me;
Coord4f coord;

I can transform coord as point using
Matrix4f matr = me;

I don't know if it hits you as much as me, but if I see a code which just assigns a pointer to superclass and this changes a result of method call...

Same goes for
Vector3f vec = coord;

In first case it is transformed as vector in second as point.

This is bound to be a cause of major and hard to detect errors in both core lib and user programs. Solutions ? I do not see ideal one, but here are some ideas:

Rename transform(Coord3f) method from MatrixExt4f to transformAsPoint(Coord3f) and add second one transformAsVector(Coord3f). Then make Coord3f to extend Tuple3f and copy vector methods there in addition to point ones - this way it will not get mistaken by accident. At the same time, transform methods as different enough to not be available with other meaning in plain Matrix4f.

In every method which has incoming Coor3f parameter, stress if it is looked at as point or vector if it makes a difference.

In some cases add explicit Point/Vector name to method, as you cannot rely on parameter signature matching to do a job, so you need to go EIFFEL route and encode everything in method name.

My personal choice would be to go back to java3d route and use Point3f/Vector3f in meaningful way, even if it costs developer a bit of extra work. But as it is one of design guidelines of xith3d to not have such distinction, at least let's make it very hard to make mistakes.

Artur Biesiadowski
Offline DavidYazel

Junior Devvie

Java games rock!

« Reply #1 - Posted 2003-12-25 16:47:04 »

Yes it is dangerous, but perhaps necessary.

I would prefer the transformAsPoint or transformAsVector methods.

I personally prefer a unified solution.  The collision code really brought it home as I was constantly switching back and forth from vectors to points, making extra copies for no good reason.  Unfortunately all the methods in the Vecmath library are declared final, so we cannot alter the behavior whatsoever.

Basically is there some reason why we would not want to calculate the distance between two vector endpoints?  Well Vector3f does not have this method.  Is there any reason why we would apply a transform with a translation component to a vector and not have it apply the translation part?  I think it is non-intiutive that transform of a vector will only effect rotation and scale, but ignores the translation.

I personally would prefer that Xith3d used a single unified Coord which did away with the distinction of point and vector except that would introduce too much incompatiibility with older code.

I will revert the Transform3D back to using the Matrix4f and will introduce the two transformAs methods.  I do think having the Coord3f as a unified Tuple for use in subsystems like collision should be allowed.

David Yazel
Xith3D Project Founder

It may look complicated, but in the end it is just a bunch of triangles
Offline Jens

Senior Devvie

Java for games!

« Reply #2 - Posted 2004-01-18 16:08:14 »

A related question: If you had the chance to do a vecmath library from scratch, would you make the distinction between vector and point or not?

I'm currently writing a program and it's really frustrating to write vector math things. You always have to convert between vector and point (sometimes making unnecessary copies). On the other hand distincting between point and vector can increase readability. (Side note: In this case operator overloading would greatly enhance readability.)

Xith3D Getting Started Guide (PDF,HTML,Source)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline overnhet

Junior Devvie

Java games rock!

« Reply #3 - Posted 2004-01-20 12:56:37 »

In my own vecmath lib, I have Vector and Point extend Tuple4f and I use homogeneous coordinates.

That way, when it makes sense to handle vectors and points the same way (eg. homogeneous transformation), I use them as tuple.

The main drawback is obviously the use of an additionnal float (w), even if the user doesn't really need it.
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

theagentd (114 views)
2017-02-18 13:42:33

theagentd (118 views)
2017-02-18 13:35:16

h.pernpeintner (1282 views)
2017-01-24 22:39:11

h.pernpeintner (1270 views)
2017-01-24 22:38:32

Galdo (1830 views)
2017-01-12 13:44:09

Archive (1934 views)
2017-01-02 05:31:41

0AndrewShepherd0 (2472 views)
2016-12-16 03:58:39

0AndrewShepherd0 (2302 views)
2016-12-15 21:50:57

Lunch (2381 views)
2016-12-06 16:01:40

ral0r2 (2156 views)
2016-11-23 16:08:26
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!