Matti:
Yes, currently there is a bug where one needs to do a getImage() when
using byReference during offScreen rendering and readRaster. This bug will be
fixed for 1.2.1 Beta.
Could you please send us a test program for the exception that you are
getting with BufferedImage.TYPE
Malc:
This problem has been fixed in 1.2.1 Beta.
-Uma
Java3D Team
> MIME-Version: 1.0
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
> Date: Fri, 23 Jun 2000 18:24:01 +0100
> From: Malcolm Binstead <[EMAIL PROTECTED]>
> Subject: [JAVA
Java3D 1.2.1 will be available late summer.
-Uma
> User-Agent: Mozilla/5.0 (Windows; N; WinNT4.0; de-DE; m14) Netscape6/6.0b1
> X-Accept-Language: en
> MIME-Version: 1.0
> Date: Tue, 27 Jun 2000 09:58:48 +0200
> From: Andreas Ebbert <[EMAIL PROTECTED]>
> Subject: Re: [JAVA3D] Rendering problem
Raffi:
The orderedGroup problem is fixed in 1.2.1 Beta. Please send us a testcase
for the second problem so
that we can address it in the beta release.
Thanks
Uma
Java3D Team
> MIME-Version: 1.0
> Date: Fri, 7 Jul 2000 14:42:47 -0400
> From: "Kasparian, Raffi J." <[EMAIL PRO
The bug
4345505 - Multiple transparent objects do not render correctly
is fixed in the upcoming beta release.
-Uma
Java3D Team
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
>
Paul:
Problem #1 is fixed in the soon to be released Java3d 1.2.1 Beta. Do you
have a test case for the other 2 bugs? You also mention that you filed a
bug - do you have the bug id?
Thanks
Uma
Java3D Team
> X-Warning: VM230.AKH-WIEN.AC.AT: Host LYMNAEA.imc.akh-wien.ac.at claimed
to be akh-wien
Damir:
In your mail you mention that you use Java3D 1.3. Have you tried
Java3D 1.2? Also, there will soon be the release of Java3D 1.2.1 beta that
has some transparency bug fixes. If you have a test program that shows the
bug, please send it to [EMAIL PROTECTED]
Thanks
Uma
Java3D Team
Vivek:
The reason the Java3D implementation does not use display list for
by-ref geometry is because OpenGL display list memory is retained from one
call to another. When a Java3D app uses geometry by-reference the Java3D
implementation internally trades off performance for space. In future, we
Chuck:
Which platform are you running on?
-Uma
Java3D Team
> MIME-Version: 1.0
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
> Date: Thu, 19 Oct 2000 13:27:37 -0400
> From: Chuck Carpenter <[EMAIL PROTECTED]>
> Subject: [JAVA3D] G
Shawn:
Your usage is correct. When changing the validVertexCount it is
not necessary to change the initialVertexIndex unless you want to
change the starting index also. This bug is fixed in 1.2.1 beta:
4338910 - change in valid vertex count not reflected in rendering w
Shawn:
In the current implementation, Copy-mode may also use VertexArray if the
geometry is editable (i.e. any of the write capability bits are turned set
for the geometry). By-ref mode always uses vertex array.
Vertex Array still levarages the hardware T&L. The difference between
using Displa
Matthew:
Not all matching formats are retained as "by-ref" in the
implementation. Here are the combinations for which a copy will NOT be
made.
- Texture by reference and Y-up
Using texture by reference and Y-up format may reduce the
memory needed to store a texture ob
Kenneth:
Shawn is right. The setValidVertexCount() is broken for strips in 1.2.1
beta1 but will be fixed in beta2. The bug fix in 1.2.1 beta only fixes non-strip
geometry.
-Uma
> X-Accept-Language: en
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Date: Thu, 2 Nov 2000 12:44:
02 Nov 2000 14:33:36 -0500
> From: Kenneth Gordon <[EMAIL PROTECTED]>
> Subject: Re: [JAVA3D] setValidVertexCount
> To: Uma Sabada <[EMAIL PROTECTED]>, Shawn Kendall <[EMAIL PROTECTED]>
> MIME-version: 1.0
> Content-transfer-encoding: 7BIT
> X-Accept-Language:
In the case of IndexedGeometryArray, setValidIndexCount() and setInitialVertexIndex()
apply to the index arrays. For example, if your coordinateIndices array has a length
of 10, and the initialVertexIndex is 2 and validVertexCount is 5, then the
coordinateIndices array from 2 to 6 will be rendere
> 1) Do I have to use the updataData method if I use the setCoordinate, >
setCoordinates, setColor, setColors, ... methods ?
You don't have to use updateData() if you use setCoordinate(), setColor() etc.
updateData() method ensures that the coordinate change and color change happens as
one atomi
is 5, then the
coordinateIndices array from 2 to 6 will be rendered.
For GeometryStripArray, setValidVertexCount() and setInitialVertexIndex() are
ignored.
-Uma
Java3D Team
> Date: Fri, 10 Nov 2000 10:19:29 -0800 (PST)
> From: Uma Sabada <[EMAIL PROTECTED]>
> Subje
Sameer:
This bug is fixed in 1.2.1 beta2 (bug id 4378642). This bug
occurs when a shape's first geometry(index 0) in the geometry list is
null. You can workaround this bug temporarily, by making sure that
the Shape3D's first geometry entry in the geometry list is non-null.
-Uma
Java3D T
Qiuli:
This problem is fixed in 1.2.1 beta2. You could workaround the problem in one of 2
ways:
1. Disable compile - Disabling compile in 1.2.1 beta1 should still give you the
same performance as .compile() in 1.2 while allowing you to benefit from any bug
fixes in 1.2.1 beta1.
2. Rearrange
Bob:
There is a bug fix in 1.2.1 beta that was omitted in the README
that could fix your problem:
4345505 - Multiple transparent objects do not render correctly
I verified that 1.2 FCS behaves incorrectly for this case, but this case
works on 1.2.1 beta.
For the second part of your que
Kenneth:
Your interpretation is correct. In Java3D 1.2 there was bug that
prevented it from working correctly. This bug is fixed in the soon to be
released 1.2.1 beta1. For your reference, here is the bugid and description.
4338910 - change in valid vertex count not reflected in renderin
David:
There are some alternateapprarance bug fixes in the beta2 release.
However, we do need a testcase or you app inhouse to confirm that your
specific bug has been addressed.
-Uma
> MIME-Version: 1.0
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By
Adam:
This is a bug. For your reference, bug 4397076 has been filed.
-Uma
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> Importance: Normal
> Date: Fri, 8 Dec 2000 18
What version of Java3D are you using? setValidVertexCount for TriangleArray
should work correctly in 1.2.1 beta1.
-Uma
> MIME-version: 1.0
> Date: Tue, 12 Dec 2000 01:54:06 -0500
> From: David Ko <[EMAIL PROTECTED]>
> Subject: [JAVA3D] TriangleArray
> To: [EMAIL PROTECTED]
>
> Are there bugs as
Harry:
Have you tried using 1.2.1 beta1? Its not clear from you email if you
are using compiled mode. In 1.2.1 beta1, multiple geometries should work as
expected except for one bug (applicable only in compile mode) where it throws an
exception if first geometry in the list is null. This b
Jean-Marie:
There is internal bookkeeping needed to render each Shape3D which
results in increase in memory footprint and affects performance when there are
several thousand dynamically changing Shape3Ds in a scene. There are couple of
ways to reduce the number of Shape3Ds in a scene:
Lee:
This bug is fixed in the FCS release.
-Uma
> MIME-Version: 1.0
> Date: Thu, 22 Feb 2001 16:02:45 -0500
> From: "J. Lee Dixon" <[EMAIL PROTECTED]>
> Subject: Re: [JAVA3D] LocalToVworld transform and deriving from Node
> To: [EMAIL PROTECTED]
>
> I had already tried using an empty Sha
Roy:
Its a bug in Java3D. For you reference, bug 4418472 has been filed.
-Uma
Java3D Team
> MIME-version: 1.0
> Content-transfer-encoding: 7BIT
> X-Accept-Language: en
> Date: Thu, 22 Feb 2001 19:43:09 -0500
> From: Roy Duffy <[EMAIL PROTECTED]>
> Subject: [JAVA3D] OrientedShape3D bug
>
This bug is fixed in the FCS release.
-Uma
> X-Accept-Language: en
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Date: Mon, 26 Feb 2001 13:27:43 +0100
> From: Karsten Fries <[EMAIL PROTECTED]>
> Subject: [JAVA3D] What's the meaning of this exception??
> To: [EMAIL PROTECTED]
>
> Hi th
"Daniel Selman" <[EMAIL PROTECTED]>
To: "Uma Sabada" <[EMAIL PROTECTED]>
Cc: "Java3D" <[EMAIL PROTECTED]>
Subject: 1.2B1 ColoringAttributes problems?
Date: Sun, 23 Jan 2000 16:50:41 -
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: No
Lining:
byReference and Yup are what is needed to prevent an internal
copy. However, this does not guarantee that Java3d will not make
a copy. In any case, the performance of the byreference case
should be equal to or better than the by-copy case. Please send
Java3D allows node component objects (such as coloring attributes in
your test program) to be shared between multiple views/universes. You
have pointed out a bug in our implementation and will be fixed in
beta2.
-Uma
Java3D Team
- Begin Included Message -
>From [EMAIL PROTECTED] Mon Fe
Pasi:
This could be a different problem. Are you using 2 universes? Please
send us a test program.
Thanks
Uma
Java3D Team
- Begin Included Message -
>From [EMAIL PROTECTED] Thu Feb 10 07:26:05 2000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Nor
Please send us a test program for this bug.
Thanks
Uma
Java3D Team
- Begin Included Message -
>From [EMAIL PROTECTED] Fri Feb 25 21:28:11 2000
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1
Zanardi:
Please send us a test case.
Thanks
Uma
Java3D Team
- Begin Included Message -
>From [EMAIL PROTECTED] Tue Mar 7 22:47:02 2000
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date: Tue, 29 Feb 2000 04:46:16 EST
From: Christian Zanardi <[EMAIL PROTECTED]>
Su
Thank you for reporting the bug. This bug will be fixed in the FCS
release of Java3D.
-Uma
Java3D Team
- Begin Included Message -
>From [EMAIL PROTECTED] Thu Mar 16 07:11:00 2000
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.
Please send us a test program.
Thanks
Uma
Java3D Team
- Begin Included Message -
>From [EMAIL PROTECTED] Tue Mar 14 01:50:55 2000
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Date:
Please send us a test program for the bug.
Thanks
Uma
Java3D Team
- Begin Included Message -
>From [EMAIL PROTECTED] Fri Mar 17 17:23:17 2000
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Date: Thu, 16 Mar 2
Dean:
You have found a bug in Java3D. Please send us a test program.
Thanks
-Uma
Java3D Team
- Begin Included Message -
>From [EMAIL PROTECTED] Tue Apr 11 21:07:33 2000
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importan
Olivier:
Yes, the print statements are from Java3D and will be removed
in the next release. Also, could you please send us a test
program for the exception?
Thanks
- Uma
Java3D Team
- Begin Included Message -
>From [EMAIL PROTECTED] Wed Apr 12 23:27:39 2000
MIM
There are new APIs in 1.2 that allows you to set a bigger
GeometryArray and use only part of it.
For Copy case:
GeometryArray::setInitialVertexIndex()
GeometryArray::setValidVertexCount()
For By Reference Case:
GeometryArray::setInitialColorIndex()
GeometryArray::
Duncan:
You are setting the capability bits as part of the vertexFormat and this
is incorrect. vertexFormat only specifies what components of the vertex (such
as texture, color etc..) are present. use setCapability() method to set the
capability bits.
The GeometryArray doc cle
Andrian:
This sounds like a bug. Please send us a test case.
Thanks
-Uma
Java3D Team
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
> Date: Tue, 16 May 2000 14:43:23 +1000
> Fro
Dani:
Please send us a test case so that we can take a look.
Thanks
Uma
Java3D Team
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Date: Fri, 19 May 2000 12:07:19 +0200
> From: Daniel del Río <[EMAIL PROTECTED]>
> Subject: [JAVA3D] Bug in Texture
> To: [EMAIL PROTECTED]
>
> Hi everyon
Thomas:
Please send us a test case so that we can take a look.
-Uma
Java3D Team
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> Importance: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
> Date: Fri, 19 May 2000 15
iel del Río" <[EMAIL PROTECTED]>
> MIME-Version: 1.0
> To: Uma Sabada <[EMAIL PROTECTED]>, Discussion list for Java 3D
<[EMAIL PROTECTED]>
> Subject: Re: [JAVA3D] Bug in Texture
>
> Here is the test...
>
> Thanks.
>
>
> > Dani:
> >
> >
Raffi:
Java3D currently does not provide a mechanism to do a partial update of texture
images. Using ImageComponent with the flag byReference and yUp is one way of
achieving what you want. Using byReference enables you to change a part of the
image on the application side. The advantage of us
Dave:
You have uncovered 2 bugs in Java3D and both of which will be fixed in 1.2.1
beta.
Bug1: TYPE_3BYTE_BGR does make a copy on windows, the way to avoid copy
on windows is to use TYPE_CUSTOM
Bug2: ByReference texture and raster does not work with immediate mode
> 1. If you have two shapes which have different appearences, but the same
> material, do you sort and then only send the material once if possible?
Yes, Java3D maintains dirty bits for material, point/line/polygon attrs,
coloring attrs and transparency and sends these attributes down only when
t
Brad:
You have discoverd a bug in 1.2.1 (beta2 and FCS version). I have filed
a bug
4427436 - Alternate Appearance may throw exception when scoped to a
sharedGroup.
This bug occurs when you have a scenegraph of form
BG0
/ \
/ \
/ \
TG1 BG1
\
Paula:
Are you using 1.2.1? Using your code sample as guide, I modified
the texture program under demo/java3d/TextureTest/TextureImage and it works
correctly. I have attached the modified program.
-Uma
Java3D Team
> MIME-version: 1.0
> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.26
In 1.2.1, setValidVertexCount() and setInitial{Vertex,Coord,Color,
Normal,TexCoord}Index are used only for GeometryArray. They are ignored for
Strips and Indexed Geometry Array.
setValidVertexCount() is applicable for both by-ref and by-copy geometry
array.
For by-ref geometry, setInitial{Coord,
Alex:
You have uncovered a bug in Java3D. A bug 4447897 has been filed to
track this problem and will be fixed in the next release.
-Uma
Java3D Team
> MIME-Version: 1.0
> Content-Disposition: Inline
> Date: Sun, 15 Apr 2001 14:26:33 EDT
> From: Alex Terrazas <[EMAIL PROTECTED]>
> Subjec
Lee:
You have discovered a bug with OrderedGroup.moveTo. A bug 4447901 has
been filed to track this problem and will be fixed in the next release. Also
note that depth-ordered transparency will be supported in Java3D 1.3.
-Uma
Java3D Team
> MIME-Version: 1.0
> Date: Thu, 19 Apr 2001 1
>
> What exactly should I do to update image on Raster ?
>
> 1) Should I set it's ImageComponent2D to null and back to same IC after
> update ?
> 2) Should I reuse same ImageComponent2D, use two (kind of double buffer)
> or create new one every time ?
Both methods work. But, in the first case, yo
>
> These are the questions mostly to Java3D developers but if anybody else has
> the answers I will be grateful to know them.
>
> 1. Does setting the vertex format of geometry as BY_REFERENCE really help
> save memory? The memory usage does not change if we use regular methods but
> Ref ones. Whe
Joachim:
Please send us a test program.
-Uma
Java3D Team
> MIME-Version: 1.0
> Date: Thu, 10 May 2001 10:42:34 +0200
> From: Joachim Diepstraten <[EMAIL PROTECTED]>
> Subject: [JAVA3D] Problems with more than one locale
> To: [EMAIL PROTECTED]
>
> Hi
>
> Yep it's me again with another n
> 1. Does by-ref geometry get sent over to the card every frame even if a
> GeometryUpdater has not been used to change it?
> 2. If so, why? Since it the only time you are supposed to update the
> geometry is inside the GeometryUpdater, which you have knowledge of. Is it
> because you don't put
Dave:
> 1. If we use a geometry updator and use the set() methods on non-ref
> geometry, but only update the normals and coords does the texcoords and
> colors still get sent to the card that frame?
Yes. All components (changed or not) will be sent down every frame. Typically,
there are several
This problem :
4467858 - GeometryArrayRetained getDlistTimeStamp() throws
ArrayIndexOutOfBoundsException
is fixed in the soon to be released _02 patch.
-Uma
Java3D Team
> Delivered-To: [EMAIL PROTECTED]
> X-Accept-Language: fr
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Date: Tue
J.D:
There is no reason why the light scenegraph case should be faster than
the heavy scenegraph case. Would it be possible to give us a test case?
Thanks
-Uma
Java3D Team
> Delivered-To: [EMAIL PROTECTED]
> MIME-Version: 1.0
> Date: Tue, 3 Jul 2001 22:18:40 +0200
> From: Joachim Diepst
OpenGL does not support global alpha(although there is an extension
GL_SUN_global_alpha supported on Solaris that does this). So, in Java3D, When
color_4 vertex data is present and transparency is turned on, the vertex alpha
value is multipled with the transparency value to get the correct renderi
Raffi:
I am able to reproduce the bug with the _02 patch. The bug happens when
a Shape3D under a sharedGroup is "made live" and a group(direct or indirect
parent) above this Shape3D is scoped to a light/fog/mclip/alternateappearance.
There are a couple of workarounds for this bug:
>From the line #, looks like you are using Java3D 1.2, upgrading to Java3D 1.2.1
will fix the problem.
-Uma
> Delivered-To: [EMAIL PROTECTED]
> X-Sender: ceetm2@odin
> MIME-Version: 1.0
> Date: Sat, 4 Aug 2001 14:05:58 +0100
> From: Tina Manoharan Valappil <[EMAIL PROTECTED]>
> Subject: Re: [JA
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
In Java3D 1.2.1, Java3D will unindexify IndexedGeometryArray before rendering.
In Java3D 1.3, we have a new API - GeometryArray.USE_COORD_INDEX_ONLY which when
specified as a component of vertexFormat will not unindexify but use
glDrawElements() instead and this mode is acceleared on many graphics
Java3D does not depth sort the Shapes rendered in immediate mode. It would be
application's resposibility to render them in the right order.
-Uma
Java3D Team
> Delivered-To: [EMAIL PROTECTED]
> X-Warning: VM230.AKH-WIEN.AC.AT: Could not confirm that host [149.148.62.15]
is akh-wien.ac.at
> X-Ac
J.D:
This bug is fixed in 1.2.1_02
4465145 - setFog(null) in immediate mode causes NullPointerException
Could you please verify that you are using 1.2.1_02?
-Uma
Java3D Team
> Delivered-To: [EMAIL PROTECTED]
> MIME-Version: 1.0
> Date: Fri, 21 Sep 2001 11:50:16 +0200
68 matches
Mail list logo
