Skip to main content

Java 3D Future Direction

38 replies [Last post]
kcr
Offline
Joined: 2004-03-17

We have posted our slides from the Java 3D BOF @ JavaOne 2007 at:

https://java3d.dev.java.net/j3dbof07/index.html

You will notice that this includes a discussion on the future direction of Java 3D: namely, whether to do a more major "2.0" version at this time, or whether to continue to evolve the API as we have recently done with another "1.x" version.

We would like to get feedback from you developers on the forum. Which do you think we should do and why?

To summarize from the slides, the major differences of the two approaches are

Java 3D "2.0"
. Simplified implementation (including rewrite of RenderBin, Renderer, and MasterControl)
. Source/binary compatible, with semantic changes
--- Most apps will run without modifications
--- Some old programs may not work correctly (e.g., apps that rely on undocumented behavior)
. Benefits:
--- Easier to add new rendering features
--- Easier to allow extensibility
--- More scalable threading model
--- Memory footprint reductions
--- Remove barriers to community contribution

Java 3D 1.x
. 100% source/binary compatibility
--- Preserve most semantics
. Minor release, could include:
--- New, updated utilities
--- Some new features
--- Bug fixes
. Benefits:
--- More utilities

The pros/cons of each are as follows:

Java 3D "2.0"
-------------
Pro: Improved performance, threading, memory
Pro: Ability to easily add new features
Con: Takes time away from utilities & minor features
Con: Could break some old apps

Java 3D 1.x
-----------
Pro: Delivers new utilities and minor features sooner
Pro: 100% binary compatibility
Con: Some major features not feasible
Con: Many performance improvements will be delayed

Please let us know what you think by replying to this thread. Thank you.

-- Java 3D Team @ Sun Microsystems

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jfelrod1960
Offline
Joined: 2003-11-01

To: Kevin/Mark

Sun, as you probably know already Kevin, has come out with JSE for Embedded Use which they state requires 32MB of RAM and 32MB of ROM.

Doesn't Sony's PSP fall into that category? I know the PSP does not run Java games.

I guess the more obvious question is does JSE for Embedded Use have all that Java3D requires. I don't know the subset JSE for Embedded Use has.

Jeff

sanbikinoraion
Offline
Joined: 2009-05-11

Well, I think it's brilliant to be consulted!

My two cents, though I've not been here long, is that a board full of developers are quite likely to be in favour of a wholly new version and damned be compatibility.... and I have to say, I agree! Though I think that we should all realize that starting again is likely to engender more bugs and more waiting than incremental improvement would.

Someone else also mentioned rollout, and this is vital for me - I'm writing a Java3D game at the moment and if users could be relied upon to acquire the latest version of Java3D themselves then that would make distribution for me a lot easier.

edwardboszczowski
Offline
Joined: 2006-02-05

With so many things being made available to openGL (Vertex, Geometry and Fragment(Pixel) Shaders, several extensions like NVidia Bindess Graphics, multuipass rendering) is essential to java 3d keep up to date on technology point of view.
Speed up are always welcome and utilities can be made available with more people using java3d, and for more people use java 3d, it needs more capabilities.

Sure, things are utilities are very important, but in moment, in my opinion new features are still more.

2.0 on head

chaose71
Offline
Joined: 2008-04-15

I vote for 2.0 as well. Time to move forward!

Ingo

facedancer
Offline
Joined: 2006-02-27

2.0 of course. Faster is better :)

chadkellycolorado
Offline
Joined: 2007-11-23

Version 2. The focus should be on solely supporting and extending JOGL with additional features (multi-threaded, scene graph, physics). If there are any additional performance cost for supporting D3D, then D3D should be excluded.

Chad Peyton

chadkellycolorado
Offline
Joined: 2007-11-23

When will D3D be implemented for other platforms? DirectX for Linux? More info at http://chadkellycolorado.blogspot.com.

aces
Offline
Joined: 2003-07-17

Hi Kelly

>When will D3D be implemented for other platforms?

I guess D3D will be Win32/64 only. Afaik, DirectX implementations for other platforms, as Wine, doesn't perform very well or reliably.

So far, OpenGL/Mesa3D is the best choice for linux platform.

goddard
Offline
Joined: 2007-05-14

