The air hockey game had '1000's of nodes', whilst the video ball demo had in excess of '15,000 nodes'.I think the shapes on these nodes were basic cubes, rather than complex Shape3D's (assuming these will be in the JavaFx2.1 API?).Wonder how many nodes one can have with complex shapes comprising many triangles.

@Joe: Will there be Shape3D and all the underlying Geometry classes as in Java3D?

@Joe: Sorry we're bombarding you with questions, but we've been left in the dark and would really like to know what to expect, so we can plan for the future. What about the SlimShady project? Is its development ongoing? It was meant to be better than prism for hardware acceleration, wasn't it?

Before I answer, let me say a bit more about myself. I graduated from Sonoma State in 2008 and I joined Sun in early 2009 to write shader fastpaths for prism. My focus in University and after was Computer Graphics and i had worked at a couple of places before joining Sun. If I were to have a specialty it would be Lighting/Modern Shader pipelines. Anyways, at the time I joined JavaFX 1.2 was just about to come out.

Since then I have written many shaders/features/demos using JavaFX/Prism for releases/JavaOne and i also wrote the binding API for PhysX .

So, lets see what i can answer... Keep in mind if I avoid answering a question its not because I don't want to lol.

Quote

will it be possible to use Prism as a minimal binding over D3D and OGL without using the scenegraph? For example, can OGL/D3D be used with DisplayLists or VBO's, ie without 'immediate mode' rendering? Sounds like this is not the case if you couldn't do a minecraft-like game in it.

Number one reason why there is no minecraftfx, no lighting engine. minecraft consists of all cubes... which you have seen many of in FX recently. How many cubes can you have in JFX? good question. With Cube Primitives this will be higher, since currently cubes consist of 6 3d transformed rects/mediaviews/imageviews in a group.

As for the binding stuff.... this is a question to ask Rich who is one of our Architects.

Quote

There is some experimental 3D support in JavaFx1.3, which appears to have gone mainstream with JavaFx2.0.

Ah yes, Jim Weavers stuff is pretty awesome. He is doing a lot of the 3D Calc on his own though. What you saw before that is directly from us was 3d transforms/transitions, and that is being included in the next release.

Quote

Wonder how many nodes one can have with complex shapes comprising many triangles.

I am dieing to figure this out myself. Stay tuned.

Quote

Will there be Shape3D and all the underlying Geometry classes as in Java3D?

Our graphics lead is from the Java3D project, and he is great. I can imagine we will take what we have learned from java3d and use that to make JavaFX better (we already have).

but we've been left in the dark and would really like to know what to expect, so we can plan for the future. What about the SlimShady project? Is its development ongoing? It was meant to be better than prism for hardware acceleration, wasn't it?

We don't mean to leave anyone in the dark. Honestly, Oracle has been treating JavaFX extremely well. I can speak for all of the devs in saying that we feel we have been well received, and well directed. All of us believe in the development community of Java..... Slim Shady != Prism... but like Java3D, we have learned a ton from them, etc.

will it be possible to use Prism as a minimal binding over D3D and OGL without using the scenegraph? For example, can OGL/D3D be used with DisplayLists or VBO's, ie without 'immediate mode' rendering? Sounds like this is not the case if you couldn't do a minecraft-like game in it.

As for the binding stuff.... this is a question to ask Rich who is one of our Architects.

Thanks for the answer. Well if you could ask Rich that would be fantastisch

