Java3d not totally dead

Engines, Libraries and Tools Java 3D
#1

I’ve mirrored the Java3d svn repos to github and started updating it assuming Java6
as a feature baseline. For now all that I’ve added is a lot of generics annotations.

But I’ve fixed to races that I hit in practice on larger core-count machines and cut the
memory use of the Bounding regions in half.

If anyone has any patches they’ve been carrying, I’d be more than happy to take them.

I maintain an engineering application that requires Java3d, so I’ll likely be maintaining this for the
foreseeable future.

Cheers,

Harvey Harrison harvey.harrison@gmail.com harvey.harrison@ausencosandwell.com

#2

Oh wow, this is probably the biggest thing to happen to Java3D in like…6 years?

#3

I wish you the best of luck.
I also recommend that you have a hammer and large wooden stake ready just in case Justin Couch shows up.

#4

Good to see someone patching up Java3D. We might have some fixes laying around. We had to resort to forking Java3D as well as some of our fixed didn’t get approved and checked in. For example http://java.net/jira/browse/JAVA3D-608. Although the best way to fix this bug would be to use a ThreadLocal. But I didn’t know at the time.

#5

Do you plan to switch to JOGL 2.0? Java3D still uses JOGL 1 whereas this version is no more maintained. Best regards. Good luck.

#6

Thanks for the pointer, I’ll have a look. In our application we write all the scenegraph changes from
a Behavior, so haven’t run into those exceptions.

In all seriousness, I will give a good long look at any and all patches you have laying around for
Java3d that are even remotely reasonable. Please feel free to e-mail them to me. At very least
I would create a holding branch on that github mirror to make them more visible to others.

Harvey

#7

Thank you very much, Hharrison. This is good news.

I always liked Java3D and it’s very useful for many projects. It would be a shame in case it died.

#8

Great!
I am writing a game with Java 3d V 1.5.2 at the moment and i experienced some problems with the “picking” stuff.

#9

What problem? I know of one bug where pickfast will bleed outside the specified branchgroup when picking.

#10

You have any more info to offer about the pickfast behavior? If it’s something with a small
testcase, or even a decent description I might have a look. I just spent some time cutting the
memory use of the Bounding region calculations in half, and at least was looking at the picking
code while doing so…thoughts?

Harvey

#11

I can try to make a test case. Do not remember how reproducible it was. The ease fix was to use the “old/slow” picking instead.

#12

I had the issue that picking via a PickCone with multiple objects in the Cone and then trying to get all hits delivered me a ArrayIndexOutOfBoundsException.
I don’t have a small example for that issue and not even the big code of my game because i changed the way i checked if i have targets in a 90 degree area (not a cone any more) via good old angle mathematics and the stored positions of the gangers (=targets).

#13

Well, if you have any of the backtraces still laying around, maybe that would be enough. Feel free to
post them if you have any (Assuming Java3d 1.5.2?)

Harvey

#14

Hi

I thank Harvey, Gabi and all the persons who drives it possible. I have ported Java 3D to JOGL 2.0:
http://forum.jogamp.org/Java3D-now-works-with-JOGL-2-0-td3732206.html

Let’s have fun. I will be actively maintained anew. I will make a small demo next week if I have enough spare time.