definitely j3d 2.0 with a careful look at ogl 3.0 standard.

dhnizdor
Offline
Joined: 2005-11-22

Go for 2.0.
Take a look at Panda3d for the reasons.

knirps
Offline
Joined: 2007-02-02

any news on this topic?

aces
Offline
Joined: 2003-07-17

I would love to have a (optional) pure Java renderer, to not worry about binary deployments. Software renderer, as Mesa3D, plays quite good on today multi core processors, so I guess a pure Java renderer can do the same. Or better ;)

No flame war on D3D subject, but I'd like to think it as an ace up sleeve. Intel & Vista are some examples where it can shines (and save the day).
Btw, D3D pipeline has high FPS, since you don't have quads wireframes.

jfelrod1960
Offline
Joined: 2003-11-01

Would the memory footprint reductions allow Java3D to run on a handheld device?

kcr
Offline
Joined: 2004-03-17

> Would the memory footprint reductions allow Java3D to run on a handheld device?

Only if the device runs J2SE. We could consider a subset that runs on J2ME, but the API currently depends on SE features.

Mark Hood

> Date: Wed, 27 Jun 2007 11:05:32 PDT
> From: java3d-interest@javadesktop.org
>
> > Would the memory footprint reductions allow Java3D to run on a handheld
> > device?
>
> Only if the device runs J2SE. We could consider a subset that runs on J2ME,
> but the API currently depends on SE features. [Message sent by forum member
> 'kcr' (kcr)]

If full Java 3D functions are not a requirement for your mobile application
then you might consider two other APIs in the J2ME space:

JSR-184 is an object-oriented 3D API that's very similar to Java 3D but is not
a strict subset. If you need fairly high-level abstractions then that may be a
good choice.

JSR-239 is a Java binding to the OpenGL ES subset for embedded and mobile
devices. It takes the JOGL route of exposing as much of the native OpenGL ES
API as possible.

-- Mark

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

stylertim
Offline
Joined: 2006-05-04

My vote also goes to Java 2.0. But ...

To circumvent too long waiting times you could simply release an alpha, several betas and the final version like it's happening with 1.5.1 now, offering certain new features after some weeks or months of development. This way you can add completely new features, have them tested while implementing different ones and have the community covered with new material. Keep in mind that releasing another 1.x version leaves some currently available OpenGL 2.1 features aside and surely does not contribute to the upcoming OpenGL 3.0 API which surely isn't getting smaller. :) Therefore Java 2.0 is essential!

For the concern of app compatibility, if the changes to the code aren't to extensive it should not take a miracle to be able to adapt to a new release of Java 3D. Of course I acknowledge the variables such as code length and complexity and the version it was originally based on, but I guess for a lot of features redesigning should not be nescessary since they work already fine which keeps compatibility satisfied for most areas of the API.

Concerning widening the spectrum of available utils, you could assemble a list of utils you'd like to see in a future release and then outsource their development to experienced users, like it happened with pepe and JCanvas3D. Of course contributing has been possible all the time but how about directly addressing the community to fulfill a couple of demands? This way you also have a clear community estimation of desired and undesried features.

What I'm basically saying is: Mix up the two models for the future of Java3D! My personally suggested model would look a little like this:

Java 3D "2.0":

. Simplified implementation (including rewrite of RenderBin, Renderer, and MasterControl)
. Source/binary compatible, with semantic changes
--- Most apps will run without modifications
--- Some old programs may not work correctly (e.g., apps that rely on undocumented behavior)
.Periodic test releases to verify newly added features/shorten waiting terms
.Outsource development of demanded features to the community

Another thing that could be interesting is the addition of a special Java 3D 2.0 subforum, or converting the one existing forum into a Java 3D 1.x and a Java 3D 2.0 (if possible!!).
In my eyes this could make the development process more efficent.

Best regards,

Thomas

vsabol
Offline
Joined: 2006-03-09

Vote for 2.0. An get it into Java 7!

nvaidya
Offline
Joined: 2004-08-03

My vote for Version 2.0 !

Firstly, it will quell any lingering misgivings about Sun's sustained interest in Java 3D. Secondly, it is important to evolve the API and the code base to a version that the Java 3D Team is most comfortable with from the viewpoint of easy extensibility to keep pace with OGL/D3D and also of easy maintenance.

