Well, the video board (Voodoo3 2000 to be exact) is a 16mb board. I
would think at least 8mb is available for textures, maybe more. So it
should definitely be able to fit a 4mb texture. I'm not all that
concerned because I really shouldn't be using a texture that big, but I
can definitely think of apps that would (large terrain textures).
I think it is a driver problem. As I mentioned, the textures were
sporadically in the wrong places, but random line geometry would also
show up. In other words, TOTALLY HOSED UP. ;-%
-----Original Message-----
From: Justin Couch [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 18, 2000 8:33 AM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] J3D 1.2beta DirectX on Voodoo3
"J. Lee Dixon" wrote:
> After debugging, I figured out that the culprit was that I had a LARGE
> (>4mb) texture. After replacing this texture with a much smaller one
> (256x128), texturing worked fine. Sounds to me like this board does
not
> like textures probably greater than 2mb or some other limit.
Funny you should mention this as I was involved in a conversation about
this today (well, actually more like an innocent bystander at the time).
As a big disclaimer, I'm relaying all of this second hand as I have
absolutely no background knowledge on the subject so I'll probably get
something wrong in the process. However my sources were Kevin Rushforth
(he's down under at the moment) and a guy that did a masters thesis on
texture mapping. So hopefully they know what they are talking about.....
It appears that a lot of boards don't release texture memory or attempt
to swap textures in/out of memory when the texture cache gets full. This
is actually a driver implementation problem and a small contribution
from Java 3D. What happens is some drivers fill the texture cache as you
request textures. Because video cards tend to use only video memory for
the cache, when this fills up (say 4MB of the 8MB video memory on your
card) the drivers fail to free memory when another texture is needed.
The visible result of this is that some objects don't get textures or
the wrong ones because the old ones are not swapped out of memory when
not needed.
>From the Java 3D perspective, it assumes that the boards handle their
own texture memory. J3D just requests textures to be loaded and assumes
the board looks after the rest of the details. For the card drivers that
properly manage their own memory resources (They use a concept of
virtual memory by automagically swapping stuff in and out of video
memory) you don't see these bugs. For cards that don't do anything (far
simpler to implement!) you see these problems. Now to solve this, Java
3D is going to have to be more intelligent about knowing what
implementation the driver supports and then do The Right Thing from
there.
So, the wash up of all this is that it may be a J3D problem, but
probably not, but J3D is helping to contribute to it.
--
Justin Couch Author, Java Hacker
http://www.vlc.com.au/~justin/ Java 3D FAQ Maintainer
http://www.j3d.org/ J3D.org The Java 3D Community Site
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
process data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
- Greg Bear, Slant
-------------------------------------------------------------------
========================================================================
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message "signoff JAVA3D-INTEREST". For general help, send email
to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
