>On Thu, 6 May 2004 16:55:33 -0700, Chien Yang <[EMAIL PROTECTED]> wrote:
>Vaidya,
>Indexed geometry with the USE_COORD_INDEX_ONLY attribute set
>should avoid unindexify before rendering. I'm not seeing anything
>obvious in your code segment. Can you send me a test case ?
>
>thanks,
>
>- C
Vaidya,
Indexed geometry with the USE_COORD_INDEX_ONLY attribute set
should avoid unindexify before rendering. I'm not seeing anything
obvious in your code segment. Can you send me a test case ?
thanks,
- Chien.
N. Vaidya wrote:
Chien,
I'm using an IndexedTriangleArray with ByRef and UCIO bi
Hallo Ian,
your application runs in that exception, because the pick branch group
contains at least one shape, which hasn't set the necessary capabilities. I
took a look at your code and found following:
MouseOverCityBehavior behavior = new MouseOverCityBehavior(canvas, objRoot,
new BoundingSphere
Mark Hood wrote:
Date: Tue, 10 Jun 2003 13:02:23 +0200
From: Karsten Wutzke <[EMAIL PROTECTED]>
I'm delving into geometry compression for a university seminar. But I
still have some problems understanding the variation a the Huffman
coding used.
The source code for the GeometryCompressor
> Date: Tue, 10 Jun 2003 13:02:23 +0200
> From: Karsten Wutzke <[EMAIL PROTECTED]>
>
> I'm delving into geometry compression for a university seminar. But I
> still have some problems understanding the variation a the Huffman
> coding used.
The source code for the GeometryCompressor utilit
> Date: Thu, 27 Feb 2003 09:14:34 +0700
> From: Andrew Davison <[EMAIL PROTECTED]>
> > Use setCoordRefDouble or setCoordRefFloat instead.
>
> In response to:
> > > I want to update my geometry using coordinates stored in a Point3f[]
> > > array. But in the GeometryArray docs, it says that s
Dear All,
> Use setCoordRefDouble or setCoordRefFloat instead.
In response to:
> > I want to update my geometry using coordinates stored in a Point3f[]
> > array. But in the GeometryArray docs, it says that setCoordRef3f()
> > and getCoordRef3f() are deprecated. To be precise, it says:
> > ...
I
Use setCoordRefDouble or setCoordRefFloat instead.
Sean
> -Original Message-
> From: Andrew Davison [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 26, 2003 9:22 AM
> To: [EMAIL PROTECTED]
> Subject: [JAVA3D] Geometry Updater and Point3f[] arrays
>
>
> Dear All,
>
> I want to upd
Hi,
I think you can find some answer here :
http://www.j3d.org/implementation/properties.html
because some features are optional due compatibility.
I think Java3D 1.3 is mainly upon OpenGL 1.3...
Alessandro
- Original Message -
From: "AJCacho" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]
Thank you, Carlos,
I tried what you said here. But the situation hasn't changed.
I guess, normals for Cylinder and Cone are generated by default.
Frustrated with this.
Mingtian Ni
On Mon, 28 Oct 2002, Carlos D Correa wrote:
> Hi,
>
> I think this problem can be solved by setting the appropriate
According to the API, you need to use setInitialCoordIndex (not
setInitialVertexIndex) when the geometry is BY_REFERENCE.
Raffi
-Original Message-
From: Artur Biesiadowski [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 15, 2002 7:04 AM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D
Zak Nixon wrote:
> If my default length of my array, and the number of points do not
> EXACTLY match up, what then? I have extra positions in my array that
> will point to null.
>
> My question: How do I fill up these last positions with valid vertices,
> but doesnt distort/mess up my original ge
m: Discussion list for Java 3D API
> [mailto:[EMAIL PROTECTED]]On Behalf Of Gary L. Graf
> Sent: Wednesday, July 10, 2002 11:40 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JAVA3D] Geometry
>
> Zak,
>I'm not totally sure of which problem you're looking at, but Mercator
>
Of Gary L. Graf
Sent: Wednesday, July 10, 2002 11:40 AM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Geometry
Zak,
I'm not totally sure of which problem you're looking at, but Mercator
projections 'distort' the view only because the classic problem of how you
go
about proje
Zak,
I'm not totally sure of which problem you're looking at, but Mercator
projections 'distort' the view only because the classic problem of how you go
about projecting 3D into 2D. If you are placing objects, keep the mentality
in 3D (i.e., Latitude and Longitude). If you use those coordin
This type of exposure is what we are looking at for one part
of extensibility in Java 3D 1.4.
Doug.
>Subject: Re: [JAVA3D] Geometry Types
>To: [EMAIL PROTECTED]
>MIME-version: 1.0
>Content-transfer-encoding: 7bit
>X-Accept-Language: en-us, en
>Delivered-to: [EMAIL PROT
Doug Twilleager wrote:
> The big part that is miising is explicit low level buffer
> control - something like you suggested below. We could do
> it in the current system, but how we allocate buffers would
> be just a best guess. We would need new API to let the application
> help tell us which b
. This is one of
the possible additions we are looking at for 1.4. So, no there
in no reason we can't do it today, but we need some new buffer
control API's to complete the story.
Doug.
>Subject: Re: [JAVA3D] Geometry Types
>To: [EMAIL PROTECTED]
>MIME-version: 1.0
>Content-tran
Doug Twilleager wrote:
> Efficient usage of some of the new data movement extensions is
> also very
> application dependent. We are looking at ways to incorporate it into
> the API though.
It seems for me that java3d should get it for free. Normally, opengl
driver cannot do this automatically, b
The pinning ends up being essentially free. There is no impact on
performance.
You are correct. Nio becomes very usefull when the memory associated with
a primitive is controlled by native code, such as in some current nvidia
extensions.
Today we use vertex arrays with no extensions (or display
Doug Twilleager wrote:
> If all of your data is created in java land, then nio doesn't get you
> any faster. If you read the current specifications about JNI, it talks
> about the potential of data being copied when it is passed from java
> through JNI. There are API's in JNI that prevent such a
rce. Then NIO does not incur the cost of getting the
data from native spaces to java spaces. If your data is coming from
a native source, then NIO is a huge win for getting the data into Java.
Doug Twilleager
Java 3D Team
Sun Microsystems
>Subject: Re: [JAVA3D] Geometry Types
>
API <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: [JAVA3D] Geometry Types
>Date: Mon, 22 Apr 2002 15:47:46 +0200
>
>Chris Forrester wrote:
>
>>BYREF geometry notes:
>>
>>Using the BYREF flag indicates that the data used within the geometry is
&
>QuadArray -
>
>Mostly used in particle systems due to the billboard nature of a single
>quad, works nicely in OpenGL. DirectX has issues however, since it doesn't
>natively support quads and java3d must support this with
>DrawPrimitiveStrided. Tested and true, don't use this geometry type if you
Simeon H.K. Fitch wrote:
> Is there some other section of the site where this type of information would
> be more appropriate?
Possibly the architecture & implmentation area as these pieces of
information are specific to the Sun implementation of the spec. Another
implementation might do things
It may not be asked frequently but I do think most of us think about it
and wonder when we are first learning Java 3D. Chris's summary looks
fairly decent to me on quick glance but I'd be inclined to ask one of
the Sun people to review it before we commit it to a FAQ.
- John Wright
Starfire Resea
> Simeon H.K. Fitch wrote:
>
> > Justin, any chance of getting this info in the FAQ? It would
> certainly serve
> > as a seed for more information on the topic...
>
> Could do, but I've never seen it asked before so not exactly sure its a
> FAQ :)
I thought it sort of fell into the category of "
Simeon H.K. Fitch wrote:
> Justin, any chance of getting this info in the FAQ? It would certainly serve
> as a seed for more information on the topic...
Could do, but I've never seen it asked before so not exactly sure its a
FAQ :) I also have something that I've been writing up _very_ slowly in
Chris Forrester wrote:
> BYREF geometry notes:
>
> Using the BYREF flag indicates that the data used within the geometry is
> accessed through user arrays. Really the only way to go for volatile
> meshes,
> particle systems, bones animation, and multi/sub material objects, add two
> grades for me
>
> This list is from my personal experience and whatever i've read on the
> internet about the various formats. That said:
>
Thanks for sharing this with us.
Justin, any chance of getting this info in the FAQ? It would certainly serve
as a seed for more information on the topic...
Simeon
>
This list is from my personal experience and whatever i've read on the
internet about the various formats. That said:
IndexedQuad/Triangle/StripArray -
A poor option to use, since java3d must unindexify the data each frame to
send it to the card. But dead simple to work with, and the nicest form
Karl,
You use instances of TransformGroup to translate, rotate and scale all the
scenegraph nodes below your TransformGroup:
TG <-- call setTranslate / setTransform3D on the Transform3D and
TransformGroup
|
|
BG <-- add the BranchGroup to the TransformGroup (allows you to
detach/reattach)
|
|
Sh
d absolute paths
(C:\3DSMax..) are a pain. but rest looks fine :-)
greetings
-Michael Nischt
>
> >From: Michael Nischt <[EMAIL PROTECTED]>
> >Reply-To: Discussion list for Java 3D API <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: [JAVA3D] Geome
OORD_INDEX_ONLY combined with indexed arrays should be quick.
>From: Michael Nischt <[EMAIL PROTECTED]>
>Reply-To: Discussion list for Java 3D API <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: [JAVA3D] Geometry Update
>Date: Mon, 1 Apr 2002 23:06:19 +0200
&
SMax's
MutiMaterialsof a mesh insteadand I need to share the vertices for
effiecient vertex blending..greetings-Michael
Nischt>> Doug Twilleager> Java 3D Team>
Sun Microsystems>> >Subject: Re: [JAVA3D] Geometry
Update> >To: [EMAIL PROTECTED]>
>MIME-version:
: [JAVA3D] Geometry
Update
Ooh
this is a good one!
Since it is considered illegal to update the vertices
of by-ref geometry outside of a geometry updater it would be "bad" to do as
you have suggested. However, I am not sure if it would actually be a
problem if you do t
This will work in the current implementation, but it is technically
one of those "undefined behavior" cases.
Doug Twilleager
Java 3D Team
Sun Microsystems
>Subject: Re: [JAVA3D] Geometry Update
>To: [EMAIL PROTECTED]
>MIME-version: 1.0
>Delivered-to: [EMAIL PROTECTED]
>
Ooh
this is a good one!
Since
it is considered illegal to update the vertices of by-ref geometry outside of a
geometry updater it would be "bad" to do as you have suggested. However, I
am not sure if it would actually be a problem if you do this from a behavior
since I would expect that both
For the TRIANGLE_STRIP_ARRAY primitive you must set the stripCounts
with GeometryInfo.setStripCounts(). The stripCounts array is an array
of integers that indicate how many vertices are to be used for each
strip. For example, an array of {5, 4, 6} indicates that there are
three strips of length
If you did not use setCoordRefFloat() to set the coordinates, then doing a
getCoordRefFloat() will return null value. The get() values for Geometry
ByReference returns the pointer that has been set by the user. In your case,
only getColorRefFloat() and getCoordRef3f() will return non-null values
> Date: Thu, 10 May 2001 12:40:40 +0200
> From: Radoslaw Mantiuk <[EMAIL PROTECTED]>
>
> I have some problems with geometry compression. During decompression the
> exceptions java.lang.IllegalArgumentException and
> java.lang.ArrayIndexOutOfBoundsException appears.
> Most of the objects a
> > Hi,
> >
> > I have loaded an object (*.wrl file) using the VRMLloader.
> > I got its geometry like this
> >
> > GeometryArray childGeom = (GeometryArray) childShape.getGeometry();
> > // where childShape is its Shape3D
> >
> > Now in the VRML fil
Tina Manoharan Valappil wrote:
>
> Hi,
>
> I have loaded an object (*.wrl file) using the VRMLloader.
> I got its geometry like this
>
> GeometryArray childGeom = (GeometryArray) childShape.getGeometry();
> // where childShape is its Shape3D
>
> Now
, we
hope to add an API that gives user the control on this Space Vs
Performance tradeoff.
-Uma
Java3D Team
> MIME-Version: 1.0
> Date: Tue, 17 Oct 2000 14:36:39 -0700
> From: Vivek Verma <[EMAIL PROTECTED]>
> Subject: Re: [JAVA3D] Geometry By-Ref vs. Copying question
>
21 PM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Geometry By-Ref vs. Copying question
>My question is this;
>Is there any performance cost with the by-ref vs. copying in general,
>meaning just regular rendering without GeometryUpdaters?
Yes, using geometry by reference will preven
So how is the
skin and bones coming? When can I see that!?
Will
-Original Message-From: Shawn Kendall
[mailto:[EMAIL PROTECTED]]Sent: Monday, October 16, 2000 8:07
PMTo: [EMAIL PROTECTED]Subject: [JAVA3D]
Geometry By-Ref vs. Copying questionI am implementing
"Skin and Bones"
Hi Shawn,
>X-Accept-Language: en
>MIME-Version: 1.0
>Date: Mon, 16 Oct 2000 20:07:09 -0400
>From: Shawn Kendall <[EMAIL PROTECTED]>
>Subject: [JAVA3D] Geometry By-Ref vs. Copying question
>To: [EMAIL PROTECTED]
>
>I am implementing "Skin and Bones" animation in our system. To do this
>I have to
va 3D API
[mailto:[EMAIL PROTECTED]]On Behalf Of Carl Smotricz
Sent: Monday, August 21, 2000 9:05 PM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Geometry Utilities ?
Hi Hans,
At 16:58 21.08.00 , you wrote:
>Hi all,
>I would like to know if there are any methods right now to perform
&g
There is an extrusion in the package
com.sun.j3d.loaders.vrml97.impl;
You can download this from http://www.web3d.org/TaskGroups/x3d/sun/cvs.html
It is meant to be used with VRLM, but with some effort, you can use it also
for other purposes.
Good luck,
Pasi
-Original Message-
Hi Hans,
At 16:58 21.08.00 , you wrote:
>Hi all,
>I would like to know if there are any methods right now to perform
>extrusion or merging between two 3D Objects ?
As far as I know (but others probably know more), there is extrusion only
for text,
and merging only in terms of color blending to
Hi Shravan,
I experienced this problem in my first week working with Java3D.
Maybe my workaround is incorrect, but I think you have to create the
elements of your Color3f array and Point3f array individually first. The
getCoordinates and getColors methods do not allocate, they only assign the
v
You say there are more than 2000 vertices in the geometry, but you only
make an array to hold 2000? That could be a problem, though I think the
real problem is that you are not allocating the colors...
int i;
for(i=0; imailto:[EMAIL PROTECTED]]
Sent: Thursday, August 03, 2000 3:55 AM
To: [EM
Hi Ajit,
There are various reasons why your geometry might not be displayed. The most
common problem seems to be placing your view frustum in front of your geometry
so the objects are behind you (and hence "invisible"). There have been some
posts on this, but try moving your ViewPlatform away fr
53 matches
Mail list logo