jogl utils

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

jogl utils

Fred Vernier
Thank you for supporting jogl even when Sun didn't show any support for a long time. I read other post talking about jogl, gluegen, joal and wonder about joglutils. It's still there in the Sven repository but you never mention it as live project (and it was almost dead in the previous kenai framework). There are useful stuff in there anyway like the .3ds loader. I hope it will still work. By the way I found 2 bugs and suggest one improvement in 3ds loader.

in src/net/java/joglutils/ThreeDS/Loader3Ds.java

line 447 : normals[i] = vVector2;
WHY: otherwise 2 lines after when the cross product is made it is computed between vVector1 and vVector1 => no normals are computed !!!!

line 358 and 336: all "swap(dataInputStream.readFloat())" should be replaced with something like this
declare an array of 4 byte before the loop:
"byte[] data = new byte[4];"

in the loop, read the byte as byte and swap them BEFORE converting anything to float
"dataInputStream.readFully(data);
int v  = ((data[3]&0xff)<< 24) | ((data[2]&0xff) << 16) | ((data[1]&0xff) << 8) | ((data[0]&0xff) << 0);
float f0 = Float.intBitsToFloat(v);"

do it 2 or 3 times (2 for uv, 3 for vertex) and compute f0, f1 and/or f2

finally compute the vector with f0, f1 or f0,f1, f2

WHY: because Java handle float with special values (POSITIVE_INFINITY, NaN, etc.). When a loaded float leads to such a special value it becomes impossible to swap the bytes anymore. I found a 3ds model with vertices around x~=2200.0 and about 5% of the vertices were corrupted due to this problem.

I'm sorry I can't commit my fixes. I don't know git yet and I really don;t know if I will have time to jump into it in the near future.

BTW, I suggest the tempNormal made available as a global value of the Obj (line 427 of Loader3Ds.java). It is a normal per face (instead of the normals per vertex) and I find very usefull to be able to access such normals (and as far as they are already computed...)

Reply | Threaded
Open this post in threaded view
|

Re: jogl utils

Michael Bien
thank you for the bug report Fred.

We are currently busy with the other 9 projects. Not sure if we will have time to maintain the utils project too (at least not now). If you can contribute in this area by committing into the repository it would be great.

git isn't that hard. Just fork the utils repository (the top right button on github) and you can start hacking.

good to know that someone actually uses the utils project - we weren't sure about that :)

best regards,

michael

Fred Vernier wrote
Thank you for supporting jogl even when Sun didn't show any support for a long time. I read other post talking about jogl, gluegen, joal and wonder about joglutils. It's still there in the Sven repository but you never mention it as live project (and it was almost dead in the previous kenai framework). There are useful stuff in there anyway like the .3ds loader. I hope it will still work. By the way I found 2 bugs and suggest one improvement in 3ds loader.

in src/net/java/joglutils/ThreeDS/Loader3Ds.java

line 447 : normals[i] = vVector2;
WHY: otherwise 2 lines after when the cross product is made it is computed between vVector1 and vVector1 => no normals are computed !!!!

line 358 and 336: all "swap(dataInputStream.readFloat())" should be replaced with something like this
declare an array of 4 byte before the loop:
"byte[] data = new byte[4];"

in the loop, read the byte as byte and swap them BEFORE converting anything to float
"dataInputStream.readFully(data);
int v  = ((data[3]&0xff)<< 24) | ((data[2]&0xff) << 16) | ((data[1]&0xff) << 8) | ((data[0]&0xff) << 0);
float f0 = Float.intBitsToFloat(v);"

do it 2 or 3 times (2 for uv, 3 for vertex) and compute f0, f1 and/or f2

finally compute the vector with f0, f1 or f0,f1, f2

WHY: because Java handle float with special values (POSITIVE_INFINITY, NaN, etc.). When a loaded float leads to such a special value it becomes impossible to swap the bytes anymore. I found a 3ds model with vertices around x~=2200.0 and about 5% of the vertices were corrupted due to this problem.

I'm sorry I can't commit my fixes. I don't know git yet and I really don;t know if I will have time to jump into it in the near future.

BTW, I suggest the tempNormal made available as a global value of the Obj (line 427 of Loader3Ds.java). It is a normal per face (instead of the normals per vertex) and I find very usefull to be able to access such normals (and as far as they are already computed...)
Reply | Threaded
Open this post in threaded view
|

Re: jogl utils

Fred Vernier
I'm not sure either. I found so many bugs I don't believe the 3DSLoader ever worked for instance. On the other hands I wonder if this project wasn't started to test new feature before adding them in the main jogl repository. One of the things everyone like I think are the java objects to load textures. in jogl-utils you find an attempt to make java objects to map lights. IMO the 3DS Loader should have moved to a java object to manage display lists (or VBO), as well as the 3d font util.

For git even if I fork the repository on my computer how the other people will use my bug fixes then ?
Reply | Threaded
Open this post in threaded view
|

Re: jogl utils

Michael Bien
if you have an github account you can fork sven's repository on github by pressing the fork button:
http://github.com/sgothel/jogl-utils

now you can simply clone your very own jogl-utils repository and push/pull to it.
This makes it very easy to move changes between repositories... sven (or someone else) could just pull from your repo and he is done.

thats distributed versioning in a nutshell.
hope that helps,
regards,
michael


On 05/18/2010 11:43 AM, Fred Vernier [via jogamp] wrote:
I'm not sure either. I found so many bugs I don't believe the 3DSLoader ever worked for instance. On the other hands I wonder if this project wasn't started to test new feature before adding them in the main jogl repository. One of the things everyone like I think are the java objects to load textures. in jogl-utils you find an attempt to make java objects to map lights. IMO the 3DS Loader should have moved to a java object to manage display lists (or VBO), as well as the 3d font util.

For git even if I fork the repository on my computer how the other people will use my bug fixes then ?


View message @ http://jogamp.762907.n3.nabble.com/jogl-utils-tp819809p825822.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.