Many thanks to Kevin and his Team for a great job over the past 3 years in getting Java 3D to be a lean, performant, and stable API.

--Vaidya

pauldb
Offline
Joined: 2003-08-30

I vote for Version 2.

I would also like to add my gratitude to Kevin, Chien and the rest of the Java3D team and contributors for their magnificent work on, not just resurrecting Java3D, but taking it forward so positively.

Many thanks,
-Paul

pepe
Offline
Joined: 2003-06-10

Hello.
Please count my vote for 2.0.

My personal experienced with JCanvas3D showed that extending and understanding core is much too difficult. I will blame lack of time/dead brain to really and fully understand core, but i honestly think that it is too hard to get if you did not write it.
My biggest problem with java3D was scheduling. I hope 2.0 will change that and i also hope that my recent experience with creating swash scheduler will be helpful in that direction.
I am also happy that, in the end, much of the hacks for JCanvas3D will poof away to an endless void. Reimplementing render destination to take in account swing/render to texture/greater offscreen/ and reduce the 'lag'/time to display will be a great step ahead.

Being very backward compatible is not extremely important in my eyes. Maybe we can think about what changes can be made painless using APIs like Jackpot to let users transition form 1.x to 2.0. This would give us more latitude in changes.

interactivemesh
Offline
Joined: 2006-06-07

Hi Java 3D Team,

it isn't easy not to follow your arguments for redesigning Java 3D. I'm with you as long as maintenance releases (1.5.x) are published in reasonable periods until a stable 2.0 is available (autumn 2008?).

- It's a must for Java 3D to adapt itself in time to get most out of upcomming CPUs (multi-core) and GPUs (DirectX xx, OpenGL x.y).

- Performance is a key argument for users and decision makers, even if they don't need it. Only counting on hardware improvements will throw back Java 3D in acceptance.

- Personally, I'm not a friend of Simple-, Simpler-, Simplest-Universes. At the end they aren't simple at all and you are imprisoned due to utilities which are limited to them. Scene graph recipes (MyFirstUniverse), generally usable utilities and updated tutorials would be more effective.

- What about going open source, GPLv2?

Currently, Java 3D 1.5.1 and JRE 6.0 are the best couple for multi platform, powerful, and reliable desktop/web based 3D applications. I'm looking forward to see Java 3D 2.x top it as soon as possible.

August

tmilard
Offline
Joined: 2004-03-25

Hello java3D team.
My thougts is that 1.5.1 is a good release up to what I can say.
The best we have had so far. So bravo.
For future I am not good enought to choose 2.0 or 1.x. I trust community and Sun for
decision.

But of course as a french latin developper I will still say a few "thougts" on this issue

A) Short time future (0-6 month)
Nevertheless, for short-future, I just feel the more "easy" deployement (messages, duration, no fortknox paramonia, no need be admin on XP) the better we will all feel in the community.
I have said it many times. I do understand it is maybe not a java3D 100% issue but... well I hope some tiny improvments is all welcome.
And please do not think of the 0.03% of machine under Unix-home-made-in-Russia, but think more of XP (a lot) and Vistas (a bit) machines.
Fot the compatibilyty issues with old java3D that could break, never mind. Anyway very old java3D application that did not upgrades are already dead (not used).

B) Long time future ( 5 month - 1 year)
Ok for me. Get pleasure programing all issues in 2.0 you want to do. I really do not know enough 3D to have an imput. All I can say is please as a developper do keep in mind :
a) Small concretes upgrades usually are better for all of us.
b) The more you rewrite java3D source code ... the more it will take time to eradicate bugs you ad inevitally. I mean new rewriting weakings automaticly all the previous debugings issues you have all made. Well .... please do rewrite only necessary things: things really badly written in the past or because it limits things for future.
Well . Not just because it is 'interesting' to change it.

--------------------------------------------
Java 3D "2.0"
Pro: Improved performance, threading, memory
==> Performance ? Not that important. Memory print ? why not improve it.
Pro: Ability to easily add new features ==> yes interesting to open java3D to other API.

Con: Takes time away from utilities & minor features ==>
Con: Could break some old apps ==> Who cares: Let's burry old code.

