I may be wrong, but...
I believe that setShapeRay will set the picking shape to a RAY (ie a
semi-infinte line. The definition of a Ray is a start point and a
DIRECTION - those are the two arguments).
What you think you are doing, and what in fact you want, is a
PickSegment. Is there a setShapeSegme
Just a quick thought - Do you have separate Appearance instances for the
two shapes? What you are describing would happen if they were in fact
sharing the same Appearance instance.
Lewis.
-Original Message-
From: Discussion list for Java 3D API
[mailto:[EMAIL PROTECTED] On Behalf Of Madet
Each node in a scene graph, including Shape3Ds, have capability bits
that you can explicitly set/unset. By default, you can hardly do
anything with a node once it is attached to a live scene graph, and this
allows the renderer to perform lots of optimisations.
Have a look at the capability bits def
hanks anyway
Dafna
- Original Message -
From:
Lewis Walker
To: [EMAIL PROTECTED]
Sent: Tuesday, October 07, 2003 3:02
PM
Subject: Re: [JAVA3D] removing
childs
Hi
Dafna,
You should be
able to remove the BranchGroup itself
Title: Message
Hi
Dafna,
You should be
able to remove the BranchGroup itself that is the ultimate parent of all of your
spheres. So - you are not removing all of the BranchGroup's children, but rather
you are removing the BranchGroup. That works fine. (As long as you have set the
relevant c
Get the Java3D documentation, and read about Picking. There are examples
in the standard Java3D demos. Essentially, you have to cast a ray from
the notional 'eye', through the mouse pointer and into your Universe.
Test for intersections with your Shape3Ds, and detect them. Choose the
one you want (
Just a quick thought - and not really a fix as such, but why create and
destroy the scene like this? The scene, and the Universe which contains
it is best thought of as pretty persistant, and independent of a
view/canvas if at all possible. Then all you have to do is attach and
detatch views with t
Title: Message
No - think about
the language of the thing - you want two different views of the SAME universe.
The Universe, after all, by defintion, contains everything - all of your
objects.
So - you want to
have two ViewPlatform nodes in your unique Universe. The ViewPlatform node
enca
Title: Message
Hi -
this is a manifestation of the problem I outlined before. Rotate before you
translate!
Lewis.
-Original Message-From: Discussion list
for Java 3D API [mailto:[EMAIL PROTECTED] On Behalf Of
Johannes NeubauerSent: 07 September 2003 20:06To:
[EMAIL PROTE
Title: Message
Excuse
the sketchy details, but I can point you in the right direction (I
think).
Ultimately, the translation / rotation etc. is encapsulated in a single
Transformation between Local and World Coordinate Systems. This single
Transformation, however, is obtained by traversing t
Title: Message
To be
honest, there's not enough to go on here. Forget for a minute the fact you're
doing this in Java3D, or on a computer, and get some pencil and paper out.
All it will come down to is working out the distance and the angle between your
object's pointing direction, and the
Title: Message
I
suspect the problem is that you are doing the update from your own thread. The
whole point of the behavior setup is that it lets Java3D execute code in the
right order and at the right time to make everything work nicely. Also - setting
up a behavior to execute every frame v
Also - shouldn't it be ElapsedFrames(0) to wakeup on the next frame?
Wouldn't ElapsedFrames(1) wakeup every other frame?
Lewis.
-Original Message-
From: Discussion list for Java 3D API
[mailto:[EMAIL PROTECTED] On Behalf Of John Wright
Sent: 25 August 2003 15:26
To: [EMAIL PROTECTED]
Subj
You just want to perform animation by moving the particle, is that
correct?
That's what TransformGroups are for. A TransformGroup specifies the
position, rotation etc. of its children. So just parent your particle
with a TransformGroup, and for every frame, set the translation
component of the Tran
Title: Message
Just a
quick thought - does your canvas ever have the focus? Sometimes it can be tricky
to get a component like that to get the focus - and if it doesn't, your key
events won't happen!
Lewis.
-Original Message-From: Discussion list
for Java 3D API [mailto:[EM
Title: Message
Hi.
You
are not calling super() in the constructor, so you are losing important
processing in the superclass constructor.
Lewis.
-Original Message-From: Discussion list
for Java 3D API [mailto:[EMAIL PROTECTED] On Behalf Of
Johannes NeubauerSent: 15 Augus
I'm not too surprised. The way to get around it is to store a UserObject
in the inner shape, to refer to the containing shape. That way, you can
examine the UserObject of the picked shape to determine the REAL picked
shape. If you see what I mean.
The idea is that UserObject is a payload that you
Maybe this is an annoying or naiive question, but..
Why not just have a singleton behaviour class?
Lewis.
-Original Message-
From: Discussion list for Java 3D API
[mailto:[EMAIL PROTECTED] On Behalf Of nagehan pala
Sent: 04 August 2003 15:21
To: [EMAIL PROTECTED]
Subject: [JAVA3D] killin
> OTOH, I'm trying to do graphical modeling of elastic deformations,
> so the more general cases may present a real challenge.
I'm doing something similar - I have a numerical integration step that
is run iteratively, and I have enough 'permanent' objects lying around
to use as the operands to the
The light should illuminate a background polygon as long as the Bounds
are set right. As for 'seeing' the light cone ... As you hint at, we
only see the light cone from a lighthouse because it is reflecting off
dust / moisture in the air as it goes on its way. So we aren't seeing
the light directly
I think the reason that the methods are destructive to the operands is
for performance. To be non-destructive would require the overhead of
creating a new instance of a Vector3D for each operation to store the
result. An approach worth bearing in mind for your own code - reuse the
same instances of
Title: Message
This
problem of performance is rather unavoidable, I believe. The performance of the
Java3D rendering is rather due to the fact that the underlying hardware is doing
the drawing to the screen. As such Java doesn't really get a look-in. Although,
as you know, it is possible to
Title: Message
Why
not just do it the easy way - set the components of the viewplatform
transform to match the aircraft's, every frame by using a behavior with a
wakeupOnElapsedFrames(0)?
Lewis.
-Original Message-From: Discussion list
for Java 3D API [mailto:[EMAIL PROTECTE
Just a thought - when you Maximise the Jframe, is the Canvas3D resizing
upwards too? If so then Java3D needs more memory from the Graphics card,
I believe, and depending on your card, along with the colour depth and
resolution of your desktop, etc, there may not be enough memory to
fulfil the reque
1
> Date: Sat, 12 Jul 2003 11:29:51 +0100
> From: Lewis Walker <[EMAIL PROTECTED]>
> Organization: Rhema Designs
>
> > We haven't seen this problem. There have been a lot of bug fixes
> > from Java 3D 1.3 to 1.3.1; you may want to try upgrading to se
, with different
materials. This seems ridiculously expensive, though, so I haven't done
it.
Anything to help would be VERY MUCH appreciated.
Thanks,
Lewis Walker
===
To unsubscribe, send email to [EMAIL PROTECTED] and
I have encountered EXACTLY the same problem. Firstly, I actually just
set the color components of the material. Then I tried using multiple
materials like you are doing.
It would very much appear to be a bug, since in my application, you can
make the color change 'flicker' on and off by rotating th
27 matches
Mail list logo