Skip to main content

petition for java3d in the next java release

46 replies [Last post]
optimusprime1982
Offline
Joined: 2007-11-24
Points: 0

yes ... the title already says it. i think java3d was one the best inventions of sun (much better den JOGL, i need easy and fast developing ^^). unfortunately it's not supported anymore. in javafx there will be 3d support, but only with reduced abilities. so why this regression? the jdk is growing and growing, why not even integrate java 3d? downloading it manually or over jnlpappletlauncher is really annoying.

where can i apply for integration of java3d in future releases? i already know a page where you can "vote" for which improvements should be added in future releases(OpenCms). is there something similar in java? i would appreciate any support. if i know where to do it, i would start the petition and if you want so you can join.

best wishes

PS:maybe put it sticky, so others can see...

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
aces
Offline
Joined: 2003-07-17
Points: 0

JMonkey uses LWGL [i] "with plans for JOGL support in the near future." [/i]

On LWGL project there is a *frozen* D3D pipeline project.

David Grace

Hi,

Can anyone tell me if the jMonkeyEngine is ever going to have a DirectX
port?

Without it, it really is not a replacement for Java3D since it will not run
on half of the world's computers.

Dave.

--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.
http://www.mailguard.com.au/mg

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Alan Hudson

David Grace wrote:
> Hi,
>
> Can anyone tell me if the jMonkeyEngine is ever going to have a DirectX
> port?
>
> Without it, it really is not a replacement for Java3D since it will not run
> on half of the world's computers.
>
You do know that OpenGL runs on all computers including Windows? We've
never had a problem running the OpenGL version of Java3D on lots of
machines. Certainly some machines are more optimized for DirectX but in
general they run the same.

--
Alan Hudson

President Yumetech, Inc. www.yumetech.com
President Web3D Consortium www.web3d.org
206 340 8900

Open Source CAN be free, as in "free puppy"

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

ofh
Offline
Joined: 2003-06-10
Points: 0

In our customer-world, OpenGL is absolutely no alternative. I really don't like this fact, but it is the reality.

jada
Offline
Joined: 2004-03-17
Points: 0

To share some data on why Direct3D pipe is needed for SG3D (same for Java 3D) :

a) Starting with Java SE 6U10 the default 2D graphics pipeline on Windows in Direct3D.

b) Most graphics hardware vendors deliver better Direct3D driver than OpenGL driver.

c) Windows Vista prefers Direct3D than OpenGL.

- Chien

kcr
Offline
Joined: 2004-03-17
Points: 0

To follow up on Chien's point (a): for SG3D we plan a tighter integration with 2D, meaning that we need to use the same pipe that they do. By default, this means D3D on Windows.

-- Kevin

elix
Offline
Joined: 2006-09-14
Points: 0

>It is always good to have 2 or 3 or even 4 options for 3D APIs on java langage.

May be but splitting the power of comunity may not be so beneficial because of the weakness of java in 3d compared to c/c++.

> Please do not forget 3D is 97% or 99% C++ up to now :
>
> ==> Perhaps you should stay calme and your anger
> elsewhere please. It reminds me of two twin brothers
> always angry against each other ... but finally they
> so look alike !
> Please do blade C++ nice 3D APIs competition. Not the
> other java 3D API on the market.
>
> Another thing :
> I might try in the future JMonkey (or others API) .
> But the lound noice on this forum about project
> wonderland changing its 3D API is really not fair
> from my point of Vue. Personnally I do not see any
> kind of future for this Wonderland project. I think
> it looks less good then competition identical project
> (again all in C++).
> Frankly this wonderland project can switch 3D API
> just like a lady is changing TShirt : It doesnt not
> make the lady more or less beautiffull or ugly.
> Maybe you think because some persons from Wonderland
> project are salary men from Sun it will be one
> enormous publicity for JMonkey. Maybe. Sweet of you.
> Please choose a cool and nice project next time for
> this purpose.

I like the way of thinking at this part of your post.

You may be pleased if you don't postpone to try jmonkey.

> c) Performance and stability of java3D is good. I
> experience it : It is good. Honest.

May be I am not experienced in 3d but still I can't agree with you on this point.

David Grace

Hi,

Adding JOGL to the JRE wouldn't create much bloat at all. The JRE already
uses OpenGL for rendering, it is just the Java programmer can't access the
calls to OpenGL because they aren't wrapped by JOGL. Also the native code is
OpenGL, which is already on the users computer, JOGL just adds Java calls to
these already existing native libraries.

I just wish people would look at this from a software engineering
perspective. The solution for Java is to write API's that wrap native API's,
then write API's that unite these API which are similar (if not almost
identical) on the different platform that the JRE will run on.

This would mean putting JOGL and a DirectX wrapping API in the JRE for
rendering to the screen. Then Java2D wraps these APIs for 2D rendering and
Java3D (whether it is the current Java3D or not) wraps these APIs for 3D
rendering.

The same goes for sound, there should be an API wrapping OpenAL (JOAL) and
API's wrapping each platform specific sound rendering API. Then there should
be JavaSound which wraps these APIs.

The same goes for input devices (mouse, keyboard, joystick etc). There
should be an API wrapping DirectInput and API's wrapping each platform
specific input API. Then there should be JInput which wraps these APIs.

The same goes for all hardware/services that the OSes provide access to.

It is simply applying divide and conquer to the problem to be solved. If
there is a better approach/solution I would love to hear it.

Dave.

-----Original Message-----
From: java3d-interest@javadesktop.org
[mailto:java3d-interest@javadesktop.org]
Sent: Thursday, May 29, 2008 4:02 AM
To: interest@java3d.dev.java.net
Subject: Re: petition for java3d in the next java release

