JavaFX 3D

[Roman Kennke]

Am Freitag, den 18.05.2012, 14:46 +0200 schrieb Mario Torre:
> Well, Collada *is* format independent and is a standard, that's
> why I suggested this, while what you mention is all proprietary
> and closed formats.
> 
> It was created exactly to solve portability issues between
> applications in the asset production pipeline, it makes
> sense to use it rather than re-inventing a new format,
> and would give us, for once, a nice way to use a standard,
> rather than a proprietary format.
> 
> Even in case you really want to reinvent the wheel, you can still
> benefit from a Collada exporter/importer that works for all the major
> modelling software, and still use your internal representation if it
> makes sense and if is more suitable/performing that the default
> collada xml document.
> 
> You can find more info here:
> 
> https://collada.org/mediawiki/index.php/COLLADA_-_Digital_Asset_and_FX_Exchange_Schema

I fully agree with this. Either make the collada (or another high
quality free-as-in-freedom -- if there exists one --) format the core
format for JavaFX 3D, or provide an importer/exporter for it in addition
to JavaFX format.

Roman

> Cheers,
> Mario
> 
> 2012/5/18 Kirill.Prazdnikov <kirill.prazdnikov at oracle.com>:
> >
> > 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
> >>
> >>
> >>
> >
> >
> 
> 
>