Java 3D 1.x
-----------
Pro: Delivers new utilities and minor features sooner
==> keep a red light for web deployement improvements. Even small improvements because any small one will have a high impact on all java3D users. I might be a bad guy but I do not recall any users that did not complain about installation. I bet you improve 50% install and you get 400% more happy users. This is what I call productivity.

Pro: 100% binary compatibility =>> Not important. What all have to repaint the facade of our house once every two years. As long as 2.0 does not force more than 10% rewrite.

Con: Some major features not feasible ==> This is bad (of course)
Con: Many performance improvements will be delayed ==> bad.

Thierry

Dmitri Darine

> And please do not think of the 0.03% of machine under Unix-home-made-in-Russia

I don't get "Russia" part here, Mr. Napoleon.

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

t.milard@free.fr

Selon Dmitri Darine :

>
> > And please do not think of the 0.03% of machine under
> Unix-home-made-in-Russia
>
> I don't get "Russia" part here, Mr. Napoleon.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
> For additional commands, e-mail: interest-help@java3d.dev.java.net
>
>

-Oh ! I also will objectly think of
"home-made-LINUX-FLAVOR-for-French-dreamers". ;-)
I am a Napolean with USA americain eyes : the more user the better.
Pure liberal thinking : pure cost thinking.

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

goddard
Offline
Joined: 2007-05-14

then move your butt to some d3d api, j3d should remain multiplatform as ogl is in a way

drpaul
Offline
Joined: 2006-02-04

I cast the lone vote for 1.x.

Computers and graphics are always getting faster and more powerful so performance improvements are automatic with new hardware.

Better to let hardware improve the performance and maintain backward compatability.

yowmhong
Offline
Joined: 2003-06-19

Dear Java3D Team:

After looking at the presentation, I have the following suggestions:

Deployment – this is always a burning issue. Make Java3D easier to deploy not only on supporting auto-download on demand and JNLP but also the licensing/redistribution limitations. I would suggest to make it happen earlier and even better for this coming release (except licensing/redistribution issues which would be a question Sun's lawyer's )

JCancas3D – I would look at current JCancas3D implementation as a proof of concept and my sincere appreciation for this community contribution. An implementation similar to JOGL’s JGLCanvas in capabilities, functionalities and life cycle management is more desirable. My major concern is the ability to have transparent behaviors both under Canvas3D and JCanvas3D. Especially when coupled with JOGL immediate mode rendering in the future.

OpenGL View Transform Pipeline – I would recommend stick to OpenGL style as the primary viewing pipeline and build current Java3D view pipeline on top of it. Majority of end users don’t have the HUD environment. Java3D developers are forced to deal with current Java3D viewing pipeline and struggle to implement similar behaviors that are real simple and straight forward under OpenGL.

Backward compatibility for 2.x – I would prefer to have a sound architecture for 2.x rather than constrained by current Java3D implementation. Keep maintaining 1.5.x branch and deliver bug fixes in a timely manner will help move Java3D development forward. However, backward compatibility and fail nicely with OpenGL version is a very important requirement.

Thanks,

--Scott

russelleast
Offline
Joined: 2004-01-09

Your plans for 2.0 sound great - the sooner the better!

Dmitri Darine

1.x or 2.0? :) Which one includes nice, stable and flexible JCanvas3D? I
vote for that one. I think it is time to make it right after ALL these
years.

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

Hong Cao

Go for 2.0 please. Java 3d RenderBin, Renderer, and MasterControl are
our headache right now. No matter it is memory, performance, or thread
extensibility.

What we want is fault tolerance - we frequently ecounter exception from
RenderBin, Renderer and MasterControl, when that happens, the program
freeze, no way to recover. We believe only a brand new version could
improve.

Thanks.

Hong