There was a good reason Sun decided to abandon Java3D: It was really a
pretty awful 3D engine. That is not to say they necessarily learned from the
mistake as they are doing pretty much the same thing over again in JavaFX.
That said, integration of JOGL or LWJGL could be a great thing in the JRE,
but I also agree that there's already too much bloat in the JRE without
adding more crap to it. On the other hand having an OpenGL implementation
budled in the JRE would mean no native includes need to be handled and you
can simply write Java code to integrate with it.

Sun has begun relying on jMonkeyEngine (http://www.jmonkeyengine.com) for
the majority of their current 3D work (apart from JavaFX...which I think is
evil in many ways apart from this discussion). See Project Wonderland for
example. I would suggest taking a look at this engine as it is more
complete and more powerful than Java3D ever was or ever could be in the
paradigm they designed.

Please forgive any hurt feelings my blunt statements may have caused. ;)
[Message sent by forum member 'sunsett' (sunsett)]

http://forums.java.net/jive/thread.jspa?messageID=277065

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content
filtering.
http://www.mailguard.com.au/mg

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> I just wish people would look at this from a software
> engineering
> perspective. The solution for Java is to write API's
> that wrap native API's,
> then write API's that unite these API which are
> similar (if not almost
> identical) on the different platform that the JRE
> will run on.
>
> This would mean putting JOGL and a DirectX wrapping
> API in the JRE for
> rendering to the screen. Then Java2D wraps these APIs
> for 2D rendering and
> Java3D (whether it is the current Java3D or not)
> wraps these APIs for 3D
> rendering.
>
> The same goes for sound, there should be an API
> wrapping OpenAL (JOAL) and
> API's wrapping each platform specific sound rendering
> API. Then there should
> be JavaSound which wraps these APIs.
>
> The same goes for input devices (mouse, keyboard,
> joystick etc). There
> should be an API wrapping DirectInput and API's
> wrapping each platform
> specific input API. Then there should be JInput which
> wraps these APIs.
>
> The same goes for all hardware/services that the OSes
> provide access to.
>
> It is simply applying divide and conquer to the
> problem to be solved. If
> there is a better approach/solution I would love to
> hear it.

I have nothing against JOGL but you can't simply add an OpenGL or DirectX API into the JRE. One obvious problem is that not all platforms support DirectX and (less so) OpenGL. Secondly, if JOGL is a one-to-one mapping between C and Java code why not integrate something like JNIEasy or some other JNI library that lets you invoke C/C++ code from Java without building any wrappers at all?

David Grace

Hi,

I believe JOGL was created by running Gluegen over the OpenGL API. So it is
essentially exactly what you are talking about. The same is true for JOAL.
Really the only difference is you get javadocs the Gluegen way.

Also, all the JNI calls to OpenGL are already in the JRE in the OpenGL
rendering pipeline (The same is true for DirectX and the DirectX rendering
pipeline).

As I understand, the same was true for Java3D until all the JNI calls to
OpenGL were mapped to the corresponding calls in JOGL.

I am not saying add JOGL OR a wrapper for DirectX into the API, I am saying
add both. I am also saying that both already exist in the JRE, they are just
not public APIs. And there is no reason not to. It won't bloat the Java
codebase or the JRE, there will be no more native code and just more
classes/functions made public which are now private.

The problem is there is an OpenGL wrapper hidden in the JRE, there was an
OpenGL wrapper hidden inside Java3D, and there is JOGL which is a basically
a public version of the same. Lets just use JOGL for all these cases and
stop duplicating code for no reason whatsoever. This will simplify the
codebase of all these APIs and the JRE, it will result in them working
seamlessly together, reduce duplication of code, and also divide the tasks
into smaller more manageable components for development in the future. And
almost certainly reduce bloat.

I still say there is no reason not to go down the path I described in my
previous email (for rendering 2D/3D, sound, input etc). And it is a huge
waste of time and resources not to, not to mention a recipe for bugs and
incompatibilities.

As I said in my last email, it is simply applying divide and conquer to the
problem to be solved, if there is a better approach/solution I would love to
hear it.

Dave.

-----Original Message-----
From: java3d-interest@javadesktop.org
[mailto:java3d-interest@javadesktop.org]
Sent: Thursday, May 29, 2008 11:29 AM
To: interest@java3d.dev.java.net
Subject: Re: RE: petition for java3d in the next java release

> I just wish people would look at this from a software
> engineering
> perspective. The solution for Java is to write API's
> that wrap native API's,
> then write API's that unite these API which are
> similar (if not almost
> identical) on the different platform that the JRE
> will run on.
>
> This would mean putting JOGL and a DirectX wrapping
> API in the JRE for
> rendering to the screen. Then Java2D wraps these APIs
> for 2D rendering and
> Java3D (whether it is the current Java3D or not)
> wraps these APIs for 3D
> rendering.
>
> The same goes for sound, there should be an API
> wrapping OpenAL (JOAL) and
> API's wrapping each platform specific sound rendering
> API. Then there should
> be JavaSound which wraps these APIs.
>
> The same goes for input devices (mouse, keyboard,
> joystick etc). There
> should be an API wrapping DirectInput and API's
> wrapping each platform
> specific input API. Then there should be JInput which
> wraps these APIs.
>
> The same goes for all hardware/services that the OSes
> provide access to.
>
> It is simply applying divide and conquer to the
> problem to be solved. If
> there is a better approach/solution I would love to
> hear it.

I have nothing against JOGL but you can't simply add an OpenGL or DirectX
API into the JRE. One obvious problem is that not all platforms support
DirectX and (less so) OpenGL. Secondly, if JOGL is a one-to-one mapping
between C and Java code why not integrate something like JNIEasy or some
other JNI library that lets you invoke C/C++ code from Java without building
any wrappers at all?
[Message sent by forum member 'cowwoc' (cowwoc)]

http://forums.java.net/jive/thread.jspa?messageID=277152

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content
filtering.
http://www.mailguard.com.au/mg

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

