JavaFX 3D

Fri May 18 08:38:39 PDT 2012

I think some people are confusing public api of JavaFX with something a utility class would do.

Making a 3rd party tool (a Maya importer) part of public api is simply not a good idea, everything from version changes to compatibility issues, it is never ending. We do not want to stamp our api with a version of an importer. However, this actually has NOTHING to do with providing HIGH quality importers. A nice Maya importer as a sample would do just fine, and, in my opinion, a plugin for Maya would be much better. 

-Joe

----- Original Message -----
From: goddard at seznam.cz
To: richard.bair at oracle.com
Cc: openjfx-dev at openjdk.java.net
Sent: Friday, May 18, 2012 7:53:29 AM GMT -08:00 US/Canada Pacific
Subject: Re: Re: JavaFX 3D

Hi Richard,

thanks for the thorough answer and I'm sorry I unleashed the 3D content warriors :)

I agree with you that is better to get the concept (scenegraph) right for now then to spend time on content loaders. But I also see a need for it if JFX wants to be the next J3D-like thing, and I'm sure that it would be pity (not only for Oracle) to lose such thing.

I've played with 3D in JFX recently and I kind of struggled with it (not only because of the math ;) ), so I can testify what you wrote about the 2D/3D paths in JFX scenegraph. I think it'd be clearer to have Node3D/Shape3D than to switch the semantics based on "depthTest=true" or on using PerspectiveCamera (think about isometric engine - 2.5D, not necessarily  3D) in my code.

" (I hate the XXXBase naming convention, but I made that bed and now I have to lie in it :-))" - This makes me smile, as I'm an environment specialist on our project and sometimes it's difficult to live with my past decisions :)

Documentation is a must, and I hope there'll be some modern version of javadoc without frames and with fulltext search and both code and live examples. Kind of an interactive e-book (Josh Marinacci made one about HTML5 Canvas API). Actually this could be nice community project (among others), if coded under a license that Oracle has no problem with to accept.

Regards, Jiri

------------ Původní zpráva ------------
Od: Richard Bair <richard.bair at oracle.com>
Předmět: Re: JavaFX 3D
Datum: 18.5.2012 16:17:18
----------------------------------------
Potentially the same thing as webm? SVG we actually do use some portion of -- it
is more that we have not had any overwhelming demand to spend time on a full SVG
importer.

Richard

On May 18, 2012, at 7:01 AM, Dr. Michael Paus wrote:

> So what's the problem with open formats like SVG and Collada then?
>
> Am 18.05.2012 15:51, schrieb Richard Bair:
>> Perhaps I was too subtle :-). We would be happy to provide built in importers
if we get legal approval to do so. Like media (h264, webm) this is an area that
requires care.
>>
>>
>>
>> On May 18, 2012, at 5:46 AM, "Dr. Michael Paus"<mp at jugs.org>  wrote:
>>
>>> I completely disagree with that. High-quality importers for the most common
formats
>>> are simply a must. What is a framework good for if you don't get any data
into it?
>>> Or would you accept an image framework which just provides you with a pixel
buffer
>>> but lets you write your JPEG-decoder yourself?
>>> This mistake was already made in the past (with Java3D for example) and we
should
>>> not repeat that again. Actually this mistake has already been repeated
because JavaFX
>>> does not provide any importer for vector graphics (like SVG) for example.
>>>
>>> Am 18.05.2012 14:14, schrieb Kirill.Prazdnikov:
>>>> Then why not 3DSMax, why not Maya ?
>>>> Or procedural geometry and scene graph  ?
>>>>
>>>> I think the best API would be format-independent.
>>>> And Maya\Max importers in the samples...
>>>>
>>>> -Kirill
>>>>
>>>> On 18.05.2012 16:02, Mario Torre wrote:
>>>>> Why not use collada?
>>>>>
>>>>> Mario
>>>>>
>>>>> 2012/5/18 Richard Bair<richard.bair at oracle.com>:
>>>>>> Hi Jiri,
>>>>>>
>>>>>>> where's JFX heading regarding 3D API? Will there be for example support
for 3D content formats like OBJ?
>>>>>> Funny you should ask :-). Right now we don't have any concrete plans to
provide built-in format converters. Rather, we are thinking about providing a
flexible scene graph (Mesh, etc) and then it should be reasonably easy to write
most importers. It seems like it would be nice to have a collection of 3rd party
importers rather than bundling every format imaginable, and avoids any nasty
licensing issues.
>>>>>>
>>>>>> Regarding 3D API in general, Kevin, Jasper and I were just discussing
this yesterday afternoon and I would like to detail what the current thinking
is. This is in no way a final path but it is my current thinking.
>>>>>>
>>>>>> The JavaFX Scene Graph today is, for the most part, a true unified scene
graph between 2D and 3D. Every node has a 'z', we have 3D bounds objects and
internally we use a pick ray for doing the picking, etc. Mouse, Key, Drag, and
other events are exactly the same for both 2D and 3D scenes (or rather, are
equally applicable).
>>>>>>
>>>>>> However there are some aspects of every Node that are 2D-centric and
really provides surprising results in a 3D context. For example, in the
following scene graph I have three rectangles, r1, r2 and r3. Normally r1 would
be painted on the bottom, then r2, and then r3 on top (painters algorithm).
However (assuming my scene was created with "depthTest" enabled), since r2 has a
z value of -1 (closer to the camera), what actually will be rendered is r1, r3,
and then r2. So far so good, as this is normally how one would expect 3D to
behave.
>>>>>>
>>>>>> Rectangle r1 = new Rectangle(0, 0, 100, 100);
>>>>>> Rectangle r2 = new Rectangle(10, 10, 100, 100);
>>>>>> r2.setTranslateZ(-1);
>>>>>> Group branchA = new Group(r1, r2);
>>>>>> Rectangle r3 = new Rectangle(20, 20, 100, 100);
>>>>>> Group branchB = new Group(r3);
>>>>>> Group root = new Group(branchA, branchB);
>>>>>>
>>>>>> However, suppose that I now set opacity to .5 on branchA. Now what I will
get is r1 painted, and then r2, and then r3 on top! The Z value no longer works
the way it once did. This is because when you set opacity, we have to flatten
the scene graph down into an image which we can then composite into the rest of
the scene with the specified Z value. We have to do this in order to get the
right result for 2D, however this is the wrong behavior for 3D. Likewise, if you
set a blend mode on the group other than SRC_OVER we flatten, or a clip (that
isn't an axis&   pixel aligned rectangle, so as to get smooth anti-aliasing on
the clip), an effect (since these are by definition a filter operation on a
group there is no other way to do it and get the semantics right), or set cache
to true (clearly :-)). Some of these are obvious, but some are so non-obvious as
to be quite surprising and useless in true 3D programming. The current Scene
Graph was designed such that a 2D application could have 3D added to it, but it
wasn't deep down inside a 3D scene graph. Well, almost all of it is a true 3D
scene graph, but like I said in the introduction here, there are certain things
that are just 2D specific.
>>>>>>
>>>>>> Presently there is no good way to do 2D->3D->2D->3D integration either.
Imagine you have a game where the background is 2D, the game on top of it is 3d
(think angry birds where the birds&   boxes have depth to them) there is a 2D
overlay (score, etc) and on top of the 2D overlay is a 3D avatar of the current
character (bird). Right now, the only way to handle this is by toggling
depthTest to enabled/disabled on different branches of the scene graph and
manually partitioning Z space between the two 3D layers (since all 3D content in
the scene graph lives in the same Z space -- unless you set cache to true or one
of the other above properties!).
>>>>>>
>>>>>> One way to resolve this situation is to just live with these kinds of
mismatches. It makes the 3D scene graph use cases a bit more cumbersome, but you
have a single unified scene graph API. Another way to resolve this situation is
to factor the Node class such that we end up with a base class, Node, and
Node3D. The vast majority of the existing API on Node would be moved up to
NodeBase (I hate the XXXBase naming convention, but I made that bed and now I
have to lie in it :-)). Node3D and Node would then be subclasses and the 2D
specific APIs (effect, opacity, blendMode, etc) would be in Node but not Node3D.
Node3D might have other APIs such as "alpha" or "blending" -- similar to
"opacity" and "blendMode" except that they have different semantics and thus
probably should have different names to avoid confusion.
>>>>>>
>>>>>> We've gone back and forth on it, right now I prefer a unified scene graph
where we just add Shape3D nodes into the standard Scene Graph, and just document
on Node that certain APIs on node cause the node to "flatten" into an image, and
then just go from there. We have to document it anyway.
>>>>>>
>>>>>> So, still thinking about it :-)
>>>>>>
>>>>>> Richard
>>>>>
>>>>
>>>
>>> --
>>>
--------------------------------------------------------------------------------------
>>> Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
>>> For more information visit www.jugs.de.
>>>
>
>
> --
>
--------------------------------------------------------------------------------------
> Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
> For more information visit www.jugs.de.
>
>