Skip to main content

FYI: JUniversal3D started. 3D Java API derived from Java 3D.

11 replies [Last post]
interactivemesh
Offline
Joined: 2006-06-07

Hi,

since analyzing the core engine of the current stable version 1.5.2 and implementing first adaptions I'm convinced that this API is a very pragmatical and efficient starting point to realize a highly competitive 3D API that will meet future requirements for 3D applications.

Hereby I would like to inform you about my intentions and activities concerning JUniversal3D.

The transition will go through several not downwards compatible development steps und will lead to version 2.0 which will provide long-term compatibility.

The current development is guided by the following mission and objectives:

Mission

Derive from the '3D Graphics API for the Java Platform'
a cross system Java and DirectX/OpenGL based
open source 3D scene graph API
to provide up-to-date native 3D capabilities for Java / JavaFX applications which target
professional, scientific, educational, and entertainment needs.

Objectives

1. Independent access to native 3D APIs and GPUs to benefit directly from system capabilities
2. Structure of core, advanced, and individual features that reduce internal complexity, minimize dependencies, and allow application specific packaging
3. Elimination of deprecated and as obsolete declared features
4. Release from Canvas3D and support of multiple render targets
5. Declaration and implementation of new features
6. Programming based on Java 5.0 language features
7. Open source for commercial and public use

To 1. Independent access to native 3D APIs and GPUs to benefit directly from system capabilities

In progress:

- JOGL pipeline removed
- Native pipeline DirectX Graphics / Direct3D 9
- Native pipeline OpenGL 2.1 (Linux / GLX, Windows / WGL)

Planned:

- Native pipeline DirectX Graphics / Direct3D 9, HLSL/Effects
- Native pipeline DirectX Graphics / Direct3D 10, Effects
- Native pipeline OpenGL 2.1 (Mac OS X / AGL)
- Native pipeline OpenGL 3.0 (Linux / GLX, Mac OS X / AGL, Windows / WGL)
- Nvidia Cg
- DirectX Audio
- OpenAL

To 2. Structure of core, advanced, and individual features that reduce internal complexity, minimize dependencies, and allow application specific packaging

Current structure

org.juniversal3d.*;
org.juniversal3d.geometry.*;
org.juniversal3d.gui.awt.*;
org.juniversal3d.gui.qtj.*;
org.juniversal3d.gui.swt.*;
org.juniversal3d.j3d.*;
org.juniversal3d.loaders.*;
org.juniversal3d.math.*;
org.juniversal3d.picking.*;

org.juniversal3d.j3d.* stands for several com.sun.j3d.utils-subpackages. These are already ported to this new namespace, but are still subject of redesign, adaption, renaming, and repackaging.

To 3. Elimination of deprecated and as obsolete declared features

In progress

- All deprecated packages, classes, methods, etc. removed
- HiResCoord in Locale removed
- Text3D/Font3D/FontExtrution removed (will be replaced by ShapeExtruder/String3D)
- Pure immediate mode, GraphicsContext3D removed
- Compilation, SharedGoup/BranchGoup.compile() removed
- com.sun.j3d.utils.geometry.compression.* removed
- com.sun.j3d.utils.scenegraph.* removed (if it will be replaced then based on XML)
- com.sun.j3d.utils.universe.* (SimpleUniverse etc.) removed

Planned

- OrientedShape3D, Billboard Behavior: to be replaced by a BillboardGroup

To 4. Release from Canvas3D and support of multiple render targets

In progress

- Canvas3D as the sole render target is replaced by an engine related base class ViewTarget and a public API related interface ViewSurface. Furthermore, a GUI platform has to provide access to the native window by implementing a subclass of DrawingSurfaceObject.

- ViewTarget/ViewSurface prototypes are realized for:
- JU3D internal: ImageComponent2D used in Background, Raster, Texture2D
- AWT/Swing: java.awt.Canvas (Canvas3D), javax.swing.JPanel (JCanvas3D), java.awt.image.BufferedImage
- Eclipse/SWT: org.eclipse.swt.widgets.Canvas
- Qt Jambi: com.trolltech.qt.gui.QWidget
- All these targets can be added simultaneously to a single View (new: Viewer)