lamer77
Offline
Joined: 2006-12-22
Points: 0

There is a difference between a OpenGL binding and using OpenGL. A binding provides a 1:1 mapping of the native calls to java. Java3D directx and opengl (not jogl) pipeline do not use a binding. They use custom JNI calls to c code. The c code uses directx/opengl. I'm pretty sure Java2D does the same thing, and that there is no hidden directx and opengl binding in the jre.

David Grace

Hi,

I understand there is a difference between the JOGL 'bindings' making calls
to 'bind' to OpenGL using JNI and code in the JRE making 'custom/private'
calls to 'bind' to OpenGL using JNI without using these bindings.

I guess what is really important:

'Would there be a performance penalty in using the JOGL bindings or is it
two ways of achieving the exact same result?'

'Is the JOGL version of Java3D slower than the 'custom' OpenGL version of
Java3D?'

Dave.

-----Original Message-----
From: java3d-interest@javadesktop.org
[mailto:java3d-interest@javadesktop.org]
Sent: Thursday, May 29, 2008 4:52 PM
To: interest@java3d.dev.java.net
Subject: Re: RE: RE: petition for java3d in the next java release

There is a difference between a OpenGL binding and using OpenGL. A binding
provides a 1:1 mapping of the native calls to java. Java3D directx and
opengl (not jogl) pipeline do not use a binding. They use custom JNI calls
to c code. The c code uses directx/opengl. I'm pretty sure Java2D does the
same thing, and that there is no hidden directx and opengl binding in the
jre.
[Message sent by forum member 'lamer77' (lamer77)]

http://forums.java.net/jive/thread.jspa?messageID=277175

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content
filtering.
http://www.mailguard.com.au/mg

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

tmilard
Offline
Joined: 2004-03-25
Points: 0

> I understand there is a difference between the JOGL
> 'bindings' making calls
> to 'bind' to OpenGL using JNI and code in the JRE
> making 'custom/private'
> calls to 'bind' to OpenGL using JNI without using
> these bindings.
>
> I guess what is really important:
>
> 'Would there be a performance penalty in using the
> JOGL bindings or is it
> two ways of achieving the exact same result?'
>
> 'Is the JOGL version of Java3D slower than the
> 'custom' OpenGL version of
> Java3D?'

===> Hello David,
I would not add anything to this excellent discution because my technical knowledge on JNI call is ... level zero. I learned a few things here.
I also like this simple idea of David to just unify all 3D calls ( OpenGl ot DirectX) from java plateform to a unique JOGL API use.
On the performance issue I am pretty sure that when java3D made the transition
from direct OpenGl call to JOGL calls ... performance was identical or better : no degradation at all.

But maybe one or 2 technicall person from Sun could give us their thoughts on this.
As this is One importance issue : simplifying 3D programming on java platform.

Thierry

stylertim
Offline
Joined: 2006-05-04
Points: 0

Plus JOGL is a real low-level 3D graphics API. This would more appropriately complement the 2D functionality already provided and even extend the 2D facilities if a hardware accelerated, yet direct implementation is desired. If you add JOAL to the mix you got everything you need (well, except physics...). :)

IMHO the real problem with an inclusion of Java3D into the JRE would be the fact, that its development will be halted in favor of the new scenegraph currently in development. This means no further improvements until annouced otherwise which is a major concern in an area that's changing as quickly as computer graphics. In addition the guys at Sun have already pointed out that some major parts of the J3D implementation aren't as efficient as they should be and would need a general overhaul. JOGL on the other hand will (hopefully) adapt to every current OpenGL specification and most newly added vendor extensions and therefore never come out of style...as long as the Kronos group sees the need to improve the OpenGL specification. And the caps that already exist in OpenGL 2.1 simply work and are stable - as mentioned by aces before.

Sure, a scenegraph is nice, easy and clean but let's face it: a lot of people use Java3D for projects that could also easily and quickly be developed with a low-level API. (I'm talking small and simple stuff like the very common solar system!). And the OpenGL learning curve definitly is not as flat as many people fear before they touch the API. If you gathered some skills you can even write a little scenegraph yourself. (Don't get me wrong, I still love J3D...). :)

In short: Java3D may not be the best choice for an inclusion in the JRE.

- Thomas

ofh
Offline
Joined: 2003-06-10
Points: 0

> like Corba which no one is using.

Hey man, I use CORBA very often because there is no easier client server programming technique. And yes, currently together with Java3D!

;o)

sunsett
Offline
Joined: 2004-04-07
Points: 0

There was a good reason Sun decided to abandon Java3D: It was really a pretty awful 3D engine. That is not to say they necessarily learned from the mistake as they are doing pretty much the same thing over again in JavaFX. That said, integration of JOGL or LWJGL could be a great thing in the JRE, but I also agree that there's already too much bloat in the JRE without adding more crap to it. On the other hand having an OpenGL implementation budled in the JRE would mean no native includes need to be handled and you can simply write Java code to integrate with it.

Sun has begun relying on jMonkeyEngine (http://www.jmonkeyengine.com) for the majority of their current 3D work (apart from JavaFX...which I think is evil in many ways apart from this discussion). See Project Wonderland for example. I would suggest taking a look at this engine as it is more complete and more powerful than Java3D ever was or ever could be in the paradigm they designed.

Please forgive any hurt feelings my blunt statements may have caused. ;)

tmilard
Offline
Joined: 2004-03-25
Points: 0