java3d-interest@javadesktop.org wrote:
> We have posted our slides from the Java 3D BOF @ JavaOne 2007 at:
>
> https://java3d.dev.java.net/j3dbof07/index.html
>
> You will notice that this includes a discussion on the future direction of Java 3D: namely, whether to do a more major "2.0" version at this time, or whether to continue to evolve the API as we have recently done with another "1.x" version.
>
> We would like to get feedback from you developers on the forum. Which do you think we should do and why?
>
> To summarize from the slides, the major differences of the two approaches are
>
> Java 3D "2.0"
> . Simplified implementation (including rewrite of RenderBin, Renderer, and MasterControl)
> . Source/binary compatible, with semantic changes
> --- Most apps will run without modifications
> --- Some old programs may not work correctly (e.g., apps that rely on undocumented behavior)
> . Benefits:
> --- Easier to add new rendering features
> --- Easier to allow extensibility
> --- More scalable threading model
> --- Memory footprint reductions
> --- Remove barriers to community contribution
>
> Java 3D 1.x
> . 100% source/binary compatibility
> --- Preserve most semantics
> . Minor release, could include:
> --- New, updated utilities
> --- Some new features
> --- Bug fixes
> . Benefits:
> --- More utilities
>
>
> The pros/cons of each are as follows:
>
> Java 3D "2.0"
> -------------
> Pro: Improved performance, threading, memory
> Pro: Ability to easily add new features
> Con: Takes time away from utilities & minor features
> Con: Could break some old apps
>
> Java 3D 1.x
> -----------
> Pro: Delivers new utilities and minor features sooner
> Pro: 100% binary compatibility
> Con: Some major features not feasible
> Con: Many performance improvements will be delayed
>
> Please let us know what you think by replying to this thread. Thank you.
>
> -- Java 3D Team @ Sun Microsystems
> [Message sent by forum member 'kcr' (kcr)]
>
> http://forums.java.net/jive/thread.jspa?messageID=217020
>
> ---------------------------------------------------------------------
> 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

Mark Hood

I've not had time to go through the slides, but I would concur with
the majority here that 2.0 is the way to go. At some point the
architecture has to be refined to enable progress forward with
graphics features such as multi-pass and immediate rendering modes and
better support for correctly rendering multiple levels of transparency.

Java 3D also needs to clean up the various levels of latency that
occur within the current architecture -- it's very cumbersome to code
when updates to the scenegraph are viewable after 1 or 2 frames of
latency depending upon whether you're updating Transforms or Geometry
with by-ref or by-copy semantics.

MT performance will also be crucial now with the prevalence of
multiple cores and CPUs on baseline hardware. Although Java 3D has
always been forward-looking in its use of concurrency, I recall at one
point Java 3D actually ran slower on some multi-CPU systems because of
excessive locking. Hopefully that's already been addressed.

I think the implicit MT support given to every Java 3D application
could be one of the most significant and attractive features of the
API to a graphics developer at this point, but it has to be robust and
truly scalable on the common multi-core/cpu hardware out there.

Also, given the prevalence of Java on the server side, it would cool
if Java 3D could function on a headless server running without a
window system or monitor, but with access to a bunch of graphics cards
serving up pbuffers.

Glad to see things moving forward!

-- Mark Hood

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

mlouka
Offline
Joined: 2004-06-27

Thanks for posting the slides.

I'd say to go for 2.0, if possible, but I also think that it is important that minor (but potentially important) bug fixes can be done to the 1.5.x branch while 2.0 is under development. It should be possible to release 1.5.1.x releases with minor (incremental) bug fixes more quickly that every six months. My only concern would be if insufficient resources are committed to developing 2.0 such that it takes "forever" to reach final release status, in which case a more incremental 1.6, etc. path would be safer. Of course, if the (re-)design is well-documented then it might be easier for the community to assist in development.

Michael.

aces
Offline
Joined: 2003-07-17

I vote for "2.0"

Joerg Plewe

I'd vote for 2.0.

Although more utilities like a HUD would be just great!

- J

