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
ey are completed as well. DirectX adopts the latest and
> greatest in hardware much more quickly, but since java3d will be playing
> catch up anyhow, I'm sure that supporting only one graphics environment
> would free up man hours to get us better features now, no?
>
> Of course, I
point that the DirectX
runtime has always had better *general* performance on my system
(pIII600/Geforce2MX).
>From: Brad Christiansen <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: [JAVA3D] Geometry Types
>Date: Mon, 22 Apr 2002 10:02:07 +08
Hi,
I was wondering if anybody could point me at a good (detailed)
discussion of the advantages and disadvantages of the various geometry
array types. I would like info on things such as the relative
performance and memory usage of indexed versus non index, triangle fan
vs triangle strip etc.
I
17 matches
Mail list logo