> There was a good reason Sun decided to abandon
> Java3D: It was really a pretty awful 3D engine.
.....
> Sun has begun relying on jMonkeyEngine
> (http://www.jmonkeyengine.com) for the majority of
> their current 3D work (apart from JavaFX...which I
> think is evil in many ways apart from this
> discussion). See Project Wonderland for example. I
> would suggest taking a look at this engine as it is
> more complete and more powerful than Java3D ever was
> or ever could be in the paradigm they designed.

It is always good to have 2 or 3 or even 4 options for 3D APIs on java langage.
I do not think, as a "pro java" developper, that it is of any good to just shout (and shoot ) against each other's API.
Please do not forget 3D is 97% or 99% C++ up to now :
==> Perhaps you should stay calme and your anger elsewhere please. It reminds me of two twin brothers always angry against each other ... but finally they so look alike !
Please do blade C++ nice 3D APIs competition. Not the other java 3D API on the market.

Another thing :
I might try in the future JMonkey (or others API) . But the lound noice on this forum about project wonderland changing its 3D API is really not fair from my point of Vue. Personnally I do not see any kind of future for this Wonderland project. I think it looks less good then competition identical project (again all in C++).
Frankly this wonderland project can switch 3D API just like a lady is changing TShirt : It doesnt not make the lady more or less beautiffull or ugly.
Maybe you think because some persons from Wonderland project are salary men from Sun it will be one enormous publicity for JMonkey. Maybe. Sweet of you.
Please choose a cool and nice project next time for this purpose.

Back to main issue :
a) 3D is here to stay on java platform : I have seen 2 compnies looking for java3D skills. First time in 3 years. It is a good sign.
b) 3Ds API issues relly on a good part on the install-executing issues of the [u]jre[/u]. This will hopefully be fixed. If this is not fixed anyway java platform is just dead on the client side (Rich Web )

c) Performance and stability of java3D is good. I experience it : It is good. Honest.

Thierry

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> b) 3Ds API issues relly on a good part on the
> install-executing issues of the [u]jre[/u]. This will
> hopefully be fixed. If this is not fixed anyway java
> platform is just dead on the client side (Rich Web )

Give me a break. Today you're saying that Java is "dead" if Java3D is not bundled with the JRE, tomorrow it's closures. I think you guys are being just a bit melodramatic here.

You're complaining about Java3D deployment problems. One way to solve that is to bundle Java3D with the JRE, but it is hardly the only (or best) way. Secondly, I hardly believe that the majority of client-side applications use 3D nowadays. In fact, I would say the vast majority do *not* unless you're talking about video games.

aces
Offline
Joined: 2003-07-17
Points: 0

It may sounds strange, but I would like to see JOGL on JRE. As JOGL may change each 2 or 3 years, it is stable enough to be bundled on JRE, I guess.

This would simplified Java3D deployment, as it won't require extra "native libs".
In another words, Java3D could become a "pure java" API !!! :D Almost ;)

Of course, I'm not counting that Intel vcards (~50% market share) are very bad OpenGL players and Java3D may need to use the DirectX D3D pipeline on those cards...
So maybe in the future.

And I don't like to see Java3D tied to specific JRE. Updates/new releases would be a nightmare!!!

jeeky
Offline
Joined: 2003-06-15
Points: 0

I would support inclusion of the JSR231 JOGL binding, but not any higher level API. JOGL could be used in a large number of desktop APIs (Java2D, Java3D, JMonkey, etc.) to provide hardware accelerated graphics. This would make it easy for developers to use their favorite higher level APIs without having to deal with the burden of figuring out native library deployment for different platforms.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Native DLLs don't compress or split well. What I mean by that is that if you wanted to exclude the majority of a native library from the Kernel installer or make the majority otherwise optional it would take a lot of work. Pure-Java libraries are far easier to split, compress and run automated dependency-analysis on. For example, I can run Proguard to strip out any Java code not used by a specific program, but I can't do the same for native code.

Just keep this in mind. The less native code in the JRE, the better. If you absolutely *have* to do it then fine, but avoid it if you can.

optimusprime1982
Offline
Joined: 2007-11-24
Points: 0

>>Can you honestly say that the vast majority of JRE users will use Java3D? I think not.
no. but manual installations is a barrier for sure. i know many examples of writing own 3d engines in java to get rid of this problem.

it's likely that a very lightweight 3d component will win the race and also will be "bundled" ...

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> >>Can you honestly say that the vast majority of JRE
> users will use Java3D? I think not.
> no. but manual installations is a barrier for sure. i
> know many examples of writing own 3d engines in java
> to get rid of this problem.
>
> it's likely that a very lightweight 3d component will
> win the race and also will be "bundled" ...

I think we are far better off improving deployment problems because in the grand scheme of things there are many 3rd-party modules that desktop applications need/want to install and we can't possibly bundle them all with the JRE. If we work on improving deployment it might take longer in the short term but in the longer term we'd be far better off. Just my 2 cents.

That said, I think Sun is doing a great job in the update 10 release. If the Kernel JRE were to allow truly-optional modules (as opposed to downloading them in the background) then it would likely solve this problem.

optimusprime1982
Offline
Joined: 2007-11-24
Points: 0