- In consequence the input event handling is adapted: the engine now provides cross GUI platfom event handling based on WakeupOnGUIEvent, whereas for each GUI platform a specific subclass is implemented: WakeupOnAWTEvent, WakeupOnQtJEvent, WakeupOnSWTEvent

Planned

- Native 3D rendering to Texture2DNative
- Shadow mapping based on Texture2DNative and the new view rendering concept (see below)

To 5. Declaration and implementation of new features

In progress

- Each VirtualUniverse is now driven independently by its own MasterControl thread and its own set of further threads. Therefore sharing of NodeComponents across several VirtualUniverses and exchange of Nodes between them isn't supported anymore. Several VirtualUniverses inside a single application run on a common native 3D pipeline.

- All Node types can be added, inserted, moved, removed, and detached in a live scene. The BranchGroup dependency is obsolete.

- A BackgroundGroup is introduced as the root of the Background geometry.

- BranchGroup will be renamed as PickGroup and will operate only as the root of a pickable subscene.

Planned

- The Locale will be replaced by the VirtualSpace group as the top scene graph node and as the sole child type of the VirtualUniverse. It is open if VirtualSpace will keep the picking capabilities.

- View specific rendering will base on the scope feature as it is well known for Light, Fog, etc.. The default universal scope can be limited for each View object to individually selected Group nodes. In addition a scope can be terminated at each Group node below its root. ViewSpecificGroup will be removed.

- The viewing concept will be extended to layered view rendering. The Viewer class will be introduced. View objects are to be added as layers to a Viewer object. Their order determines which View is rendered on top of another View. ViewSurfaces (former Canvas3D, see above) are to be added to the Viewer object instead of to the View object. All layers/Views will be rendered into each added ViewSurface. In addition a viewport parameter will be introduced for Views to determine their drawing region. This allows an arbitrary layout of multiple Views inside a single ViewSurface. This concept combined with the scope feature will in principal not influence how a scene graph is to structure. Nodes (per SharedGroup) and NodeComponents are shareable across several layers respectively Views. It might be good practice to choose different VirtualSpaces for each layer.

- Shader attribute binding of JU3D attributes for programmable shader pipelines. Multipass rendering according to DirextX/Cg/Collada-effects for all native 3D APIs.

To 6. Programming based on Java 5.0 language features

In progress

- All collections are now typesafe.
- Visibility of classes, constructors, methods and fields is reduced to the minimum.
- All non API classes which are not subclassed are declared as final.

Planned

- Replacement of integer based symbolic constants by enums under consideration of native code access.

To 7. Open source for commercial and public use

- Classes of the derived work inside JUniversal3D are licensed under 'GPL2 + classpath exception' or BSD according to the classes they are derived from. New classes are licensed under 'GPL2 + classpath exception'.

- The use of some GUI related classes requires further open source or commercial licenses (e.g. SWT, Qt) depending on which packages are imported.

This overview doesn’t claim to be the best solution or to be complete, surely there´s room for improvement.

To those who would like to benefit from the JUniversal3D API in future: please provide your ideas how you can contribute personally or financially to determine and to push the development of this API.

You are very welcome to post your comments here or to send them to the author: juniversal3d at interactivemesh dot com.

All trademarks mentioned here are the property of their respective owners.

August Lammersdorf, InteractiveMesh e.K.

www.InteractiveMesh.com - www.InteractiveMesh.org

Kolomanstrasse 2a, 85737 Ismaning, Germany / Munich Area
Commercial register: district court Munich HRA 89887

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
interactivemesh
Offline
Joined: 2006-06-07

Hi,

let me again answer both of you, optimusprime1982 and Thierry.

[b]Marketing[/b]

Before answering how to join the forces the potential partners should be committed to common goals. So far, I haven't seen new alternative concepts about the future development. I'm sure this community is highly interested in further ideas.

I fear that naming a derived product similarly will create conflicts. If APIs are drifting into different directions and the former name is held by someone else the APIs should be distinguished by their own 'brand'. In consequence accompanying media (forum, sample, etc.) have to be set up separately.