java3d-interest@javadesktop.org schrieb:
> We have posted our slides from the Java 3D BOF @ JavaOne 2007 at:
>
> https://java3d.dev.java.net/j3dbof07/index.html
>
> You will notice that this includes a discussion on the future direction of Java 3D: namely, whether to do a more major "2.0" version at this time, or whether to continue to evolve the API as we have recently done with another "1.x" version.
>
> We would like to get feedback from you developers on the forum. Which do you think we should do and why?
>
> To summarize from the slides, the major differences of the two approaches are
>
> Java 3D "2.0"
> . Simplified implementation (including rewrite of RenderBin, Renderer, and MasterControl)
> . Source/binary compatible, with semantic changes
> --- Most apps will run without modifications
> --- Some old programs may not work correctly (e.g., apps that rely on undocumented behavior)
> . Benefits:
> --- Easier to add new rendering features
> --- Easier to allow extensibility
> --- More scalable threading model
> --- Memory footprint reductions
> --- Remove barriers to community contribution
>
> Java 3D 1.x
> . 100% source/binary compatibility
> --- Preserve most semantics
> . Minor release, could include:
> --- New, updated utilities
> --- Some new features
> --- Bug fixes
> . Benefits:
> --- More utilities
>
>
> The pros/cons of each are as follows:
>
> Java 3D "2.0"
> -------------
> Pro: Improved performance, threading, memory
> Pro: Ability to easily add new features
> Con: Takes time away from utilities & minor features
> Con: Could break some old apps
>
> Java 3D 1.x
> -----------
> Pro: Delivers new utilities and minor features sooner
> Pro: 100% binary compatibility
> Con: Some major features not feasible
> Con: Many performance improvements will be delayed
>
> Please let us know what you think by replying to this thread. Thank you.
>
> -- Java 3D Team @ Sun Microsystems
> [Message sent by forum member 'kcr' (kcr)]
>

--
Joerg Plewe
http://www.hardcode.de
'Life is hard and then you die.'

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

Aaron Metzger

java3d-interest@javadesktop.org wrote:

> We would like to get feedback from you developers on the forum. Which do you think we should do and why?
>

Go for 2.0 now.

Anything that improves performance, memory, and threading beats out a
few new utilities IMHO.

Although a backward compatible API is a noble goal, it is not a hard
requirement for us. We'd be happy with a Java 1.5 minimum language
requirement including the use of generics and annotations as appropriate
in the API.

With that said though, we'd be disappointed if there were no releases
for a year. I didn't see a roadmap against the calendar in the
pros/cons summary for 1.x VS 2.x. Can the 2.0 features be phased in or
are they all tightly coupled?

Thanks for restoring vitality to the Java3D world!

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

gmrolf
Offline
Joined: 2005-01-26

Hi,
again me.
I'd just looked into your BOF-pdf and read, that you need examples from real world usage.
may have a look at:
http://www.plan.aau.dk/~enc/AGILE2007/PDF/129_PDF.pdf
page 9 /chapter 6, theres a description what I did to visualize geodata using j3d
at:
http://www.lgi.geographie.uni-kiel.de/module-pagesetter-main-tid-6.phtml
in the flash-animation at the bottom it is in action.[in german]

cheers
rolf

bheffner75
Offline
Joined: 2005-05-19

My vote is to start working on a 2.0 release. Reasons are:

While the code base for Java3D is good, industry experience shows that first versions (and this is still a first major version) have a lot of good ideas, but not necessarily the best architecture. Architecture, as alluded to in the Java3D sides, is as important -- or more important -- of a factor contributing to performance, stability, and extensibility than the algorithms used to power the architectural components. Recommend taking the lessons learned from this first version and all of its attendant modifications and craft an architecture that will execute more cleanly, more intuitively (complex is not always better), and allow for unforseen extensions.

The current OpenGL specification and associated code bases (e.g., JOGL) contain features that Java3D does not support. Examples noted include multipass rendering. These features provide valuable technology to enable modern graphics effects. Not being able to access these features via Java3D puts Java3D behind the curve, from a technology perspective.

The development language used to build the Java3D API has evolved. A move to 2.0 would be a very good time to take a hard look at the language advancements offered by the latest offering of the Java SE and evaluate which improvements will (1) simplify the API, (2) improve performance, (3) promote reusability and extensibility. Backward compatibility is important, but after a period of time it can also become an obstacle to innovation and improvement. Judicious application of new language features may turn out to be more beneficial than keeping the API immutable.

gmrolf
Offline
Joined: 2005-01-26

I see many advantages for 2.0 as described,
will be a way to have e.g. a 1.3 for older software
and a 2.0 running in any way or with any human-madeable
worgarround, together, if this
could be possible - my direct vote will go for 2.0
hoping that the utils will grow again..
cheers
rolf