hmmm ... i don't get the point.
will future releases of java maybe provide automatic download on demand in background.
the jarsigningdialog dialog for my 3dapplets is really annoying. ;(

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> the jarsigningdialog dialog for my 3dapplets is
> really annoying. ;(

I don't think there is a simple answer to that. It may be "annoying" but consider the alternative.

Even Microsoft prompts you when you run Windows Update the first time, asking you if you trust a certificate signed by them. The alternative would allow malicious Java code to wreck havoc with user's computers.

With respect to Java3D specifically, if it were signed using the same certificate as the JRE and that certificate was accepted by default then the prompting would go away. The same can't be said for other 3rd-party modules.

If you have a better solution in mind please suggest it because a lot of people have been complaining about this for years but honestly I haven't heard of a workable alternative (and yes, I'd like to see this improved too!).

David Grace

Hi all,

I really hope that Java3D will be included in the JRE in the future.

The whole point of Java is that it is platform independent. This is far
easier to achieve if you are not directly coding to an OS specific library.

For 2D graphics Java2D is written on top of OpenGL and DirectX (etc) and
then everything 2D is written on top of Java2D.

The same should be true for 3D graphics. There should be a Java layer
(Java3D) written on top on OpenGL and DirectX and then everything 3D is
written on top of Java3D.

It really is that simple. Any other long term solution for Java is crazy.

Dave.

-----Original Message-----
From: java3d-interest@javadesktop.org
[mailto:java3d-interest@javadesktop.org]
Sent: Wednesday, May 28, 2008 12:26 AM
To: interest@java3d.dev.java.net
Subject: Re: petition for java3d in the next java release

> the jarsigningdialog dialog for my 3dapplets is
> really annoying. ;(

I don't think there is a simple answer to that. It may be "annoying" but
consider the alternative.

Even Microsoft prompts you when you run Windows Update the first time,
asking you if you trust a certificate signed by them. The alternative would
allow malicious Java code to wreck havoc with user's computers.

With respect to Java3D specifically, if it were signed using the same
certificate as the JRE and that certificate was accepted by default then the
prompting would go away. The same can't be said for other 3rd-party modules.

If you have a better solution in mind please suggest it because a lot of
people have been complaining about this for years but honestly I haven't
heard of a workable alternative (and yes, I'd like to see this improved
too!).
[Message sent by forum member 'cowwoc' (cowwoc)]

http://forums.java.net/jive/thread.jspa?messageID=276757

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content
filtering.
http://www.mailguard.com.au/mg

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> Hi all,
>
> I really hope that Java3D will be included in the JRE
> in the future.
> [...]
> The same should be true for 3D graphics. There should
> be a Java layer
> (Java3D) written on top on OpenGL and DirectX and
> then everything 3D is
> written on top of Java3D.
>
> It really is that simple. Any other long term
> solution for Java is crazy.

Dave,

I don't think you can do this purely from a practical point of view. You can't add anything into the JDK until it's a solved problem. 2D APIs are mostly a well-understood solved problem. The same can't be said about 3D APIs. Furthermore I would argue that just because something is added into the JDK doesn't magically make it portable. The vast majority of 3D libraries are native code under the hood. The vast majority of 2D libraries, on the other hand, are mostly pure Java under the hood.

David Grace

Hi,

I was under the impression 2D rendering was done by OpenGL or DirectX (or
some other platform specific API) under the hoods.

My point was that Java2D removes the programmer from having to be concerned
with OpenGL or DirectX or any other OS specific code. You just write Java2D
code and the JRE does the platform specific stuff under the hoods.

This of course makes it much easier to port Java to other/new platforms
because you only have to implement Java2D to the new platform and all
programs written for Java2D work (thus making them portable).

The same follows for Java3D. There should be a Java layer above OpenGL and
DirectX (and any other OS specific 3D library) so programmers can program in
Java for 3D applications and let the JRE do the platform specific stuff
under the hoods. The fact is Java3D already does this pretty well, if not
very well.

I just think people make it more complicated that it really is. Microsoft
has DirectX, the other platforms have OpenGL. There should be a Java layer
over OpenGL (JOGL), and there should be a Java layer over DirectX (I don't
know if this exists? JDirectX?) and both Java2D and Java3D should be written
on top of those. If a new platform is to be supported (say for PS3) then a
layer should be written for the PS3, and Java2D and Java3D implemented on
top of that layer. Then all existing programs will run on this new platform.

In the long run it could (and should) be that simple.

Dave.

-----Original Message-----
From: java3d-interest@javadesktop.org
[mailto:java3d-interest@javadesktop.org]
Sent: Wednesday, May 28, 2008 9:15 AM
To: interest@java3d.dev.java.net
Subject: Re: RE: petition for java3d in the next java release

> Hi all,
>
> I really hope that Java3D will be included in the JRE
> in the future.
> [...]
> The same should be true for 3D graphics. There should
> be a Java layer
> (Java3D) written on top on OpenGL and DirectX and
> then everything 3D is
> written on top of Java3D.
>
> It really is that simple. Any other long term
> solution for Java is crazy.

Dave,

I don't think you can do this purely from a practical point of view. You
can't add anything into the JDK until it's a solved problem. 2D APIs are
mostly a well-understood solved problem. The same can't be said about 3D
APIs. Furthermore I would argue that just because something is added into
the JDK doesn't magically make it portable. The vast majority of 3D
libraries are native code under the hood. The vast majority of 2D libraries,
on the other hand, are mostly pure Java under the hood.
[Message sent by forum member 'cowwoc' (cowwoc)]

http://forums.java.net/jive/thread.jspa?messageID=276896

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content
filtering.
http://www.mailguard.com.au/mg

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

swpalmer
Online
Joined: 2003-06-10
Points: 0

Don't forget that OpenGL is already a cross-platform API for 3D graphics... so bindings to it are just as cross-platform. There isn't really a need to invent yet another cross-platform API on top of it.

That Java3D should be implemented via JOGL for the OpenGL back-end is a no-brainer. And to keep the API generic as well as provide better performance on Windows (where Microsoft is not letting OpenGL compete fairly) it makes sense to maintain the Direct 3D back-end too. But a full 3D scene graph API is not yet justified in the base JRE. As long as it is easily referenced with the JNLP extension mechanism and can be included by developers with their application when the need it, that should be enough for now.

bilal_el_uneis
Offline
Joined: 2006-12-10
Points: 0

http://graphics.im.ntu.edu.tw/~robin/jGL/

This api is written in pure java.

jada
Offline
Joined: 2004-03-17
Points: 0

I guess the question worth asking is how difference should the scene graph APIs for 2D and 3D, from the same company, has to be.

Project Scene Graph : https://scenegraph.dev.java.net/

Should a Java developer requires to learn 2 very different APIs for 2D and 3D tasks ?
If the long term answer is no, then it's maybe the time to jump on the JavaFX Runtime train.
We might also solve our long standing deployment issue too!

- Chien

t.milard@free.fr

Hello chien.
JavaFx poses for me one big issue : It is not compiled in java.
It doesn't generate bytecode yet (I know there is a project working on this).

So (I think) the deployement issues and hot-and-cool JVM start execution time
Sun is [my god at last] resolving is on ONE step is really looks BADLY in
opposition to this long new execution layer of javaFx.

Maybe I am wrong but I have tested 2 or three demos made in javaFx ==> My god :
it was longer to start than my big fat 3D software.
==> This does not look good at all from a Web service perspective.

Don't you think ? It doesn't frightens you from a Web sertvice perspective ?
Thierry

Selon java3d-interest@javadesktop.org:

> I guess the question worth asking is how difference should the scene graph
> APIs for 2D and 3D, from the same company, has to be.
>
> Project Scene Graph : https://scenegraph.dev.java.net/
>
> Should a Java developer requires to learn 2 very different APIs for 2D and 3D
> tasks ?
> If the long term answer is no, then it's maybe the time to jump on the JavaFX
> Runtime train.
> We might also solve our long standing deployment issue too!
>
> - Chien
> [Message sent by forum member 'jada' (jada)]
>
> http://forums.java.net/jive/thread.jspa?messageID=277656
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
> For additional commands, e-mail: interest-help@java3d.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

jada
Offline
Joined: 2004-03-17
Points: 0

JavaFX is built on Java. To be precise, JavaFX Desktop is built on Java SE 6 update 10. If a task is too complex or inefficient to be JavaFX scripted, a Java developer can code it up in Java and still deploy it on the JavaFX Runtime. With JavaFX Runtime, a Java developer can assume the presence of addition RIA packages, such as 2D/3D scene graph and media support.

Conceptually, you can think of JavaFX Desktop = 6u10 + RIA packages.

For more info. on 6u10 : http://java.sun.com/javase/downloads/ea/6u10/6u10beta.jsp

- Chien

David Grace

Hi Chien,

When can we expect to be able to create 3D applications using JavaFX. Where
is the best place to get information about 3D using JavaFX? I can't seem to
find information about 3D using JavaFX.

Will the rendering of 3D using JavaFX be as fast as Java3D? Will it use
OpenGL and DirectX for the rendering?

Dave.

-----Original Message-----
From: java3d-interest@javadesktop.org
[mailto:java3d-interest@javadesktop.org]
Sent: Sunday, June 01, 2008 3:56 AM
To: interest@java3d.dev.java.net
Subject: Re: petition for java3d in the next java release

JavaFX is built on Java. To be precise, JavaFX Desktop is built on Java SE
6 update 10. If a task is too complex or inefficient to be JavaFX scripted,
a Java developer can code it up in Java and still deploy it on the JavaFX
Runtime. With JavaFX Runtime, a Java developer can assume the presence of
addition RIA packages, such as 2D/3D scene graph and media support.

Conceptually, you can think of JavaFX Desktop = 6u10 + RIA packages.

For more info. on 6u10 :
http://java.sun.com/javase/downloads/ea/6u10/6u10beta.jsp

- Chien
[Message sent by forum member 'jada' (jada)]

http://forums.java.net/jive/thread.jspa?messageID=277709

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content
filtering.
http://www.mailguard.com.au/mg

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

jada
Offline
Joined: 2004-03-17
Points: 0

Our plan is stated in the 3D BOF slides @ JavaOne 2008 :
https://java3d.dev.java.net/

We are working toward an early access soon after the early access of JavaFX SDK.

A DirectX pipe work is currently in progress. We understand the value of providing a DirectX pipe on Windows.

- Chien

Thierry Milard (free)

Our plan is stated in the 3D BOF slides @ JavaOne 2008 :
> https://java3d.dev.java.net/
>
Yes, .... apart from the (3D-javaFx mix) teasing ... I can only see :
"java3D API is curently on hold"(only bugs ).

Please don't ask me why we feel bad and try to see alternatives (if
there ever are) from java3D,
the better is to think why we should not think otherwise !
Hapilly java3D is quite ok technically for me.

But for the communication things ... maybe a 5 days learning course
would be a nice for you Sun smart guys...

Thierry, Paris (too uncleaver to understand all this)

> We are working toward an early access soon after the early access of JavaFX SDK.
>
> A DirectX pipe work is currently in progress. We understand the value of providing a DirectX pipe on Windows.
>
> - Chien
> [Message sent by forum member 'jada' (jada)]
>
> http://forums.java.net/jive/thread.jspa?messageID=277842
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
> For additional commands, e-mail: interest-help@java3d.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

jada
Offline
Joined: 2004-03-17
Points: 0

Hi Thierry,
I noticed you are reading this thread via the email alias and not from the forum, hence missing on connection of my reply. I was answering to David Grace question :

>When can we expect to be able to create 3D applications using JavaFX. Where
>is the best place to get information about 3D using JavaFX? I can't seem to
>find information about 3D using JavaFX.

Regarding the status of Java 3D, if we state anything else other than what was stated in the BOF slides, we will be less than honest to our community. We have great interest in this community. We want to continue the positive engagement we have here with Java 3D, and SG3D in the future.

- Chien

dav0
Offline
Joined: 2005-11-23
Points: 0

As a former C/C++ programmer and Java/Javascript/VRML hacker who has since been locked away in a J2EE server for the past 10 years or so, I can also relate to simply cutting to the chase and using the silly OpenGL api via JOGL or JavaMonkeyEngine or whatever and be done with it, but there is something I think people are missing in this discussion, and that is the whole history behind the Java3d scenegraph paradigm and why I think it exists in the first place (where are the rest of the old VRML hackers in this discussion?).

Is there is a way to blend an API which still supports the old VRML hackers by importing old VRML scenegraphs the way Java3d seems to, but which also takes advantage of OpenGL, DirectX, and the realities of the ever-changing hardware world?

Today's lead article on Java.net about mobile devices is instructive here : http://developers.sun.com/mobility/apis/articles/opengles_mobilesensor/
...or the article the day before on OCAP, which promises to ignite a flurry of new interest in developing 3d games and applications for interactive TV in the very near future.

Is there a way for the JRE to "lazy-load" the appropriate JNI layer for 3D as needed?

Alan Hudson

java3d-interest@javadesktop.org wrote:
> As a former C/C++ programmer and Java/Javascript/VRML hacker who has since been locked away in a J2EE server for the past 10 years or so, I can also relate to simply cutting to the chase and using the silly OpenGL api via JOGL or JavaMonkeyEngine or whatever and be done with it, but there is something I think people are missing in this discussion, and that is the whole history behind the Java3d scenegraph paradigm and why I think it exists in the first place (where are the rest of the old VRML hackers in this discussion?).
>
> Is there is a way to blend an API which still supports the old VRML hackers by importing old VRML scenegraphs the way Java3d seems to, but which also takes advantage of OpenGL, DirectX, and the realities of the ever-changing hardware world?
>
Not a perfect answer here. But us old VRML hackers did come up with an
answer for that. We called it Aviatrix3D, http://aviatrix3d.j3d.org/

It's what Xj3D uses now as its main rendering engine. Most of our
projects these days are a combination of VRML/X3D content with low level
coding to OpenGL.

Just having OpenGL access is great if you know how to program your own
culling, picking, state sorting and follow all the latest events in 3D
graphics. Otherwise you are typically better off with a scenegraph that
solves most of those problems for you. The infrastructure to make a
good scenegraph is at least 100K of code and likely more.

The main problem with Java3D currently is that it's not being actively
supported. It had its day but I think it is finally dead. You can
either choose to follow Sun to its new scenegraph API or look around at
other engines. The chance of it getting into the JRE release is next to
nill. Having JOGL in there would be nice.

As an aside Xj3D is architected to support multiple renderers. So if
someone wanted to do a JMonkeyEngine port they could. It's a lot of
work porting each node but it can be done. Same with the Java3D
version, its there but needs lots of work to be functional again.

--
Alan Hudson

President Yumetech, Inc. www.yumetech.com
President Web3D Consortium www.web3d.org
206 340 8900

Open Source CAN be free, as in "free puppy"

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

dav0
Offline
Joined: 2005-11-23
Points: 0

> The main problem with Java3D currently is that it's not being actively
> supported. It had its day but I think it is finally dead. You can
> either choose to follow Sun to its new scenegraph API or look around at
> other engines. The chance of it getting into the JRE release is next to
> nill. Having JOGL in there would be nice.

I have been on this java3d mailing list since it's inception, some 10 years ago or whatever, and ironically, it seems like it has never been busier than it is now. If Java3d is dead, then it is certainly having a better death than it had a life (or maybe this is simply a well attended wake?)

I personally don't really care which API we go with here, I will "support" whichever API makes the most sense. The main point is, Java has reached a very important crossroads in it's evolution, with the recent decision to use Java as *the* language for interactive cable TV (OCAP), it is time to stop the squabbling amongst the various 3D programming tribes and rally around the most logical solution ASAP!

(dodges apples and tomatoes and quickly dismounts soapbox)

Seriously, there would seem to be an ongoing problem in the world of 3d when it comes to Java. It's almost as though there are and have always been some major forces at work which are determined to thwart any success stories when it comes to lumping the words "Java" and "3d" into the same sentence.

The same can also be said of 3d technology in general however to some extent I suppose - at least when it comes to 3d on the web. This technology has certainly been plagued by more than its fair share of near misses and tragedies. My 3d web graphics dreams were initially shattered ten years ago when the VRML Cosmo Player plugin, which seemed so poised to launch the web world into a new 3D Millenium, seemed to suddenly die a cruel death (only to be resurrected later - see http://mclures.net/david/resume/Titanic/Titanic.html).

A similar fate awaited SGI - a company which many assumed would take the world by 3d storm, but which later flopped due to a long list of other apparent market failures. I guess these experiences (coupled with the fact that I lost a fair amount of money in SGI stock) caused me to become a little 3Depressed! :-(

I'm happy to report however, that I have since licked my wounds (as well as hopefully having grown up a little) and I am also now back on board with 3d technology. This time I am here to not only fiddle with making some newer and better 3D UI demos but also hopefully to roll up my sleeves and see if I can't help to make this thing happen for Java as well!

-dav0

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> The main point is, Java has reached a very
> important crossroads in it's evolution, with the
> recent decision to use Java as *the* language for
> interactive cable TV (OCAP), it is time to stop the
> squabbling amongst the various 3D programming tribes
> and rally around the most logical solution ASAP!

... why? One would think competition is as welcome in this field as in any other. Java has multiple XML, GUI, 2D and 3D APIs. There are (seemingly) plenty of resources to go around (in the open-source community that is) and the competition has resulted in very healthy competition. If the APIs have not yet converged on one or two winners it is because this isn't (yet) a solved problem and the APIs are not (yet) mature enough to settle down. I wouldn't want to freeze these things until some sort of consensus is reached. Just make sure it's easy to deploy whichever solution the developer has chosen and go from there.

Correct me if I'm wrong but I'm under the impression people are complaining about deployment problems not the lack of a single API to monopolize the 3D field. I think people like having these choices (at least for now).

dav0
Offline
Joined: 2005-11-23
Points: 0

Points well taken, but from a 3d application developer perspective, when shopping for a 3d framework to begin working on a new application which might take six months to a year (or more even - for hobbiests such as myself) to complete, it's hard to begin designing, much less building without a solid foundation that isn't going to disappear in three months.

When it comes to the web, standards are needed to move forward. Case in point: the browser wars continue, but things used to be much worse programming on the client side prior to ECMA, XHTML, CSS, and a variety of other w3c standardizations. On the Java server side, it is a safe bet that if you code to the Spring Framework or possibly Seam, that your application will not only enjoy cutting edge features, but will also still basically work a couple of years down the road. Prior to Java 1.1, the Java server side was a pretty bumpy ride as well, but things have remained pretty backwards compatible since then. I don't think anyone would call this sort of framework stability a monopoly.

I don't mind competing technologies, but there is a big difference between a monopoly and a standard API. I mentioned that I have been lurking in the background in terms of doing any significant 3d development for the past 10 years while what are clearly still ongoing Java 3d API wars sorted themselves out because I have been burnt many times before by dying frameworks. If you want to talk about monopolies, the real non-Java monopoly (big company - starts with "M") is likely dancing with glee watching as 3d technology continues to fail to standardize on a foundation in the Java community after over 10 years of squabbling. Kind of makes you wonder who is really behind all of these competing and sometimes divisive options...

OK, maybe I'm just being paranoid, combined with being a little lazy - after all, I want an API without really having to work to help create it. But really, if Java3d truly is dead, then we are standing at its graveside and a little emotional unloading should be expected. Not to mention, a little curiosity as to the reasons behind its death (i.e. did it die of natural causes or was it murdered?). Lastly, if Java3d truly is dead, then why are we all still here? (i.e. shouldn't someone put the sword through the head of this Java3d forum - cap it with a read-only lock and provide pointers to the surviving Java 3D APIs so we can stop wasting our time here?)

Maybe what makes the most sense (while we are all still gathered here in mourning) is to build a little review spreadsheet which compares the current 3d API frameworks complete with a ranking of features and benefits such as : "Java Support", "Speed", "Launchability", "OS Support", "Browser Support", etc., complete with a way to review and rank each platform. Application programmers could quickly choose the platform they need based on the priorities of their application. Does anyone know whether something like this already exists somewhere? If so, then my work here is done. I mean, sure there is always web3d.org, but the word "Java" hardly seems to comes up on their radar - in fact, the only place it comes up on their current page is a call for papers on Java3d of all things), so what I'm looking for is a little more Java specific.

Thanks for listening. (this is what happens when you wait ten years to voice your opinions on something :-)

cowwoc
Offline
Joined: 2003-08-24
Points: 0

The problem with software products, especially open-source ones, is that no one tells you when they're dead. They just a die a very slow death when they are no longer being developed or supported in a decent way. Eventually some competitor steals their market-share.

The Java3D mailing list could be busy for the next couple of years but it says nothing about Java3D specifically, it just shows people are interested in 3D technologies in general. If Java3D, or any product for that matter, is alive you would expect regular releases and new features being added at a consistent rate. Java3D stopped growing a few years back. Maybe it's growing again but I haven't looked ever since Sun open-sourced it.

dav0
Offline
Joined: 2005-11-23
Points: 0

From a branding perspective, I'm finding that it's real hard to even talk about Java and 3d without simply calling it "Java3d", so the "Java3d" name seems to win out by default - so far anyway.

As for open source projects lingering on needlessly, I don't know that this is really what is happening here. Like I said, I've been on the Java3d mailing list pretty much since day one, so if anyone is interested, I can supply backlogs of digests which for some unknown reason I have been squirreling away all these years. My general impression however, is that there has been a steady spike in activity since Java went Open Source.

Like you said, some of this could simply be attributed to an increased interest in 3d in general, or it could be the open sourcing which ignited the interest. One thing about Open Source projects is that they are truly grass roots efforts, so there is no longer any excuse to sit around and moan about the freaking crappy API or what have you - since it is now up to us to help fix it.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

1) If Java3D wins as the premiere 3D engine for Java then you can be sure Sun and others will support. It is open-source after it. My guess is that it's not winning because there are other, better, engines out there. Part of better is "better supported".

