I suspect some other problem as G450 certainly does support a depth
buffer. No modern card, as of '97 or so, lacks this support. Even
scene-capture cards, ala Kyro, perform depth-buffer operations.
-Original Message-
From: Octavian Nasarimba [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, Augu
Just make sure you aren't buying a gf4 MX, which is a cleverly disguised gF2 variant.
-Original Message-
From: ABAK Systèmes [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 04, 2002 2:39 AM
To: [EMAIL PROTECTED]
Subject: [JAVA3D] Java3d and Winfast TI4600
Hello,
We are on the point to
Its my understanding that although similar, the HLL is not transparent
between D3D9 with Shader Model 2.0 and OGL 2.0.
Certainly the amazing similarity of the vertex pipeline operations in
D3D8 with Shader Model 1.x and OGL extensions should persist.
The convergence of the pixel pipeline operati
DirectX 8.x interfaces dont like 24-bit mode display modes for windowed operation,
iirc. its generally safer to stay with 16 or 32-bit modes.
using the debug runtime and capturing debug output ( either with a debugger or a tool
like at sysinternals.com ) can help track things like this down.
t
correct, the SDK enables the REF device.
the REF device is different from the old RGB sw rasterizer.
the REF device is provided as a prototype and debugging tool only, is only part of the
SDK, is not part of the redist runtime, and is not allowed to be redisted onto
end-users machines.
it is
if you run DXDiag on the machine in question, do the display tests run?
> -Original Message-
> From: Fábio Magalhães [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 18, 2002 6:24 PM
> To: [EMAIL PROTECTED]
> Subject: [JAVA3D] Windows XP and Java 3D?
>
>
> Please, i have a problem wi
Title: RE: [JAVA3D] Java 3D 1.3 Beta 1 - frozen app
if you
are on 9x-based OS's, the killhelp utility in the SDK may provide relief from
reboots. I find in about 80% of the cases it works.
-Original Message-From: Jacob Marner
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, December 11,
Title: RE: [JAVA3D] Okay I have to ask
lets
take this off-line, as this is uninteresting for J3D.
-Original Message-From: Pierce, Gregory (TBS)
[mailto:[EMAIL PROTECTED]]Sent: Monday, November 19, 2001
2:03 PMTo: [EMAIL PROTECTED]Subject: Re:
[JAVA3D] Okay I have to ask
Hi
there is significant dis-information re the provenance of shaders in D3D.
no, we are not simply implementing what nVidia says.
earlier this year there was a long thread on the OGL mailing list about just this. I
am sure the archive of that mailing list will be informative, various folk were eat
here is one that is not currently a reason, but will likely be one in the future.
in the future as J3D adds shader support, that is going to be easier on D3D since D3D
shader versions for pixel shaders work across IHV hardware offerings; as in ps 1.1
will work on both gF3 and R8500.
Compare th
that
could be a config issue.
download the benmark sample from the nVidia developer site. if you dont
get around millions of polys/s - then your graphics hw setup isnt
correct.
-Original Message-From: Okdano
[mailto:[EMAIL PROTECTED]]Sent: Friday, November 16, 2001 5:04
PMT
I
think we need the authoritative answer from Sun engineers, and, respectfully,
not "I've heard this or that" level information. that doesnt do a service to the
original query.
-Original Message-From: Leyland
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, September 11,
2001 11:18 P
loaders should be independent of the rendering API that underpins J3D.
-Original Message-
From: Fredrik Andersson [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 03, 2001 4:08 AM
To: [EMAIL PROTECTED]
Subject: [JAVA3D] DirectX and OpenGL do they fit together?
Hello!
I have the jdk f
yes, please lets not devolve into an API-WARS discussion.
I would note that NT4 lacks other critical multimedia support, so its
likely your and your customers experience will be less than satisfactory
on that platform.
specifically, besides the D3D limitation ( DX3 interfaces, sw only )
DSoun
Kelvin produced a pretty accurate rendition of the deltas in the APIs.
in terms of driver support, we are not aware of where IHVs are not
providing DX drivers. not sure I can do anything about it other than
contact the IHV in question, but please send me private mail so I can
understand the issue
for
those of you using DX on W2K, there is a perf issue wrt to agp/vidmem vertex
buffers that can inhibit perf on W2K.
using
the DX 8 runtime with DX 8 DDI drivers, and updating to W2K SP2
addresses this issue.
W9x
does not suffer from this issue.
the
fixes are built-in to WXP.
as I recall screendoor was only used for the software
rasterizer...although its possible a really, really old card/driver
might do that.
> -Original Message-
> From: Kelvin Chung [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 20, 2001 10:38 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JAVA
WinCE in the near future will enable a version of D3D...but I dont know
if that will be sufficient to run J3D...
> -Original Message-
> From: Justin Couch [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 19, 2001 6:37 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JAVA3D] Java 3D in Mobile D
this would mean system.currenttimemillis is using windows timers, the
worst choice available on windows.
a better choice would be the multimedia timers.
perhaps the right folk could be pointed out, so this could be addressed?
> -Original Message-
> From: Fred Klingener [mailto:[EMAIL PR
just as an fyi to anyone running the DX version of Java3D on W2k, there
is a known kernel issue wrt to AGP memory that affects vertex buffer
performance.
installation of DX 8, DX 8 drivers, and WK SP2 will result in better
poly thruput.
nvidia has a sample, benmark5, that can be useful to verif
in addition to being pre-calculated, lightmaps and detail textures can
typically be lower res than the basemap since their purpose is to add
richness to the basemap.
if you have 256x256 base maps ( required for Voodoo1-3 compatability )
then 64x64 or 32x32 will suffice for the lightmap res. this
its
not the size of the texture. fetching texels is relatively
cheap.
its
the number of passes, and for how many pixels in the scene. consider that
each additional pass
burns fill-rate.
so if you do this
for an object that affects most of the pixels in the render-target, like
terrai
most
current hardware supports 2-3 texture stages.
geForce3 supports 4. Kyro I and Kyro II support 8.
expecting to use 10-30 textures per primitive is guaranteeing many
passes, 10-15 for most hardware, and poor performance.
-Original Message-From: Michael Nischt
[mailto:[EMAI
its almost assuredly dependant on the hardware. thats why zbuffer
formats are typically treated as opaque.
one tactic to use is to write some known values to the zbuffer by
rendering objects at certain known locations ( z=0, z=1, z=near-plane,
z=10, z=100, z=far-plane, etc ) and reading those val
me several times before I managed to get them to
> understand that only downloads "ie5setup.exe" which is only
> 499K and is
> NOT a full install of IE (I need to be able to install it on a machine
> that doesn't have Internet access to do some testing on a customer's
rosoft then later
> apologized, but to this date hasn't provided the information of how to
> actually download a full copy of IE. Customer service?
> Appreciation of
> a customer pointing out a bug?
>
> - John Wright
> Starfire Research
>
> Philip Taylor wrote:
> >
Phil
-Original Message-
From: Kelvin Chung [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 7:50 PM
To: Philip Taylor
Cc: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Fog (Linear) Differing Results
Hi Philip,
Great summary. The problem of non W-Friendly projection matrix
is fixed
there are two important bits here:
1) report all driver bugs
2) D3D fog
1) report all driver bugs.
this is SO important. if all ISVs dont report driver bugs they find, the
quality of the drivers never gets better. please take the time to report
these.
Most IHVs do have helpful d
new hardware over the next 2 years will be close in terms of horsepower
to making real-time raytracing possible.
nvidia has already demonstrated a life-game that mostly runs on the GPU.
not directly related to raytracing, but shows what sort of computations
can be done in shaders already.
>
DX 7 does provide stereo support.
it can be tested for ( in DX, not Java ) via the ddcaps.dwcaps2 caps
bits, when DDCAPS2_STEREO is set the ddcaps.dwSVCaps bit is enabled to
indicate the card supports stereo mode. The driver can do stereo in at
least one mode other than the current mode. The appl
and Voodoo cards up to Voodoo3 had a maximum texture size of 256.
this is a hw limitation, and in general the hw capabilities of each card
should be queried before assuming "it just works".
there also might be hw with min texture size limitations, as in an old
Matrox ( iirc ) card had a min text
usingnvidia's deronator for geforce? If not try it. It might
help. Personally I have the detonator for tnt2 and it works just fine.
--- Philip Taylor <[EMAIL PROTECTED]> wrote:
> known issue re performance.
>
> see http://msdn.microsoft.com/library/techart/d3dpu.htm
>
> don
known issue re performance.
see http://msdn.microsoft.com/library/techart/d3dpu.htm
dont know about mouse shadows.
-Original Message-
From: Adam Tegen [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 10, 2000 9:06 AM
To: [EMAIL PROTECTED]
Subject: [JAVA3D] Windows 2000 Performance.
H
while this is a cool feature, can be very useful, and ISVs want it all the
time - there is currently no hardware support.
this feature will not receive hardware support until 2002-2003 timeframe at
the earliest. This isnt cheap in terms of gates and does have an impact on
the cache architecture i
no, hardware support for texture compression and hardware support for
transform and lighting are 2 entirely separate pieces of silicon.
they have never been co-joined.
DX 6 supported texure compression, TnL wasnt supported until DX 7.
-Original Message-
From: Jimmy Talbot [mailto:[EMAIL
yes this card is one of the slow dogs.
RAGE PRO AGP is ~3 years old. RAGE PRO AGP is contemporaneous with Voodoo2.
It isnt as good at fillrate as Voodoo2, and doesnt do much multi-texturing.
Any card that cannot do significant multi-texture is old.
~2 years old but aging cards are: ATI RAGE 128,
iif this is the DX version of J3D, its possible this artifact in a window is
caused by the J3D runtime not using a clipper...
-Original Message-
From: J. Lee Dixon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 06, 2000 5:25 AM
To: [EMAIL PROTECTED]
Subject: [JAVA3D] ATI Rage 128 P
most cards, esp older cards, do better at 16-bit rendering than at higher
depths. never seen any card accelerate 8-bit rendering. 8-bit textures yes.
rendering no.
new cards with fill-rate to burn can deal with >16-bit rendering well.
RagePro AGP isnt bad amongst 1st gen consumer cards. Voodoo1,
I do believe that 3dfx has fixed their 256x256 texture size limit with cards
after Voodoo3.
bummer on the limit I agree, it forces itself into the art pipeline and
thats always a bad thing when technology dictates to the artists.
otoh they had the fastest texture loads, probably because they had
when parts of a triangle fall outside the viewing frustum they are clipped.
and extra verts are added at the edge of the frustum to complete the
triangle.
there is control over this behavior at the D3D level, eg you can
enable/disable clipping. its oftimes beneficial for the app itself to
perfor
Ignoring the Voodoo texture size limit, this discussion of texture
management is essentially correct in that it is up to the app to manage
texture memory.
When using D3D as the interface to the hardware its possible for the J3D
runtime to create "managed" textures on your behalf that then use the
Voodoo1,2,3 all have a 256x256 maximum texture size limitation. in hw, by
design.
I dont know if or how this is expressed thru the J3D API to J3D API users
for runtime discovery.
If you have the DX SDK, run the DX caps viewer tool. Check out the
capability bits for the HAL device for that card;
could be several reasons for this.
most obvious is bad batching behavior when calling DrawPrimitive. D3D can be
sensitive to batch size. worst case performance is drawing a single tri per
DP invocation.
there are a couple other possible issues. if the sun engineers responsible
for the d3d versio
erroneous article
>and for any concerns this may have raised.
>
>rgds
>JR
>
>
>-Original Message-
>From: Discussion list for Java 3D API
>[mailto:[EMAIL PROTECTED]]On Behalf Of Philip Taylor
>Sent: Monday, April 10, 2000 1:11 PM
>To: [EMAIL PROTECTED]
no.
these are separate issues.
the mini-GL issue is basically one of driver availability, eg some IHVs ( I
wont name names ) shipped enough GL to run Quake and its derivatives instead
of a full-blown ICD. to be fair, ICDs are not trivial to develop. ASFAIK,
the IHVs in question have ICDs either
I will speak up here, since that "article" purportedly quotes my email; I
wont call it journalism.
MS replied in a very public way about this last December, see our official
response at http://www.opengl.org/News/Archives99/Dec99.html under the
headline "The Final Word from Microsoft: OpenGL wil
its
possible the j3d runtime is leaving d3d in a bad state.
if you
have the dx sdk, run killhelp or pview from MSVC tools and kill the ddhelp
process.
another test is can you run a plain d3d application
after exit and/or kill ddhelp?
that
helps isolate whether its the j3d or the d3d runtim
our measurements show its possible for an app using D3D DX7 interfaces with
DX7 drivers to see from 20-30% improvement over using D3D DX6 interfaces
with DX6 drivers.
this depends on codepaths; with vertexbuffers and indexed lists being (
generally speaking ) the fastest paths. this also depends
what chipset is 3DLabs VX1? might be dated.
its likely that you would be better of using a more recent part.
like an nVidia card. geForce is available at under $500, so is the 1
generation back TNT2. TNT2 is likely to be heavily discounted now that its a
rev back and may be very close in price t
answers inline below
-Original Message-
From: Adam Belmont mailto:[EMAIL PROTECTED]]
Sent: Friday, October 01, 1999 11:38 AM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Performance issues. How to do it better?
It could also be your graphics card (Assuming you are on WinNT/98).
Some card
50 matches
Mail list logo
