Hi August, I thought I had gotten to that in the summary of the email, but maybe you can help me learn what I don't yet understand about the space so that we can define what we're doing better.
> Instead I propose that we keep the integrated scene graph as we have it, but > that we introduce two new classes, Scene3D and SubScene3D. These would be > configured specially in two ways. First, they would default to depthTest > enabled, scene antialiasing enabled, and perspective camera. Meanwhile, Scene > and SubScene would be configured for 2.5D by default, such that depthTest is > disabled, scene AA is disabled, and perspective camera is set. In this way, > if you rotate a 2.5D shape, you get perspective as you would expect, but none > of the other 3D behaviors. Scene3D and SubScene3D could also have y-up and > 0,0 in the center. > > Second, we will interpret the meaning of opacity differently depending on > whether you are in a Scene / SubScene, or a Scene3D / SubScene3D. Over time > we will also implement different semantics for rendering in both worlds. For > example, if you put a 2D rectangle in a Scene3D / SubScene3D, we would use a > quad to represent the rectangle and would not AA it at all, allowing the > scene3D's anti-aliasing property to define how to handle this. Likewise, a > complex path could either be tessellated or we could still use the mask + > shader approach to filling it, but that we would do so with no AA (so the > mask is black or white, not grayscale). > > If you use effects, clips, or blendModes we're going to flatten in the 3D > world as well. But since these are not common things to do in 3D, I find that > quite acceptable. Meanwhile in 3D we'll simply ignore the cache property > (since it is just a hint). > > So the idea is that we can have different pipelines optimized for 2D or 3D > rendering, and we will key-off which kind to use based on Scene / Scene3D, or > SubScene / SubScene3D. Shapes will look different depending on which world > they're rendered in, but that follows. All shapes (2D and 3D) will render by > the same rules in the 3D realm. The idea is to give a very well defined way in the API to separate "real 3D" from 2.5D scenes. Because the needs of the two different worlds are quite different, it makes sense to give them well defined boundaries. This would allow our rendering code to render the same primitive (a Rectangle, for instance) differently depending on whether the developer was assembling a 2D/2.5D application or a 3D application. We could decide that depthBuffer enabled is that flag, although some "real 3D" apps might want to disable the depth test for some portion of their scene, or maybe disable the depthBuffer entirely, and if they do I'm not sure that that alone would mean that we should switch rendering modes? > You are talking a lot about implementation details. But, what I really miss > is a commitment to precisely specified MISSION and OBJECTIVES concerning 3D > support in the JavaFX API. Our initial goal with 3D is to support enterprise 3D use cases. So for example, 3D representations of human anatomy for medial devices, or viewing mechanical devices or drawings in 3D (like a CAD viewer). From before 1.0 shipped we've had conversations with customers who were building software that needed these capabilities. We want to be able to import and represent COLLADA files. Our initial goal is not game development. That being said, we don't want to absolutely preclude game development from being possible, either in the future as part of the platform if it turned out that we got used for that, or as a 3rd party add-on to JavaFX. We're just not likely to devote engineering time to adding features specifically designed for gaming. (Although it seems to me that many of the things games want to do are also the things enterprise use cases want to do -- animations, quality rendering, performance, etc). Richard