The video wall had 1300 cubes, each with 6 mediaviews, so we have 7800 mediaviews (although at least half these are backfacing at any one time. There's probably a couple hundred more in the video ball and a 100 or so rects in the ramps; say at least 8000 quads of various types. There's 15,000 nodes; say 8000 linked to quads, a further 1300 or so linked to cubes and a few 100 above those. Not quite 15,000 nodes. Maybe there are more quads making up the background chequer pattern. Can't really tell what the framerate was; 60Hz was mentioned earlier in the presentation, but this might apply to any of the demos. There's enough performance there to do something interesting in 3D so I'll start thinking about dynamic scene graphing, with a view to targeting JavaFx2.1. A proof of concept using quads (without lighting) should be possible on JavaFx2.0, so I'll probably try some stuff out when the public beta comes out.

WRT: Unreal - Dynamic scene graphs. What Tim is calling a DSG is really a portal system. So at render time, a scene graph like structure is built from the "current" cell and all visible portals (potential recursive for mirrors, teleporters, etc.).

WRT: Unreal - Dynamic scene graphs. What Tim is calling a DSG is really a portal system. So at render time, a scene graph like structure is built from the "current" cell and all visible portals (potential recursive for mirrors, teleporters, etc.).

Yes, that's what I meant. And I'm hoping I can layer a portal system on top of JavaFx2.1, so as to be able to have decent sized world models without overloading the scene graph.

I think others can answer this for you. remember prism implements javafx on ogl and d3d. java + ogl = ?As for integration, 2.0 will not have this, and I kind of address this point earlier, if you feel like you have to resort to using jogl, we have failed.

JavaFX 1.3 on Linux & Mac uses JOGL, I can prove it easily as I have found JOGL jars in the SDK and if I remove them, it does not work anymore I have a lot of source code in free open source projects and in commercial projects that uses JOGL with Ardor3D and 2 scenegraphs of mine, I'm not the only one who has a lot of legacy code using Java bindings of OpenGL (JOGL, LWJGL) and various scenegraphs. There are some OpenGL GUI libraries for Java but they are some noticeable drawbacks, Nifty GUI uses too much memory for example.

In my humble opinion, JavaFX 2.0 should at least provide a way of forcing the use of the OpenGL renderer to avoid conflicts between Direct3D and OpenGL at driver level (which means it should respect the flags about Direct3D/DirectDraw including "noddraw" and those concerning OpenGL). Moreover, it would be fine that Oracle developers working on JavaFX and Prism could work a bit together with the maintainers/contributers of Java bindings of OpenGL (both JOGL and LWJGL) to implement some interoperability. Using JavaFX 2.0 in my own projects would allow me to save a lot of time especially in commercial projects. Please let me know what could be done about these aspects.

I found a post from September which suggested that there might be a degree of JavaFx/Swing interoperability by making JavaFx a heavyweight component in swing. However this doesn't seem to have been mentioned since, so maybe it was too hard. However if true, I wonder if it would be possible to have a JOGL heavyweight component and a JavaFx heavyweight component at the same time. It might not be, if they are both using the same interface. Also what happens if two heavyweight components overlap and one has transparancy?

I found a post from September which suggested that there might be a degree of JavaFx/Swing interoperability by making JavaFx a heavyweight component in swing. However this doesn't seem to have been mentioned since, so maybe it was too hard. However if true, I wonder if it would be possible to have a JOGL heavyweight component and a JavaFx heavyweight component at the same time. It might not be, if they are both using the same interface. Also what happens if two heavyweight components overlap and one has transparancy?

Anyway, I signed up to receive email updates on the Beta programme.

In JavaFX 1.2, it was even possible to mix AWT with JavaFX, allowing to use GLCanvas and JavaFX nicely. In JavaFX 1.3, it was no more working and the remaining Swing interoperabily was not working with JOGL, only pure Swing things were drawn.

JavaFX 2.0 APIs can be used within a Swing application to provide a smoother transition to JavaFX. JavaFX components, such as WebView, will allow developers to extend existing Swing applications and gain experience with the new JavaFX APIs.

Also explains what is Prism:

Quote

All new fully hardware accelerated pipeline, project name "Prism". It will target DirectX on Windows platforms (both 32 and 64 bit) and OpenGL on other systems. It will also support software rendering when the graphics hardware on a system is not sufficient to support hardware accelerated rendering. It will also use an all-new windowing implementation instead of AWT for interfacing with the operating system.

I found a post from September which suggested that there might be a degree of JavaFx/Swing interoperability by making JavaFx a heavyweight component in swing. However this doesn't seem to have been mentioned since, so maybe it was too hard. However if true, I wonder if it would be possible to have a JOGL heavyweight component and a JavaFx heavyweight component at the same time. It might not be, if they are both using the same interface. Also what happens if two heavyweight components overlap and one has transparancy?

Anyway, I signed up to receive email updates on the Beta programme.

In JavaFX 1.2, it was even possible to mix AWT with JavaFX, allowing to use GLCanvas and JavaFX nicely. In JavaFX 1.3, it was no more working and the remaining Swing interoperabily was not working with JOGL, only pure Swing things were drawn.

I would rather see Swing entirely replaced with JavaFX then mix the two. Especially if JavaFX will be all hardware accelerated. Swing and Java2D were good for the time; but these days they look dated and there is a kind of typical look to them (you can usually always tell something is an applet when you look at it).

Swing is rather good at what it does though. It's still the best crossplatform widget toolkit out there, handily thrashing Qt and GTK in terms of look, feel, and ease of use (heh, mainly by being in Java in the first place).

All this touches on 3 questions I'd like to ask, though I'm not necessarily expecting answers on all of them ...

1. Does Prism have something akin to the JSL shading language in Scenegraph Effects, and if so, is it something there might be an API to access? WORA shaders sound good!

2. Is there a plan for some sort of bridge between Prism and AWT / Swing / Java2D (mainly thinking of Swing rendering through Prism)? I realise this is likely to be suboptimal - just thinking of the possibilities of incrementally updating larger projects - probably more of a general apps than games question.

3. When will there be (or is there and I've missed it) any clarification of what license all this will be released under? I'm hoping that it will all be licensed under the same license as OpenJDK - a two tier Java ecosystem doesn't seem to benefit anyone. Two things to my mind that will help drive adoption are to undercut the competition (and Flash is already free!) and to provide some sense that the platform has a future and things won't be discontinued at the drop of a hat (which, quite frankly seems to be most peoples' impressions of JavaFX so far!)

Best wishes, Neil

PS. For those who liked JavaFX script but aren't aware, it is still being developed as Visage (http://code.google.com/p/visage/) with an Android binding in the works.

Swing is rather good at what it does though. It's still the best crossplatform widget toolkit out there, handily thrashing Qt and GTK in terms of look, feel, and ease of use (heh, mainly by being in Java in the first place).

Cas

The problem is that Swing forces a threading model - you can only create, modify, and paint Swing components on the Event Dispatch Thread. This fundamental inflexibility is very frustrating and stops us from using it in games. It also makes code look butt-ugly since all swing code has to be run in an anonymous Runnable class and then have 'invokeLater' called on it.

Other problems:No browser componentSub-par text components. I wish they incorporated more of Netbean's improvements back into Swing. Many components are not extensible since there are lots of private and package-level fields which can't be seen by sub-classes.

The problem is that Swing forces a threading model - you can only create, modify, and paint Swing components on the Event Dispatch Thread. This fundamental inflexibility is very frustrating and stops us from using it in games. It also makes code look butt-ugly since all swing code has to be run in an anonymous Runnable class and then have 'invokeLater' called on it.

What about the OpenGL GUI's like FengUI and TWL ( http://twl.l33tlabs.org/ )? I thought that they make do without scheduling stuff on their own thread, because all openGL painting has to be done on the same thread (at least in LWJGL, I don't know about JOGL).

the API is outdated such as making much better use of enums over int constants and generics

good flowing layouts are difficult to build because they can only really be learnt through experience (and for me it always requires tonnes of JPanels and LayoutManagers)

Swing is not that easy to theme (especially if you want it to look good or fit a site-theme like you can with Flash, Silverlight or HTML inputs + CSS)

Swings cross-platform themes don't look that great (although this is mainly because everything else looks so much better)

Again, it's great for the time it's just that given that Java is the most popular language in the world I think it deserves something much better. Especially if you want to build an applet. Something on par with WPF would just be awesome!

the API is outdated such as making much better use of enums over int constants and generics

good flowing layouts are difficult to build because they can only really be learnt through experience (and for me it always requires tonnes of JPanels and LayoutManagers)

Swing is not that easy to theme (especially if you want it to look good or fit a site-theme unlike say Flash, Silverlight or HTML inputs)

Swings cross-platform themes don't look that great (although this is mainly because everything else looks so much better)

Again, it's great for the time it's just that given that Java is the most popular language in the world I think it deserves something much better. Especially if you want to build an applet. Something on par with WPF would just be awesome!

the API is outdated such as making much better use of enums over int constants and generics

good flowing layouts are difficult to build because they can only really be learnt through experience (and for me it always requires tonnes of JPanels and LayoutManagers)

Swing is not that easy to theme (especially if you want it to look good or fit a site-theme like you can with Flash, Silverlight or HTML inputs + CSS)

Swings cross-platform themes don't look that great (although this is mainly because everything else looks so much better)

Again, it's great for the time it's just that given that Java is the most popular language in the world I think it deserves something much better. Especially if you want to build an applet. Something on par with WPF would just be awesome!

My frustration is that Swing has been made inflexible so that it is thread-safe. To dictate that all UI code must run on a designated single thread seems silly. All that is really needed is a guarantee that UI code is run from one thread at a time. The actual thread it is run from shouldn't matter.

I wish there was a UI toolkit that had a single update(ArrayList<Event> events) method. Of course the method should only be called by one thread at a time, maybe it should be made synchronized. This method would process the list of events and run all updates. That way the UI toolkit could run on top of LWJGL or AWT or whatever without being tied to an event or threading model. The UI toolkit could be used with LWJGL where events are polled from any thread, or AWT where events are listened for on the event dispatch thread.

I do like the way all Swing painting is all done through the Graphics2D object. The GoldenT Game Engine devs even extended Graphics2D to draw using LWJGL. Pretty cool.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org