[b]'ogl' pipeline - Apple[/b]

Even if OpenGL is a cross platform API, windowing system and operating sytem related 'entry points' are needed. They are called extensions, provided by the system supplier, and named as: AGL for Mac OS X, GLX for Linux, and WGL for Windows. So, the native pipeline has to implement its access for each extension individually. The code for OpenGL function calls can be shared.

Enabling the 'ogl' pipeline for Mac OS X requires to implement the AGL access in a similar manner as it is done for GLX and WGL. I can't remember the reason why JOGL was chosen instead.

DirectX Graphics is exclusively available on MS operating systems.

[b]Java Web Apps - JNLP based deployments[/b]

"Applets and Java Web Start applications are now referred to as Java Web Apps - Java programs that take advantage of the Web." (see JDK 6u10 doc)

Fortunately, I can't detect any principal restrictions if a third party is going to host signed Java packages and native libraries along with an identically signed JNLPAppletLauncher and the corresponding JNP-files. These features are designed for all of us not only for Sun.

But by setting and reading "not secure" system properties some problems might arise. Therefore, JUniversal3D is going to allow to set JU3D related properties also by a Map using a specific VirtualUniverse constructor.

The first call of 'new VirtualUniverse(Map properties)' will set general properties and instance properties, if defined. Further calls will only set VirtualUniverse instance properties. This Map can be created with fixed implemented name/value pairs or dynamically by reading the specified Applet-parameters or Application-arguments.

Please, post your concerns if my assumptions are not correct or something is missing.

August

optimusprime1982
Offline
Joined: 2007-11-24

hi august,

thank you for providing those links and statements.

i still think it would be a considerable point if you would think about renaming ;).
'java 3d now', 'j3d', 'java 3d 2.0' is not "java 3d"...

will you provide blogs, tutorials, wikis and so on? (such things are often under estimated)

i also would appreciate some response from the java 3d team.

best

interactivemesh
Offline
Joined: 2006-06-07

Hi optimusprime1982 and Thierry,

thanks for your replies. Please, let me answer both of you in this post.

[b]Java 3D <--> JUniversal3D[/b]

Since 1.5.2 the source code in the javax.media.j3d and javax.vecmath packages is released under the GPLv2 license with the CLASSPATH exception. For this open source version of the Java 3D API a new 'brand' was introduced: "3D Graphics API for the Java Platform".

As Java 3D is a trademark of Sun Microsystems your derived work and its binaries may not be called 'Java 3D'.

"... we want to make it clear that:
A) we are not giving away rights to use that name, and
B) the binaries built from these (possibly modified) sources are not "Java 3D" from Sun." (see link 3.)

So, there is no alternative as to name this work differently.

I initiated JUniversal3D on my own because I assume that Sun will not return to Java 3D starting release 2.0 and will favor the development of a JavaFX dependent 3D API. If Java 3D users do not see any perspectives now and if they fear that their Java and JavaFX applications will not benefit from DirectX 10/11, OpenGL 2.1/3.x, OpenCL, etc. they will drift off gradually.

[b]JOGL <--> ogl[/b]

Java 3D provides two redundant pipelines to access the OpenGL API: the original native pipeline 'ogl' and the 'wrapper' pipeline JOGL (since 1.5.0). The important feature of JOGL is its Mac OS X support. This platform isn't implemented for 'ogl' yet.

From my strategic and functional point of view a competetive higher level 3D API like Java3D/JUniversal3D should have its own direct access to native APIs and OSs to provide best services. They should not depend on another intermediate API.

Dropping JOGL needed only the removal of several classes and the adaption of a few lines of code. The 'ogl' pipeline isn´t affected and therefore fully intact.

[b]Corresponding forum links:[/b]

1. Java 3D Future Direction, 2007/05/15, http://forums.java.net/jive/thread.jspa?messageID=217418
2. ANNOUNCEMENT: Java 3D plans, 2008/02/07, http://forums.java.net/jive/thread.jspa?messageID=256435
3. ANNOUNCE: GPL open source release, 2008/02/28, http://forums.java.net/jive/thread.jspa?messageID=261477

