Hi Jim,
We worked closely with Pavel to ensure 3D picking did extend nicely. I
believe the specification at this link is still up-to-date:
https://wiki.openjdk.java.net/display/OpenJFX/Picking3dAPI
- Chien
On 8/5/2013 3:44 AM, Pavel Safrata wrote:
On 1.8.2013 22:33, Richard Bair wrote:
How
On 1.8.2013 22:33, Richard Bair wrote:
How does that fit in with the 2D-ish picking events we deliver now? If a
cylinder is picked, how do we describe which part of the cylinder was picked?
Pavel or Chien will have to pipe in on this part of the question, I don't know.
Similar to 2D, the de
There is one Mesh per MeshView and MeshView is a Node, so we require a
node per mesh.
But, a mesh can have millions of triangles. As long as they all have a
common material...
...jim
On 8/1/13 1:38 PM, Richard Bair wrote:
I intend to agree with you that Node may be
> I intend to agree with you that Node may be "too big" to use as the basis
> for a 3D model's triangles and quads given that there can easily be millions
> of them and that manipulating or interacting with them on an individual
> basis is mostly unlikely. As you say, storing those models outside
> - What is the minimum space taken for "new Node()" these days? Is that too
> heavyweight for a 3D scene with hundreds or thousands of "things", whatever
> granularity we have, or come to have, for our Nodes?
I think each Node is going to come in somewhere between 1.5-2K in size (I
haven't m
models outside the
scenegraph seems to make sense...
-jct
-Original Message-
From: openjfx-dev-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Jim Graham
Sent: Thursday, 1 August 2013 05:58
To: Richard Bair
Cc: openjfx-dev@openjdk.java.net Mailing
Subject
I'm a little behind on getting into this discussion.
I don't have a lot of background in 3D application design, but I do have some low-level rendering
algorithm familiarity, and Richard's summary is an excellent outline of the issues I was having
with rampant mixing of 2D and 3D. I see them as
Hi August,
It is good to bring to back old memory occasionally. I've almost
forgotten ViewSpecificGroup in Java 3D. :-) Thanks for sharing your
proof of concept work in using Node.snapshot. We will take a closer
study of your work. It is possible that you might have uncovered new
area wh
Hi August,
John Yoon, Richard and I have a private discussion on the
possibility of avoiding "cloning" for your use case. We wonder do you
ever need to interact with the 3D scene via the various sub views? Or
these sub views are purely for viewing the 3d scene with different
cameras? If t
Yes, that is still the approach. The challenge isn't just strictly on
rendering. Let's take picking a "shared" node as an example. Imagine
this node is in a scenegraph viewed by more than 1 camera. The question
is where do we hang the set picked information. There is some level of
"cloning" nee
I thought the approach was not to have multiple parents, but to render into an
image.
On Jul 25, 2013, at 5:26 PM, Chien Yang wrote:
> We don't support sharable Node. Some one will have to do the cloning of the
> scenegraph, either the application or JavaFX. Now I may have opened a can of
> w
We don't support sharable Node. Some one will have to do the cloning of
the scenegraph, either the application or JavaFX. Now I may have opened
a can of worms. ;-)
- Chien
On 7/25/2013 5:20 PM, Richard Bair wrote:
Having to clone the nodes hardly seems like simultaneous viewing from different
Having to clone the nodes hardly seems like simultaneous viewing from different
points of view?
On Jul 25, 2013, at 5:17 PM, Chien Yang wrote:
> Hi August,
>
> We did talk through some use cases such as PIP and rear view mirror. You
> can do simultaneous viewing from different points of
Hi August,
We did talk through some use cases such as PIP and rear view
mirror. You can do simultaneous viewing from different points of view
into a single 3D scene via the use of SubScenes. The key point, as you
have clearly stated, is the need to clone the scene graph nodes per
SubSce
err... two identical groups of nodes**
On 7/25/2013 11:04 AM, Joseph Andresen wrote:
On 7/25/2013 10:37 AM, Richard Bair wrote:
Hi August,
"I think we already do multiple active cameras?"
More precisely: simultaneous viewing from different points of view
into a single 3D scene graph was me
On 7/25/2013 10:37 AM, Richard Bair wrote:
Hi August,
"I think we already do multiple active cameras?"
More precisely: simultaneous viewing from different points of view into a
single 3D scene graph was meant, i.e. several cameras are attached to one scene
graph.
A SubScene has exactly one
Hi August,
> "I think we already do multiple active cameras?"
>
> More precisely: simultaneous viewing from different points of view into a
> single 3D scene graph was meant, i.e. several cameras are attached to one
> scene graph.
> A SubScene has exactly one camera attached which renders the a
I hate to point out a small part of such an important reply but I must.
"before we could support DX 10, 11+, is to make it as easy as we can to write &
maintain multiple pipelines."
I cannot stress enough how important this is. I have been playing around
with extending prism to dx11 and before
And Voila!
Webstart fails again!
"Cannot launch the application…"
http://javafx.com";
codebase="http://www.interactivemesh.org/models/webstartjfx/";
href="fxTuxCube-0.6_FX3D.jnlp">
FXTuxCube 0.6
InteractiveMesh e.K.
FXTuxCube 0.6
Am 23.07.13 02:19, schrieb Richard Bair:
Alea iacta est!
I guess so, Google translate failed me though so I'm not sure :-D
http://en.wikipedia.org/wiki/Alea_iacta_est
" The phrase is still used today to mean that events have passed a point
of no return, that something inevitably will happen.
Java 8 (not JavaFX 8 specifically, although we're part of Java 8 so it also
applies to us) is not supported on XP. It may or may not work, but we're not
testing that configuration.
Richard
On Jul 22, 2013, at 5:41 PM, Pedro Duque Vieira
wrote:
> Hi,
>
> Java 8 doesn't support Windows XP, s
Hi,
> Java 8 doesn't support Windows XP, so in theory we can start taking
> advantage of DirectX 10+. At this time we are limited to OpenGL ES 2 for...
Richard did you mean Java8 won't run on Windows XP, or that 3D features
won't be supported in Windows XP?
Thanks, best regards,
--
Pedro Duq
Hi August,
I will attempt some kind of answer although what we end up doing has a lot to
do with where the community wants to take things, so some things we've talked
about, some things we haven't, and the conversation is needed and good.
> Whatever the use case will be JavaFX 3D will be measur
Feature freeze doesn't mean that there won't be changes -- just that every
major feature has an implementation and is ready for testing. Inevitably, as we
use new features, we'll find that there needs to be modifications or
clarifications. Once we ship, the possibility to refine is greatly reduc
I'm a little confused, are this changes still going to be present in
JavaFX8?
I thought JavaFX8 was feature freeze (1 month ago), but I see that some
major API discussions are still taking place.
Regards,
--
Pedro Duque Vieira
"What is the use case for rendering 2D pixel-coordinates-based shapes (or
even controls) within a 3D scene consisting of meshes constructed on 3D
coordinates of arbitrary unit?"
In my field of work (avionics displays),we might have a lot of use cases
for that. However, you also have that in video
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
Richard,
with all due respect, this is well known for a long time:
"Fundamentally, 2D and 3D rendering are completely different."
So, it isn't really suprising that issues concerning anti-aliasing and
transparency occur with the current approach providing 3D rendering
capabilities in JavaFX.
Basically the "embed and OpenGL rendering" would be treated as "rendering into
a texture using OpenGL and composite it into the scene", so it doesn't really
impact on either approach. Unless instead of giving you a surface to scribble
into using OpenGL, we gave you a callback where you issued Op
You just embed a SubScene within a 3D scene, or a SubScene3D within a 2D scene,
etc. So you can easily nest one rendering mode within the other -- where
"easily" means, that each SubScene / SubScene3D has the semantics of "draw into
a texture and composite into the parent scene".
Richard
On Ju
I'm not a 3D expert but my "gut" tells me that the two pipelines should remain
distinct as you say. I can't imagine the evolution of such different functions
converging in such a way where the semantic treatment of the two will coincide
in a clean, simple and unconfusing manner. That only seems
Does it need to be a separate class, can it not just be a setting on scene like
setRenderMode(3d)? Just thinking you may want a base 3d view for example but
then show 2d screens at times for settings, etc, so you could switch it on and
off.
I assume there's no way to do it pane by pane, so the
32 matches
Mail list logo