2) Please *please* stop trying to bundle everything with the JRE. I totally get your point about the need for better deployment (and yes that needs to be improved) but I'm not sold on the idea that bundling it (and the rest of the kitchen sink) with the JRE is appropriate. Can you honestly say that the vast majority of JRE users will use Java3D? I think not.

This wouldn't be a problem if the Java specification allowed us to *optionally* bundle packages with the JRE but as things stand now if you say something is bundled with the JRE it means it *must* be installed on the user's machine, like Corba which no one is using.

So in summary, we need to fix one of two problems: improve module deployment or allow JRE modules to be optional.

tmilard
Offline
Joined: 2004-03-25
Points: 0

> 1) If Java3D wins as the premiere 3D engine for Java
> then you can be sure Sun and others will support. It
> is open-source after it. My guess is that it's not
> winning because there are other, better, engines out
> there. Part of better is "better supported".
==> I am perfectly not sure with you.I think some other solution are surelly ok. But none is radically better then the other is anyway. For me who uses images java3D is quite Ok. Stable and ok. The support ( this mailing list I suppose) I find one good one in java world.

> 2) Please *please* stop trying to bundle everything
> with the JRE. I totally get your point about the need
> for better deployment (and yes that needs to be
> improved) but I'm not sold on the idea that bundling
> it (and the rest of the kitchen sink) with the JRE is
> appropriate. Can you honestly say that the vast
> majority of JRE users will use Java3D? I think not.
==> 100 agree with you.

> This wouldn't be a problem if the Java specification
> allowed us to *optionally* bundle packages with the
> JRE but as things stand now if you say something is
> bundled with the JRE it means it *must* be installed
> on the user's machine, like Corba which no one is
> using.
>
> So in summary, we need to fix one of two problems:
> improve module deployment or allow JRE modules to be
> optional.
==> Yes more urgent things like jre cool install, nice looking updates, seemless running, install. We all cross our fingers for a nice surprise for "Consumer jre" soon. Well I hope....

Thierry, Paris