A response from Sun would be appreciated.

August

tmilard
Offline
Joined: 2004-03-25

Hello InteractiveMesh, thank you for your precises answers.

> "... we want to make it clear that:
> A) we are not giving away rights to use that name,
> and
> B) the binaries built from these (possibly modified)
> sources are not "Java 3D" from Sun." (see link 3.)
>
> So, there is no alternative as to name this work
> differently.

> I initiated JUniversal3D on my own because I assume
> that Sun will not return to Java 3D starting release
> 2.0 and will favor the development of a JavaFX
> dependent 3D API. If Java 3D users do not see any
> perspectives now and if they fear that their Java and
> JavaFX applications will not benefit from DirectX
> 10/11, OpenGL 2.1/3.x, OpenCL, etc. they will drift
> off gradually.
===> This is very true. But before considering this eventuallity of Sun ... having no more internall ressources on java3d, perhaps why not considering working for java3D under their platform.
Question to you : Would it be a issue for you ?
Question to Sun : Would it be an issue for Sun java3D people to give you a sort of freedom to do all what you want to do ?
In overall I think Sun would gain from your skills and energy. And us java§D users also.
- Jst one small example but so usefull : When I JNLP package, I can can jnlp automatic dowlload. This is cool. If you leave Sun House this won't be possible I think.

> [b]JOGL <--> ogl[/b]
>
> Java 3D provides two redundant pipelines to access
> the OpenGL API: the original native pipeline 'ogl'
> and the 'wrapper' pipeline JOGL (since 1.5.0). The
> important feature of JOGL is its Mac OS X support.
> This platform isn't implemented for 'ogl' yet.
===> You mean that Apple is not OGL compliant ?
By the way Apple is DirectX compliant I suppose. Isn't it ?

> From my strategic and functional point of view a
> competetive higher level 3D API like
> Java3D/JUniversal3D should have its own direct access
> to native APIs and OSs to provide best services. They
> should not depend on another intermediate API.
===> As long as I do not get new rendering issues I do not mind.

Thanks Thierry

aces
Offline
Joined: 2003-07-17

Hi

about :

>Planned:
>
>- Native pipeline DirectX Graphics / Direct3D 9, HLSL/Effects
>- Native pipeline DirectX Graphics / Direct3D 10, Effects

There are some long and raged discussions about supporting DirectX10 and Vista only applications.
While Dx9 runs in all current Win OS (Win2K, XP, Vista), Dx10 only runs on Vista, and will be replaced by Dx11 on next OS.

I guess DirectX10 will loose terrain and die in a couple of years, while DirectX 9 will possible survive on next MS OS (Windows 7).

Links (From DirectX discussion List) - Interesting read, if you plan work with Dx10:

http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A2=DIRECTXDEV;ALj%...

http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A2=DIRECTXDEV;kok8...

tmilard
Offline
Joined: 2004-03-25

> >- Native pipeline DirectX Graphics / Direct3D 9,
> >- Native pipeline DirectX Graphics / Direct3D 10,

For me also, Direct3D 9 is largelly good. I do not need Direct10 because my main task is to have a portability Win/Mac/Linux

- By the way, since Sun people do not seem to answer, I say : go for it whatever the name ( think the name is really not the most important issue).

[b]BIG WISH : java3d import Collada and / or Sketchup objects [/b]
It would ne brillant to have the possibility to Import sketchup objects or Collada.
I can also help to program it ... but I need imputs and some explanations.
I think this is important for java3D, as I see more and more 3D objetcs come from google sketchup (they also have a "collada" outpup ).

Thierry

optimusprime1982
Offline
Joined: 2007-11-24

nice attempt, but why not call it Java3D 2.0?
watch it from a marketing perspective. Java3D is well known among 3D enthusiasts, and will not be seen as another 3D-framework which will disappear after a while. Maybe you can keep that in mind.
the step forward could be stated with the postfix 2.0.

just my 2 cents.

good luck with your project.

tmilard
Offline
Joined: 2004-03-25

As a java3D API user I forward any opportunity to "Upgrade" and modernise this cool 3D API.
So I will just say : Cool ! You look good and you sem to know your stuff.

Concerning JUniversal3D, I have a few questions :

- Why fork this java3D project. Is it really necessary ? Maybe Sun people would be cool enough to let you tweek their Open Source API. java3D but also yourself could perhaps benefit of a continuity.
No ? By the way if someone from Sun could give his honest though here, I would not be against it...

- You wrote you drop would drop JOGL. Why so ? JOGL is not maintained ? JOGL performance is not good ? I don't get it, I don't think java3D has a bad rendering performance.
I am agraid changing this core thing might be dangerous.... I do not want to go back to one alpha version. We all know an api or software like this takes years to stabelise and have few bugs. Which is the case now for java3D. Why destroy things that are working fine ?

To finish my personnal wishes :
- Having a simple API to modify the visual aspect of the final rendering; Color change, blur, ect...
- Quicker loading if you have a lot images textures. It takes 20 seconds in my application.... I wish it could take 3 seconds. I don't know if it is possible but this is my main wish : A quick display of the 3D scene.

Thierry , Free-visit.com

weiland
Offline
Joined: 2005-08-05

August,

I certainly welcome someone stepping up and taking Java3D forward. You're not taking on an easy task.

Questions:
- Are you intending to take the general cleanup to the level of adding some interfaces?
- Moving to Java 5 -> removing Enumeration in favor of Iterators?
- Doing anything different with the capabilities and compilation model (which I suspect is hard to get right in most cases)?
- Can layered rendering take care of the float resolution problem that Locale attempted to address? (I think it might be usable for at least some of those cases).
- Any ideas about how you will run your development process (in terms of design evolution - out in the open, commit privileges, etc)? Also, I hope you will consider hg or git instead of svn.

Good luck!

Bill

interactivemesh
Offline
Joined: 2006-06-07

Bill,

thanks for your inspiring questions.

[b]- Interfaces[/b]

One point of view is: How can all data types that are part of the rendering system (SuperStructure, SceneGraph, Viewing) be covered by an interface hierarchy? A typical benefit would be the integration of classes which are not part of the API. A first sample is the ViewSurface interface that allows to add arbritary render targets to a Viewer object. Furthermore, some of the abstract classes of the scene graph may be canditates for interface types (SceneGrpahObject, Node, NodeComponent, Leaf, Group, Behavior). Of course, the API would provide a base implementation for all existing subclasses. Marker interfaces like ShareableNode or BackgroundNode are worth considering.

What are your ideas?

[b]- Java 5: Enumeration -> Iterator[/b]

That wasn't on my list yet. Now it is.

Further suggestions?

[b]- Capabilities / compilation model[/b]

I expect that in future releases the implementation of an effective compilation feature in the sense of performance improvement will be more complex. Therefore, the engine should provide best build-in performance and the application should take care of sharing NodeComponents and a streamlined scene graph.

So capabilites will still be part of the API (e.g. the mirror object model relies on them). As an application programmer I wouldn't really miss them, but the engine does benefit from them.

[b]- Layered/view specific rendering as substitution for Locale[/b]

A Viewer will allow to enable each of the added layers/Views individually. Only enabled layers will be rendered. Enabling just one at a time would let you jump from 'Locale' to 'Locale'.

[b]- Development process[/b]

This should be discussed as soon as a core team has been settled.

August

zesharp
Offline
Joined: 2006-12-21

> Enumeration -> Iterator

Just a reminder : on Lists, the traditional for loop with integer index is faster and use less memory.

the forEach loop is a erasure feature, and the resulting byte codes are the same for tradiodional

[code]

List list = new ArrayList();

// forEach as typed
for(Object obj : list){
}

// above forEach results in below code
for(Iterator iterator = list.iterator(); iterator.hasNext(); ) {
Object obj= iterator.next();
}

// but this one is better

for(int i = 0 ; i < list.size(); i++){
Object obj = list.get(i);
}

[/code]